検証サイトを検索に出さない設定｜認証・noindexと公開時の確認

検索除外と閲覧制限の目的を分ける

完成物は、環境ごとのURL、閲覧条件、検索向け設定、確認担当者を並べた表です。noindexは検索への掲載を制御するための指示で、未公開資料の秘密を守る認証の代わりにはなりません。URLを知っている人が開ける状態かも確認します。

顧客情報や未発表情報があるなら、まず適切な認証やアクセス制限を選びます。検索に出ていないことだけで安全と判断せず、別の閲覧者として開けるかを確認します。

環境ごとに設定の期待値を書く

検証と本番のホスト、認証条件、robotsのメタ情報、HTTPヘッダー、robots.txt、canonicalを記録します。設定名だけでなく、実際の公開応答で何が出るべきかを書きます。

検証環境は閲覧制限をかけ、本番は対象ページを公開するなど、期待値を別にします。すべてのホストへ同じ設定を配布する実装では、環境判定や例外を開発担当に確認します。

noindexを確認するときの取得条件を理解する

Googleの案内では、noindexを読み取るにはページへアクセスできる必要があり、robots.txtで取得を止めるとその指示を確認できません。robots.txtの禁止とnoindexを同じ効果だと考えないようにします。

認証で保護した検証環境に、検索ボットが入れないこと自体は目的に合う場合があります。認証を外してまでnoindexを見せようとせず、未公開情報の保護を優先して環境の目的に合う設定を選びます。

検証URLを確認メールや外部資料に貼ると、認証できない読者へ届く場合があります。共有先を一覧にし、公開後には本番URLへ置き換える箇所を決めます。環境設定を変える担当と記事を公開する担当が別なら、公開時刻と確認順を共有します。公開側の設定を変更した際に、検証環境の保護まで外れていないかも最後に確認し、二つの環境を別々に合格判定します。

検証から本番へ切り替える例

架空の検証ホストpreview.example.comと本番www.example.comを考えます。検証では認証を必須にし、本番の記事では一般閲覧と検索掲載を許可します。公開時には本番URLの応答ヘッダーとHTMLを調べ、検証用のnoindexが残っていないか確認します。

canonicalやサイトマップに検証ホストが残っていないかも確認します。本番のトップだけではなく、記事、一覧、画像など代表的なURLを選び、環境差が意図どおりか確認します。

確認表には、管理者として開いた結果と、未ログインで開いた結果を別に残します。管理者は認証を通過しているため、保護が失敗しているかどうかをその画面だけでは判断できません。公開URLを共有する担当には本番ホストの一覧を渡し、検証リンクを料金案内や申込メールへ混ぜないようにします。検証先を廃止する場合も、必要な確認記録を残してから閲覧先と共有先を整理します。

本番が除外されていた場合の戻し方

公開したい本番ページにnoindexが残っていたら、対象の環境設定を直し、本番応答で除去されたか確認します。URL検査では、確認対象のURLと取得内容を照合します。設定ファイルを直しただけで公開応答が変わったと決めないようにします。

誤って未公開情報を一般公開した場合は、検索への対応だけでなく閲覧制限へ戻します。必要な担当へ状況を渡し、確認記録を残します。検索反映の時期は保証せず、公開状態と検索側の観測を分けて追います。

公開チェックに環境差を組み込む

既存のホスティング機能で適切な制限が使えるか確認し、追加の契約が必要なら対象環境と担当人数を見積もります。どのサービスでも、機能名より実際の未認証アクセスを確認することが重要です。

完了条件は、検証を開くべき人だけが開け、本番の代表ページが意図した検索設定で配信されることです。公開後の確認担当と、次回のリリースでも同じ検査を行う場所を決め、個人の記憶に頼らない運用にします。

• robots.txtの点検｜巡回制御・noindex・必要な素材を区別する
• 公開前後のSEO確認｜URL・検索除外・言語版を検証する
• JavaScriptサイトのSEO点検｜初期HTMLと表示後の本文を比べる