去年の春、火曜日の朝にクライアントから電話がかかってきました。声には本当のパニックが込められていました。彼は物件掲載サイトを運営していて、ページ数は約42,000ページ。Google Search Consoleには、そのうちわずか5,800ページしかインデックスされていないと表示されていました。インデックス可能なページのおよそ86%を一晩で失ったのです。アルゴリズム更新もない。手動対策もない。最近のデプロイメントも思い当たらない。ただ消えていました。
重要なポイント：40,000ページのWordPressサイトで6,000ページしかインデックスされていない場合、その原因はほぼ確実にアーキテクチャにあります。つまり、ファセット化されたURL、シンテンプレート、クロール浪費が原因であり、Googleペナルティではありません。
Seahawkの12,000以上のWordPress構築全体で、この正確なシナリオを何度も見てきました。そして本当にやっかいなのは、大規模サイトのインデックス喪失には通常、一つの原因ではなく、通常は3つか4つの小さな失敗が静かに複合されて、最終的に何かが崩壊するということです。
ここが私が実際に診断する方法です。
---
Google Search Consoleから始める、ただしそこで止まらない
私がまず最初にすることは、Google Search ConsoleのPagesレポートを開くことです。古いCoverageレポートではなく、Googleは2023年にこれを更新し、新しいPages表示はインデックス済みと非インデックスを適切な理由コードで分類しています。初日にスクリーンショットを撮ってください。ベースラインが必要です。
理由コードは極めて重要です。「クロール済み、現在インデックスに登録されていない」は「'noindex'タグで除外」とは全く異なる問題です。前者は品質シグナルの問題で、後者は設定のミスです。両者を同じものとして扱い、数週間を無駄にしている開発者を見てきました。
大規模サイトで最も頻繁に見られる理由
- クロール済み、現在インデックスに登録されていない：Googleはページにアクセスしましたが、インデックスに登録する価値がないと判断しました。通常、コンテンツが薄い、近い重複、またはバックリンクや内部リンクを獲得していないページです。
- 発見済み、現在インデックスに登録されていない：GoogleはURL（おそらくサイトマップから）を見つけましたが、まだクロールしていません。これはコンテンツの問題ではなく、クロールバジェットの問題です。
- 'noindex'タグで除外：誰か、もしかしたらあなた、またはプラグインがnoindexディレクティブを追加しました。詳しくは下を参照してください。
- 重複、Googleが別の正規URLを選択：正規タグが予期しない場所を指しているか、Googleが正規タグをオーバーライドしています。
- リダイレクト付きページ：インデックス可能であるべきページが、正しくまたは正しくないかはともかくどこかにリダイレクトしています。
合計を見るだけではいけません。各理由コードの完全リストをCSVとしてダウンロードしてください。40,000ページのサイトでは、ソートとフィルター処理ができる必要があります。
---
クローリング予算は実在し、大規模サイトを破壊する
2019年に遡ると、Seahawkは大規模なeコマースクライアント、約28,000の商品ページを扱っていて、Googleが1日あたり約3,000ページしかクロールしない理由が全く理解できませんでした。サイトは高速でした。サイトマップはクリーンでした。表面上はすべてうまくいっているように見えました。
サイトが数千個のファセットナビゲーションURL（?colour=red&size=large&sort=priceのような）を生成していたことが判明しました。これらは クローラブルでしたがカノニカルタグが適切に設定されておらず、Googlebotの実際の商品ページに到達する前にクロール予算を消費していました。
クロール予算は基本的に、Googlebotが一定期間内にサイト上をクロールすることを厭わないURLの数です。Googleのクロール予算に関する公式ドキュメントは本当に読む価値があります。彼らは正直にその仕組みについて説明しています。簡潔に言うと、ゴミURLにそれを無駄にしていれば、重要なページはクロールされません。
クローリング予算を実際に監査する方法
- サーバーログを取得しましょう。Googleのクロール統計ではなく、実際のサーバーログです。Screaming Frogのログファイルアナライザーのようなツールなら、Googlebotのヒットだけをフィルタリングできます。
- Googlebotの訪問のうち実際に関心のあるURLに着地しているパーセンテージを確認してください。60%以下であれば、予算に問題があります。
- 最もクロール数を消費しているURLパターンを見つけてください。頻度でソートしてください。トップの問題は例外なく次の4つです：ファセット化されたナビゲーション、ページング化されたアーカイブのページネーション、セッションIDパラメータ、および空のカテゴリ・タグアーカイブページ。
- 症状ではなく根本を修正してください。クロールすべきではないパラメータに対してはrobots.txtで Disallow を設定してください。その他すべてはcanonical タグを使用してください。
そのeコマースプロジェクトでは、robots.txtでファセット化されたURLをブロックし、すべてのフィルタビューにrel="canonical"を追加しました。6週間以内に、インデックス済みページは8,000から24,000に増加しました。コンテンツは同じです。Googlebotが単にそこに到達できるようになっただけです。
---
noindexの災い（思ったより頻繁に起こっている）
自分でやったことがあるから、これについて話す必要があります。最高の瞬間ではありませんでした。2021年に、ニュースサイトのステージング環境から本番環境への移行中に、WordPress設定の「読み込み」セクションで「検索エンジンがこのサイトをインデックスするのを控えるようにリクエスト」のチェックボックスを外し忘れました。サイトは全サイト規模のnoindexを付けたまま本番環境に移行しました。クライアントがオーガニックトラフィックが激減したことに気づくまでに11日かかりました。
WordPressはそのチェックボックスを誰も予想しない場所に埋め込んでいます。そして Yoast、Rank Math、AIOSEOなど、特定のSEOプラグインはポストタイプレベル、タクソノミーレベル、個別ページレベルで独自のnoindexトグルを持っています。それらのいずれかが、サイトの大部分を静かにnoindexにしてしまう可能性があります。
規模を大きくしてnoindexをチェックする方法
Screaming Frogをサイト全体に実行し、noindexディレクティブを返すページをフィルタリングしましょう。リストをエクスポートし、その後、商品ページ、サービスページ、ブログ記事、ビジネスにとって重要なものなど、重要なURLグループと相互参照してください。
また yourdomain.com/robots.txt にあるrobots.txtを確認しましょう。過度に広いDisallow:ルールを探してください。Googleがページを正しくレンダリングするために必要なCSSやJSをブロックするDisallow: /wp-content/のようなルールを見てきました。それはインデックス登録の問題に見えますが、実際はGooglebotが壊れたページを見ているレンダリング失敗です。
---
静かに不具合を起こしているカノニカルタグ
カノニカルは大規模なWordPressサイトで最も狡猾なインデックス殺しです。単独で見ると正しく見えるため、規模を大きくするとだけその被害が明らかになるからです。
私が頻繁に見かけるパターンはこれです。WooCommerceを使用しているサイトには、複数のURLパス（/product/red-shoes/、/product-category/footwear/red-shoes/、時には /shop/red-shoes/）でアクセス可能な商品があります。それぞれにカノニカルタグがありますが、それらのカノニカルが若干異なるURL（HTTPとHTTPS、末尾スラッシュあり/なし、wwwあり/なし）を指している場合、Googleはそれらを異なるページを指すシグナルとして扱い、統合を拒否します。
修正方法は地味ですが必要です。
- WordPressがどのようなURL構造を生成しているかすべて監査してください。Screaming Frogでサイトをクロール→「Canonical」でフィルタ→エクスポートします。
- プロトコルの不一致、末尾のスラッシュ、サブドメインの違いをチェックしてください。
- canonicalが優先URLと完全に一致していることを確認してください。1文字も異なってはいけません。
Rank MathもYoastもcanonicalタグを自動生成しますが、どちらのプラグインも.htaccessのリダイレクトやCDNのURL正規化については把握していません。プラグインが出力していると思っているものではなく、実際に表示されるcanonicalを検証する必要があります。httpstatus.ioのようなツールでページを取得し、実際のレスポンスヘッダーとHTMLを確認してください。
---
大規模サイトではXMLサイトマップが間違っていることが多い
ほとんどのWordPress SEOプラグインはサイトマップを自動生成します。その多くは、サイトマップに含める必要のないURL（ページネーションページ（/page/2/、/page/3/）、著者アーカイブ、2つの投稿しかないタグページ、添付ファイルページ）も含めます。
サイトマップは、最高の標準的なページの短いリストであるべきです。WordPressが生成したあらゆるURLを並べたものではなく。
実際に実行しているサイトマップ衛生管理ルール
- ページネーション付きアーカイブページは除外する。常に。
- マルチオーサーサイトでオーサーページが本物のコンテンツ価値を持つ場合を除き、オーサーアーカイブページは除外する。
- タグが編集上で管理され、意味のあるコンテンツを持つ場合を除き、タグアーカイブは除外する。
- 投稿数の閾値を設定してください。通常は5未満の投稿を持つアーカイブページを除外します。
- 大規模なサイトマップをサイトマップインデックスに分割する。個々のサイトマップファイルは10MB未満で50,000URL未満に保つ。Googleはここに記録された制限を発表している。
このポストの最初の物件リストサイトでは、サイトマップに41,000個のURLが含まれていました。すべてのタグアーカイブ、すべてのページネーションページ、そして申し訳ないのですが、WordPressのログインページまで含めて。最初にクリーンアップしてください。常に。
---
内部リンクはインデックスの問題である
人々は内部リンクをインデックスツールとして考えない。そうあるべきなのに。
ページに指すインターナルリンクがない場合、サイトマップに含まれていても、Googlebotはそのページを見つけられない可能性があります。サイトマップはGoogleに「このURLが存在する」と伝えます。インターナルリンクはGoogleに「このURLが重要である」と伝えます。これらは異なるシグナルです。
大規模なコンテンツサイトでは、孤立したページが蔓延しています。3年前に公開されたブログ記事が、投稿アーカイブからはリンクされているものの、他のどの投稿からもリンクされていない場合、時間が経つにつれてそのクロール頻度はほぼゼロに低下します。
Screaming Frogの「Orphan Pages」レポート（Site Structureセクション配下）を使用して、サイトマップに含まれているがインターナルリンクがゼロのページを特定しています。その後、コンテンツを遡ってリンクを追加する論理的な箇所を見つけます。強制的なリンクではなく、実際に関連性のあるものです。時間はかかりますが、インデックス化への影響は確実にあります。
---
体系的な診断チェックリスト
これを Seahawk のジュニアデベロッパーに渡す場合、以下の順序で進めるよう指示します。
- Google Search Console の「ページ」レポートを取得し、理由コード付きのインデックス登録されていない URL をすべてダウンロードします。
- robots.txt で誤った広範な disallow がないか確認します。
- WordPress の「検索エンジンに対してサイトをインデックスしないよう要求する」チェックボックスがオフになっているか確認します。
- Screaming Frog を実行し、ページレベルの noindex ディレクティブでフィルタリングします。
- プラグイン設定ではなく、canonicalタグの確認と実際の出力を確認してください。
- サーバーログを取得し、Googlebotのクロール分布をURLタイプ全体で確認する。
- XMLサイトマップを監査し、不要なURL（ページネーション、空のアーカイブ、非カノニカルバリアント）を特定する。
- オーファンページレポートを実行し、内部リンクがないページを特定する。
- ファセットナビゲーションやパラメータベースのURLが重複してクロール可能なパスを生成していないか確認する。
- ページ速度を確認してください。一貫してタイムアウトするページはGooglebotによって優先度を下げられます。
すべてを一度に修正しようとしないこと。問題のカテゴリを1つ修正し、Googleが再クロールするまで3〜4週間待ち、測定してから次に進む。すべてを同時に変更すると、実際に機能したものが何かわからなくなる。
---
FAQ
ページが1週間インデックスされた後、翌週にドロップされるのはなぜか？
Googleのインデックスは静的ではありません。品質シグナル、新鮮さ、クロール効率に基づいて常にページを再評価します。6ヶ月前にインデックスされたページでも、リンクを獲得していない、インターナルリンクされていない、またはGoogleがあなたのドメインに対する品質評価を変更した場合は削除される可能性があります。これはサイトマイグレーション後や大規模なコンテンツ全体の見直し後に特に一般的で、Googleは再クロール、再評価を行い、以前インデックスされていたページが基準を満たしていないと判断することもあります。
サイト速度はインデックスに影響しますか?
多くの人が認識しているより直接的です。ページの応答が遅い場合、初期サーバーレスポンスが一貫して2～3秒を超える場合、Googlebotはそのページのクロール優先度を下げます。規模が大きくなると、低速ページは単純にインデックスを維持するのに十分な頻度でクロールされません。他の速度関連の対策を気にする前に、Time to First Byte（TTFB）を修正してください。WP Rocketのような安価なキャッシングプラグインで測定可能な改善が実現します。Core Web Vitalsはランキングに重要ですが、TTFBはクロール自体に重要です。
サイトマップに含まれるページが多すぎるとインデックスに悪影響を及ぼしますか?
直接的ではありませんが、低品質のURLが含まれた肥大したサイトマップはGoogleに送信している「何が重要か」についてのシグナルを薄めます。サイトマップに40,000個のURLが含まれており、そのうち30,000個が質の低いアーカイブページである場合、Googleはサイトマップをノイズとして扱うことを学びます。サイトマップはシンプルで高品質に保ってください。URL在庫ではなく、編集的なキュレーション作業と考えてください。
Google の URL 検査ツールを使用して手動でインデックスをリクエストすべきですか?
個別の重要なページについてはもちろんそうですが、何千ものURLに対して手動でインデックス登録をリクエストしようとしないでください。スケールしませんし、Googleは長期的には手動でリクエストされたURLに特別扱いを与えないと述べています。根本的なクロールと品質の問題を修正し、Googleの自然なクロールに任せてください。手動検査は特定のページがインデックス可能であることを確認するために使用し、すべてをインデックス化させるために強制するためではありません。
---
正直なところ、インデックス化の診断は地味な仕事です。スプレッドシート、ログファイル、そして多くの待機時間を伴います。しかし、大規模なサイトであれば、失われたインデックス化ページの20%を回復させるだけでも、オーガニックトラフィックの意味のある上昇につながり、40,000ページの物件リスティングサイトであれば、それは実際の収益になります。何か特殊なことを追い求める前に基本を正しく理解してください。ほぼ常に、特殊なことは関係ありません。