robots.txtは、対応するクローラーに対して、サイト内のどのURLへのアクセスを許可するかを伝えるファイルです。一方、noindexは、対象コンテンツを検索のインデックスに登録しないよう指示します。URLを知っている人も含めて閲覧を制限したい場合は、認証などのアクセス制御が必要です。Googleの説明でも、robots.txtをウェブページの検索除外や情報保護の代用にしないことが示されています。[1][2][3]

この区別は、社内で使う言葉にも反映させます。「このページを非公開にしてください」だけでは、担当者によって、メニューから外す、noindexにする、ログインを必須にする、といった異なる対応が選ばれかねません。「一般利用者はURLから閲覧できるが、Google検索には掲載させたくない」「関係者以外はURLを知っていても閲覧できない状態にしたい」のように、期待する挙動まで書きます。

例えば、申込後に表示する完了画面は、一般的な検索流入の入口として必要なのかを検討する対象です。ただし、完了画面に申込者の情報が表示されるなら、検索除外だけで安全とは判断できません。ページの用途と、表示される情報の性質を別々に確認しましょう。検索上の整理を担当する人だけで非公開の要否を決めず、情報の管理責任者にも確認すると判断の抜けを減らせます。

noindexを指定しても、検索エンジンがその指示を取得できなければ、期待する処理につながりません。Googleは、noindexのあるページをrobots.txtでブロックしないよう案内しています。また、robots.txtにnoindexという行を追加する方式は、Googleではサポートされていません。HTMLのmetaタグ、またはHTTPレスポンスヘッダーで設定することが基本です。[2]

ここで起こりやすいのが、「確実に消したいので両方付ける」という発想です。対策を重ねたつもりでも、クロールを止めた結果、ページ側の検索除外指示を読めなくなることがあります。すでに検索に出ているページを対象にするなら、設定を追加した事実だけでなく、検索エンジンが変更後の状態を確認できるかまで点検する必要があります。

制作会社への依頼には、「対象URLにnoindexを付ける」に加え、「そのURLをrobots.txtで遮断していないことを確認する」と記載します。非公開情報が含まれる場合は、noindexを読ませるために閲覧制限を外してはいけません。まず情報保護を優先し、一般公開を続けられるページなのかを確定させます。この順序を守ることで、検索から消す作業が別の情報公開事故を生むことを防ぎます。

設定に着手する前に、対象URLを小さな管理表にまとめます。最低限必要なのは、URL、ページの用途、検索に掲載させたいか、一般閲覧を許可するか、現在の設定、変更責任者です。部署別に管理するサイトでは、確認した日付と判断者も残します。技術設定だけを一覧にしても、なぜその状態にしたのかが分からなければ、更新時に誤って解除される可能性があります。

ページ数が多い場合は、すべてを同じ深さで調べるのではなく、まずテンプレートや機能の単位で分類します。サービス詳細、記事詳細、検索結果、フォーム完了画面などの分類ごとに代表URLを選び、個別に異なる設定が入っていそうなページを追加します。代表ページだけの確認で全件が正常と断定せず、確認した範囲を明記することも大切です。

例外の扱いも先に決めます。同じ「キャンペーン」でも、終了後に実績として残すページと、期間中だけ利用するページでは、必要な対応が異なります。終了したという理由だけで一律にnoindexを付けるのではなく、内容が今も利用者の役に立つか、問い合わせ導線が誤解を招かないかを担当部署と確認します。設定の簡単さに合わせて、ページの役割を変えないようにしましょう。

robots.txtは対象サイトのルートに配置し、そのプロトコル、ホスト、ポートの範囲に適用されます。そのため、本体サイトの設定だけを確認しても、別のサブドメインで動く採用サイトや予約ページまで確認したことにはなりません。Googleの公式資料は、ファイルの位置、書式、ルールの対象範囲を示しています。[4]

実務では、依頼書に「本番サイト」とだけ書かず、httpsから始まるホスト名を明記します。wwwの有無や検証用サブドメインを混同しないよう、管理表とブラウザーで開いたURLを照合しましょう。取得できたrobots.txtの内容も、編集画面ではなく、外部から参照される最終的な内容で確認します。CMSや配信基盤が自動生成している場合は、サーバー上のファイルを直すことが正しい変更経路とは限りません。

変更前の内容は、日時とともに保存しておきます。広い範囲を指定するルールを加える場合は、止めたいURLと、止めてはいけないURLをそれぞれテスト対象にします。一つの対象ページで期待どおりになっても、共通のパスを持つサービス紹介まで影響していないかは別の確認です。運用担当者が記号の意味を推測して本番を編集するより、対象と除外対象を具体的に渡す方が、制作側も検証しやすくなります。

HTMLページのnoindexは、head内のrobotsメタタグで設定できます。HTTPレスポンスヘッダーのX-Robots-Tagでも指定でき、HTML以外のリソースを扱う場面にも利用されます。複数の指定がある場合は、その組み合わせを含めて確認が必要です。Googleのメタタグとヘッダーのリファレンスは、対応するルールや指定方法を説明しています。[2][5]

管理画面の「検索エンジンに表示する」というスイッチだけを見て、実際の配信状態を判断しないことが重要です。テーマ、拡張機能、サーバー、CDNなど、別の場所から指示が付いている可能性があります。画面では有効になっていても、応答ヘッダーに検索除外の指示が残っているなら、管理画面を何度切り替えても原因に届かないことがあります。

技術担当者には、対象URLのHTML内の指示と、実際のHTTP応答に含まれる指示を分けて報告してもらいます。「設定なし」と回答する場合も、何を確認して設定なしと判断したのかを残します。運用側は、コードの断片を集めるより、設定元、対象範囲、変更方法、戻す方法を把握すると、その後の更新に活用できます。PDFのような個別形式の公開設計は別途検討し、サイト全体の検索制御と混同しないようにします。

制作中の環境と公開環境では、必要な保護が異なります。検証環境に設けた検索除外を、そのまま本番へ引き継いでしまうと、公開して検索流入を得たいページまで対象になるおそれがあります。一方で、本番公開に合わせてすべての制限を外すと、本来は関係者向けの情報まで閲覧可能になるかもしれません。公開作業は「制限を外す作業」ではなく、ページごとに目的の状態へ合わせる作業として扱います。

公開判定に使う確認票には、検索に掲載させたい代表URL、検索から除外するURL、アクセス制限を維持するURLを別々に載せます。ページの表示、robots.txt、HTML内の指示、レスポンスヘッダーを、変更後の本番URLで確認します。公開直前の検証環境で合格していても、配信環境が異なる本番まで正常とは限りません。

担当者の分担も具体的にします。制作会社が設定を変更し、社内担当がページの用途と対象URLを照合する形なら、同じ画面を二人で見るだけの確認よりも異なる種類の誤りを発見しやすくなります。予約公開や夜間切り替えの場合は、確認の担当者が不在にならないかも調整します。設定の反映時刻、確認開始時刻、問題が起きたときの連絡先を公開計画に含めておきましょう。

ブラウザーで正常に開けることと、Googleが変更後の状態を認識していることは同じではありません。Search ConsoleのURL検査では、Googleが把握している情報と、公開URLをその場でテストした結果を区別して確認できます。公開URLのテストで問題がないことは、インデックス登録や検索掲載の保証ではありません。[6]

確認記録には、対象URL、検査日時、確認した結果の種類、主な判定を残します。過去のクロールに基づく情報を見ているのか、現在の公開ページをテストしているのかを書き分けると、制作会社との認識のずれを減らせます。検索除外を意図したページと、検索に出したいページでは正常な結果が異なるため、画面上の表現だけで良し悪しを決めないようにします。

変更直後に検索結果が変わらなくても、ただちに設定を戻すとは限りません。まず変更後の配信が正しいか、対象URLを取り違えていないか、変更がGoogleに確認されたかを順番に調べます。「まだ検索に出る」という現象だけで、noindexの追加、robots.txtの変更、URL削除を同時に実施すると、どの対応が効いたのかも、何を元に戻すべきかも分からなくなります。

誤公開などで早急な対応が必要な場合は、検索結果上の表示と、公開元の状態を並行して扱います。Search Consoleの非表示ツールは、対象となる検索結果の一時的な非表示を申請する手段ですが、公開元の情報を削除する機能ではありません。恒久的な対応を別に行う必要がある点を理解して使います。[7]

社内では、検索担当者だけに対応を任せず、公開内容の責任者とサイト管理者を含めて状況を共有します。まず、何が公開され、誰が閲覧できる状態なのかを確認します。機密情報や個人情報を含むなら、検索結果に出ていないことをもって解決とせず、公開元の閲覧を止める措置を優先します。外部サイトや検索サービスの状態まで自社だけで制御できるわけではない点にも注意が必要です。

作業記録には、対象URL、発見時刻、公開元への対応、検索側への対応、確認結果を分けて残します。焦って似たURLやディレクトリ全体を対象にすると、通常の営業ページまで影響するおそれがあります。申請や設定の前に、担当者同士で対象範囲を読み合わせましょう。公開事故としての報告や法的判断が必要な場合は、社内の所管部署につなぎ、SEOの設定だけで問題全体を処理しないことが大切です。

サービス紹介など検索に出したいページがnoindexになっていた場合は、最初に影響範囲を確かめます。一つのページだけの編集なのか、共通テンプレートの変更なのか、サイト全体の設定なのかで、調べる範囲が変わります。確認できたURLと未確認のURLを分け、重要な問い合わせ導線や主要サービスのページから優先的に点検します。

そのうえで、原因となった設定を正しい場所で修正します。HTMLだけを直してもヘッダーに指示が残る場合や、管理画面を直しても配信キャッシュに古い状態が残る場合は、最終的な応答の確認が欠かせません。制作会社には「修正しました」という報告だけでなく、どの設定を変更し、どのURLで変更後の状態を確認したかを回答してもらいます。

検索への復帰までの時間は一律に約束できません。運用上の完了を、設定修正の完了、配信確認の完了、Googleによる再確認、検索上の状態確認に分ければ、社内への報告も正確になります。原因が確定していない段階では推測を断定せず、確認済みの事実と次の調査を伝えましょう。復旧後は、誤った設定がテンプレートや公開手順に残っていないかまで確認します。

依頼文には、対象URLと現在の症状に加え、最終的にどうしたいかを記載します。例えば、「このページは一般閲覧を継続し、Google検索には掲載させない方針です。noindexの配信とクロールを妨げる設定の有無を確認してください」のように書けば、robots.txtを追加するだけの対応を避けやすくなります。これは一般的な依頼の例であり、実際の顧客案件を示すものではありません。

検索に出したいページなら、「本番URLのHTMLとレスポンスヘッダーに意図しないnoindexがないか、robots.txtで対象URLが遮断されていないかを確認してください」と分けて依頼します。対象外のページに影響を与えないこと、変更前の内容を残すこと、公開後に確認することも併記します。依頼の段階で調査と変更を区別しておくと、原因を見ずに設定を上書きする対応を防ぎやすくなります。

回答を受け取ったら、専門用語の多さより、期待結果との対応を見ます。変更した場所、影響する範囲、確認済みのURL、未確認事項、残っている待ち時間が明確なら、社内の判断につなげられます。技術担当者が説明した内容を運用担当者が短く整理して保管すると、担当交代時にも判断の理由を引き継げます。

一度正しく設定しても、テーマの更新、拡張機能の入れ替え、環境の複製などで状態が変わる可能性があります。定期点検だけに頼るのではなく、設定が変わり得る作業を実施したときに、代表URLを確認する手順を追加しましょう。点検の頻度はサイトの更新量や重要度に合わせ、必要以上に毎日全件を確認する仕組みにする必要はありません。

確認対象には、検索に掲載させたいページだけでなく、除外や閲覧制限を維持すべきページも含めます。前者だけを確認すると、公開範囲が広がった問題を見逃します。逆に、保護対象だけを見ていると、主要ページが検索対象から外れた問題に気付きにくくなります。正しい状態が異なる代表例を少数ずつ持つことが、日常運用では役に立ちます。

robots.txtとnoindexの使い分けで大切なのは、設定を増やすことではありません。ページの目的を定め、その目的に合う手段を選び、実際に配信される状態と検索側の認識を分けて確認することです。対象URL、判断理由、変更箇所、確認結果が残っていれば、公開時の確認も障害時の復旧も進めやすくなります。まずは重要なページから、現在の設定と本来の目的が一致しているかを見直してみてください。

XMLサイトマップの作り方と送信方法｜Search Consoleで更新ページを伝える運用
canonicalタグの使い方｜重複URLを整理して正規ページを伝える方法

公式資料の確認日 2026年10月20日
[1] Google 検索セントラル robots.txtの概要 
[2] Google 検索セントラル noindexを使用してコンテンツをインデックスから除外する 
[3] Google 検索セントラル Googleと共有するコンテンツを制限する 
[4] Google robots.txtの書き方 設定と送信 
[5] Google 検索セントラル Robots metaタグとX-Robots-Tagの設定 
[6] Search Consoleヘルプ URL検査ツール 
[7] Search Consoleヘルプ 非表示ツールとセーフサーチ レポートツール