インデックスされない原因の見分け方｜待つべき症状と直すべき構造
インデックスされない原因の見分け方｜待つべき症状と直すべき構造
ページを公開したのに検索結果に出てこない。Search Console（サーチコンソール）で見ると表示回数が伸びない、あるいはある日を境にゼロに落ちている。このとき取るべき行動は2つに1つです。何もせず待つか、サイトの構造を直すか。この判断を間違えると、待つべき場面で余計な設定変更を重ねて回復を遅らせるか、直すべき場面で数か月放置して機会を捨てることになります。
先に結論を書きます。判定は次の順番で行います。
| 手順 | 確認すること | 結果の意味 |
|---|---|---|
| 1 | 本当に出ていないのか（ページ単位ではなくサイト全体で見る） | ここで解決することが多い |
| 2 | ページのHTMLに本文が入っているか | 入っていなければ構造の問題 |
| 3 | sitemapに載っているか／robots.txtで塞いでいないか | 塞いでいれば出ない |
| 4 | canonicalとURLが自分自身を指しているか | ずれていれば別ページの一部として扱われる |
1で終われば「待つ」、2〜4のどれかで引っかかれば「直す」です。この順番で見るのは、上ほど頻度が高く、確認コストが低いからです。以下、それぞれを実際のデータで説明します。
手順1：ページ単位のグラフだけを見て判断しない
最初に確認すべきは「本当にインデックスされていないのか」です。ここを飛ばして構造を疑い始めるケースが非常に多く、実際には健全なのに手を入れてしまうことがあります。
自社サイトで実際に観測した例を挙げます。Search Consoleを特定ページで絞り込んで見たところ、ある日以降クリックも表示もゼロになっていました。サイト内で最も検索流入のある記事だったため、一見すると重大な事故に見えます。
しかし同じ記事のURLを洗い直すと、評価が3つのURLに分かれていただけでした。
| URL | 表示 | クリック | 平均順位 |
|---|---|---|---|
| 末尾スラッシュなしの旧URL | 211 | 5 | 9.0 |
| 移行前ディレクトリのURL | 169 | 3 | 8.5 |
| 現在の正規URL | 7 | 0 | 7.4 |
3つとも実際の挙動は正しく、旧URLは正規URLへ転送されていました。見ていたのは引っ越し前の住所だったわけです。新住所側はまだ数字が積み上がっていないので、そこだけ見れば「死んだ」ように見えます。
こうした誤読を防ぐため、判定は必ず3つの層で行ってください。
- ページ単位 … 一番手前に見える数字。単独では判断材料にならない
- クエリ（検索語）単位 … 同じ検索語で自サイトが何回表示されたか
- サイト全体 … 総表示回数の推移
先の例では、ページ単位はゼロでも、クエリ単位は安定〜微増、サイト全体はむしろ増加していました。この形なら手を入れる必要はありません。
移行の規模感も数字で出しておきます。200ページ超を静的サイトへ切り替えた際、旧ディレクトリと新ディレクトリの実績はこう動きました。
| 期間 | 旧ディレクトリ | 新ディレクトリ |
|---|---|---|
| 切替前の29日間 | 147ページ・3,237表示 | 78ページ・1,555表示 |
| 切替後の3日間 | 45ページ・223表示 | 53ページ・227表示 |
1日あたりの表示は切替前165・切替後150でほぼ横ばい。新旧の入れ替わりが完了するまでには数週間かかります。この期間中は同じ記事が2つのURLで表示されるため、クリック率も実態より悪く見えます。したがってこの時期にタイトルや説明文を触っても、効果測定ができません。まず収束を待つのが正しい進め方です。
この期間に一番やってはいけないのが、焦って転送設定や正規URL指定を短期間で反転させることです。検索エンジン側は変更のたびに再評価をやり直すため、回復がさらに遅れます。移行から数週間は原則として触らない、と決めておくのが安全です。
手順2：ブラウザで見えている画面と、検索エンジンが読む画面は違う
ここから「直すべき」側です。まず確認するのは、ページのHTMLに本文の文字が入っているかどうか。
JavaScriptで画面を組み立てる構成のサイトでは、サーバーが返すHTMLの中身が空で、ブラウザが後から本文を差し込んでいることがあります。この状態でもブラウザでは正常に見え、通信の応答コードも200が返ります。「ページは存在するのに検索に出ない」の典型です。
確認は、ブラウザの「ページのソースを表示」で本文の一節を検索するだけで済みます。見えている文章がソースに無ければ、それが原因です。実際、自社サイトでも記事170本弱がすべて同一の空HTMLを返している状態が見つかったことがあります。この構成のまま記事を増やしても、増えた分の評価は積み上がりません。
対処は、ビルド時に本文を書き出す構成（静的生成）に切り替えるのが確実です。表示速度の副次的な改善も同時に得られます。改修規模が大きい場合でも、少なくとも記事ページだけは本文入りのHTMLを返すようにしてください。
手順3：sitemapとrobots.txtを実際に開いて確認する
ここは費用ゼロで直せるのに、見落とされやすい箇所です。
sitemap.xmlをブラウザで開き、出ないページのURLが実際に載っているかを確かめてください。手書きで作られたsitemapが数URLしか持っておらず、記事が1本も載っていない、といったことが起こり得ます。すでに存在しないページが載ったままになっていることもあります。sitemapは公開ページ数と件数が一致しているのが正常な状態です。自動生成に切り替え、更新日時（lastmod）まで入れておくのが望ましい形です。
robots.txtは、意図しない範囲を塞いでいないかを確認します。特に注意したいのが、開発用・管理用のサブドメインを全面的に遮断している場合の副作用です。ページ自体は本番ドメインで正常に配信できていても、画像だけを遮断ドメインから読ませていると、検索結果のサムネイルや共有時の画像が表示されません。自社サイトでは記事167本分のアイキャッチ画像がこの状態にあったため、画像を公開ドメイン側に配置し直して解消しました（1200×630に圧縮して配置、追加容量は約11MB）。
もう1つ、逆方向の落とし穴があります。「検索結果から消したい」ページをrobots.txtで丸ごと遮断すると、かえって消えなくなることがあるという点です。ページ内に「検索に出さない」指定（noindex）を書いても、robots.txtで遮断していると検索エンジンはその指定を読みに来られません。結果、URLだけが検索結果に残ることがあります。確実に消したい場合は、そのページへのアクセスは許可し、noindexを読ませる設計にします。管理用サイトなら「全面遮断＋必要なページだけ許可」の組み合わせが実務的です。
手順4：canonicalとURLの実体を確認する
最後に、ページが自分自身を正規URLとして宣言しているかを見ます。ソース内の canonical の指し先が、そのページ自身のURLになっていれば正常です。全ページがトップページを指しているような状態だと、個別ページは独立したページとして扱われません。
もう1つ、URLそのものが成立していないケースもあります。日本語をURLに使っているサイトで起こりやすい問題です。WordPressのAPIから取得したURL文字列は変換済みの形式で返るため、その文字列をそのままファイル名として書き出すと、記号の羅列のようなディレクトリができて404になります。日本語URLを含むサイトを静的化・移行するときは、必ず変換を戻してから扱い、公開後に日本語URLのページを実際に開いて確認してください。
直すときの安全な進め方
構造を直す作業には、既存の評価を落とすリスクが伴います。転送設定の書き間違いで無関係なページまで巻き込む事態は起こり得るので、次の手順を型にしておくと安全です。
- 本番に反映する前に、影響範囲を実測する。特定のパラメータが付いたときだけ動く一時ルールを入れて、意図したURLだけが反応するかを確認します。通常のアクセスには一切影響しません
- sitemapに載っている全URLに対して、機械的に照合する。転送されるべき1件だけが転送され、残りが正常であることを数で確認します
- 設定ファイルのバックアップを2か所に取る（公開ディレクトリの中と外）。デプロイ作業で設定ファイルごと上書きされ、転送設定が消えるという事態を防げます
- 反映後、主要ページを一通り開いて応答を確認する
直したあと、いつ判定するか
改善の効果は、翌日には出ません。1日あたりの表示回数が数十回規模のサイトでは、数日分の比較は誤差しか見えないからです。平均順位は1回の検索で大きく動きます。
自社では5日ごとに分析を実行し、比較は28日のローリング期間で行う運用にしています。施策を打った記録も残し、後から「実施前14日 対 実施後14日」で自動的に効果を測る形です。打ちっぱなしにしないための仕組みです。
構造を直した直後にできることとしては、更新をすぐ通知する仕組み（IndexNow）をビルドに組み込んでおく方法があります。ただしこれは通知が届くだけで、順位や表示が保証されるものではありません。
よくある質問
Q. 公開してから何日待てば「出ない」と判断していいですか
新規ドメイン・新規サイトなら数週間、既に他のページが検索に出ているサイトの追加ページなら数日から2週間が目安です。ただし待つ前に手順2〜4だけは先に済ませてください。HTMLが空だったりsitemapに載っていなかったりする場合は、何か月待っても出ません。逆に4項目すべて問題なければ、待つ以外にできることはほとんどありません。
Q. Search Consoleの「インデックス登録をリクエスト」は押すべきですか
構造を直した直後に1回押すのは有効です。ただし同じURLに対して繰り返し押しても早くはなりません。数十ページ以上ある場合は個別のリクエストではなく、sitemapを正しく整備して再送信するほうが確実です。
Q. 記事を増やせばインデックスされやすくなりますか
原因が構造側にある場合、記事を増やしても状況は変わりません。仮に本文がHTMLに出力されていない構成なら、増やした分もすべて同じ状態になります。まず4項目を確認し、問題がないと確認できてから増やすのが順番です。
Q. サイトを引っ越したあと、旧サイトはいつ消していいですか
転送設定を維持したまま、最低でも数か月は残してください。旧URLでの表示が実質ゼロに収束し、新URLに数字が移り切ったことをSearch Consoleで確認してから判断します。急いで消すと、転送も評価の受け渡しも同時に切れます。
まとめ
インデックスされない、という症状は原因が1つではありません。判定の順番だけ覚えておいてください。
- ページ単位のグラフを鵜呑みにしない。クエリ単位とサイト全体を必ず併せて見る。移行中は評価が複数URLに分散し、数週間かけて収束する
- HTMLに本文が入っているかを「ページのソースを表示」で確認する。ここが空なら、記事を増やしても積み上がらない
- sitemapとrobots.txtは実際に開く。載っていない・塞いでいるは、費用ゼロで直せる
- canonicalとURLの実体を確認する。特に日本語URLは公開後に実際に開いて確かめる
- 直したら数週間は触らない。短期間での反転は回復を遅らせる
「待つ」と判断できることも成果です。原因を特定せずに設定を変え続けるのが、いちばん時間を失う進め方です。
graciautoでは、ホームページ制作と並行して、公開後に検索から人が来る状態までを設計しています。サイトを作ったのに問い合わせが増えない、記事を書いているのに検索に出ない、という段階でのご相談も承っています。