サイトリニューアルやURL変更、CMS・テンプレートの改修では、画面が正しく表示されていても、検索エンジンから見ると公開事故が起きていることがあります。特に危険なのは、テスト環境用のnoindexやrobots.txtが残っている、canonicalが旧URLや検証環境を向いている、301リダイレクトが抜けている、といった検索エンジン向け設定の不整合です。
こうした事故を防ぐリリース前チェックで大切なのは、項目を大量に並べることではありません。公開を止めるべきクリティカル項目を先に確認し、GO（公開してよい）かHOLD（公開を止める）かを判断できる状態にすることです。
この記事では、変更の種類ごとの必須確認、公開を判断する承認ゲート、公開後の再確認までを、実務の流れとして整理します。読み進めると、自社のリリースでどこまで確認し、誰が公開を判断するかを決められます。公開前チェックで扱う各技術要素の全体像は、テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリストで確認できます。
SEOリリース前チェックは、公開してよいかを決めるゲートにする
この節で決めるのは、チェックの結果を「公開してよいか」という判断にどうつなげるかです。SEOリリース前チェックでは、最初に、問題が見つかったら公開を止める項目と、公開後でも修正できる項目を分けます。
すべてを同じ重みで扱うと、公開時刻が迫ったときに、noindexや誤ったcanonicalのような重大項目が埋もれてしまいます。
Googleはサイト移行時に、開発中だけ使用していたnoindexやrobots.txtの制限を公開時に解除すること、canonicalを新URLへ更新すること、リダイレクトをテストすることを案内しています。これらは公開判断に直接関わる項目なので、重大項目として先に確認します。
次の表は、確認の結果を3段階の判定にまとめたものです。自分のリリースの状態に当てはまる行を探し、右端の対応に従います。
| 判定 | 状態 | 例 | 対応 |
|---|---|---|---|
| HOLD | 検索流入を失う可能性が高い | 重要URLがnoindex、robots.txtでブロック、canonicalが検証環境、必須リダイレクト欠落 | 修正・再QAまで公開しない |
| CONDITIONAL GO | 影響が限定的で修正計画がある | 一部の内部リンク更新漏れなど | 責任者・期限を記録して公開 |
| GO | クリティカル項目が合格 | index可能、canonical正常、必要な転送正常、主要URLが200 | 公開後確認へ進む |
判定の軸になるのが、確認項目の優先度です。この記事では、公開可否に直結する最優先の項目をP0、影響が限定され、期限を決めて対応できる項目をP1、軽微な項目をP2と呼びます。
SEOリリース前QA（公開前の品質確認）では、確認したかどうかだけでなく、P0の結果を基準に公開可否まで判断します。
「確認済み」と記録するだけでなく、誰がGOを出したかまで残すと、チェックリストが承認ゲートとして機能します。
公開前に最優先で確認する5つのSEOクリティカル項目
ここで確認するのは、検索流入を失う事故につながりやすい5項目です。
5項目は個別に見るだけでなく、canonical・リダイレクト・サイトマップ・内部リンクが同じ正規URLへ揃っているかを合わせて確認します。なお、この5項目は設定の種類でまとめたもので、後述のチェックリストの優先度とは一致しません。チェックリストでは、サイトマップと内部リンクはP1に、この5項目に含まれないHTTPステータスはP0に分類しています。
1｜noindexとX-Robots-Tagが重要ページに残っていないか
公開対象では、HTMLのmeta robotsだけでなく、HTTPレスポンスヘッダーのX-Robots-Tagも確認します。
Googleは、noindexをmetaタグまたはHTTPヘッダーとして解釈し、クロール時に検出したページを検索結果から除外すると説明しています。PDFなどHTML以外ではX-Robots-Tagが使われることもあるため、画面ソースだけでは確認が足りない場合があります。
ステージング環境では、意図的にnoindexを使う場合があります。本番デプロイで設定が切り替わるのであれば、その切り替え自体をQAの対象にします。
2｜robots.txtが本番用になっているか
robots.txtは、クローラー（検索エンジンがページを巡回して情報を取得するプログラム）がどこを巡回してよいかを制御するファイルです。noindexが制御するのは、検索結果への掲載の可否です。
この2つは役割が違います。Googleは、robots.txtでブロックされたページではクローラーがnoindexを確認できないため、両者を混同しないよう案内しています。
公開前はドメイン直下のrobots.txtを取得し、Disallow: /などの開発用ルールや、重要ディレクトリの誤ブロックがないかを確認します。
Googleはrobots.txtを通常24時間程度キャッシュする場合があります。そのため、本番用ルールは直前ではなく事前に準備しておく方が安全です。
3｜canonicalが公開後の正規URLを指しているか
canonicalは、重複・類似URLの中で代表として扱ってほしいURLを示すシグナルです。
Googleは、リダイレクトとrel="canonical"を強いシグナル、サイトマップへの掲載を弱いシグナルと説明しています。また、canonicalページ自身にも自己参照canonicalを設定することを推奨しています。
公開前には、ステージングURL、旧ドメイン、http版、意図しないパラメータURLをcanonicalが指していないかを、テンプレート単位で確認します。
4｜301・308リダイレクトがURL対応表どおりに動くか
URL変更がある場合は、旧URLと新URLの対応表を作り、実際のHTTPレスポンスで転送先とステータスコードを確認します。
Googleは、恒久的な移転では301または308などのサーバーサイド恒久リダイレクトを推奨しています。旧URLを一律でトップページへ送るのではなく、内容が対応する新URLへ転送します。
転送が何段も続くリダイレクトチェーンも、可能な限り避けます。Googleは、Googlebotが最大10ホップまで追えるとしています。一方、サイト移行ガイドでは、理想的には3以下、5未満に抑えるよう案内しています。
5｜XMLサイトマップと内部リンクが正規URLへ揃っているか
canonicalだけが新URLでも、XMLサイトマップや内部リンクが旧URLを指していれば、検索エンジンへ送るシグナルが揃いません。
Googleは、サイトマップには検索結果へ出したいcanonical URLを掲載し、完全な絶対URLを使うよう案内しています。
URL変更時は、サイトマップ、パンくず、グローバルナビ、関連記事、本文リンクを旧URL一覧と照合します。確認するのは「サイトマップが生成されたか」ではなく、「今回公開する正規URLが入っているか」です。
変更種別によって、必須チェックはどう変わるか
この節では、変更の大きさに応じて確認の深さを決めます。毎回すべてを同じ深さで確認するのではなく、変更リスクに応じて確認範囲を変えるためです。
次の表は、変更種別ごとの必須確認と追加確認をまとめたものです。「上記＋」は、上の行までの必須確認をすべて含み、さらに加えるという読み方になります。
| 変更種別 | 必須確認 | 追加確認 |
|---|---|---|
| 本文・titleのみ変更 | index可否、canonical、200応答、内部リンク | 構造化データ、OGP |
| テンプレート・CMS変更 | noindex、robots、canonical、ステータス、内部リンク、サイトマップ | レンダリング後HTML、計測 |
| URL・ディレクトリ変更 | 上記＋旧新URL対応表、301/308、チェーン、404 | 外部リンク、hreflang |
| ドメイン移行・大規模リニューアル | 上記＋Search Console設定、旧新サイト監視 | Change of Address、ログ監視 |
表と図のとおり、URL変更やドメイン移行など影響範囲が大きいリリースほど、リダイレクトやSearch Consoleを含めてQAの対象を広げます。
URLを変えない小規模更新であれば、全旧URLの転送確認は不要です。
一方、URL変更ではリダイレクトとcanonicalを別々に見るのではなく、同じ新URLへ揃っているかを1セットで確認します。
実装者・SEO確認者・公開責任者を分ける
同じ担当者が実装・確認・承認をすべて行うと、自分の実装への思い込みから見落としが起きやすくなります。そのため、最低でも「実装」「SEO確認」「公開判断」の役割を分けます。
次の表では、この3つに、公開後の再確認を担う「公開後確認者」を加えた4つの役割について、責任と完了条件を示します。
| 役割 | 主な責任 | 完了条件 |
|---|---|---|
| 実装者 | 設定・コード・転送を反映 | 自己チェックと差分提示 |
| SEO確認者 | noindex、robots、canonical、redirect、sitemapを検証 | P0項目をOK/HOLD判定 |
| 公開責任者 | 影響範囲と未解決事項を確認 | GO / CONDITIONAL GO / HOLDを決定 |
| 公開後確認者 | 本番URLを再検証 | 本番環境で正常を確認 |
公開責任者がCONDITIONAL GOを許可する場合は、未解決項目、影響URL、担当者、修正期限を残します。「あとで直す予定」という状態だけでは、公開しないようにします。
そのまま使えるSEOリリース前チェックリスト
ここまでの判断基準を、本番公開前の承認ゲートとして使える形にまとめたのが、次のチェックリストです。
| 優先度 | チェック項目 | 合格条件 | HOLD条件 |
|---|---|---|---|
| P0 | HTTPステータス | 公開対象が200 | 重要ページが4xx/5xx |
| P0 | noindex / X-Robots-Tag | 公開対象にnoindexなし | 重要ページがnoindex |
| P0 | robots.txt | 重要URLをクロール可能 | 全体・重要領域を誤ってDisallow |
| P0 | canonical | 本番の正規URLを指す | 旧URL・検証環境・無関係URL |
| P0 | redirect | 対応表どおり301/308で最終URLへ | 欠落、誤転送、ループ |
| P1 | XMLサイトマップ | 正規URLを掲載 | 大量の旧・非正規URL |
| P1 | 内部リンク | 正規URLへ更新 | 重要導線が旧URL・404 |
| P1 | Search Console準備 | 対象プロパティを確認 | 移行後サイトを監視できない |
| P2 | title / description / OGP | 仕様どおり | 軽微な表記差のみならHOLD対象外 |
表の読み方は、優先度ごとに次のとおりです。P0は、原則として1件でもNGならHOLDです。
P1は影響が限定されるため、修正対象・担当者・期限が明確な場合のみCONDITIONAL GOを検討します。
公開前または公開後に4xxやsoft 404が見つかった場合は、一律転送せずURLごとに原因と正しい処置を判定してください。詳しい監査手順は404・soft 404のSEO監査方法で解説しています。
公開後は本番環境で同じP0項目を再確認する
ステージングで正常でも、本番で同じ結果になるとは限りません。CDN、WAF、CMSキャッシュ、環境変数などにより、本番だけ異なるHTTPヘッダーやHTMLが返る場合があるためです。
そこで公開直後は、主要URLのHTTPステータス、meta robots、X-Robots-Tag、canonical、robots.txt、リダイレクトを再確認します。
その後、Google Search ConsoleのURL検査でライブURLをテストします。URL検査では、Googleがページを取得できるか、インデックス可能か、レンダリングされたページやレスポンス情報などを確認できます。
確認のタイミングと目的は、次の表のとおりです。
| タイミング | 主に見るもの | 目的 |
|---|---|---|
| 公開直後 | P0項目、主要導線 | 実装事故を即時発見 |
| 24時間以内 | URL検査、サイトマップ処理、クロールエラー | Googleからの取得可否を確認 |
| 7日後 | インデックス状況、旧新URL、404 | 再クロールの進行確認 |
| 28日後 | 検索流入、主要クエリ、CV | SEO影響を評価 |
表の確認は28日後までですが、大規模移行では、Googleも旧URLと新URLのトラフィックやクロール状況を継続監視するよう案内しています。
移行用の恒久リダイレクトは、一般に少なくとも1年間維持することが推奨されています。
よくあるSEOリリース事故3つと確認のしかた
実際に起きやすい事故を3つ挙げます。いずれも、ここまでの確認項目のどこかが抜けたときに起きます。
1つ目は、CMS上ではindex設定でも、WebサーバーやCDNがX-Robots-Tag: noindexを付与しているケースです。このため、HTMLとHTTPヘッダーの両方を確認します。
2つ目は、robots.txtとnoindexを同じものとして扱うケースです。robots.txtでクロールを止めると、Googleがnoindexを読めない場合があります。別項目として検証します。
3つ目は、canonicalだけ新URLにして、内部リンクやサイトマップが旧URLのまま残るケースです。canonical、サイトマップ、内部リンク、リダイレクトの指し先は、同時に照合します。Googleも、正規URLの判断に複数のシグナルを組み合わせられると説明しています。
SEOリリース前チェックを再現できる公開プロセスにする
最後に、ここまでの確認を、誰が担当しても同じ手順で回せる公開プロセスにします。
SEOリリースQAは公開ボタンを押した時点で終了せず、本番環境の再確認とSearch Consoleでの継続確認までを一つの運用として設計します。
SEO事故を減らすには、担当者の注意力に依存するのではなく、変更種別、P0/P1、GO/HOLD判定、確認者、公開後確認を標準化します。最低限、次の流れを1つの公開プロセスとして固定します。
- 変更範囲を確定する
- 変更種別から必須QAを決める
- P0項目を検証する
- SEO確認者がOK / HOLDを判定する
- 公開責任者がGOを出す
- 本番公開後にP0を再検証する
- Search Consoleで取得・インデックス状況を確認する
Googleの仕様は変わるため、チェックリスト自体にも更新日と根拠となる公式情報を持たせます。robots、canonical、リダイレクト、Search Consoleなどの仕様が変わった場合は、チェック項目そのものを更新してください。
まとめ
SEOリリース前チェックは、noindex、robots.txt、canonical、301/308リダイレクト、XMLサイトマップを個別に確認するだけでは足りません。
変更種別に応じて必須項目を決め、検索流入を失う可能性があるP0項目をHOLD条件として固定し、公開責任者がGOを出せる承認ゲートにします。さらに、公開直後に本番HTML・HTTPヘッダー・リダイレクトを再確認し、Search Consoleで取得・インデックス状況を追います。
公開前と公開後を1つのQAフローにすれば、「設定したつもり」「確認したはず」によるSEO事故を減らせます。最初の一歩として、次のリリースで変更種別を決め、その種別の必須確認とP0のHOLD条件を書き出してみてください。
参考文献・データ元
この記事で参照した情報を確認できます。
- Google Search Central「How to move a site」：サイト移行時のnoindex、robots.txt、canonical、redirect、公開後監視。最終更新 2026年8月20日。 URL: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- Google Search Central「Block Search indexing with noindex」：noindex、X-Robots-Tag、robots.txtとの関係。最終更新 2025年12月10日。 URL: https://developers.google.com/search/docs/crawling-indexing/block-indexing
- Google Search Central「How to specify a canonical URL」：canonicalシグナルと自己参照canonical。 URL: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
- Google Crawling Infrastructure「How Google interprets the robots.txt specification」：robots.txtの作用範囲とキャッシュ。最終更新 2026年7月8日。 URL: https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec
- Google Search Central「Redirects and Google Search」：恒久・一時リダイレクトの仕様。最終更新 2026年4月14日。 URL: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central「Build and submit a sitemap」：canonical URLとXMLサイトマップ。最終更新 2026年7月8日。 URL: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
- Google Search Console Help「URL Inspection tool」：公開後のライブURL検査とインデックス確認。 URL: https://support.google.com/webmasters/answer/9012289?hl=en
‹ 親記事: テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト
関連記事
- › INDEX削除（インデックス削除）とは？検索結果から消える仕組みと対処法
- › Core Web Vitals改善ガイド｜LCP・INP・CLSの原因特定と優先順位付け
- › SEO内部リンクの確認方法｜孤立ページ・深度・アンカー偏りを改善
- › ページがインデックスされない原因は？Search Consoleで未登録・除外・重複URLを確認
- › JavaScript SEOの確認方法｜表示・内部リンク・登録状況
- › クロールバジェットの確認方法｜無駄なクロールと改善優先度
- › 構造化データの確認方法｜エラー・本文との不一致・重複を検証
- › 多言語ページの言語・地域指定を確認｜相互参照・正規URLをチェック
- › 絞り込み検索のSEO確認方法｜URL増加・クロール・重複を防ぐ
- › SEOリダイレクトの確認方法｜多段転送・ループ・誤転送を検出
- › robots設定のSEO確認方法｜クロール許可と登録制御の矛盾を確認
- › ページネーションのSEO確認方法｜正規URL・内部リンク・クロール
- › サイト移行後のSEO確認方法｜転送・正規URL・順位変動を確認
- › 404・soft 404のSEO確認｜リンク切れ・消失URLを修正
- › 画像SEOの確認方法｜alt・画像URL・遅延読み込みを確認
- › 求人ページの構造化データを確認｜給与・勤務地・期限の不一致
- › サイト内検索ページのSEO確認｜noindex・クロール・重複URL
- › サイトリニューアルでSEO評価を落とさない移行方法｜URL・301・計測・公開手順
- › サービス終了ページは削除すべき？301・404/410・残す場合のSEO判断基準
- › SEOに強いURL・ディレクトリ設計｜階層・命名・変更時の注意点
- › サブディレクトリとサブドメインの違い｜SEO・運用の判断基準
- › リッチリザルトとは？種類・構造化データ・表示確認方法を解説
- › Google Search Consoleとは？登録方法と最初に見る4つの指標
