テストサイトのnoindexを外し忘れないための公開前確認

テストサイトで検索エンジンへの登録を避けるために付けたnoindexが、本番公開後も残っていると、ページは閲覧できても検索結果へ登録されません。解除漏れを防ぐには、CMSの設定画面でチェックを外したかどうかではなく、公開対象の本番URLが実際に返している内容を基準に承認する必要があります。

公開前に見るべきものは、meta robotsだけではありません。HTTPレスポンスヘッダーのX-Robots-Tag、CMSやSEOプラグインの設定、robots.txt、認証、canonical、サイトマップが互いに矛盾していないかを確かめます。さらに公開後は、ログインしていない状態で本番URLへアクセスし、Search ConsoleのURL検査でライブURLを確認します。

大切なのは「noindexを外す」という一つの操作を手順化することではなく、次の三つをつなげることです。

• どのURLを検索対象にするかを先に決める
• そのURLへnoindexを出力し得る設定元を把握する
• 本番URLの実際の出力とGoogleが取得できる状態を確認する

この形にすると、制作担当者が設定を変更し、Web担当者が公開を承認する場合でも、確認内容が「たぶん外した」ではなく、URLごとの証拠として残ります。

公開承認の基準を「設定変更」から「本番URLの状態」へ変える

noindexは、HTMLのrobotsメタタグでnoindexを指定する方法やHTTPレスポンスヘッダーのX-Robots-Tag: noindexなどで検索エンジンへ伝えられます。CMSの管理画面は、その出力を操作する入口の一つにすぎません。テーマ、SEOプラグイン、サーバー、CDN、公開環境の設定が別に存在すれば、管理画面上では解除済みに見えても、本番URLにはnoindexが残ることがあります。

反対に、HTMLへindexが出ているから安全とも限りません。別の場所からnoindexが返っている場合、より制限の強い指示が適用されます。したがって、公開承認は「この設定を変えた」という作業報告ではなく、次の条件を本番URLで満たしたかどうかで判断します。

公開判定の対象	合格とする状態
閲覧	ログインや社内ネットワークに依存せず、公開予定URLを取得できる
robots指示	HTMLとHTTPヘッダーのどちらにも、意図しないnoindexがない
クロール	公開対象URLがrobots.txtで遮断されていない
正規URL	canonicalがテスト環境や旧URLではなく、意図した本番URLを示す
サイトマップ	検索対象にする正規URLだけが載り、テストURLや除外URLが混ざっていない
Googleからの取得	URL検査のライブテストで、公開ページとして取得できる

この表のすべてを一度に全URLで確認するのが難しい場合でも、トップページだけで済ませてはいけません。ページ種別ごとに代表URLを選び、共通テンプレートと個別設定の両方を確認します。

先に「検索に出すURL」と「出さないURL」を分ける

noindex解除の作業を始める前に、公開対象URLの一覧を作ります。ここが曖昧だと、解除漏れだけでなく、本来は検索結果へ出したくない確認ページや完了ページまで一括でindex対象にしてしまいます。

一覧には、少なくとも次の項目を持たせます。

• 本番URL
• ページ種別または使用テンプレート
• 検索対象にするか
• noindexを出力する設定元
• canonicalの予定先
• サイトマップ掲載の要否
• 確認担当者と確認時刻

検索対象にするページの例は、トップページ、主要なサービスページ、会社情報、問い合わせ導線の入口、公開する記事や実績ページです。一方で、問い合わせ完了ページ、会員限定ページ、重複する絞り込みURL、社内確認専用ページなどは、意図的にnoindexとする場合があります。サイトの目的や構成によって判断は変わるため、「サイト全体をindexにする」という一括判断ではなく、URLまたはテンプレート単位で決めます。

公開前の一覧は、全URLを人手で列挙するだけの表にしなくても構いません。共通テンプレートで同じ設定が出るページは、代表URLを決めたうえで、例外ページを別に記録します。たとえば、固定ページ、投稿、カテゴリ、カスタム投稿、検索結果、添付ファイルなど、出力経路が異なる単位で代表URLを持つと、確認の抜けを見つけやすくなります。

PDFなどHTML以外のファイルを公開する場合も注意が必要です。meta robotsを持たないファイルでは、HTTPヘッダーのX-Robots-Tagで制御されていることがあります。記事ページだけを確認して、配布資料や画像ファイルのレスポンスを見ていないと、意図した公開範囲とずれる可能性があります。

noindexを出力し得る設定元を一枚にまとめる

公開事故を防ぐには、設定画面の場所を覚えるより、どの層が最終出力へ影響するかを整理します。制作会社、社内担当者、サーバー管理者で担当範囲が分かれている場合は、次のような設定元マップを作ると確認先が明確になります。

設定の層	noindexが出る主な場所	公開前の確認
HTML	テーマ、テンプレート、個別ページ設定、SEOプラグイン	ページソースまたは開発者ツールでrobotsメタタグを確認
HTTPヘッダー	Webサーバー、CDN、セキュリティ設定、ファイル種別ごとのルール	最終URLのレスポンスヘッダーでX-Robots-Tagを確認
CMS全体	検索エンジンへの表示を抑制する全体設定	管理画面だけでなく、公開ページの実出力も確認
環境設定	環境変数、ビルド設定、デプロイ時の設定ファイル	テスト用の値が本番ビルドへ引き継がれていないか確認
アクセス制限	Basic認証、IP制限、メンテナンスモード	ログアウト状態と外部ネットワークから取得できるか確認
URL正規化	canonical、リダイレクト、ドメイン・URL置換	最終URLとcanonicalが本番の正規URLで一致するか確認

WordPressには、検索エンジンがサイトをインデックスしないよう促す全体設定があります。ただし、管理画面のチェック状態だけを公開判定にしてはいけません。テーマが必要な出力処理を行っていない場合や、別のSEOプラグイン・サーバー設定が上書きしている場合は、画面上の状態と公開ページの出力が一致しない可能性があります。

個別ページにもnoindexを設定できる構成では、全体設定を解除しても一部ページだけ残ります。反対に、全体設定を解除する操作で、意図的に除外していたページまでindex対象へ変わることもあります。全体設定、テンプレート設定、個別設定の優先関係を確認し、どこを変更すればどのURLへ反映されるかを記録します。

HTTPヘッダーは見落とされやすい場所です。HTML内にnoindexが見当たらなくても、X-Robots-Tag: noindexが返れば検索エンジンへの指示は残ります。CDNやサーバーの設定はCMSの外側にあるため、CMS担当者だけでは確認できないことがあります。公開手順には、ヘッダーを確認できる担当者と確認方法を含めておきます。

テスト環境と本番環境を、同じスイッチで管理しない

テストサイトは、未公開の内容や確認途中のページを含むため、検索結果へ出さない設計が必要です。ただし、その役割をnoindexだけに任せると、本番へ複製したときに解除漏れが起きやすくなります。

テスト環境では、Basic認証やIP制限などで第三者が閲覧できない状態を基本にし、noindexは補助的な防御として扱います。本番環境では、公開対象ページの認証を外し、検索対象URLだけnoindexを解除します。環境ごとに設定値を分け、テスト環境の設定ファイルやデータベースを本番へそのまま持ち込まないことが重要です。

特に注意したいのは、次のような切り替えです。

• テスト用ドメインから本番ドメインへURLを置換する
• ステージングのデータベースを本番へ複製する
• 本番へ初回デプロイした後、修正のため再度テスト環境から上書きする
• CDNやキャッシュを有効にした状態で設定を変更する
• 公開直前にSEOプラグインやテーマを更新する

最初の公開時にnoindexを解除しても、その後の再デプロイやデータ移行で古い設定が戻ることがあります。そのため、解除確認は一回限りの作業ではなく、本番へ反映するたびに通す公開ゲートとして扱います。

テスト環境と本番環境で設定を分ける方法は、CMSや構築方法によって異なります。環境変数、設定ファイル、デプロイ処理、ドメイン判定など、どの方式でも構いません。ただし、担当者の記憶や手作業だけに依存せず、「本番ではこの値」「テストではこの値」が再現できる形にします。

公開前は代表URLのHTML・ヘッダー・最終到達先を確認する

本番公開の直前には、公開予定の環境で代表URLを確認します。可能であれば、本番ドメインを一時的に確認端末だけで向ける方法や、公開直前のプレビューURLを使います。ただし、最終承認は実際の本番URLで行うため、事前確認の結果だけで完了扱いにはしません。

確認は、ログインしていないブラウザのプライベートウィンドウで行います。管理者としてログインした状態では、キャッシュの除外、プレビュー権限、認証の通過などにより、一般の閲覧者や検索エンジンと異なる応答になる場合があるためです。

まずリダイレクト後の最終URLを確定する

httpからhttps、wwwあり・なし、末尾スラッシュ、旧URLから新URLなど、途中でリダイレクトする構成では、最初に入力したURLだけでなく、最終到達先を確認します。途中の応答や最終応答へX-Robots-Tagが付くこともあるため、リダイレクトチェーン全体を見るのが安全です。

ブラウザの開発者ツールでは、Network欄から各応答のステータス、Location、レスポンスヘッダーを確認できます。コマンドを使える場合でも、確認する内容は同じです。最終URLまで追跡し、途中と最終応答のステータス、Location、X-Robots-Tagを記録します。

X-Robots-Tagが表示された場合は、その値を確認します。noindexが残っていれば、CMSの画面ではなく、そのヘッダーを付けているサーバー、CDN、アプリケーションの設定元を修正します。

HTMLのrobotsメタタグを実出力で見る

ページソースまたは開発者ツールで、robotsやgooglebotを検索します。公開対象ページにnoindexがなければ、少なくともHTML側の解除を確認できます。コマンドでHTMLを取得する場合も、robots関連の指定が実際のHTMLに出ているかを確認します。

確認結果は、取得したURL、確認時刻、robots関連の指定の有無が後から分かる形で残します。

何も表示されなかった場合でも、それだけで公開判定を終えません。HTMLにnoindexがないことと、HTTPヘッダーにnoindexがないことは別の確認です。また、キャッシュが古いHTMLを返していないか、別端末やログアウト状態でも同じかを確認します。

URL種別ごとに代表ページと例外ページを見る

トップページだけが正常でも、投稿テンプレートやカテゴリ、カスタム投稿にnoindexが残っていることがあります。公開対象URL表に沿って、少なくとも次の単位で代表URLを選びます。

• トップページ
• 固定ページ
• 投稿またはコラム
• サービスや実績などのカスタム投稿
• カテゴリ・一覧ページ
• 個別にSEO設定を変更したページ
• PDFなど、検索対象にするHTML以外のファイル

同じテンプレートでも個別設定があるページは、代表URLとは別に確認します。確認件数を増やすことより、設定経路の違いを覆うことが目的です。

robots.txt・canonical・サイトマップを一緒に確認する

noindexだけを外しても、検索エンジンがページへ到達できなかったり、別URLを正規ページとして認識したりすれば、意図した状態にはなりません。公開前確認では、robots.txt、canonical、サイトマップを一つの組として見ます。

robots.txtは「検索結果から消す設定」ではない

robots.txtは、主にクローラーがどのURLへアクセスできるかを制御します。公開対象URLをrobots.txtで遮断すると、検索エンジンがページをクロールできず、HTMLやHTTPヘッダーのnoindexを確認できない場合があります。

テスト環境を検索結果へ出さない目的で、robots.txtのDisallowだけに頼るのも適切ではありません。外部からリンクされるなどの条件によっては、内容を取得されなくてもURLが検索結果へ現れる可能性があります。テスト環境は認証で保護し、本番では公開対象URLをクロールできる状態にします。

canonicalは本番の正規URLを示しているか

テスト環境を複製すると、canonicalがテスト用ドメイン、仮URL、旧サイトのURLを指したまま残ることがあります。noindexを解除してもcanonicalが別URLを示していれば、検索エンジンへ矛盾した情報を送ることになります。

代表URLごとに、HTMLのcanonical指定が意図した本番URLを示すかを確認します。リダイレクト、canonical、サイトマップで示すURLは、できるだけ同じ正規URLへそろえます。robots.txtをcanonicalの代わりに使わず、URLの統合が必要ならリダイレクトやcanonicalで明示します。

サイトマップは公開対象の正規URLだけにする

XMLサイトマップには、検索結果へ出したい正規URLを載せます。noindexのURL、テスト環境のURL、リダイレクト元、重複URLが混ざっていないかを確認します。

CMSがサイトマップを自動生成している場合、noindex設定の変更が反映されるタイミングや、キャッシュの更新条件も確認します。設定を解除した直後に古いサイトマップが残ることがあるため、生成結果のURLを実際に開いて確認します。

robots.txtにサイトマップの場所を記載している場合は、そのURLも本番用になっているかを見ます。Search Consoleへ送信するサイトマップと、公開サイトが案内するサイトマップを一致させると、後の確認がしやすくなります。

公開直後は「検索結果」より先にライブURLを確認する

本番切り替え後は、公開前と同じ代表URLを、実際の本番ドメインで再確認します。ここでは、ブラウザで表示できるかだけでなく、公開前の確認結果が本番へ反映されているかを確かめます。

最初に、ログアウト状態・外部ネットワークから本番URLへアクセスします。社内のDNS、hosts設定、VPN、管理者用キャッシュなどに依存していないことを確認してください。次に、HTMLのrobotsメタタグ、X-Robots-Tag、canonical、robots.txt、サイトマップを再確認します。

その後、Search ConsoleのURL検査で対象URLを開き、ライブURLをテストします。ライブテストは、現在のURLをGoogleが取得できるか、noindexなどの問題がないかを公開直後に確認するために使います。「Googleに登録されているURL」の情報は、過去に取得された状態を示すため、公開直後はライブテストと分けて見ます。

ライブテストが通り、公開対象URLとして問題がないことを確認してから、重要な代表URLについてインデックス登録をリクエストします。リクエストを送っても、クロールや登録が即時に完了するとは限りません。何度も繰り返して送るより、まず取得を妨げる設定がないことを確認し、その後の状態を追います。

site:example.comのような検索も補助的な確認には使えますが、公開判定の主な証拠には向きません。検索演算子の結果は網羅的ではなく、公開直後は反映に時間がかかります。「site検索に出ないからnoindexが残っている」「site検索に出たからすべて正常」とは判断せず、URL検査と実際のレスポンスを優先します。

公開後の確認は、時間を分けて記録すると状況を追いやすくなります。

1. 公開直後：本番URLの閲覧、HTML、ヘッダー、canonical、robots.txt、サイトマップ
2. 公開直後から当日中：URL検査のライブテスト、重要URLの登録リクエスト
3. 数日後以降：URL検査の登録状況、サイトマップの取得状況、対象URLの推移

検索結果への反映時期は一定ではありません。すぐに表示されないこと自体を解除失敗と決めつけず、まずGoogleが本番URLへ到達でき、noindexがなく、正規URLが一致しているという技術的な条件を確認します。

誰が何を確認したかを残し、再デプロイにも同じ判定を使う

noindex解除漏れは、確認項目がないことだけでなく、作業者と承認者が同じ画面を見て「大丈夫だろう」と判断したときにも起こります。公開記録には、設定変更の内容より、確認したURLと実際の応答を残します。

最低限、次の内容を記録します。

• 確認日時
• 確認した本番URL
• 期待する状態（index対象／noindex対象）
• HTMLのrobots指示
• HTTPヘッダーのX-Robots-Tag
• 認証・アクセス制限の状態
• canonicalのURL
• サイトマップ掲載の有無
• URL検査のライブテスト結果
• 作業者と確認者

作業者は設定元を変更し、確認者はログアウト状態の本番URLを別経路で確認します。同じ人が両方を担当する場合でも、設定画面を見た直後に完了とせず、ブラウザやコマンド、URL検査へ確認場所を切り替えます。

問題が見つかったときは、目の前のHTMLを書き換えるのではなく、noindexを出している設定元へ戻ります。たとえば、サーバーのヘッダー設定が原因ならCMSの個別設定を変えても解決しません。設定元マップと公開対象URL表を照合し、修正後に同じ本番URLで再確認します。

また、初回公開で合格しても、テーマ変更、SEOプラグイン更新、CDN設定変更、ステージングからの再反映で状態は変わります。公開判定表を初回公開だけのチェックリストにせず、検索表示に関わる変更を本番へ反映するたびに再利用します。

公開日の担当・時刻・切り戻しを含む全体の進行は、ホームページ公開日の切り替え手順で扱います。この記事の確認表は、その中の「検索エンジンへ公開できる状態か」を判定する工程として使い分けると、役割が重なりません。

まとめ｜noindex解除は本番URLの証拠で完了させる

テストサイトのnoindexを外し忘れないためには、CMSの一つのチェック項目だけに依存しないことが重要です。検索対象URLを先に決め、HTML、HTTPヘッダー、CMS、環境設定、認証のどこからnoindexが出るかを整理します。あわせてrobots.txt、canonical、サイトマップを本番の方針へそろえます。

公開前は代表URLで実出力を確認し、公開後は同じ本番URLをログアウト状態で再確認します。Search Consoleでは登録済みの情報だけでなく、URL検査のライブテストを使い、現在のページをGoogleが取得できる状態かを見ます。

「設定を変えた」ではなく、「この本番URLは公開条件を満たした」と記録できれば、初回公開だけでなく、再デプロイや更新時のnoindex再混入も同じ手順で防げます。