サイトリニューアルやURL変更、CMS・テンプレート改修では、画面が正しく表示されていてもSEO上は公開事故が起きます。特に危険なのは、テスト環境用のnoindexやrobots.txtが残る、canonicalが旧URL・検証環境を向く、301リダイレクトが欠けるといった検索エンジン向け設定の不整合です。
公開前チェックで扱う各技術要素の全体像は、[テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト](https://rebranding.co.jp/media/technical-seo/)で確認できます。
リリース前チェックは項目を大量に並べるのではなく、公開を止めるべきクリティカル項目を先に確認し、GO / HOLDを判断できる状態にすることが重要です。この記事では、変更種別ごとの必須確認、承認ゲート、公開後の再確認までを実務フローとして整理します。
SEOリリース前チェックは「公開してよいか」を決めるゲートにする
SEOリリース前チェックでは、最初に「問題が見つかったら公開を止める項目」と「公開後でも修正できる項目」を分けます。
すべてを同じ重みで扱うと、公開時刻が迫ったときに、noindexや誤ったcanonicalのような重大項目が埋もれてしまいます。
Googleはサイト移行時に、開発中だけ使用していたnoindexやrobots.txtの制限を公開時に解除すること、canonicalを新URLへ更新すること、リダイレクトをテストすることを案内しています。これらは公開判断に直接関わる項目です。
| 判定 | 状態 | 例 | 対応 |
|---|---|---|---|
| HOLD | 検索流入を失う可能性が高い | 重要URLがnoindex、robots.txtでブロック、canonicalが検証環境、必須リダイレクト欠落 | 修正・再QAまで公開しない |
| CONDITIONAL GO | 影響が限定的で修正計画がある | 一部の内部リンク更新漏れなど | 責任者・期限を記録して公開 |
| GO | クリティカル項目が合格 | index可能、canonical正常、必要な転送正常、主要URLが200 | 公開後確認へ進む |
SEOリリース前QAでは、確認したかどうかだけでなく、P0の結果を基準に公開可否まで判断します。
「確認済み」だけでなく、誰がGOを出したかまで記録すると、チェックリストが承認ゲートとして機能します。
公開前に最優先で確認する5つのSEOクリティカル項目
公開前は5項目を個別に見るだけでなく、canonical・リダイレクト・サイトマップ・内部リンクが同じ正規URLへ揃っているか確認します。
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は検索結果への掲載可否を制御します。
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へ転送します。
リダイレクトチェーンも可能な限り避けます。Googlebotは最大10ホップまで追えるとしていますが、サイト移行ガイドでは理想的には3以下、5未満に抑えるよう案内しています。
5. XMLサイトマップと内部リンクが正規URLへ揃っているか
canonicalだけが新URLでも、XMLサイトマップや内部リンクが旧URLを指していれば、検索エンジンへ送るシグナルが揃いません。
Googleはサイトマップには検索結果へ出したいcanonical URLを掲載し、完全な絶対URLを使うよう案内しています。
URL変更時は、サイトマップ、パンくず、グローバルナビ、関連記事、本文リンクを旧URL一覧と照合します。
「サイトマップが生成されたか」ではなく、「今回公開する正規URLが入っているか」まで確認します。
変更種別によって必須チェックを変える
SEOリリース前QAでは、毎回すべてを同じ深さで確認するのではなく、変更リスクに応じて確認範囲を変えます。
| 変更種別 | 必須確認 | 追加確認 |
|---|---|---|
| 本文・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確認」「公開判断」を分けます。
| 役割 | 主な責任 | 完了条件 |
|---|---|---|
| 実装者 | 設定・コード・転送を反映 | 自己チェックと差分提示 |
| SEO確認者 | noindex、robots、canonical、redirect、sitemapを検証 | P0項目をOK/HOLD判定 |
| 公開責任者 | 影響範囲と未解決事項を確認 | GO / CONDITIONAL GO / HOLDを決定 |
| 公開後確認者 | 本番URLを再検証 | 本番環境で正常を確認 |
CONDITIONAL GOを許可する場合は、未解決項目、影響URL、担当者、修正期限を残します。
「あとで直す予定」という状態だけで公開しないことが重要です。
そのまま使えるSEOリリース前チェックリスト
以下は、本番公開前の承認ゲートとして使うための基本形です。
公開前または公開後に4xxやsoft 404が見つかった場合は、一律転送せずURLごとに原因と正しい処置を判定してください。詳しい監査手順は[404・soft 404のSEO監査方法](https://rebranding.co.jp/media/404-soft-404-seo-audit/)で解説しています。
| 優先度 | チェック項目 | 合格条件 | 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 | 仕様どおり | 軽微な表記差のみ |
P0は、原則として1件でもNGならHOLDです。
P1は影響が限定され、修正対象・担当者・期限が明確な場合のみCONDITIONAL GOを検討します。
公開後は本番環境で同じ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影響を評価 |
大規模移行では、Googleも旧URLと新URLのトラフィックやクロール状況を継続監視するよう案内しています。
移行用の恒久リダイレクトは、一般に少なくとも1年間維持することが推奨されています。
よくあるSEOリリース事故
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も複数のcanonicalizationシグナルを組み合わせられると説明しています。
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事故を減らせます。
参考文献・データ元
- 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