インデックスを技術的にブロックする原因と直し方【2026年】｜
ページがGoogleにインデックスされない技術的な原因を、noindex（metaタグとX-Robots-Tagヘッダ）、robots.txtのDisallow、canonicalの誤り、リダイレクトの誤用、404・ソフト404・5xx、JavaScriptレンダリング問題、hreflangまで、1つずつ「見つけ方」と「直し方」をセットで解説。Search ConsoleのURL検査・curl・ソース表示での確認手順つき。noindexの消し方、robots.txtでインデックスをブロックする落とし穴、canonicalの誤り、JavaScriptでインデックスされない問題を実務目線で整理した、インデックス深掘りシリーズ全4回の第2回（技術ブロック編）です。
このシリーズの位置づけ｜技術ブロック編とは
この記事は、「Googleにインデックスされない」問題を深掘りする全4回シリーズの第2回（技術ブロック編）です。総合的な原因と対処の全体像は、核となるGoogleにインデックスされない原因と対処法【2026年】にまとめています。まずは全体像をつかみたい方は、そちらを先に読むのがおすすめです。 総合ガイドが「浅く広く」原因を並べているのに対し、この記事は「技術的にインデックスを妨げている原因」を1つずつ深く掘り下げます。noindex、robots.txt、canonical、リダイレクト、サーバー応答、JavaScriptレンダリング——これらは設定ミス1つでページ全体が検索結果から消えることがある、影響の大きい要素です。それぞれについて「どう見つけるか」と「どう直すか」をセットで解説します。
シリーズ全4回の構成
第1回・診断編（Search Consoleのレポートの読み方）では、ステータスやカバレッジの読み方を詳しく扱います。この技術ブロック編（第2回）は、そこで見つかった「登録されない理由」を技術的に潰していく回です。第3回・品質編（コンテンツ品質とインデックス）は、技術的な問題がないのに登録されない場合の質・重複・薄いページの話。第4回・実践編（早くインデックスさせる方法）は、ブロックを解いたあとに登録を促進する実践策です。ステータスの読み方の詳細は第1回へ、品質面の対処は第3回へ、それぞれ誘導します。
この記事で使う3つの確認道具
技術ブロックの調査では、主に3つの道具を使い分けます。1つ目はSearch Consoleの「URL検査」——Googleが実際にそのURLをどう扱っているか（登録可否と理由、正規URL、クロール時の応答）を名指しで教えてくれます。2つ目はコマンドラインのcurl——サーバーが返すHTTPステータスやレスポンスヘッダを、ブラウザの表示に惑わされず生で確認できます。3つ目はブラウザの「ページのソースを表示」——JavaScriptで組み立てる前の、サーバーが最初に返したHTMLを見られます。以降、原因ごとにこの3つのどれで確認するかを具体的に示します。
原因①｜noindex（metaタグとX-Robots-Tagヘッダ）
インデックスされない技術的原因で最も多いのがnoindexです。noindexは「このページを検索結果に載せないで」という明確な命令で、これが残っているとGoogleはクロールしても登録を見送ります。厄介なのは、noindexには2つの伝え方があり、片方だけ見て「消したつもり」になりやすい点です。
metaタグ版の見つけ方と直し方
1つ目はHTML内のmetaタグです。ページのソースに `<meta name="robots" content="noindex">` （またはgooglebot指定）が入っていないかを確認します。ブラウザの「ページのソースを表示」でheadタグ内を検索するのが手早い方法です。公開前のステージング環境で全ページにnoindexを付け、本番反映時に消し忘れる——これが典型的な事故です。 直し方は、そのmetaタグを削除するか、`content="index,follow"` に変更します。WordPressなら「設定→表示設定→検索エンジンでの表示」のチェックや、SEOプラグイン側のnoindex設定を確認します。テーマやプラグインが自動で付けているケースもあるため、ソース上で消えたことを必ず確認してください。
X-Robots-Tag（HTTPヘッダ）版の落とし穴
もう1つが、HTTPレスポンスヘッダで送るX-Robots-Tagです。これはHTMLのソースには現れないため、ソース表示だけ見ていると見落とします。`curl -I https://example.com/page/` を実行し、レスポンスヘッダに `X-Robots-Tag: noindex` が含まれていないかを確認します。サーバー設定（.htaccessやNginx設定）やCDN、アプリ側のミドルウェアが付けていることがあります。 Search ConsoleのURL検査で「noindexタグにより除外」と出るのに、HTMLソースにmetaタグが見当たらない——そんなときはほぼこのヘッダ版が原因です。直し方は、サーバー設定やアプリのレスポンス処理からその出力を取り除くこと。metaタグとヘッダの両方をチェックする習慣が事故を防ぎます。
原因②｜robots.txtのDisallow（noindex併用の落とし穴）
robots.txtは、クローラーに「このパスは読み込まないで」と伝えるファイルです。noindexが「読んでいいが載せるな」なのに対し、robots.txtのDisallowは「そもそも読み込むな（クロール禁止）」という、より手前の制御です。この違いを理解していないと、直したつもりが逆効果になることがあります。
Disallowの見つけ方
まず `https://あなたのドメイン/robots.txt` をブラウザで直接開くか、`curl https://example.com/robots.txt` で中身を確認します。`Disallow: /` があれば全体がクロール禁止、`Disallow: /blog/` のように特定パスが禁止されていることもあります。Search ConsoleのURL検査でも「robots.txtによりブロック」と理由が表示され、robots.txtテスターで該当URLがブロック対象かを検証できます。 開発中に全ブロックの設定を入れたまま公開した、CMSが意図しないパスを塞いでいた、といったケースが典型です。まずは「今、何を禁止しているか」を正確に把握しましょう。
noindexと併用してはいけない理由
ここが最大の落とし穴です。「確実にインデックスから外したい」とき、noindexとrobots.txtのDisallowを両方かけるのは逆効果です。Disallowでクロールを禁止すると、Googleはページ本文を読み込めず、その中のnoindex指定にも気づけません。結果、URLだけがインデックスに残り続けることさえあります。 正しい使い分けはこうです。インデックスから確実に外したいページは、robots.txtでは許可（クロールさせる）したうえでnoindexを付けます。逆に、検索に載せたいページは、robots.txtでブロックしていないことを確認します。「載せたいのにDisallowで塞いでいる」「消したいのにnoindexがクロール禁止で読まれない」——どちらもよくある取り違えです。
原因③｜canonicalの誤りとリダイレクトの罠
canonical（正規URL）とリダイレクトは、どちらも「どのURLを正とするか」をGoogleに伝える仕組みです。設定が正しければ重複を整理して評価を集約できますが、誤ると本来載せたいページがインデックスから外れます。
canonicalの誤り（他ページ参照・自己参照ミス）
canonicalは `<link rel="canonical" href="...">` でheadに書き、「このページの正規URLはこれです」と宣言します。誤りで多いのは、全ページのcanonicalがトップページなど別の1ページを指してしまうケース。この場合、指されている以外のページはインデックスから外れます。テンプレートに固定URLを埋め込んだ、移行時に置換し損ねた、などが原因です。 見つけ方は、各ページのソースでcanonicalのhref値を確認し、そのページ自身のURL（末尾スラッシュやhttps/www有無まで一致）を指しているかをチェックします。Search ConsoleのURL検査では「ユーザーが指定した正規URL」と「Googleが選択した正規URL」が表示され、両者がずれていれば要調査です。直し方は、原則として各ページが自分自身を指す自己参照canonicalにすること。重複を集約したい意図がある場合だけ、集約先を正しく指定します。
リダイレクトの誤用（301/302・チェーン・ループ）
リダイレクトの誤りも登録を妨げます。恒久的な移転なら301、一時的な移転なら302を使うのが原則ですが、恒久移転に302を使い続けると評価の引き継ぎが不安定になります。また、A→B→C→…と何段も転送する「リダイレクトチェーン」や、A→B→Aとなる「リダイレクトループ」は、クロールを浪費させ、最悪ページに到達できません。 見つけ方は `curl -IL https://example.com/page/` です。`-L` を付けると転送を追いかけ、各段のステータス（301/302）と最終到達URLが順に見えます。何段も続く、あるいはループしているなら問題です。Search ConsoleのURL検査でも「リダイレクトエラー」や「リダイレクトあり」として検出されます。直し方は、転送は1段で最終URLへ直接飛ばすこと、恒久移転は301に統一すること。canonicalとリダイレクトが別々のURLを指して矛盾していないかも、あわせて確認します。
原因④｜サーバー応答（404・ソフト404・5xx・タイムアウト）
Googleがクロールしようとした瞬間にページが正しく返らなければ、当然インデックスされません。応答まわりの問題は「見た目は正常でも中身が問題」というパターンがあり、ステータスコードで切り分けるのが基本です。ステータスコードの詳しい読み方は第1回・診断編で扱いますが、ここでは技術原因として要点を押さえます。
404・5xx・タイムアウトの見つけ方
`curl -I https://example.com/page/` で先頭のステータス行を確認します。`200` なら正常、`404` はページが存在しない、`500`〜`503` などの5xxはサーバー側のエラーです。5xxが一時的でなく頻発していると、Googleはクロール頻度を下げ、インデックスにも悪影響が出ます。応答が極端に遅くタイムアウトする場合も同様に、クロールが途中で打ち切られます。 Search Consoleの「ページのインデックス登録」レポートでは、「404（見つかりませんでした）」「サーバーエラー（5xx）」といった理由が集計されます。まずここで、どの種類のエラーがどれだけ出ているかを把握し、curlで個別URLの実際の応答を裏取りするのが確実です。
ソフト404という厄介なケース
特に見落としやすいのが「ソフト404」です。これは、内容が実質的に存在しない（または「見つかりませんでした」と表示する）のに、サーバーは正常の200を返してしまっている状態です。Googleは中身を見て「これは実質404だ」と判断し、インデックスしません。curlで200が返るのに登録されないなら、これを疑います。 典型例は、在庫切れ・削除済みの商品ページを200で「該当商品はありません」と表示する、検索結果0件ページを200で返す、中身が空に近いページを大量生成する、など。直し方は、本当に存在しないページはきちんと404（または恒久移転なら301）を返すこと、そして残すページには意味のある内容を持たせることです。ソフト404は技術と品質の境界にある問題で、内容の薄さが根本原因の場合は第3回・品質編もあわせて確認してください。
原因⑤｜JavaScriptレンダリングとhreflang
近年のサイトはJavaScriptで本文を組み立てるものが増え、これがインデックスの新しいつまずきポイントになっています。Googleはある程度JavaScriptを実行しますが、それを前提にしすぎた構造は取りこぼしの温床です。あわせて、多言語サイトで起きやすいhreflangの取り違えも軽く触れます。
CSRで本文が空になる問題の見つけ方
完全なクライアントサイドレンダリング（CSR）では、サーバーが最初に返すHTMLはほぼ空で、本文はブラウザ上でJavaScriptが後から描画します。ここで確認すべきは「JS実行前のHTMLに本文が入っているか」です。ブラウザの「ページのソースを表示」（これはJS実行前の生HTML）を見て本文が空なら要注意。一方、開発者ツールの「要素」タブはJS実行後なので、両者の差が大きいほどCSR依存が強いと分かります。curlで取得したHTMLに本文テキストが含まれるかでも判定できます。 Search ConsoleのURL検査で「公開URLをテスト」し、レンダリング後のスクリーンショットやHTMLを見れば、Googleが最終的に何を認識したかが分かります。ここで本文が欠けている、hydration（JSでの後付け描画）を待つ前に主要コンテンツが無い、という状態なら、インデックス内容が薄くなったり登録自体が遅れたりします。
レンダリング問題の直し方
根本的な対処は、主要なコンテンツを最初のHTMLに含めることです。サーバーサイドレンダリング（SSR）や静的生成（SSG）を使えば、Googleはレンダリングを待たずに本文を読めます。当社が採用するNext.jsのような仕組みが有利なのはこの点で、詳しくはWordPressとNext.jsの比較やホームページSEOの基本で整理しています。加えて、重要な情報は構造化データでも補強すると、機械的な理解が安定します。 どうしてもCSR中心にせざるを得ない場合でも、最低限の本文・見出し・メタ情報はサーバー側で返す、無限スクロールやタブ切り替えの裏に本文を隠さない、といった配慮で取りこぼしを減らせます。「人には見えているのにGoogleには見えていない」状態を作らないことが要点です。
hreflang・言語ページの取り違え（軽く）
多言語サイトでは、hreflangで各言語版の対応関係をGoogleに伝えます。ここで日本語ページが英語版を指す、相互参照（相手からの返しのhreflang）が欠ける、といった誤りがあると、意図しない言語版が選ばれたり、正しく評価されなかったりします。見つけ方は、各ページのhreflang指定がお互いを正しく指し合っているか、URLや言語コードに誤りがないかの確認です。まずは単一言語のインデックス問題を解決してから、多言語の整合に取り組むのが現実的な順序です。
まとめ｜技術ブロックの切り分け手順
技術的にインデックスをブロックする原因は、上から順に潰していくのが効率的です。(1)noindexをmetaタグとX-Robots-Tagヘッダの両方で確認、(2)robots.txtのDisallowと、noindexとの併用ミスをチェック、(3)canonicalが自分自身を正しく指しているか、(4)リダイレクトが1段で正しいステータスか、(5)curlでステータスを確認し404/ソフト404/5xxを切り分け、(6)JS実行前のHTMLに本文が入っているか、(7)多言語ならhreflang。この順でURL検査・curl・ソース表示を使えば、技術原因の大半は特定できます。
技術は片づいたのに登録されないときは
ここまでの技術ブロックをすべて解いても登録されない場合、原因は技術ではなく「登録に値するか」という品質・重複・独自性の側にあることが多いです。その切り分けと対処は第3回・コンテンツ品質とインデックスへ。ブロックを解いたあとにインデックスを早める具体策は第4回・早くインデックスさせる方法にまとめます。ステータスコードやカバレッジレポートの読み方をより深く知りたい方は、第1回・Search Consoleのレポートの読み方へ戻ってください。
よくある質問
Q.noindexを消したのに、まだインデックスされません。なぜですか。
HTMLのmetaタグだけ消して、HTTPヘッダのX-Robots-Tagが残っている可能性があります。`curl -I` でレスポンスヘッダに `X-Robots-Tag: noindex` が無いかを確認してください。metaタグ（ソース表示）とヘッダ（curl -I）の両方をチェックするのが確実です。反映後にSearch ConsoleのURL検査で再確認しましょう。
Q.robots.txtでブロックすればインデックスから消せますか。
いいえ、むしろ逆効果になることがあります。robots.txtのDisallowはクロールを禁止するため、ページ内のnoindexが読まれず、URLだけがインデックスに残ることがあります。確実に消したいページは、robots.txtでは許可（クロールさせる）したうえでnoindexを付けてください。この2つの併用が典型的な落とし穴です。
Q.canonicalの誤りはどう確認すればいいですか。
各ページのソースで `<link rel="canonical">` のhref値を確認し、そのページ自身のURL（https/www・末尾スラッシュの有無まで一致）を指しているかをチェックします。全ページが同じ1ページを指していると、その他はインデックスから外れます。Search ConsoleのURL検査で「Googleが選択した正規URL」と自分の指定がずれていないかも見てください。原則は自己参照canonicalです。
Q.ソフト404とは何ですか。普通の404と何が違いますか。
ソフト404は、実質的に中身が無い（または「見つかりません」と表示する）のに、サーバーが正常の200を返している状態です。Googleは内容を見て実質404と判断し、インデックスしません。curlで200が返るのに登録されないなら疑ってください。本当に存在しないページは、きちんと404（恒久移転なら301）を返すのが正しい対処です。
Q.JavaScriptで作ったサイトはインデックスされにくいのですか。
完全なクライアントサイドレンダリング（CSR）だと、最初のHTMLが空で本文がJS描画頼みになり、取りこぼしや登録の遅れが起きやすくなります。ブラウザの「ソース表示」（JS実行前）で本文が入っているかを確認しましょう。SSRやSSG（Next.jsなど）で主要コンテンツを最初のHTMLに含めるのが根本的な対処です。
Q.技術的なブロックを全部直しても登録されません。
noindex・robots.txt・canonical・リダイレクト・サーバー応答・レンダリングをすべて解消しても登録されない場合、原因は「登録に値するか」という品質・重複・独自性の側にあることが多いです。第3回・品質編（/blog/google-index-content-quality）をご確認ください。全体像は核となる総合ガイド（/blog/google-index-troubleshoot）にあります。