下層ページがSEOで効かない理由｜トップだけ強いサイトを立て直す判断基準
下層ページがSEOで効かない理由｜トップだけ強いサイトを立て直す判断基準
「会社名で検索すればトップページは出る。でも、サービスページもブログ記事も、いくら書いても検索に出てこない」
この状態のとき、記事を増やしたりリライトしたりしても、多くの場合は状況が変わりません。下層ページがSEOで効かない原因は、コンテンツの中身より先に「検索エンジンが下層ページを1枚のページとして認識できていない」構造側にあることが多いからです。
結論から書きます。下層ページが効かないと感じたら、最初にやるべきことは次の3つの確認です。
- 下層ページのHTMLに本文テキストが入っているか
- canonical（正規URL）が自分自身のURLを指しているか
- sitemap.xmlにその下層ページが載っているか
この3つのどれかが崩れていると、記事を何本積んでも評価はゼロのまま積み上がります。逆に言えば、ここを直すだけで既存の記事が一斉に検索資産に変わります。
この記事では、その3点診断のやり方と、「構造から作り直すべきか」「今の構造のまま直せるか」を分ける判断基準を、実際に測った数字とあわせて書きます。
—
1. ブラウザで見えている画面は、検索エンジンが見ている画面ではない
まず大前提として、下層ページの状態はブラウザで見ても判断できません。
いまのサイトの多くは、JavaScriptで画面を組み立てる作りになっています。この方式だと、ブラウザ上では記事本文が普通に表示されるのに、検索エンジンが最初に受け取るHTMLには本文が1文字も入っていない、ということが起こります。人間の目には完璧に見えるので、担当者も制作会社も気づけません。
だから、HTTPの生のレスポンスで確認する必要があります。ターミナルが使える環境なら、次の3つで判定できます。
# 記事を2〜3本、バイト数を比べる
curl -s https://example.com/blog/kiji-a/ | wc -c
curl -s https://example.com/blog/kiji-b/ | wc -c
# canonicalがどこを指しているか
curl -s https://example.com/blog/kiji-a/ | grep canonical
# 本文の一節がHTMLに含まれるか
curl -s https://example.com/blog/kiji-a/ | grep "本文の書き出し"判定基準はシンプルです。
| 結果 | 意味 |
|---|---|
| 記事ごとにバイト数が違う・canonicalが自分のURL・本文が含まれる | 正常。下層は評価されうる状態 |
| 複数の記事がまったく同じバイト数を返す | 全記事が同じ1枚のHTMLを返している疑い |
| canonicalがトップページなど別のURLを指している | 「このページの正体はトップです」と自ら申告している状態 |
| 本文テキストがHTMLに含まれない | 検索エンジンから見ると中身の無いページ |
ターミナルが使えない場合は、ブラウザで下層ページを開き、右クリック →「ページのソースを表示」で出てくるテキストの中を検索してください。「検証」ツールではなく「ソースを表示」です。前者は組み立て後の状態を見せてしまうので判定になりません。
—
2. 実際に測ると、168記事すべてが評価ゼロだったことがある
この診断が有効なのは、実際にそれで問題が見つかるからです。
graciautoが自社サイトに同じ診断をかけたときの実測値を出します。JavaScript主体の構成で、ブログ記事は168本ありました。本番のHTTPレスポンスを測ると、こうなっていました。
/blog/{記事名}/は、どの記事にアクセスしても372,542バイトのまったく同じHTMLを返していた- そのHTMLのcanonicalは、全記事ともトップページ（
https://graciauto.jp/）を指していた - つまり168本すべてが、検索エンジンから見ると1枚のトップページでしかなかった
一方、同じサイト内で裏側に残っていたCMS側のURLは139,509バイトで、canonicalも自分自身を指していました。検索エンジンに評価されていたのはそちらだけで、表側の168本は評価がゼロだったということです。
ブラウザで開けば記事は普通に読めます。表示速度も速い。だからこそ、生のレスポンスで測るまで誰も気づきません。「表示されている＝インデックスされている」ではないという一点が、下層ページの問題では一番大きな落とし穴です。
JavaScript主体のサイトは「200が返る＝ページが存在する」ではない
もうひとつ、この構成には確認上の罠があります。JavaScript主体のサイトは、どのURLにアクセスしても同じHTMLを返す設定になっていることが多く、その場合は存在しないURLでも正常応答（200）が返ります。そのため、URLを叩いて200が返ったことは、そのページが実在する証拠になりません。
このときは、サイトが読み込んでいるJavaScriptファイルの中にあるルート定義（どのURLでどの画面を出すかの一覧）を確認するのが確実です。実際にこの方法で数えたところ、当時の自社サイトの実在ページは22本だけでした。この数え方をすると、社内の記録上は存在するはずのページが本番には無い、というズレも同時に見つかります。
サイトの現状把握は、記憶や過去の記録ではなく実測から始めるのが安全です。「作ったはず」「入れたはず」は、次の作り替えのときに黙って消えていることがあります。
—
3. 下層ページを殺すもう1つの経路は、sitemapと内部リンク
本文とcanonicalが正常でも、下層ページが拾われないことがあります。原因は導線です。検索エンジンはリンクとsitemapをたどってページを見つけるので、そのどちらにも載っていないページは、存在しても発見されません。
同じサイトを実測したとき、sitemap.xmlはこうなっていました。
- 手書きで7URLしか書かれていなかった（168記事は1本も掲載なし）
- しかも実在しないURLが1本混ざっていた（
/companyと書かれていたが、実際のページは/about） - robots.txtが別系統のsitemapも同時に宣言していて、同じ内容の2つのURLを自ら検索エンジンに差し出していた
sitemapを手書きで運用すると、こうなりやすくなります。ページを増やしたときに追記されず、消したページが残り、実在しないURLを載せ続けることになるためです。
正しいやり方は次の3つです。
① sitemapは自動生成にする
記事・カテゴリ・固定ページを全件、更新日（lastmod）付きで自動出力する仕組みにします。自社サイトを作り直した際は220URLが自動で載るようにしました。日本語のURLを使っている場合は、sitemap内ではASCII形式に変換して出力する必要があります。なお、sitemapのファイル名を変えなければサーチコンソールへの再登録は不要です。ファイル名を変えると再送信が必要になるので、意味なく変えないほうが安全です。
② robots.txtで宣言するsitemapを1本に絞る
複数宣言していると、同じ内容の2系統のURLを両方インデックスさせようとして、自分で自分の順位を割ることになります。
③ 内部リンクを手作業に頼らない
「関連記事を手で貼る」運用は、記事が数十本を超えたあたりで止まります。自社サイトでは、全168記事に対して同カテゴリの新しい記事3本を自動で挿入し、記事のカテゴリに応じたサービスページへの導線も自動で出すようにしました。あわせてカテゴリ別の一覧ページを19本新設し、「カテゴリ一覧 → 記事 → 関連記事」というかたまりを作っています。個々の記事を孤立させないことが、下層ページを効かせる条件です。
—
4. 作り直すか、今のまま直すかの判断基準
ここまでの診断結果で、打ち手は変わります。判断基準を表にします。
| 診断結果 | 打ち手 | 規模感 |
|---|---|---|
| 下層のHTMLに本文が無い／全ページ同一バイト | 構造から作り直す。部分修正では直らない | 数週間規模の再構築 |
| 本文は入っているが、canonicalが自ページを指していない | テンプレートの修正で足りる | 数日 |
| 本文もcanonicalも正常。sitemap未掲載・内部リンクが無い | sitemapの自動生成と内部リンクの整備 | 数日 |
| 下層は正常。それでもトップだけ強い | 構造ではなくコンテンツと検索意図の問題。記事側の改善へ | 継続対応 |
上2つと下2つでは、やることも費用もまったく違います。診断せずに「SEO対策」を発注すると、構造が壊れているのに記事を書き足す、という一番効かない組み合わせになりがちです。
制作会社に任せている場合は、次の3つをそのまま聞いてみてください。答えられない会社には、構造側の判断は任せないほうがいいと思います。
- 「記事ページのHTMLに、本文テキストは入っていますか」
- 「記事ページのcanonicalは、そのページ自身を指していますか」
- 「sitemapは自動生成ですか。記事は全件載っていますか」
なお、作り直しになった場合の規模感として、自社サイトは記事168本を含む204ページとして再構築し、そこにカテゴリページやサービス関連ページを足して最終的に228ページ構成になりました。ページ数そのものより、「全ページが本文入りのHTMLを返し、canonicalが自己参照で、sitemapに全件載っている」状態を作れるかが本質です。
—
5. 作り直すときにURLを1本も落とさないための原則
構造から作り直すと決めた場合、最大のリスクは今あるインデックスを失うことです。ここは順番を間違えると、下層を直したのに検索流入が落ちる、という結果になります。
原則は1つだけです。すでに検索エンジンに登録されている下層URLは、新しいサイトでも同じURLのまま採用する。これだけでリダイレクトが不要になり、評価をそのまま引き継げます。
愛知県内のクリニックのサイトを158ページ構成で作り直した際は、この原則で設計しました。既存でインデックス済みだった18本のURLはそのまま採用し、57本ある解説記事もディレクトリ構成を変えずに維持。結果、301リダイレクトが必要になったのは3系統だけに絞れています。
あわせて、移行時に起こりやすい失敗と、その予防策を挙げておきます。どれも事前に手を打てるものです。
URLを「分かりやすい名前」に変えたくなる
リニューアルの打ち合わせでは必ず出る話ですが、URLを変えた分だけ評価は一度リセットされます。変えるなら意図的に、旧URLと新URLの対応表を作ってから変える。「なんとなく整えた」が一番損をします。
リダイレクトの一括ルールが、実在するページを巻き込む
「この形式のURLはもう存在しないはず」という前提で一括ルールを書くと、条件に合致する現役ページを誤って転送してしまうことがあります。数字だけのURLを持つ記事が現役で残っていた、というのは実際に起こるパターンです。ルールを置く前に、そのパターンで実データを検索して突き合わせるのが予防策になります。
日本語URLのリダイレクトが効かない
日本語を含むURLをリダイレクト設定に書くとき、記号を変換した形式（%E3%81%82 のような表記）で書くと、サーバー側は元の日本語に戻した状態で判定するためマッチせず、そのページだけ404になります。英語のURLは通るのに日本語のURLだけ死ぬ、という症状です。日本語URLがあるサイトでは、移行後に日本語URLのページを個別に確認してください。
移行後の確認を1ページで終わらせる
トップページだけ見て正常と判断すると、残りが壊れていても気づけません。確認とは、確認した項目についてしか言えないものです。作り直し後の検証は、確認する項目を先に決めて、全下層URLに同じチェックをまとめて回すのが確実です。
—
6. 直したあとに見るべき数字
構造を直したら、次の順で確認します。
- 全下層URLが正常応答を返すか（サンプル数本ではなく全件）
- 全ページでcanonicalが自己参照になっているか
- sitemapのURL数と、実在するページ数が一致しているか
- サーチコンソールでsitemapを再送信し、インデックス登録済みページ数の推移を見る
4番は反映に時間がかかります。構造を直した効果は、当日ではなく数週間かけて登録済みページ数の増加として表れます。直後に順位が動かないことを理由に「効果が無かった」と判断しないことが大事です。
—
まとめ
下層ページがSEOで効かないとき、原因はコンテンツより先に構造にあります。順番はこうです。
- まず測る：下層ページのHTMLに本文が入っているか、canonicalは自分を指しているか、sitemapに載っているか
- ブラウザで判断しない：表示されていても、検索エンジンには空のページに見えていることがある
- 診断結果で打ち手を分ける：本文が無いなら作り直し、canonicalだけならテンプレ修正、導線だけならsitemapと内部リンク
- 作り直すならURLを維持する：インデックス済みのURLをそのまま使えば、評価は引き継げる
- 効果は登録済みページ数で見る：順位より先に、インデックスされたページ数が動く
実測してみると、168本の記事が丸ごと評価ゼロという状態も現実に起こります。逆に言えば、記事の中身は十分なのに構造だけで損をしているサイトは珍しくありません。新しい記事を書き足す前に、いまある下層ページが検索エンジンに届いているかを1度測る。ここから始めるのが、最も費用対効果の高い順番です。