2026年7月時点のGoogle Search CentralとWordPress公式資料を基準に、廃止・無効化されたディレクティブ、JavaScript実装の注意点、削除・移転時の判断まで見直しました。検索サービスやCMSの仕様は変わるため、公開前に公式ページと実レスポンスを再確認してください。
noindexは、検索エンジンに「このURLを検索結果へ表示しないでください」と伝えるための指示です。アクセス制限ではなく、順位を上げる施策でもありません。正しく機能させるには、検索エンジンがページをクロールしてnoindexを読める状態にし、公開後のHTMLまたはHTTPヘッダーを確認する必要があります。
「出したくない理由」を決めてから、noindex・canonical・404を選ぶ
検索結果に不要な完了ページや内部検索結果にはnoindexが候補です。一方、機密情報は認証、移転は301、削除は404・410、重複統合はcanonicalが基本です。目的が違う対策を混ぜると、意図しない除外や解除漏れにつながります。
| 目的 | 対象URLを検索結果へ表示しないよう、対応する検索エンジンへ指示する |
|---|---|
| HTMLでの実装 | <meta name="robots" content="noindex"> |
| 非HTMLでの実装 | HTTPヘッダーで X-Robots-Tag: noindex を返す |
| 重要条件 | 検索エンジンがnoindexを読めるよう、robots.txtなどでクロールを妨げない |
| 反映時期 | 再クロールと処理の後。設定直後に検索結果から消えるとは限らない |
| 確認方法 | 公開レスポンス、HTTPヘッダー、Search ConsoleのURL検査、対象URL一覧を照合 |
noindexとは、検索結果への掲載を止める指示
Webページの公開状態は、「誰が閲覧できるか」「クローラーが取得できるか」「検索結果に登録・表示されるか」の3段階に分けて考えると整理しやすくなります。noindexが担当するのは、主に3段階目のインデックス制御です。
アクセス
利用者がURLを開けるか。機密情報や社内資料は、ログイン・Basic認証・権限管理で守ります。
クロール
検索クローラーがURLを取得できるか。robots.txtは主にこのアクセスを制御します。
インデックス
取得したURLを検索結果へ載せるか。noindexはこの段階に対する指示です。
「noindexだけ」で十分なことが多い
Googleではリンクのクロールを許可する状態が既定なので、検索結果から外すだけなら noindex で目的を満たします。noindex,follow と書いて意図を明示することもできますが、follow の追記は必須ではありません。
none は noindex,nofollow と同じ意味です。リンク先をたどらせたくない明確な理由がない限り、機械的に nofollow を追加しない方が運用意図を保ちやすくなります。
noarchive、nocache、nositelinkssearchbox は効果を持ちません。検索結果の説明文や画像プレビューを調整したい場合は、max-snippet や max-image-preview など、目的に合う現行ディレクティブを確認します。noindexを使うページ・使わないページの判断基準
「内容が薄いから」「SEOに悪そうだから」という曖昧な理由で一括設定すると、検索流入の入口まで失うおそれがあります。まず、対象URLを検索結果へ出さない理由と、そのURLを今後も200 OKで公開し続ける理由を1文で説明できるか確認してください。
閲覧は必要、検索入口には不要
- 購入・申込み・問い合わせの完了ページ
- サイト内検索結果や、検索価値のない絞り込みURL
- 公開プレビューなど、一時的に外部共有するページ
- 検索結果に出す必要がないPDF・資料ファイル
- 会員向け導線のうち、認証前でも表示される補助ページ
目的がnoindexでは解決しない
- 機密情報・社内限定：認証、権限、ネットワーク制限
- 別URLへ移転：301または308リダイレクト
- 削除して代替なし：404または410
- 重複URLの代表を決める：canonicalやリダイレクト
- 低品質な本文：改善、統合、削除、情報設計の見直し
実務で迷いやすいページの選び方
| ページ例 | 基本判断 | 理由・補足 |
|---|---|---|
| サンクスページ | noindex候補 | 直接閲覧は必要でも、検索結果の入口としての価値は通常低い。URL推測で特典を取得できない設計も別途必要。 |
| サイト内検索結果 | noindex候補 | 検索語ごとに大量のURLが生まれる場合は、内部リンク・パラメータ設計・クロール負荷も合わせて見直す。 |
| ステージング環境 | 認証を優先 | noindexだけでは外部閲覧を防げない。Basic認証、IP制限、VPNなどを主対策にする。 |
| 商品・記事の重複URL | canonical検討 | 検索評価を代表URLへまとめたいならcanonicalやリダイレクト。検索不要ならnoindexも候補だが目的を分ける。 |
| 終了したキャンペーン | 状況で分岐 | 後継ページがあればリダイレクト、資料価値が残るなら更新して公開、代替がなければ404・410を検討。 |
| タグ・カテゴリ一覧 | 一括除外しない | 検索ニーズと内部導線の価値を確認。薄い一覧は説明追加・統合・構造変更も比較する。 |
noindexの正しい設定方法
HTMLページはhead内のrobots metaタグ、PDFや画像などHTMLを返さないファイルはX-Robots-Tagで設定します。CMSの設定画面だけを見て完了にせず、CDNやキャッシュを通過した公開URLのレスポンスを確認してください。
HTMLページ：robots metaタグ
<head>
<meta name="robots" content="noindex">
</head>大文字・小文字は通常区別されませんが、表記を統一した方が監査しやすくなります。複数のrobots metaタグや、プラグインが出力した別指定が重なると判断しにくいため、可能なら一箇所へ集約します。
PDF・画像・生成ファイル：X-Robots-Tag
HTTP/2 200
Content-Type: application/pdf
X-Robots-Tag: noindexX-Robots-TagはHTMLにも利用できます。アプリケーション、Webサーバー、CDNのいずれで付与するかを決め、リダイレクト後の最終レスポンスまで確認します。
Goで返す例
func preview(w http.ResponseWriter, r *http.Request) {
w.Header().Set("X-Robots-Tag", "noindex")
w.Header().Set("Content-Type", "text/html; charset=utf-8")
// レスポンス本文を返す
}Nginxで返す例
location = /files/internal-guide.pdf {
add_header X-Robots-Tag "noindex" always;
}WordPress：サイト全体の設定は解除漏れに注意
「検索エンジンがサイトをインデックスしないようにする」は全体設定
WordPressの「設定 → 表示設定」にある検索エンジン向けのチェック項目は、サイト全体へnoindex系の指定を出力します。制作中に使った場合は、公開日・解除担当・確認URLをタスクへ残してください。
ページ単位の設定はSEOプラグインやテーマで行えますが、プラグイン、テーマ、サーバー側ヘッダーが重複していないか、最終HTMLとレスポンスで確認します。
JavaScriptで設定・解除するときの注意
JavaScriptでmeta robotsへnoindexを追加する実装は、Googleがレンダリングした後に認識される場合があります。ただし、初期HTMLにnoindexがあり、JavaScriptで後から削除する設計は避けてください。Googleが初期のnoindexを見た段階でレンダリングを省略すると、解除処理が実行されない可能性があります。
noindex・robots.txt・canonical・404の違い
これらはすべて検索エンジンの動きに関係しますが、解決する問題は別です。目的とHTTPレスポンスを先に決め、複数のシグナルが矛盾しないようにします。
| 方法 | 主な目的 | 検索結果 | 向く場面 | 注意点 |
|---|---|---|---|---|
| noindex | URLを検索結果へ載せない | 再クロール後に除外 | 閲覧は必要だが検索入口には不要 | クロール可能でなければ指定を読めない |
| robots.txt | クローラーの取得を制限 | URLだけ表示される可能性あり | クロール負荷や特定パスへのアクセス制御 | 検索結果から確実に消す仕組みではない |
| canonical | 重複URLの代表候補を示す | 代表URLへ統合を促す | 同一・類似内容のURL整理 | 指示ではなくシグナル。noindexの代替ではない |
| 301 / 308 | 恒久的な移転 | 移転先へ置換を促す | URL変更、統合、後継ページ | 無関係なページへの一括転送は避ける |
| 404 / 410 | コンテンツが存在しないと伝える | 処理後に削除 | 代替のない削除ページ | 重要な内部リンクとsitemapも更新する |
| 認証・権限 | 閲覧そのものを制限 | 取得できなければ登録困難 | 機密情報、会員限定、開発環境 | SEO対策ではなくセキュリティ設計 |
robots.txtとnoindexを同じURLへ重ねない
robots.txtで対象ページのクロールを禁止すると、Googleはページ内のnoindexを確認できません。検索結果から除外したいURLは、Googleが取得できる状態でnoindexを返します。クロールを減らしたい目的もある場合は、まずインデックスから外れたことを確認し、その後のURL設計や内部リンク、パラメータ管理を別途検討します。
canonicalとnoindexを「保険」で併記しない
canonicalは代表URLを選ぶためのシグナル、noindexはそのURLを検索結果から外すための指示です。意図が異なるため、同じURLへ何となく両方を付けると、運用者がどちらを期待しているのか分からなくなります。代表URLへ評価を統合したいなら、canonicalと内部リンク、sitemapを揃える方が明確です。
XML sitemapには検索に残したいcanonical URLを載せる
noindex URLをsitemapへ載せ続けると、「検索に出したいURL一覧」と「検索に出したくない指示」が衝突します。自動生成の条件を見直し、原則として検索結果へ掲載したいcanonical URLだけを含めます。
noindexが効いているか確認する6ステップ
管理画面やソースコードの一部だけで判断せず、URL一覧、公開レスポンス、Google側の状態を分けて確認します。特に、www有無、HTTP/HTTPS、末尾スラッシュ、パラメータ、言語別URLが別レスポンスになっていないか注意してください。
対象URLと除外理由を確定する
URL、URLパターン、テンプレート、除外理由、設定日、解除期限、担当者、代替URLを台帳へ記録します。正規表現やCMS条件で広く適用する場合は、検索に残す例外URLも先に定義します。
ブラウザで最終HTMLを確認する
「ページのソースを表示」と開発者ツールのElementsは結果が異なる場合があります。サーバーから返った初期HTMLと、JavaScript実行後のDOMを両方確認してください。
HTTPヘッダーとステータスを取得する
200、3xx、4xxのどれを返しているか、リダイレクト先にX-Robots-Tagが残っているか、CDNキャッシュで古い値が返っていないかを確認します。
robots.txtでブロックされていないか確認する
Googleがnoindexを読む必要があるURLは、robots.txt、WAF、IP制限、ログイン必須、地域制限などで取得不能になっていないか確認します。
Search ConsoleのURL検査を使う
インデックス済みの情報とライブURLのテストを分けて見ます。Googleが最後に取得した状態と、現在の公開レスポンスに時間差があることを前提に判断します。
反映期間を置いて再確認する
noindexを公開しても即時反映とは限りません。クロール頻度が低いURLでは長くかかることがあります。設定日、再クロール依頼日、確認日を記録し、実装不備と反映待ちを切り分けます。
コマンドで公開レスポンスを確認する
# リダイレクト後のHTMLを取得して meta robots を探す
curl -sL https://example.com/page/ | grep -i "robots"
# リダイレクトを追い、最終レスポンスのヘッダーを確認
curl -sIL https://example.com/file.pdf
# X-Robots-Tagだけを確認
curl -sIL https://example.com/file.pdf | grep -i "x-robots-tag"site:検索だけで完了判定しない：検索演算子の結果は完全なインデックス一覧ではなく、反映にも差があります。公開レスポンスとSearch ConsoleのURL検査を主な確認手段にしてください。noindexが反映されない・解除できないときの原因
「タグは入っているのに消えない」「解除したのに戻らない」というときは、URLごとのレスポンスと配信経路を順番に確認します。
robots.txtや認証でクロールできない
Googleがページを取得できず、noindexの追加・解除を読めない状態です。目的が検索除外ならクロール可能にし、機密保護が目的なら認証を維持します。
metaタグとHTTPヘッダーが競合している
HTMLからnoindexを消しても、CDNやサーバーがX-Robots-Tagを返している場合があります。両方を確認してください。
CDN・ページキャッシュが古い
オリジンでは解除済みでも、エッジキャッシュが古いHTMLやヘッダーを返すことがあります。キャッシュ削除後に外部から再取得します。
別URLを確認している
www有無、末尾スラッシュ、URLパラメータ、AMP、印刷版、言語別URLなど、検索に登録されたURLと検証URLが違うケースです。
JavaScriptでnoindexを解除している
初期HTMLのnoindexを後から削除する実装は認識されない可能性があります。インデックスさせるページは初期レスポンスからnoindexを返さない設計にします。
Googleの再クロール待ち
実装が正しくても、Googleが古い状態を保持している場合があります。ライブテストとインデックス情報を比較し、期間を置いて再検証します。
検索結果から早く非表示にしたいとき
Google Search Consoleの削除ツールは、検索結果からURLを一時的に非表示にするための手段です。緊急対応には役立ちますが、非表示は恒久措置ではありません。noindex、認証、404・410、リダイレクトなど、URLの最終状態を同時に整えます。
Search Consoleの削除ツール
誤公開や機密情報の露出など、検索結果から急いで隠したいときに利用します。対象URL・プレフィックスを慎重に選び、影響範囲を確認します。
URL側の対応を必ず行う
公開は続けるが検索不要ならnoindex、削除なら404・410、移転ならリダイレクト、機密なら認証という形で、削除ツールの期限後も成立する状態にします。
noindexを解除して再び検索結果へ出す手順
公開時の解除漏れは、サイト全体の流入を失う大きな事故になり得ます。タグを消すだけでなく、クロール・canonical・sitemap・内部リンクまで一つの公開手順にします。
metaタグとX-Robots-Tagを解除する
HTML、アプリ、Webサーバー、CDN、SEOプラグインを確認し、対象URLからすべてのnoindex指定を削除します。
200 OKと公開本文を確認する
インデックスさせたいURLが正常な200レスポンスを返し、ログインや地域条件なしで本文を取得できることを確認します。
robots.txtとcanonicalを整える
クロールを妨げるルールがないか、canonicalが別URLを指していないかを確認します。
sitemapと内部リンクへ戻す
検索に残したいcanonical URLをXML sitemapへ含め、重要ページから通常の内部リンクを設けます。
URL検査でライブ状態を確認する
Search Consoleのライブテストで現在のレスポンスを確認し、問題がなければインデックス登録をリクエストします。
再登録を観測する
検索結果への復帰は保証された時刻で起こるものではありません。URL検査、サイトマップ、検索パフォーマンスを期間付きで確認します。
公開前・解除前のnoindexチェックリスト
設定を「作業」ではなく「変更管理」として扱うと、広域適用や解除漏れを防ぎやすくなります。
参照した公式資料
検索エンジンの仕様は更新されるため、実装前には次の一次資料と、利用しているCMS・CDN・ホスティングの公式資料を確認してください。
- Google Search Central｜noindexを使用してインデックス登録をブロックする
- Google Search Central｜robots.txtの概要
- Google Search Central｜robots metaタグ・X-Robots-Tagの仕様
- Google Search Central｜重複URLの正規化
- Google Search Central｜サイトマップの作成と送信
- Google Search Central｜JavaScript SEOの基本
- Google Search Console｜削除ツール
- WordPress.org｜Reading Settings
本記事は、特定サイトの検索順位や流入改善を保証するものではありません。検索結果への反映時期や採用されるシグナルは、URLの状態、クロール頻度、サイト構造などによって異なります。
noindexに関するよくある質問
noindexタグを設定すると、すぐ検索結果から消えますか？
すぐに消えるとは限りません。検索エンジンが対象URLを再クロールし、noindexを処理した後に反映されます。公開レスポンスとSearch ConsoleのURL検査を分けて確認してください。
noindexとrobots.txtは同時に設定してよいですか？
noindexをGoogleに読ませる必要があるURLをrobots.txtでブロックすると、指定を確認できません。検索結果から除外する目的では、クロール可能な状態でnoindexを返します。
noindex,followとnoindexだけでは何が違いますか？
Googleではfollowが既定のため、リンクをたどってよい場合はnoindexだけで目的を満たします。noindex,followは意図を明示できますが、followの追加は必須ではありません。
canonicalとnoindexはどちらを使うべきですか？
重複URLを代表URLへ統合したい場合はcanonicalやリダイレクトを検討し、そのURL自体を検索結果へ出したくない場合はnoindexを検討します。目的が異なるため、代替URLの有無で判断します。
WordPressの「検索エンジンがサイトをインデックスしないようにする」は安全ですか？
サイト全体へ影響する設定なので、公開サイトでの解除漏れに注意が必要です。また、閲覧を制限する機能ではありません。ステージング環境は認証やアクセス制御を優先してください。
PDFを検索結果から除外できますか？
できます。HTMLのmetaタグを置けないPDFや画像などには、HTTPレスポンスヘッダーで X-Robots-Tag: noindex を返します。
削除したページにもnoindexを使うべきですか？
移転先があれば301リダイレクト、代替がなく削除済みなら404または410が基本です。noindexを返すためだけに不要な200ページを残す必要はありません。
noindexを解除したのに検索結果へ戻りません。どう確認しますか？
metaタグとX-Robots-Tagの両方、robots.txt、HTTPステータス、canonical、CDNキャッシュ、URL違いを確認します。その後、Search ConsoleのURL検査でライブURLを確認し、再クロールを依頼します。
まとめ：noindexは「対象・理由・確認・解除」を一つの運用にする
noindexは、検索結果へ表示する必要がないURLを整理するための有効な手段です。ただし、アクセス制限、クロール制御、重複統合、移転、削除とは役割が異なります。
- 閲覧は必要だが検索入口には不要なURLへ限定する
- HTMLはmeta robots、非HTMLはX-Robots-Tagで実装する
- noindexを読ませるURLをrobots.txtでブロックしない
- canonical・301・404・認証との役割を分ける
- 公開レスポンスとSearch Consoleを段階的に確認する
- 期限・担当者・解除手順を台帳へ残す
ページ単位の設定だけでなく、テンプレート、CMS、CDN、sitemap、内部リンクを含む公開経路全体で整合しているかを確認することが、noindex事故を防ぐ最短ルートです。
関連するテクニカルSEOガイド
執筆・検証：Hikaru OnoWeb制作・サーバー運用・テクニカルSEOの実務視点から、公式資料、公開レスポンス、CMSの挙動を分けて確認し、設定事故を避けるための手順に整理しています。