コンテンツフロントマター：フィールドとSEOメタデータ

フロントマターは、読者がひとつのブロックとして見ることはなく、すべてのパブリッシングシステムが依存するページ要素です。これはドキュメントにアイデンティティ、レンダリング契約、検索プレビュー、所有権記録、日付、およびスキーマ入力を提供します。壊れたフロントマターは、誤ったテンプレートの選択、正規URLの競合、作成者の喪失、またはページと矛盾するマークアップの出力を引き起こす可能性があります。

ライブ標本はドキュメントレベルのレコードであり、コードとして表示されます。これはフロントマターが装飾的な本文ボックスになってはならないためです。

+++
entity = "guide-how-to"
id = "reset-api-key"
title = "How to Reset an API Key"
seoTitle = "How to Reset an API Key Safely"
description = "Reset an API key safely, replace it in every dependent service, verify the new credential, and revoke the exposed key without avoidable downtime."
url = "/academy/reset-an-api-key/"
image = "/images/academy/reset-api-key.png"
imageAlt = "API key settings with the Rotate key action highlighted"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "reset API key", "rotate API key", "revoke API key" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/reset-an-api-key/"

[[faq]]
question = "Does rotating an API key revoke the old key immediately?"
answer = "Not necessarily. Confirm the provider's rotation behavior before changing dependent services."
+++

フロントマターが存在する理由

読者にとって、メタデータは不確実性を低減します。正確なタイトルは範囲を設定し、有用な説明はクリックを獲得し、アイデンティティは主張に説明責任をもたらし、日付は情報が古くなっている可能性を明らかにします。これらのシグナルは弱いコンテンツを補うことはできませんが、それらが欠けると読者は推測せざるを得なくなります。

機械にとって、フロントマターは推論を名前付きの値に置き換えます。テンプレートは、散文をスクレイピングすることなく、フィールドをブラウザタイトル、正規リンク、人物レコード、日付、フィード、インデックス、JSON-LDにマッピングします。これが機械抽出可能性です。重要な事実は一貫した場所と型を持ちます。

エレメント作成ルールに従ってください。メタデータはドキュメントレベルに属し、読者向けの要素は本文に属します。署名行はフロントマターからレンダリングされる場合がありますが、その権威ある識別子はそこに残ります。

使用すべき場合と使用すべきでない場合

インデックス可能なすべてのページには、アイデンティティ、レンダリング、ルーティングのために1つのフロントマターレコードが必要です。ドラフトはプロダクションに入る時点で必要です。これにより検証が早期に失敗できるようになります。

記事の事実をフロントマターに隠してはいけません。製品の制限事項、安全に関する警告、アフィリエイト開示、方法、ソースは、読者が評価できる場所に表示されたままにしておく必要があります。構造化された値が開示の代わりになることは決してありません。

ほぼ正しいがために最も大きな損害が発生します。

• 独立して変化するナビゲーションラベル、キャンペーンコピー、ソーシャルキャプションはチャンネル設定です。titleを過剰に使用しないでください。
• サイト全体で共有される組織の事実は、サイトの組織レコードに属し、乖離が生じる可能性のある各ページにコピーしてはいけません。
• 質疑応答セクションは、同じコンテンツが表示可能にレンダリングされる場合にのみ[[faq]]に属します。非表示のスキーマのみのFAQは無効です。
• トピックラベルはtaxonomyに属します。ドキュメントの投稿タイプを識別するentityを置き換えてはいけません。
• リダイレクトはルーティング設定または承認されたエイリアスフィールドに属します。canonicalは推奨バージョンを識別しますが、訪問者をリダイレクトしません。

配置場所

フロントマターは最初のバイトの+++で始まり、本文前の対応するフェンスで終了します。見出し、コメント、注記、ショートコード、メタデータブロックが先行してはいけません。TOMLフィールドと配列はその1つのレコード内に属します。

本文は閉じフェンスの後に始まります。フロントマターはH1とイントロダクションの間、スクリーンショットの横、コンポーネント内、または末尾に配置することはできません。バイトオーダーマークや迷子のコメントは認識を妨げる可能性があります。重複キー、YAMLフェンス、2番目のブロックは無効です。

構造

レンダリングされた凡例はページ内に残り、画像から独立して読み取り可能かつ翻訳可能な状態を保ちます。

1. 境界： 開始と終了の+++フェンスが唯一のメタデータ領域を定義します。
2. アイデンティティ： entity、id、type、urlがシステムにドキュメントが何であり、どこにあるかを伝えます。
3. 発見： title、seoTitle、description、image、imageAlt、keywordsがプレビューと検索をサポートします。
4. 来歴： date、updated、author、reviewedByが誰に責任があり、いつ作業が有効に変更されたかを示します。
5. 分類： taxonomyは、アイデンティティを再定義することなく、ページを制御されたトピックコレクションに参加させます。
6. 重複制御： canonicalは、同等のバージョンが他の場所で到達可能な場合に、優先される公開URLを指定します。
7. 構造化コレクション： 各[[faq]]は、表示レンダリングとスキーマのために1つの型付き質疑応答レコードを作成します。

デザイン例

フロントマターにはデータ契約のバリアントがあり、視覚的なスタイルはありません。スクリーンショットはソースレコードと、それに対応するプレビューまたは署名行をペアで示します。

パラメータ

これらは、パーサーがより多くを受け入れても、編集上の制限です。「条件付き」とは、記載された条件が真の場合に必須であることを意味します。

フィールド別リファレンス

このリファレンスは、各フィールドの公開契約を定義します。「必須」とは、フィールドまたはその有効な導出値が欠落している場合、検証が公開を停止すべきであることを意味します。「条件付き」とは、画像がレンダリングされる、独立したレビューが行われたなど、記載された事実によって要件が活性化されることを意味します。デフォルトは、編集者が意図的に選択したであろうのと同じ意味を生み出す場合にのみ安全です。

アイデンティティとルーティング

title、h1、seoTitle

• 目的 — titleはドキュメントに耐久性のある編集上の名前を付けます。h1は、レイアウトコンテキストが異なる表現を必要とする場合に、ページ内のメイン見出しを制御します。seoTitleは、デフォルトでは簡潔な修飾語やブランド処理が必要な場合に、ブラウザ/検索タイトルを制御します。これらを分離することで、ナビゲーションラベル、ページ見出し、検索プレビューが1つの不格好な文字列に強制されることを防ぎます。
• 型と形式 — それぞれプレーンテキスト文字列。titleがソース値であり、上書きがない場合はこれにフォールバックする必要があります。HTML、Markdown、絵文字装飾、手動の切り詰め記号は有効な値ではありません。
• 必須？ — titleはすべての公開ページで必須です。h1とseoTitleは任意であり、titleが3つのコンテキストすべてで機能する場合は省略すべきです。
• 制限 — titleは30～70文字、h1は20～80文字、seoTitleは30～60文字を編集上の範囲として使用します。これらは検索インターフェースがすべての文字を表示するという約束ではありません。レンダリングされたH1が1つ存在する必要があります。
• 誰が何に使用するか — ページテンプレート、ブラウザタイトル、検索およびソーシャルアダプタ、ナビゲーションカード、フィード、スキーマheadline、アクセシビリティアウトライン、編集リスト。
• ルール — すべてのバージョンが同じ主題、意図、範囲を識別する必要があります。正当な差異はチャンネルの制約を解決するものです。たとえば、H1が「ダウンタイムなしでAPIキーをローテーションする方法」と述べ、短いSEOタイトルが「APIキーローテーション：安全なステップバイステップガイド」とする場合などです。後の タイトル、H1、SEOタイトルセクションで編集上のテストを説明します。
• よくある間違い — 3つのバリアントすべてで同じキーワードを繰り返す、H1にブランドサフィックスを入れる、クリックを追いかけて約束を変える、毎年メンテナンスされていないページに現在の年を埋め込む、または単に3つのフィールドが存在するという理由だけで3つの値を記述する。

slugとurl

• 目的 — スラグは最終パスセグメントであり、urlはそれを含むサイト相対の公開ルートです。これらは一緒になって、読者、クローラー、リンク、レポート、移行のためにページに安定したアドレスを提供します。獲得したすべてのリンクと保存されたブックマークがそのアドレスに依存するようになるため、安定性は重要です。
• 型と形式 — 小文字、ハイフン区切りのパス文字列を使用します（例：/academy/rotate-an-api-key/）。このリポジトリは完全なルートをurlに記録します。別個のslugフィールドを持つCMSは、同じ最終セグメントを導出する必要があります。
• 必須？ — すべての公開ページに一意のルートが必要です。セクションに承認された決定論的ルールと衝突チェックがある場合にのみ生成できます。プレイブックページは登録されたurl値を使用します。
• 制限 — 区別する主題を保持する短く読みやすいスラグを推奨します。通常3～8の有用な単語です。句読点と空の修飾語を削除します。「the」や「a」などのストップワードは、結果が自然で曖昧さがなくなった場合にのみ削除します。意味を損なうことを正当化する恣意的な文字数制限はありません。
• 誰が何に使用するか — Hugoのルーティング、内部リンク、パンくずリスト、正規URL生成、サイトマップ、フィード、分析、リダイレクト、外部参照。
• ルール — 公開されたスラグを永続的なコミットメントとして扱います。キャンペーンの見出しや一時的な年ではなく、耐久性のあるトピックから決定します。タイトルは変わってもトピックと意図が変わらない場合は、古いスラグを維持します。ページが実際に移動する場合は、新しいルートを作成し、古いルートをaliasesに保持し、内部リンクを更新し、リダイレクト先をテストします。
• よくある間違い — タイトルが変わるたびにスラグを再生成する、同義語をパスに詰め込む、 evergreenコンテンツを古く見せる日付を保持する、大文字小文字の混在やアンダースコアを使用する、末尾スラッシュのみが異なる2つのURLを作成する、古いルートを保存せずにルートを変更する。

canonical

• 目的 — 正規URLは、同等またはほぼ同等のアクセス可能なバージョンの中から優先URLを識別します。アイデンティティを統合しますが、訪問者を移動させたり、制御されていない重複を許容したりするものではありません。
• 型と形式 — 意図されたホストと正規化されたパスを含む1つの絶対HTTPS URL：https://amicited.com/academy/rotate-an-api-key/。サイトに1つの信頼できるホストとルートポリシーがある場合、テンプレートはページのパーマリンクから自己参照を導出する場合があります。
• 必須？ — すべてのインデックス可能なページは1つの正規URLを出力する必要があります。正しい自己参照値が自動的に導出される場合、フィールド自体は条件付きです。承認されたクロスドメインまたは例外的な正規URLには明示的に設定します。
• 制限 — 正確に1つの正規ターゲット。ターゲットは成功したインデックス可能なドキュメントを返し、優先プロトコルとホストを使用し、実質的に同じコンテンツを表す必要があります。
• 誰が何に使用するか — HTML <link rel="canonical">、検索エンジン、サイトマップおよび内部リンクチェック、重複排除レポート、スキーマURL識別子。
• ルール — デフォルトで自己参照。別のパブリッシャーが優先する同等物を所有し、両者が統合を意図している場合のみクロスドメイン正規URLを使用します。古いURLが置き換えられ、ユーザーが常に新しいURLに着地すべき場合は、正規URLではなくリダイレクトを使用します。正規URL、サイトマップURL、hreflang、内部リンク、スキーマアイデンティティを整合させます。
• よくある間違い — すべてのページネーションまたはローカライズページを汎用的な親に向ける、異なるコンテンツを正規化する、リダイレクトまたはエラーページをターゲットにする、HTTPとHTTPSを混在させる、エイリアスの代わりとしてフィールドを使用する、正規ディレクティブが確実に守られると想定する。

aliases

• 目的 — aliasesは、以前に同じページを識別していたルートを保持し、移動によって既存のリンクやブックマークがデッドエンドにならないようにします。これはルートの履歴を記録するものであり、代替のインデックス可能なアイデンティティを作成するものではありません。
• 型と形式 — サイト相対パスのTOML配列。例：aliases = [ "/blog/old-api-key-guide/" ]。各値には先頭と末尾のスラッシュが含まれ、サイト全体で一意でなければなりません。
• 必須？ — 新しいページでは任意。公開されたページがサイト管理下のパスから移動する場合は必須。
• 制限 — まだリンクやトラフィックを受けている既知のすべての旧ファーストパーティルートを含めます。推測のスペルバリアントや無制限のキーワードURLリストは追加しないでください。
• 誰が何に使用するか — Hugoのエイリアス出力、設定されている場合のデプロイリダイレクト処理、移行QA、リンクモニター、古いURLをたどるユーザー。HugoはオリジンレベルのHTTPリダイレクトではなくエイリアスページを出力できるため、デプロイメントの動作を想定ではなく検証する必要があります。
• ルール — 移動したページは古いパスを機能させ続けます。すべてのエイリアスは1ホップで現在の正規ルートに解決される必要があります。エイリアスが機能していても内部リンクを新しいURLに更新し、文書化されたリダイレクトシステムがそれを置き換えない限り、後の編集でもエイリアスを維持します。
• よくある間違い — エイリアスなしで古いページを削除する、古いパス→中間パス→現在のパスと連鎖させる、エイリアスを重複公開ルートとして扱う、複数の無関係なページを1つの便利な宛先に向ける、ローカルのHugo出力が本番のHTTPステータスを証明すると想定する。

typeとlayout

• 目的 — これらのフィールドはレンダリング契約を選択します。typeは共有テンプレートと動作を持つコンテンツクラスにページを配置します。layoutはそのクラス内で特定のテンプレートを要求します。正しい選択により、ページが意図されたナビゲーション、コンテンツスロット、アセット、スキーマ動作を受け取ることが保証されます。
• 型と形式 — 小文字の登録された文字列。このページではtype = "academy"を使用しています。layout値はsingleなどのテンプレートベース名であり、ファイル拡張子やパストラバーサルは含みません。
• 必須？ — typeは、コンテンツの場所が意図されたタイプを安全に示唆しない場合、またはプレイブック契約がそれを義務付ける場合に必須です。layoutは任意であり、タイプのデフォルトテンプレートが正しい場合は省略すべきです。
• 制限 — 各フィールドに1つの値。サイトがメンテナンスするテンプレートからのみ選択します。新しい値は編集上の即興ではなく、エンジニアリング変更です。
• 誰が何に使用するか — Hugoのルックアップ順序、テンプレート、部分選択、CSSおよびJavaScriptの組み込み、スキーマアダプタ、検証ルール。
• ルール — 作成前に投稿タイプとレンダリング契約を選択します。layoutは実際にサポートされているバリアントにのみ使用し、別のtypeに属するコンテンツを補うために使用しないでください。オーバーライドが存在し、ページのフロントマター形状を受け入れることを確認します。
• よくある間違い — 編集上のentityとHugoのtypeを混同する、存在しないテンプレートファイルを指定する、ランディングページタイプをアカデミードキュメントにコピーする、移行中のフォルダ推論に依存する、共有の改善をバイパスする一回限りのレイアウト名を導入する。

発見

description

• 目的 — 説明は、資格のある検索者や共有受信者がこのページがニーズを満たすかどうかを判断するのに役立ちます。これはプレビューコピーであり、圧縮されたイントロダクションでも、繰り返しによって関連性を証明する場所でもありません。
• 型と形式 — 1つのプレーンテキスト文。主要な用語を自然に含め、具体的な価値を述べ、有用な範囲、オーディエンス、方法、成果を追加する必要があります。
• 必須？ — このプレイブックでは、すべてのインデックス可能なページで必須です。
• 制限 — スペースを含めて150～160文字。これは編集上の一貫性の範囲であり、表示の保証ではありません。検索エンジンはそれを切り詰めたり、別のパッセージがクエリに適合する場合に本文からスニペットを書き換えたりする場合があります。
• 誰が何に使用するか — メタディスクリプションタグ、Open GraphおよびTwitterの説明デフォルト、リストカード、フィード、CMSプレビュー、検索品質チェック、場合によってはスキーマdescription。
• ルール — 適切な読者からのクリックを目指して書きましょう。文を十分に具体的にし、類似したタイトルの別の結果とページを区別できるようにします。以下の 説明ルールセクションで根拠と拒否テストを示します。
• よくある間違い — タイトルを複製する、キーワードを並べる、「すべてを学ぶ」で始める、裏付けのない最良または最速の主張をする、曖昧な行動喚起を使用する、目に見えないブランドサフィックスによって範囲を超える、作成したテキストが検索結果にそのまま表示されると想定する。

keywords

• 目的 — このリポジトリでは、keywordsは編集QA、コーパス検索、カバレッジ分析、内部ツールに使用されるコンパクトなクエリと用語セットを記録します。これは編集者がページが正確に使用しなければならない言語を認識するのに役立ちますが、すべてのフレーズを機械的に含めるという約束ではありません。
• 型と形式 — 自然言語文字列の配列。主要な用語から意味のあるバリアントや密接に関連する用語へと順序付けられます。
• 必須？ — このプレイブックでは必須であり、パブリックテンプレートが値をレンダリングしないページも含みます。
• 制限 — 6～8の個別のエントリ。各エントリは実際のクエリフレーズまたは必要な用語を表す必要があり、トークンレベルのバリエーションであってはいけません。
• 誰が何に使用するか — 編集バリデータ、コンテンツインベントリ、検索および機会分析、内部検索、移行ツール。パブリック検索エンジンは、このフィールドが存在するという理由だけでランキングシグナルとして使用するわけではありません。
• ルール — セットを1ページの範囲に集中させます。大文字小文字、句読点、単数/複数、些細な語順の重複を統合します。フレーズを使用してカバレッジと用語を確認しますが、不自然な密度を指示するために使用してはいけません。
• よくある間違い — このフィールドを廃止されたメタキーワードランキングメカニズムとして扱う、数十のバリアントを追加する、タイトルを8つのほぼ重複として繰り返す、本文で議論していない競合他社名を挿入する、配列が適切なタクソノミーやプロンプトターゲットを置き換えることを許可する。

targetPrompts

• 目的 — targetPromptsは、ユーザーがAI回答システムに与える可能性があり、このページが有用なソースとなるべき完全な質問やリクエストを記録します。プロンプトターゲットは、短いキーワードフレーズでは省略される会話のコンテキストを保持します。
• 型と形式 — 完全な自然言語文字列の配列。例：targetPrompts = [ "ダウンタイムなしでAPIキーをローテーションするには？", "古いAPIキーを取り消す前に何を確認すべきですか？" ]。ユーザーが質問するであろう表現で、オーディエンス、制約、希望する比較を含めて記述します。
• 必須？ — プロンプト追跡またはAI可視性コンテンツプログラムに含まれるページでは条件付き。追跡されるプロンプトセットが存在しない場合は任意。
• 制限 — 小さく意図的なセットを使用します。通常は1つの主要プロンプトと最大4つの意味のあるバリアントです。プロンプトは、その修飾語が意図を伝えるため、キーワードよりも長くなる場合があります。
• 誰が何に使用するか — コンテンツブリーフ、プロンプト追跡ワークフロー、検索およびカバレッジ監査、AI回答モニタリング、編集評価。隠し検索コピーとしてレンダリングされることはありません。
• ルール — プロンプトを句読点ではなく、実際の情報ニーズによって区切ります。「APIキーローテーション」のようなキーワードはトピックを指定します。「SaaSチームはどのように統合を中断せずにAPIキーをローテーションできますか？」はオーディエンス、タスク、制約を指定します。ページは保存されたすべてのプロンプトに正直に答える必要があります。
• よくある間違い — キーワード配列をこのフィールドにコピーする、数十の構文バリエーションを作り出す、ページよりも広いプロンプトを記録する、読みやすさの流れに関係なくプロンプトを本文見出しとして使用する、ページが提供しない情報に答えが依存している場合にプロンプトカバレッジを主張する。

信頼と来歴

dateとupdated

• 目的 — dateはページが最初に公開された時期を保持します。updatedは最新の実質的な変更または完了したレビューを報告します。2つのフィールドは履歴を保持しながら、読者が頼りにする情報が変更されたかどうかを示します。
• 型と形式 — サイト規則に従ったタイムスタンプ文字列。YYYY-MM-DD HH:MM:SS。フィードと比較が決定論的に保たれるよう、コーパス全体で1つのタイムゾーンポリシーを維持します。
• 必須？ — dateは公開された編集ページで必須です。updatedは該当する変更が発生するまでは任意ですが、ページが変更日を表示する場合は必須になります。
• 制限 — 各1つの値。updatedはdateより前または未来であってはいけません。公開から数分後に行われた修正も文書化できますが、公開前の通常のドラフト修正は更新日を作成しません。
• 誰が何に使用するか — 表示される署名行と新しさスタンプ、フィード、サイトマップ、スキーマdatePublishedとdateModified、新しさ監査、並べ替え、編集キュー。
• ルール — 事実の修正、指示の変更、新しい証拠や削除された証拠、範囲の改訂、実質的に変更された推奨事項、または時事情報の文書化されたレビューがあった場合にupdatedをリセットします。句読点、書式設定、テンプレート作業、またはタイムスタンプのみの編集でリセットしてはいけません。ポリシーの根拠については 日付、作成者、レビュアーを参照してください。
• よくある間違い — リフレッシュ時に元の日付を上書きする、新しく見せるために未来の日付を設定する、コンテンツの差分なしに日付を更新する、自動デプロイを編集更新として扱う、維持されている更新履歴に何が変更されたかを記録しない。

author

• 目的 — authorはドキュメントを、その作業に責任を持つ人物エンティティに接続します。このリンクは読者と機械に、主張を含むページから維持されたアイデンティティ、専門知識、他の作業へのパスを提供します。
• 型と形式 — サイトの作成者レジストリを通じてプロファイルURLとPersonレコードに解決される安定した作成者識別子。たとえば、author = "maya-chen"は、その識別子が解決される場合にのみ有効です。"Maya Chen, SEO Expert"のような表示名はエンティティリンクの代用にはなりません。
• 必須？ — 実質的な編集ページで必須。トランザクションページは、テンプレートとポリシーがそのエンティティタイプをサポートする場合にのみ、管理された組織所有者を使用できます。
• 制限 — デフォルトでは1人の責任者。スキーマと署名行テンプレートが真の共著をサポートする場合にのみ、文書化された識別子配列を使用します。
• 誰が何に使用するか — 表示される署名行、作成者プロファイルリンク、Articleスキーマ、フィード、編集所有権レポート、レビューワークフロー、エンティティグラフ。
• ルール — 公開前に識別子を解決します。プロファイルは署名行に表示される同じ人物を識別し、維持されていなければなりません。単にアップロードした人物ではなく、コンテンツに責任を持つ人物をクレジットします。
• よくある間違い — リンクされていない名前文字列を入力する、「Admin」や架空の編集チームを使用する、作業を作成していない著名な役員を割り当てる、識別子がプロファイルに解決されないままにする、関与していなかった専門知識を暗示するために著者を変更する。

reviewedBy、reviewedAt、reviewScope

• 目的 — これらのフィールドは、作成とは別の独立したレビューを記録します。reviewedByはレビュアーエンティティを識別します。reviewedAtはレビューが完了した時期を示します。reviewScopeはレビュアーが何を確認したかを述べ、バッジが証拠を超えた承認を暗示しないようにします。
• 型と形式 — reviewedByは維持された人物プロファイルに解決される安定した識別子。reviewedAtはサイトのタイムスタンプ形式を使用。reviewScopeは「認証情報ローテーション手順とセキュリティ上の注意事項」のような簡潔なプレーンテキスト文。
• 必須？ — 法律、リスクポリシー、主題の機密性、または投稿タイプの仕様が独立したレビューを要求する場合に条件付き。reviewedByが存在する場合、レビュー日と範囲はレビューレコードデータとして必須です（特定のテンプレートが公開フロントマターではなく接続された編集レコードに保存する場合でも）。
• 制限 — 実際のレビュアーのみを指名します。範囲は、レビューレポートにならずに除外事項を明らかにするのに十分具体的であるべきです。レビュアーは関連する能力を持ち、単に作成者役割を複製してはいけません。
• 誰が何に使用するか — レビュー済みコンポーネント、人物エンティティ結合、ガバナンス監査、高リスク公開ゲート、構造化来歴、更新ログ。
• ルール — コンテンツが安定した後にレビューを完了し、調査結果と解決策を編集履歴に記録し、後の変更がレビュー範囲に影響を与える場合は再レビューします。独立とは、レビュアーが自分のドラフトを承認するのではなく、作業をテストすることを意味します。
• よくある間違い — コピー編集を専門家レビューとして扱う、日付や範囲なしでレビュアーを表示する、最終バージョンを見たことがない人を指名する、未レビューの実質的な書き換え後にバッジを残す、記載された範囲外の法的、医学的、または技術的な承認を暗示する。

メディアとソーシャル

imageとimageAlt

• 目的 — imageは代表的なヒーローおよびソーシャルアセットを選択します。imageAltは、そのアセットが意味のあるページコンテンツとしてレンダリングされる場合に機能的なテキスト代替を提供します。ペアを一緒に保つことで、発見イメージがアクセシビリティの欠落になることを防ぎます。
• 型と形式 — imageは解決可能なサイトパスまたは承認された絶対URL。imageAltは、ファイル名やターゲットキーワードではなく、ページコンテキストにおける画像の有用な情報を説明するプレーンテキスト。
• 必須？ — 投稿タイプとテンプレートによって条件付き。ページにヒーローまたは専用ソーシャル画像が必要な場合、imageは必須です。imageAltはその画像が情報を伝えてレンダリングされる場合に必須です。純粋に装飾的なレンダリングでは、テンプレートで空のalt属性を使用する必要があり、創作された説明テキストは使用してはいけません。
• 制限 — 1つの代表アセットを使用します。ソーシャル互換性のために、予想されるクロップ比で1200×630ピクセルのソースを提供し、重要なコンテンツを端から遠ざけ、imageAltは簡潔に（通常5～160文字）。ファイルは参照される前に存在していなければなりません。
• 誰が何に使用するか — ヒーローコンポーネント、リストカード、Open GraphおよびTwitterタグ、スキーマ画像フィールド、フィード、画像パイプライン、表示時のスクリーンリーダー、アセットQA。
• ルール — 中央クロップ後およびサムネイルサイズでも伝わる画像を選択します。コンテキストにおけるその機能を説明します。「Rotateキーが強調表示されたAPIキー設定」は有用ですが、「APIキー」は有用ではありません。重要な主張をピクセル内のみに置かないでください。
• よくある間違い — 存在しない計画中のアセットを参照する、すべての記事画像にロゴを使用する、シェアで読めなくなる小さなテキストを埋め込む、「～の画像」と書く、altテキストにキーワードを詰め込む、ソーシャルaltテキストと表示画像のalt動作がプラットフォーム間で同一であると想定する。

Open GraphおよびTwitterカードフィールド

• 目的 — ソーシャルメタデータは、URLが共有された時の要約方法を制御します。一貫したタイトル、説明、URL、タイプ、画像は、受信者がクリックする前にページを認識するのに役立ち、プラットフォームが無関係なアセットを選択する可能性を減らします。
• 型と形式 — このリポジトリでは、テンプレートはog:titleとtwitter:titleをtitleから、説明をdescriptionから、URLをパーマリンクから、og:typeをレイアウトコンテキストから、両方の画像タグをimage（サイトフォールバック付き）から導出します。twitter:cardはsummary_large_imageとして出力されます。これらは生成されたタグであり、デフォルトでは重複するフロントマターフィールドではありません。
• 必須？ — 出力タグは公開ページで必須です。個別の上書きは任意であり、文書化されたテンプレート契約を通じてのみ導入されるべきです。ogTitleなどのサポートされていないアドホックフィールドは何もしません。
• 制限 — ページごとに1つの一貫したプレビューと1つの1200×630の代表画像。導出された表現をタイトルと説明の範囲内に保ち、主要な共有サーフェスで実際のクロップとオーバーレイ動作をテストします。
• 誰が何に使用するか — ソーシャルネットワーク、メッセージングクライアント、リンクアンファーラー、ブラウザ拡張機能、コラボレーションツール、シェアプレビューデバッガー。
• ルール — 導出を優先して、検索とソーシャルの主張を整合させます。ソーシャルコンテキストが本当に異なるフレーミングを必要とし、テンプレートがそれをサポートする場合にのみ上書きします。誤った画像は認識と信頼を損なう可能性があります。受信者は、古くなったインターフェース、別の製品、誤解を招く主張、または被写体を隠すクロップを見る可能性があります。
• よくある間違い — テンプレートが読み取らないフィールドを作成する、グローバルフォールバックが不足している必須ヒーローを隠蔽することを許す、ワイドカードにポートレートや小さな画像を使用する、ページよりも強い約束をするようにソーシャルコピーを変更する、フェッチされたプレビューではなくHTMLソースのみを検証する。

分類

taxonomy、categories、tags

• 目的 — 分類はページを管理されたトピック、形式、オーディエンス、製品コレクションに接続します。各語彙に宣言された意味がある場合にのみ、有用なアーカイブとフィルターを実現します。そうでなければ、ラベルは制御されていない同義語の山になります。
• 型と形式 — 登録された小文字スラグの配列。リポジトリの管理されたトピック語彙にはtaxonomyを使用します。categoriesは小さな相互理解可能な編集階層にのみ、tagsはそれらのタクソノミーが設定されている場合に管理された横断的語彙にのみ使用します。
• 必須？ — 投稿タイプとアーカイブデザインによって条件付き。トピックを持つ編集ページは通常1つ以上の管理用語を必要とします。ユーティリティページは必要ない場合があります。CMSが公開するという理由だけでフィールドに入力してはいけません。
• 制限 — 一般的なタクソノミーの場合、管理語彙ごとに1～5つの値。各用語には定義、所有者、マージルールが必要です。用語が耐久性のある読者の需要を表し、アーカイブが独自のイントロダクション、一貫したインベントリ、内部リンク、継続的なメンテナンスを提供できる場合にのみ、インデックス可能なアーカイブを作成します。
• 誰が何に使用するか — アーカイブページ、パンくずリスト、フィルター、関連コンテンツシステム、ファセットナビゲーション、コンテンツ監査、分析セグメンテーション。
• ルール — ページを正確にグループ化する最も狭い登録用語を選択します。単数/複数、略語、スペルのバリアントを1つの正規値にマッピングします。アーカイブがインデックス可能かどうかを、偶発的な作成後にタグごとではなく語彙レベルで決定します。
• よくある間違い — seo、SEO、search-optimization、search engine optimizationを別々の値として使用する、すべての名詞を説明するために一回限りのタグを追加する、ビジネスタイプとトピックを混同する、薄いインデックス可能なアーカイブを生成する、メンバーを移行せずに用語を削除する。

プレイブック結合キー

• 目的 — playbookPillar、playbookFamily、playbookWave、postTypes、elements、businessTypes、journeyStage、amicitedFeaturesは型付き結合キーです。これらにより、編集者が手動でカードをコピーすることなく、1つのソースページが生成されたライブラリやマトリックスに表示されるようになります。このページは実際の例です。そのピラーはエレメントを識別し、ファミリーはメタデータガイダンスをグループ化し、postTypes配列はそれを消費する仕様を宣言します。
• 型と形式 — 単一キーは登録された小文字スラグを使用します。playbookPillarとplaybookFamilyは文字列、playbookWaveは整数、journeyStageは管理された文字列です。リレーションシップキー（postTypes、elements、businessTypes、amicitedFeatures）は、それぞれのレジストリからの登録スラグの配列です。
• 必須？ — playbookPillarとplaybookWaveはプレイブックレコードで必須。playbookFamilyはピラーに管理されたファミリーがある場合に必須。配列結合とjourneyStageは条件付き。ページ契約が実際にサポートするリレーションシップのみを入力します。
• 制限 — モデルが明示的に複数のステージを許可しない限り、1つのピラー、そのピラー内の1つのファミリー、1つのウェーブ、1つのジャーニーステージ。配列には一意の登録キーが含まれ、表示ラベル、散文、URLは含まれません。
• 誰が何に使用するか — プレイブックハブリスト、クロスピラーマトリックス、フィルター、リレーションシップカード、完全性レポート、リリースウェーブビュー、関連するAmICited機能を見つける内部ツール。
• ルール — すべての値を正規レジストリに対して検証します。方向性が重要です。投稿タイプページは必要なelementsをリストし、エレメントページは該当するpostTypesをリストし、ビジネスタイプページは有用な投稿タイプをリストします。ラベルをプレゼンテーション、キーを耐久性のあるデータとして扱います。結合のすべての側面を更新する移行を通じてのみキーの名前を変更します。
• よくある間違い — 類似の同義語を作り出す、スラグの代わりにタイトルを保存する、ウェーブに整数と文字列を混在させる、2つのページが互いに言及しているという理由でリレーションシップを追加する、相互の配列が互いに矛盾することを許す、メタデータから乖離する手動メンテナンスのリストマークアップを作成する。

派生フィールドと構造フィールド

schemaType

• 目的 — schemaTypeは、表示可能なページを正確に記述する最も具体的なサポート対象の構造化データマッピングを選択します。これはスキーマアダプタにどの語彙契約を適用するかを伝えます。宣言だけでページをそのものにするわけではありません。
• 型と形式 — サイトアダプタがサポートするタイプから選択されたArticleなどの登録されたSchema.orgタイプ名。大文字小文字とスペルはレジストリと一致する必要があります。
• 必須？ — 条件付き。同じHugoタイプに対して複数のスキーママッピングが有効な場合、または投稿タイプ契約が明示的なタイプを要求する場合に設定します。それ以外の場合はテンプレートに安全なデフォルトを導出させます。
• 制限 — 1つの主要ページタイプ。ネストされたエンティティはアダプタが実際のコンテンツから作成します。選択されたタイプはすべての必須プロパティを満たし、読者が見ることができるものと一致する必要があります。
• 誰が何に使用するか — JSON-LDアダプタ、リッチリザルト検証、コンテンツQA、スキーマインベントリレポート。
• ルール — ページ機能と表示可能な証拠から選択し、編集者が欲しい検索機能からではありません。完全な表示可能な手順がないハウツーページは、ハウツータイプを設定しても正確性を得られません。スキーマURL、日付、人物、画像をソースフィールドと同期させます。
• よくある間違い — 必要なコンテンツなしにより具体的なタイプを選択する、複数の矛盾するプライマリタイプを出力する、無関係なテンプレートからスキーマ値をコピーする、有効な構文が資格を保証すると想定する、読者が検査できない主張をJSON-LDに入れる。

読了時間

• 目的 — 読了時間は読者に大まかな労力の見積もりを提供します。これは最終的なレンダリング可能な本文から導出されるため、実際の読了負荷が変化すると見積もりも変化します。
• 型と形式 — コンテンツパイプラインのワードカウントポリシーから生成される計算された整数の分数。コードブロック、テーブル、キャプション、埋め込みメディアは1つの文書化されたカウントルールに従う必要があります。
• 必須？ — 表示はテンプレートによって任意。作成されたフロントマターフィールドは信頼できるソースとして許可されていません。
• 制限 — 一貫して丸め、1分などの sensible な最小表示を適用します。正確な1分あたりの単語数の想定よりも、サイト全体で同じ方法を使用し、結果を見積もりとしてラベル付けすることの方が重要です。
• 誰が何に使用するか — ページヘッダー、カード、フィード、分析セグメンテーション、長いガイドを始めるかどうか決める読者。
• ルール — サイトポリシーに従ってショートコードと除外領域が処理された後に計算します。ビルドごとに再計算します。動画やインタラクティブなタスクが完了時間を実質的に変更する場合は、読了時間を壊すのではなく別途ラベル付けします。
• よくある間違い — readingTime = 8と作成し、書き換え後に更新するのを忘れる、誤った精度を提示する、ナビゲーションと定型文をカウントする、実行重視のハウツーをタスク時間なしで8分の読書として扱う。

[[faq]]

• 目的 — [[faq]]は表示可能な質疑応答ペアを1回保存し、ページと該当するFAQ構造化データが乖離しないようにします。
• 型と形式 — テーブルのTOML配列。各項目には1つのプレーンテキストquestionと1つの自己完結型answer文字列が含まれます。
• 必須？ — メインページの後に実際のフォローアップ質問が残っている場合に条件付き。単にテンプレートを埋めたり検索機能を追求したりするために必須になることはありません。
• 制限 — プレイブックページでは通常4～8の有用な項目。各質問は1回表示され、すべての回答はアコーディオンの順序に依存せずに完全でなければなりません。
• 誰が何に使用するか — 表示可能なFAQレンダリング、該当する場合のFAQPageスキーマ、ページナビゲーション、コンテンツQA、回答抽出。
• ルール — これは相互参照契約です。 FAQがフロントマターにある理由と後のFAQガイダンスに従い、個別の表示可能なコピーとスキーマコピーを維持しないでください。すべての読者がページでアクセスできる質問のみを保存します。
• よくある間違い — 非表示のスキーマのみの回答、質問として偽装された重複見出し、プロモーション的な回答、裏付けのない主張、古いJSON-LD、検索結果の資格が保証されていると想定する。

[[lnks]]

• 目的 — [[lnks]]は本文で使用される管理された内部リンクをそれぞれ記録し、表示可能なアンカーと宛先および維持された説明をペアにします。このレコードにより、レンダリングされたHTMLをスクレイピングせずにリンクを検査でき、移行とQAをサポートします。
• 型と形式 — text、path、titleを持つテーブルのTOML配列。textは正確な表示可能なアンカー、pathは先頭と末尾のスラッシュ付きのサイト相対URL、titleは宛先ページの説明。
• 必須？ — このコンテンツ規則によって管理される各内部本文リンクで必須。アプリのディープリンクと外部ソースは独自のレコードに従い、[[lnks]]エントリとして偽装されません。
• 制限 — 同じアンカーが異なる宛先を指す可能性がある場合、本文リンクの出現ごとに1つのレコード。それ以外の場合、正確な重複レコードは削除する必要があります。宛先は存在するか、調整されたリリースのために承認された正規スラグレジストリに存在する必要があります。
• 誰が何に使用するか — 内部リンク検証、コンテンツ移行、リレーションシップ分析、サポートされている場合のリンクタイトル生成、編集レビュー。
• ルール — textを本文アンカーと完全に一致させます（リンク内の大文字小文字と句読点を含む）。正規のサイト相対パスを使用します。titleは現在のページへの指示ではなく、正確な宛先の説明として記述します。レコードと本文を一緒に更新します。
• よくある間違い — 実際のアンカーよりも長いtext値を使用する、未登録のスラグを作り出す、末尾スラッシュを省略する、リダイレクトする古いパスを記録する、宛先ではなくソースを説明する、本文リンクが削除された後にレコードを残す。

投稿タイプ別の必須と任意

以下のマトリックスは、このエレメントによって現在宣言されている12の投稿タイプに上記の契約を適用します。Rは必須、Cはフィールドルールに基づく条件付き、Dは安全に導出可能な必須出力、Oは任意を意味します。「アイデンティティ」にはentity、id、title、type、安定したルートが含まれます。「発見」にはdescriptionとkeywordsが含まれます。ターゲットプロンプトはすべての行で条件付きのままです。aliasesは移動時は常に条件付きですが、作成された読了時間は決して必須ではありません。

「条件付きレビュアー」は、正確性や商業的リスクがそれを要求する場合にレビューをスキップする許可ではありません。最適Xおよび代替案ページは、その推奨事項が意思決定に実質的に影響を与える可能性があり、製品、価格、資格の変更に伴って頻繁に変更されるため、独立したレビューが必要です。他の行については、編集者の利用可能時間ではなくリスクポリシーが要件を活性化します。同様に、Dとマークされた正規URLはレンダリングされたHTMLでは依然として必須です。テンプレートが正しい自己参照を生成できる場合にのみ、フロントマター入力を省略できます。

フロントマター検証

検証は、決定論的な欠陥を自動的に拒否し、意味、証拠、または専門的能力に依存する質問については判断を留保する必要があります。この分割により、2つの逆の失敗を防ぎます。すなわち、パーサーが完全にキャッチできる構文をレビュアーに確認させることと、文字数ルールがコピーが正直かどうかを判断できるふりをすることです。

決定論的チェックは編集レビューの前に実行し、レビュアーが一貫性のあるレコードを見られるようにします。その後、フロントマターだけでなくレンダリングされたHTMLもレビューします。選択されたテンプレートが有効なソース値を無視したり、間違ったタグにマッピングしたり、必須の来歴を隠したり、公開ルートと矛盾する正規URLを生成したりする場合、それは本番の欠陥です。公開は、ソース、レンダリング、宛先の動作がすべて一致した場合にのみ完了します。

entityフィールド

entityは「このドキュメントはどの正確な投稿タイプのインスタンスか？」に答えます。「このページはどのトピックを議論しているか？」に答えるものではありません。この区別は重要です。なぜなら、2つのドキュメントが異なる役割を果たしながら同じトピックを扱うことができるからです。用語集エントリは「診断」を定義し、ブログ記事は診断ガイダンスの変更を報告するかもしれません。両方がentity = "diagnosis"を使用する場合、ダウンストリームシステムは正しいテンプレート、検証ルール、分析グループ、移行を確実に選択できません。

ファミリー内のバリアントにはグループプレフィックスと投稿タイプスラグを使用します：guide-how-to、guide-ultimate、comparison-a-vs-b、comparison-alternatives-to-x。スタンドアロンタイプにはベア名を使用します：product-pageまたはcase-study。識別子を1回登録し、安定させ、トピックやターゲットクエリが変更されたからといって決して変更しないでください。トピック概念はtaxonomyに、クエリ言語はkeywordsに入れます。

タイトル、H1、SEOタイトル

これらの値はコンテキストによって異なる場合がありますが、同じページを説明する必要があります。titleは耐久性のあるデフォルトです。h1は表示される見出しであり、コンテキストでより自然になる場合があります。seoTitleはブラウザと検索結果に使用され、簡潔な差別化要因、正当な年、またはブランドサフィックスを追加する場合があります。

たとえば、title = "APIキーローテーション"、h1 = "ダウンタイムなしでAPIキーをローテーションする方法"、seoTitle = "APIキーローテーション：安全なステップバイステップガイド"は1つのタスクに沿っています。SEOタイトルとして「無料セキュリティツール」は約束を変えるため欺瞞的です。より多くのキーワードを挿入するためだけに差異を作らないでください。

説明ルール

説明は、資格のある読者がクリックするかどうかを判断するのを助けるために存在します。150～160文字以内に保ち、主要な用語を自然に含め、ページの具体的な利点を述べ、オーディエンス、範囲、成果などの意味のある修飾語を追加します。1つの流暢な文を書き、キーワードリストは書きません。

その用語は関連性を確認します。繰り返しは価値を追加しません。タイトルを複製したり、「すべてを学ぶ」を使用したり、裏付けのない最上級表現を使用したり、途中で文を終えたりしないでください。検索システムはクエリに対して異なる表示テキストを選択する場合があります。

日付、作成者、レビュアー

dateは最初の公開タイムスタンプを保持します。updatedは最新の実質的な変更を記録します。事実の修正、新しい証拠、指示の変更、範囲の改訂、推奨事項の変更、または時事情報を確認する完全なレビュー。ポリシーが要求する場合、編集履歴に何が変更されたかを記録します。

句読点の修正、ボタンスタイルの変更、テンプレートの再構築、またはタイムスタンプのみのタッチはupdatedをリセットしません。それに伴う作業なしに日付を進めることはポリシー違反です。なぜなら、コンテンツが実際にはリフレッシュされていないのにリフレッシュされたと読者と機械に伝えるからです。これは成長戦術ではなく、不実表示です。

作成者とレビュアーフィールドは、責任あるアイデンティティを署名行と構造化データに運びます。作成者は作業に対して責任を持ちます。reviewedByは資格のあるレビューが行われた場合にのみ使用し、両方の識別子を維持されたプロファイルにリンクします。 信頼の基礎ページは、著作者、日付、証拠、エンティティの明確さが、ランキングを保証せずに信頼をどのようにサポートするかを説明しています。

FAQがフロントマターにある理由

FAQは表示可能なコンテンツであり、構造化コレクションでもあります。[[faq]]に一度保存することで、テンプレートがアコーディオンと同一のFAQPage JSON-LDをレンダリングできるようになり、古くなった非表示スキーマを防ぎます。

すべての読者がアクセスできる実際のフォローアップ質問を含めます。見出しを複製したり、回答にプロモーションを隠したり、表示されていない質問をマークアップしたりしないでください。有効なマークアップは検索機能を保証するものではありません。

構文とコード例

クロスプラットフォーム契約は、表示可能なコンポーネントではなくフィールドをマッピングします。以下のポータブルエンベロープは、インポーターがメタデータディレクティブを認識するインターチェンジファイルでのみ有効です。

:::frontmatter{entity="guide-how-to" id="reset-api-key" title="How to Reset an API Key"}
description: Reset an API key safely, replace it in dependent services, verify it, and revoke the exposed key without avoidable downtime.
author: maya-chen
:::

インポート中にネイティブページメタデータに正規化する必要があります。これは本番記事の本文では有効ではありません。Hugoでは、ライブ標本に示されているように、バイト1の+++フェンス間のTOMLが正しいマッピングです。{{< frontmatter >}}ショートコードは意図的に存在しません。ショートコードは実行が遅すぎ、誤ったドキュメント領域で実行されるためです。

WordPressでは、同じ正規フィールドを登録された投稿フィールドと投稿メタにマッピングします。例：post_title、post_excerpt、post_name、_amicited_entity、_amicited_author、_amicited_reviewed_by。<!-- wp:amicited/frontmatter -->のようなコメントや[frontmatter]ショートコードは、ドキュメントメタデータではなく本文ブロックを作成するため無効です。インポーターとエディターはメタデータパネルを表示できますが、保存された値は投稿レコードにアタッチされたままである必要があります。

例

良い例：1つの一貫性のある説明責任のあるレコード

entity = "guide-how-to"
id = "rotate-api-key"
title = "How to Rotate an API Key"
description = "Rotate an API key safely, update every dependent service, verify the replacement, and revoke the old credential without avoidable downtime."
url = "/academy/rotate-an-api-key/"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "rotate API key", "API key rotation", "revoke API key", "credential security", "API security", "secret rotation" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/rotate-an-api-key/"

これはハウツーバリアントを識別し、履歴を保持し、責任ある人物を指名し、トピックとページアイデンティティを分離しています。更新タイムスタンプは文書化された指示変更とレビューによってサポートされています。

悪い例：タイトルを説明として繰り返す

title = "How to Rotate an API Key"
description = "How to Rotate an API Key"

説明は利益、範囲、またはクリックする理由を追加していません。また、同じタイトルを使用する他のすべての結果からこのページを区別できるプレビュー領域を無駄にしています。

悪い例：1つのエンティティを2つの投稿タイプで再利用する

# 用語集エントリ
entity = "diagnosis"

# 編集ガイド
entity = "diagnosis"

共有トピックが投稿タイプのアイデンティティを置き換えています。glossary-termやguide-ultimateなどの登録値を使用し、「diagnosis」はタクソノミーまたはキーワードを通じて割り当てます。

悪い例：コンテンツ差分のない更新日

date = "2026-01-15 09:00:00"
updated = "2026-08-27 10:00:00" # 日付のみ変更

新しいさの主張をサポートする実質的な編集やレビューはありません。実際の変更が存在し、編集履歴で検査できるようになるまで、updatedは変更しないか省略したままにします。

スキーママークアップとアクセシビリティ

メタデータは値を提供します。テンプレートはセマンティックHTML、フォーカス、コントラスト、リンクの目的、代替テキストに対して責任を持ちます。

作成ルール

• 識別子を安定させ、小文字で、機械的に安全に保ちます。idを再利用したり、公開後にentityを黙って変更したりしないでください。
• タイトル類似フィールドではプレーンテキストを使用します。HTML、Markdownリンク、絵文字装飾、強制改行はメタデータ文字列に属しません。
• このプレイブックでは、説明を150～160文字、キーワード配列を6～8の個別のフレーズに保ちます。
• 作成者とレビュアーフィールドには実際の登録人物を使用します。儀礼的なレビュアーや一般的な「編集チーム」のアイデンティティは、それが維持された責任エンティティでない限り作成しないでください。
• 管理されたタクソノミーを使用します。スペルのバリアントや単数/複数の重複は断片化されたアーカイブを作成します。
• 存在し公開権利のある画像のみを参照します。imageAltは画像のSEOターゲットではなく、情報コンテンツを説明します。
• FAQの回答は直接的で自己完結型に保ちます。主張はページの他の場所の散文と同じエビデンスと開示を必要とします。
• 秘密、プライベートノート、アクセストークン、エンバーゴ指示、個人データ、未レビューの法的主張を公開可能なフロントマターに決して配置しないでください。

どの投稿タイプがフロントマターを使用し、どこで使用するか

すべての投稿タイプはバイト1でフロントマターを使用します。必要な深さは、ビジュアルデザインではなく、リスク、意図、スキーマに応じて変化します。

QAチェックリスト

• ファイルは+++で始まり、有効なTOMLを含み、本文コンテンツの前にレコードを閉じていますか？
• entityは、トピック、キャンペーン、サイト名ではなく、登録された正確な投稿タイプ識別子ですか？
• idは一意で安定しており、urlは正規スラグレジストリと一致していますか？
• title、オプションのh1、オプションのseoTitleは、欺瞞的な範囲変更なしに同じページを説明していますか？
• 説明は150～160文字で、主要な用語を自然に含み、クリックする具体的な理由を提供していますか？
• 参照されているすべての画像は存在し、imageAltはレンダリングされる画像に対して正確ですか？
• 公開日は保持されており、すべてのupdated値は実質的な差分または文書化されたレビューによってサポートされていますか？
• 作成者とレビュアーの識別子は実際の維持されたプロファイルに解決され、指名されたレビュアーは実際に作業をレビューしましたか？
• キーワードは6～8の有用なフレーズに制限され、タクソノミー値は管理された語彙から引き出されていますか？
• 正規URLはHTTPSを使用し、優先ページに解決され、サイトマップと内部リンクと一致していますか？
• すべての[[faq]]項目には、同一の表現で表示可能にレンダリングされる1つの有用な質問と自己完結型の回答が含まれていますか？
• 生成されたJSON-LDは表示可能なコンテンツと一致し、安定した識別子を使用し、サポートされていないタイプを主張せずに構文検証に合格していますか？
• 秘密、プライベート編集ノート、裏付けのない主張、本文のみの開示がレコードに存在しませんか？

FAQ

フロントマターは公開ページに表示されますか？

ソースレコードは非表示ですが、テンプレートはタイトル、人物、日付、FAQをレンダリングする場合があります。その他のフィールドはプレビュー、正規タグ、フィード、サイトマップ、スキーマ、内部システムに供給されます。

エンティティフィールドにはトピックと投稿タイプのどちらを含めるべきですか？

正確な投稿タイプを識別します。共有トピックはタクソノミーとキーワードに属し、ドキュメントのアイデンティティの代わりにはなりません。

タイトル、H1、SEOタイトルをそれぞれ異なるものにできますか？

はい。H1はより自然に読め、SEOタイトルは差別化要因を追加できますが、すべてのバージョンが同じ約束をする必要があります。

更新日はいつ変更すべきですか？

実質的な事実のレビューまたは編集の後に変更します。句読点、スタイリング、テンプレート作業、または日付のみのリフレッシュのために変更しないでください。

FAQの質問はなぜフロントマターに保存されるのですか？

構造化配列により、1つのソースが表示可能なFAQと一致するFAQPage JSON-LDの両方をレンダリングできます。これにより、スキーマが読者が検査できるものから乖離するのを防ぎます。