インデックス設定の矛盾:自サイトがGoogleに「登録するな」と伝えているとき
49件の監査のうち42.9%のサイトが、自らのサイトマップで推しているページをブロック・リダイレクト・noindexにしていました。4つの衝突パターンと、それを解消する順序を示します。
実施する各監査は、サイトが重要だと宣言するページ(ホームページと自サイトのサイトマップにリストされた URL)について、検索エンジンがそれらを宣言どおりにインデックスできるかどうかという率直な質問を投げかけます? 5月 5 から August 15, 2026 まで、21 の 49 監査済みサイトがその質問に失敗しました. これは、サンプルの 42.9% が、誰かが公開・リンク・リストしたページをクロールしないように指示したことを示しています. 失敗は同じサインを共有します:これらのサイトのすべては人間にとって完璧に機能します. ページはレンダリングされ、リンクは解決され、ブラウザ上にその下にある指令が検索エンジンを遠ざけていることを示すヒントは何もありません. インデックス可能性の衝突は、私たちのデータで最も自己誘発的なカテゴリです — 競合他社が原因ではなく、アルゴリズム更新が引き起こしたわけでもなく、チームの誰もボットがサイトを取得する方法でないとそれらを確認できません.
データセット
| 重要なページがインデックス可能 | ホームページまたはサイトマップにリストされたページが宣言どおりにインデックスできない | 21/49 (42.9%) |
| 重要ページに noindex が付いている | サイトマップにリストされたページに noindex 指令がある | 7/49 (14.3%) |
| サイトレベルのシグナルが一貫している | robots.txt がクロールをブロックするか、ホームページ自体に noindex が付いている | 5/49 (10.2%) |
| robots.txt が一般的なボットを許可している | robots.txt にすべてのボットに対して Disallow: / が含まれている | 3/49 (6.1%) |
**Methodology: 最新の完了監査スナップショットは、現在のチェックセットから取得し、5月 5 – August 15, 2026 — 49 の監査済みサイトを匿名化しています。 *Per-check denominators は 46 から 49 まで変動します。チェックは入力が存在する場合にのみ実行されるため、到達可能なサイトマップがないサイトはサイトマップページの判定を返しません。 サンプルは自己選択であり、監査を実施したオーナーのみで構成され、小規模〜中規模の傾向があるため、そのセグメントのレートは方向性として扱ってください。
リダイレクトと正規化は noindex よりも多くの失敗を引き起こします。
最初の 2 行間のギャップは発見 です。 インデックス可能性チェックは、4つの理由のいずれかでページに失敗します:robots.txt によってブロックされている、noindex ディレクティブを持っている、別の URL にリダイレクトされている、または別の場所を指す canonical を宣言している。 noindex 専用チェックは 7 サイトで失敗しました — つまり、21 の失敗サイトのほとんどで、非インデックス可能なページは noindex を一切持ちません。 彼らは sitemap が約束した URL から離れ、または Google に対して正規化が別のアドレスにあると伝えます。 その分布は重要です。チームは誤った原因を追いかけます。 みんなが知っている言葉は noindex であり、それが grep されます — そして結果はクリーンです。 実際の衝突は通常構造的です:CMS データベースから生成されたサイトマップと、ライブ URL が新しいパススキームに移行した、または正規化タグが実際にページが提供しない URL バリアントにテンプレート化された場合です。 チェックは何がカウントされるかを慎重に扱います。 正しいインフラストラクチャであるリダイレクト(裸ドメインが www バリアントへ移動)は除外し、/login や /signup のようなユーティリティパスは noindex を持つべきです。 21 の失敗は、良性ケースが除外された後に残るものです。
データ中の 4 衝突パターン
配備された staging noindex。 7 サイトは、メタ robots タグまたは X-Robots-Tag 応答ヘッダーに noindex ディレクティブを持つページを sitemap にリストします。 これはクラシックなローンチ残留です:正しく staging 環境を隠したディレクティブがテンプレート、プラグイン設定、またはプラットフォームトグル内で本番に持ち込まれます。 WordPress の「このサイトのインデックスを検索エンジンに禁止」チェックボックスは典型例です — 1 設定、サイト全体 noindex、目立った違いはありません。 robots.txt がすべてを叫ぶ。 3 サイトはすべてのボットに対して Disallow: / を含む robots.txt を提供します — サイト全体の離脱サイン — そして 5 はより広範な一貫性チェックに失敗します。robots.txt のブロックまたはホームページ noindex がランキングを意図した明確な意図と矛盾します。 このパターンの微妙な罠は、robots.txt と noindex が逆の仕事をし、組み合わせると強力な方がキャンセルされることです。 robots.txt によってブロックされたページはクロールできないため、そこに置かれた noindex は決して読み取られません — これが URL が「Indexed, though blocked by robots.txt」状態になる方法です。結果には、Google が取得禁止だった単なるリンクが表示されます。 正規化の矛盾。 正規化タグが noindex を持つターゲットを指すと、Google は両方を満たせない 2 つの指示を受け取ります:このページにシグナルを統合し、そしてこのページをインデックスから除外します。 当社のエンジンはすべての正規化ターゲットを解決し、ターゲットが noindexed、リダイレクト、または自らを正規化として宣言しない場合に監査を失敗させます。同じ矛盾は、ページが noindex と別の場所への正規化を両方持つ 1 ページ形式で現れます — Google に権威を転送させるよう求めます。 サイトマップが禁止するディレクティブを促進する。 サイトマップは、そこにあるすべての URL がインデックスされるべきであるという機械可読の主張です。 robots.txt がブロックする URL や noindex ディレクティブを持つ URL をリストすると、サイトは自らと争い、各サイクルでクロール予算を費やします。 このパターンを独自に測定しました、our sitemap hygiene report.
競合を次の順序で解決します:意図、次に1メカニズム、最後に証拠
インデックス可能性の競合は、修正がシグナルごとに適用されるために残ります — 誰かがここでnoindexをパッチし、そこではrobots.txtを編集し — それぞれのページクラスが実際に何のためにあるかを決定する人はいません. 耐久性のある修正は1方向で実行されます.
ランカブルなコンテンツ、重複バリアント、プライベートユーティリティページ、無限パラメータ空間はそれぞれ1意図を持ちます — いずれも設定ファイルに触れる前に. 1. ページクラスごとに意図を決定。 2. 各意図を正確に1メカニズムで表現する。
- Rank: サイトマップにリストされ、自己正規化を指し、robots指示なし.
- 重複を統合:
<link rel="canonical" href="https://example.com/primary/" />バリアント上で、クロール可能でサイトマップを離れます。正規化はヒントです — Google の自社ドキュメントは、他のシグナルが不一致の場合に別の正規化を選択できると述べており、これはターゲットがクリーンである必要がある理由です:インデックス可能、200、自己正規化。 - 結果から除外: ページ内の
noindexメタrobotsタグ、またはPDFやその他の非HTML応答のX-Robots-Tag: noindexレスポンスヘッダー。 ページはクロール可能である必要があります — robots.txtブロックの後ろにある指示は存在しない指示です. - クローラ予算を保存:
Disallow: /search/を robots.txt のUser-agent: *に置き、URL が無制限のスペースに予約します。 robots.txt はクロールを制御し、インデックスは決して行いません — 既にインデックスされているものは何も削除しません.
プラットフォームごとに、noindex の意図は 1 行です: Next.js ルートのメタデータエクスポートの robots: { index: false }、WordPress の「検索エンジンの可視性」トグル(環境ごとに意図的にチェックされ、ステージングから継承されません) — または nginx のロケーションブロックにスコープされた add_header X-Robots-Tag "noindex" always;。
ブラウザはここでは何も証明しません;クローラが行う方法で取得してください: 3. ページクラスごとにボットとして検証します。
curl -sI -A "Googlebot" https://example.com/page/ | grep -i "x-robots-tag\|location"curl -s -A "Googlebot" https://example.com/page/ | grep -i "robots\|canonical"
ページクラスごとに代表的な URL が 1 つあれば十分です。ステップ 1 で決定した意図と照合してチェックします。 Search Console の URL 検査は権威ある第二意見を提供し、実際に選択された canonical Google を含みます。 当社の監査は、robots.txt とサイトマップのメンバーシップ、ディレクティブと canonicals、canonical ターゲットの解決と検証をすべてのレポートで実行し、無料レポート にはそれぞれの衝突ペアと発見されたページが一覧表示されます。 42.9% の失敗率は、インデックス可能性の衝突を当社データで最も一般的な深刻な発見の一つに位置付けます。これは、当社の最も失敗したチェックのランキング のヘッダーギャップと同じ階層にあり、ブロックされたページはどれほど優れていても何も得られないという厳しい結果を伴います. 合格したサイトは、インデックスの意図が一度決定され、ページクラスごとに 1 メカニズムに書き留められ、クローラが行う方法でチェックされたものです. この失敗カテゴリに関するすべてはサイト所有者の管理下にあります — それがデータセット内で最も修正可能な 42.9% である理由です.
サイトのランキングを確認する
アクション可能な発見と優先修正を含む無料のAI搭載SEOレポートを取得
サインアップ不要.