公開前SEOチェックリスト

公開前品質保証（QA）は、SEOプロセス における最終リリースゲートです。ここでは、投稿タイプ準拠、正しい要素の使用、および先行する調査、エビデンス、実装、レビュー作業の完了という3つの契約が交わります。該当する項目に不合格があるページは修正のために差し戻されます。

ゲート： 最終公開前QA。時間枠： 標準的なページで60～90分。規制対象、セキュリティ、金融、医療、または技術的に重大な主張については、専門家の時間を追加。責任者： 最終実装を行っていない、公開をブロックする権限を持つ1名の編集者、コンテンツリード、またはSEOリード。

ソフトなチェックリストはチェックリストではありません。「ほとんど完了」には安定した意味がないからです。期限が迫ると、任意の表現は記憶補助になり、困難なチェックは消えてしまいます。QA開始前にリリース権限者を指名してください。QA責任者は合格または不合格を判断できます。不合格を通知できるのは、指名されたコンテンツ責任者、SEOリード、または同等の者のみで、文書化された例外を承認したり、項目を非該当と判断したりできます。虚偽の主張、不足している必須要素、プレースホルダーアセット、壊れた正規URL、ブロックされたインデックス可否を期日に合わせて免除することはできません。

このゲートが存在する理由と、ここで実行される理由

このゲートは、承認された投稿タイプ仕様、要素契約、ソースレコード、最終コピー、実装済み候補、専門家の承認を消費します。これらの入力が凍結された後に実行されます。QAは動く標的を検証できないからであり、公開前に行うのは、URLが公開され次第、欠陥がコピーされる可能性があるからです。

早期のQAは変更される可能性のあるドラフトを認定します。これをスキップすると、後の監査担当者は、ページのずれ、仕様の変更、一度もチェックされていないページを区別できなくなります。公開後のQAは、安価な修正を公開された欠陥に変えてしまいます。

入力と出力

出力は契約であり、チャットメッセージではありません。公開担当者はレビューを再構成することなく、それに基づいて行動できなければなりません。

チェックリスト

以下の各項目には、アクション、理由、方法、ツール、および観察可能な完了条件が含まれます。「SEO確認済み」や「問題なさそう」は決して受け入れ可能なエビデンスではありません。

1. 投稿タイプ準拠

選択した投稿タイプと範囲を確認する。 何： 候補を投稿タイプライブラリ の1つのエントリに一致させ、兄弟タイプに属する内容を削除する。なぜ： ページタイプは、意図、構造、エビデンス、コンバージョン動作を決定する。方法： 各セクションに、それがサポートする読者の判断をラベル付けし、タイプの目的と除外事項と比較する。ツール： 承認済み概要、トピックマップ、投稿タイプページ。完了条件： 正確に1つの主要タイプが記録され、導入部、本文、CTAがそれを対象とし、別のタイプの役割のためだけに存在するセクションがゼロである。

必要な構造と語数範囲をトレースする。 何： すべての必須セクションをレンダリングされた候補にマッピングし、指定された範囲に対して語数をカウントする。なぜ： 欠落したセクションは未回答の疑問を生み、管理されない長さは量の背後にギャップを隠す。方法： 要件と見出しのマトリックスと自動カウントを使用し、境界ケースを手動で検査する。ツール： 投稿タイプ仕様、ソース、レンダリングされたページ。完了条件： 必須セクションの欠落がゼロであり、すべてのセクションが指定された最小値と最大値の範囲内にある。

2. 要素準拠

要素、位置、パラメータを検証する。 何： 要素マップをソースおよびレンダリングと比較する。なぜ： 位置とフィールドは機能の一部であり、埋もれたダイレクトアンサーはもはや最初に答えず、不正なパラメータは出力を壊す可能性がある。方法： 上から下まで検査し、許可されたフィールド、値、ネスト、構文を検証する。ツール： 要素仕様、バリデータ、ブラウザ。完了条件： すべての必須要素が必要な位置にあり、すべてのパラメータが有効で、説明のつかない重複が残っていない。

型付き要素の優先順位を適用する。 何： パッセージに登録された目的がある場合は常に、要素記述ルール を適用する。なぜ： フリーテキストは似ているように見えても、コンポーネントのアイデンティティ、フィールド、アクセシビリティ動作、構造化出力を保持できない。方法： 各ブロックの役割を動詞（定義する、警告する、比較する、指示する、要約する）として記述し、一致する要素を確認する。ツール： 要素ライブラリとソースインスペクタ。完了条件： 型付き要素が必須である場所でフリーテキストを使用しているパッセージがゼロである。

3. コンテンツ品質

回答を単独でテストする。 何： ダイレクトアンサーブロック を見出しや周囲の段落なしで読む。なぜ： 検索およびAI検索システムはそのパッセージのみを抽出する可能性がある。方法： 主題を明示し、質問に答え、必要な限定条件を含み、「これ」「それ」「上記参照」に依存していないことを確認する。ツール： 分離テキストビューと人間のレビュー担当者。完了条件： 回答が自己完結的で正確であり、その要素が必須の場合、指定された40～60語の範囲内にある。

主張、言語、独自性を検証する。 何： 重要な主張をエビデンスにトレースし、専門用語を初出時に説明し、同じ意図を提供するページと候補を比較する。なぜ： 裏付けのない主張は信頼を損ない、ほぼ重複したコンテンツは競合してずれを生む。方法： 名前、日付、数値、因果的主張、製品動作、類似候補にフラグを立て、裏付け、限定、統合、または削除する。ツール： エビデンス登録簿、一次ソース、サイト検索、類似性レポート。完了条件： 裏付けのない重要な主張がゼロ、未説明の専門用語がゼロ、統合計画なしに同じ意図と範囲に答える既存ページが存在しない。

4. フロントマター

IDとプレビューフィールドを検証する。 何： フロントマター仕様 をタイトル、説明、キーワード、entity、投稿タイプ結合に適用する。なぜ： これらのフィールドは、本文を読まずにルーティング、プレビュー、スキーマ、関係性を駆動する。方法： フィールドと長さの検証を実行し、その意味を表示ページと比較する。ツール： フロントマターリンターと人間によるプレビュー。完了条件： タイトルが一意で正確、説明が150～160文字、キーワードに関連する6～8件のエントリ、entityが投稿タイプ契約と一致している。

ガバナンスとFAQフィールドを検証する。 何： 日付、著者、レビュー担当者、所有権、表示されるFAQ構造 をフロントマターと照合する。なぜ： 匿名の記録は説明責任を妨げ、FAQのずれは表示と構造化回答を不一致にする。方法： フィールドをリリース証跡および正規化された表示テキストと比較する。ツール： ソースパーサー、トラッカー、レンダリングされたページ。完了条件： 必要な日付と所有者が有効、人間のレビュー担当者が必要な場所で指名されている、FAQ数がタイプの最小値を満たしている、すべてのペアが一致している、非表示または空のエントリが残っていない。

5. 構造化データ

正しいスキーマを要求する。 何： 該当するスキーママークアップ がページとその表示要素に存在することを確認する。なぜ： 欠落または一般的なマークアップは、コンテンツモデルがすでに提供している機械可読な意味を破棄する。方法： 出力されたタイプとプロパティを投稿タイプおよび要素契約と比較する。ツール： レンダリングされたHTMLとスキーマバリデータ。完了条件： 必要な各スキーマタイプが1回存在し、必要なプロパティが入力され、該当しないタイプが出力されていない。

構文だけでなくパリティを検証する。 何： スキーマの名前、日付、著者、エンティティ、FAQ、手順、主張を表示コンテンツと比較する。なぜ： 有効な構文でも、非表示または矛盾した情報を記述している可能性がある。方法： JSON-LDを検証し、値をページと比較する。ツール： 構造化データテストと人間によるレビュー。完了条件： エラーがゼロであり、スキーマ内に表示コンテンツと矛盾またはそれを超える事実がゼロである。

6. 内部リンク

上位および横方向にリンクする。 何： 関連するピラーページへのルートと、関連ノードへのコンテキストルートを提供する。なぜ： 階層は読者とクローラーがページの所属を理解するのに役立ち、横方向リンクは読者のタスクを継続させる。方法： 各内部リンクを、数を埋めるためではなく、真の次の質問にマッピングする。ツール： リンクグラフとレンダリングされたページ。完了条件： ページがピラーへの少なくとも1つのリンク、関連ノードが存在する場合は少なくとも1つの関連する横方向リンクを持ち、公開時またはそれ以前に少なくとも1つの既存ページがこのページにリンクしているため孤立していない。

宛先とアンカーを検査する。 何： すべての宛先を開き、アンカーテキスト をレビューする。なぜ： もっともらしいURLでも欠落、リダイレクト、無関係である可能性があり、一般的なラベルは宛先の目的を隠す。方法： 内部リンクチェッカーを実行し、文脈の中でアンカーを手動で検査する。ツール： クローラーとブラウザ。完了条件： エラーを返す内部リンクがゼロ、すべての宛先が周囲の主張をサポートし、独立した「ここをクリック」、生のURL、誤解を招く完全一致アンカーが残っていない。

7. メディア

アセット、代替テキスト、鮮度を検証する。 何： すべての画像が存在し、意味のある代替テキスト または正当化された空の代替を持ち、現在のインターフェースを反映していることを確認する。なぜ： 壊れた、曖昧な、プレースホルダー、または古いメディアは情報を削除し、指示を使用不能にする可能性がある。方法： 画像を無効にし、パスを検査し、製品の手順を再現し、ラベル、値、クロッピング、編集を比較する。ツール： アセットチェッカー、アクセシビリティ監査、ライブ製品、ブラウザ。完了条件： 欠落またはプレースホルダーのアセットがゼロ、代替テキストが正確、すべてのスクリーンショットが現在の手順を表している。

8. 技術リリース

ルーティング、インデックス可否、置換を検証する。 何： スラッグ、1つの自己参照正規URL 、ステータス、ロボット動作、インデックス可否 、リダイレクトを確認する。なぜ： コンテンツは間違ったルート、noindexの背後、または古いURLが取り残された状態では機能できない。方法： レンダリングされたヘッドとレスポンスを検査し、レジストリと比較し、置換されたすべてのルートを追跡する。ツール： ヘッダーチェッカー、リダイレクトマップ、ソースインスペクタ、URLインスペクション。完了条件： 承認されたURLが、1つの意図された正規URLで200を返し、ブロックがない。置換された各URLが、最も近い有効な置換先への1つの恒久的なホップを取る。

モバイルの安定性をテストする。 何： 狭い画面での読み取り、インタラクション、オーバーフロー、Cumulative Layout Shift を検査する。なぜ： デスクトップで動作するコンポーネントでも、コントロールが隠れたり、テーブルが切れたり、メディアの読み込みに伴ってコンテンツが移動したりする可能性がある。方法： 代表的なモバイル幅でテストし、スロットリングをかけてページを読み込む。ツール： ブラウザのデバイスモードとパフォーマンスレポート。完了条件： すべてのコンテンツとコントロールが水平方向のページオーバーフローなく使用可能であり、測定されたCLSが0.1以下である。

9. AI対応準備

抽出と初期HTMLをテストする。 何： サーバー配信のHTML内で、回答、定義、重要な事実、比較、結論を独立したパッセージとして検査する。なぜ： 検索システムは1つのパッセージを選択する可能性があり、クライアントサイドのコードを実行しない場合がある。方法： 初期HTMLを取得し、周囲のコンテキストを削除し、エンティティ名、限定条件、単位、代名詞を確認する。ツール： HTML取得、パッセージ抽出ツール、ブラウザ、AmICited監査。完了条件： すべての優先事項がJavaScriptなしで存在し、単独でも主題、意味、制限を保持している。

手順構造を公開する。 何： FAQペアと順序付き手順が認識可能なフィールドとしてエンコードされ、表示されたままであることを確認する。なぜ： 見出しとスタイル付きボックスは正しく見えても、機械は非構造化散文を受け取る可能性がある。方法： 要素出力、アクセシブルな構造、スキーマを表示シーケンスと比較する。ツール： アクセシビリティツリーと構造化データバリデータ。完了条件： 必要なすべてのFAQが質問と回答のペアとして機械可読であり、必要なすべての手順が表示と構造化出力の両方で順序付きステップを保持している。

AmICitedのツール

製品を使用して候補を検査し、引き継ぎのエビデンスを確立します。人間の判断を置き換えるものではありません。

1. エージェント対応監査を開く と共にAIアクセシビリティとエージェント対応 を確認し、アクセシビリティ、クローラー到達可能性、サイトマップカバレッジ、エージェント可読コンテンツを検査する。
2. URLインスペクション で候補URLを検査 し、インデックスステータス、モバイルユーザビリティ、リッチリザルトの判定を確認する。新しいURLの場合は、引き継ぎでライブ検査を割り当てる。
3. フレッシュネス監査 をコンテンツフレッシュネス と共に開き、時間に敏感なページにメンテナンスシグナルと次回レビュー日を設定する。履歴はトラッキング開始時に始まる。履歴がないことは変更がないことを意味しない。
4. ワークスペース接続を介してSEO MCP を使用し、反復可能な読み取り専用のURL、フレッシュネス、Web Vitals、アクセシビリティチェックを実行する。出力または実行IDを保存する。

自動化：決定論的チェックをスクリプト化し、人間の判断を保持する

スクリプト化できるが手動のままのチェックは、プレッシャーの下でスキップされます。安定した機械で観測可能な結果は自動化し、目的、真実、コンテキストは人間に委ねてください。

自動化はエビデンスを書き、承認は書きません。不合格はゲートをブロックします。スクリプトの合格は人間の列の合格を意味しません。

判定ルール

「悪い」は観測可能でなければなりません。選択した投稿タイプまたは要素がより厳しい基準を定義している場合を除き、以下のしきい値を使用します。より具体的な契約が優先されます。

N/Aは緩い合格ではありません。項目が本当に該当しない場合（例えば、置き換えるURLがないためリダイレクトが不要な場合）にのみ有効であり、記録にはその理由を記載しなければなりません。例外は、変更されたルール、ビジネス上の理由、リスク、承認者、修正担当者、有効期限を記載しなければなりません。リリース権限者が署名します。QAレビュー担当者が自己承認することはできません。

成果物：合格記録

正確な候補に1つの不変の記録を添付してください。後の監査で「未チェック」と「仕様バージョン1でチェックされ合格」を区別できなければなりません。緑色のチェックマークのスクリーンショットではなく、構造化されたフィールドを保存してください。

ページパス / 正規URL：
リリース候補IDまたはコンテンツハッシュ：
投稿タイプとエンティティ：
仕様バージョン：
QA責任者：
リリース権限者：
開始 / 完了（タイムスタンプ）：

チェック：
- グループ / 項目：
- 結果：合格（PASS）| 不合格（FAIL）| 非該当（N/A）
- エビデンス：バリデータ出力、ソースの場所、宛先、または観察結果
- チェック担当者 / 日時：

例外：
- ルールと範囲：
- 理由とリスク：
- 承認者：
- 修正担当者 / 有効期限：

決定：合格（PASS）— 公開 | 不合格（FAIL）— 保留
ライブ検証担当者と期限：
次回メンテナンスレビュー日：

合格記録は追加専用です。仕様または候補が変更された場合は、履歴を書き換えるのではなく、新しい監査を実施します。

不合格時の対応

不合格はレビュースレッドでの交渉ではなく、修正ループを開始します。

1. QA責任者は候補を**不合格（FAIL）— 保留（HOLD）**とマークし、エビデンスを記録し、継続すると確実に変更されるバージョンをテストすることになる時点で停止します。
2. コンテンツ所有者は、投稿タイプ、要素、コピー、メタデータ、エビデンスの不合格を修正します。実装所有者は、スキーマ、リンク、メディア、ルーティング、レンダリング、自動化の不合格を修正します。専門家は自身のドメインの主張を再確認します。
3. 修正担当者は、変更されたすべての表面を特定します。QA責任者は、不合格となった項目、その依存項目、および変更の影響を受けるグループを再実行します。例えば、書き直された回答は、主張、要素準拠、スキーマパリティ、AI抽出を再開します。
4. QA責任者は、新しいタイムスタンプ付きの結果を作成します。該当するすべての項目が合格し、すべてのN/Aまたは例外に有効な権限が付与されるまで、公開はブロックされたままです。

著者は自身の修正を認定しません。QAが記録を所有し、制作が修正を所有し、専門家がドメイン承認を所有し、リリース権限者が例外を所有します。

よくある問題

• ゲートを校正として扱うこと。 文法が完璧でも、ページが間違った投稿タイプを使用していたり、スキーマと矛盾していたり、インデックス不可だったりする可能性があります。
• リリース候補ではなくソースをテストすること。 有効なMarkdownは、テンプレートが意図された正規URL、アクセシブルな構造、またはレスポンシブレイアウトを出力したことを証明しません。
• すべての項目を手動にすること。 レビュー担当者が決定論的チェックを繰り返しクリックし、期限が来るまでリストをスキップする習慣がつきます。
• すべての項目を自動化すること。 緑色のバリデータは、エビデンスが因果的主張を裏付けるかどうか、または比較が読者の判断に答えるかどうかを判断できません。
• 「公開後に修正する」を受け入れること。 これにより、公開前ゲートが文書化されていないバックログに変わり、合格（PASS）の意味が消去されます。
• 同じ人が実装と承認を行うこと。 自己レビューは、実際の出力を観察するのではなく、意図した動作を記憶するため、前提を見逃します。

引き継ぎ

次の状態は公開とライブ検証です。QAは、承認済み候補、合格（PASS）記録、正規URLルート、リダイレクトマップ、公開ウィンドウ、承認済み例外を引き渡します。公開担当者はライブURLとデプロイ時刻を返します。ライブ検証担当者は、ステータス、正規URL、インデックス可否、リダイレクト、スキーマ、リンク、メディア、モバイル、CTAのチェックを繰り返します。

本番環境が異なる場合、影響を受けるチェックが再開されます。一致する場合は、候補の結果を上書きせずにライブURLとエビデンスを追加します。後の監査では、保存された仕様バージョンを使用して、ずれと変更された基準を区別します。

FAQ

よくある質問

合格（PASS）とは、候補が現在の契約に適合し、検査可能なエビデンスがあることを意味します。それ以外はすべて保留（HOLD）です。アカデミーレイアウトの closing CTA はこのFAQの後に続きます。