あるクライアントから先春の火曜日の朝に電話がかかってきました。彼の声には本当にパニックが入っていました。プロパティリスティングサイトを運営していて、ページ数は約42,000でしたが、Google Search Consoleでその中の5,800ページしかインデックスされていないと表示されていたのです。インデックス可能なページの約86%を失っていました。一夜にしてです。アルゴリズムアップデートもありません。手動による措置もありません。最近のデプロイメントも思い当たりません。ただ…消えてしまったのです。
Seahawkの12,000以上のWordPress構築全体で、この正確なシナリオを何度も見てきました。そして本当にやっかいなのは、大規模サイトのインデックス喪失には通常、一つの原因ではなく、通常は3つか4つの小さな失敗が静かに複合されて、最終的に何かが崩壊するということです。
ここが私が実際に診断する方法です。
---
Google Search Consoleから始める——ただしそこで止まらないこと
まず最初にやることは、Google Search ConsoleのPagesレポートを開くことです。古いCoverageレポートではなく、Googleは2023年にこれを更新しており、新しいPages表示ではインデックス済み対非インデックス化を適切な理由コード付きで分類しています。初日のスクリーンショットを撮ってください。ベースラインが必要です。Pages report in Google Search Console. Not the old Coverage report — Google updated this in 2023, and the new Pages view breaks down indexed vs. non-indexed with proper reason codes. Take a screenshot on day one. You need a baseline.
理由コードは非常に重要です。「クロール済み — 現在インデックスされていません」は「'noindex'タグによって除外」とはまったく異なる問題です。一方は品質シグナルの問題、もう一方は設定の災害です。開発者が両者を同じに扱い、間違ったものを追いかけるのに何週間も無駄にするのを見たことがあります。
大規模サイトで最も頻繁に見られる理由
- クロール済み — 現在インデックスされていません：Googleはページにアクセスしましたが、インデックスする価値がないと判断しました。通常、薄いコンテンツ、重複に近いページ、またはバックリンクや内部リンクを獲得していないページです。: Google visited the page but decided it wasn't worth indexing. Usually thin content, near-duplicates, or pages that don't earn backlinks or internal links.
- 検出済み — 現在インデックスされていません：GoogleはURL（おそらくサイトマップから）を検出しましたが、まだクロールしていません。これはコンテンツの問題ではなく、クロールバジェットの問題です。: Google found the URL (likely in your sitemap) but hasn't bothered to crawl it yet. This is a crawl budget problem, not a content problem.
- 'noindex'タグによって除外：誰か（あなたかもしれませんし、プラグインかもしれません）がnoindexディレクティブを追加しました。詳細は以下をご覧ください。: Someone — possibly you, possibly a plugin — added a noindex directive. More on this below.
- 重複、Googleが別の正規URLを選択：正規タグが予期しない場所を指しているか、Googleが正規タグをオーバーライドしています。: Your canonical tags are pointing somewhere unexpected, or Google is overriding them.
- リダイレクト付きページ：インデックス可能であるべきページが、正しくまたは正しくないかはともかくどこかにリダイレクトしています。: A page that should be indexable is redirecting somewhere, either correctly or incorrectly.
合計を見るだけではいけません。各理由コードの完全リストをCSVとしてダウンロードしてください。40,000ページのサイトでは、ソートとフィルター処理ができる必要があります。
---
クローリング予算は実在し、大規模サイトを破壊する
2019年当時、Seahawkは大規模なeコマースクライアント（約28,000個の商品ページ）に取り組んでいましたが、Googleが1日あたり3,000ページ程度しかクロールしていない理由が判明しませんでした。サイトは高速でした。サイトマップはクリーンでした。表面上はすべてが問題なく見えていました。
実は、そのサイトは何千ものファセット化されたナビゲーションURL（?colour=red&size=large&sort=price）を生成しており、これらはクロール可能でありながら適切にcanonicalizeされておらず、実際の商品ページに到達する前にGooglebotのクローリング予算を食い尽くしていたのです。?colour=red&size=large&sort=price — that were crawlable, not canonicalised properly, and eating through Googlebot's crawl allowance before it ever reached the real product pages.
クローリング予算とは本質的に、Googlebotが一定期間内にあなたのサイトをクロールしたいURLの数です。GoogleのクローリングAPIに関する公式ドキュメントは本当に読む価値があります。彼らは仕組みについて率直に説明しています。要約すると、ゴミURLに予算を浪費すれば、重要なページはクロールされません。Google's own documentation on crawl budget is genuinely worth reading — they're honest about how it works. The short version: if you're wasting it on garbage URLs, the important pages don't get crawled.
クローリング予算を実際に監査する方法
- サーバーログを取得してください。Googleのクロールスタッツではなくサーバーログです。Screaming Frog Log File Analyserのようなツールを使えば、Googlebot hits純粋にフィルタできます。Screaming Frog Log File Analyser let you filter purely for Googlebot hits.
- Googlebotの訪問のうち実際に関心のあるURLに着地しているパーセンテージを確認してください。60%以下であれば、予算に問題があります。
- 最もクロール数を消費しているURLパターンを見つけてください。頻度でソートしてください。トップの問題は例外なく次の4つです：ファセット化されたナビゲーション、ページング化されたアーカイブのページネーション、セッションIDパラメータ、および空のカテゴリ・タグアーカイブページ。
- 症状ではなく根本を修正してください。クロールすべきではないパラメータに対してはrobots.txtで Disallow を設定してください。その他すべてはcanonical タグを使用してください。
robots.txtfor parameters that should never be crawled. Canonical tags for everything else.
そのeコマースプロジェクトでは、robots.txtでファセット化されたURLをブロックし、すべてのフィルタビューにrel="canonical"を追加しました。6週間以内に、インデックス済みページは8,000から24,000に増加しました。コンテンツは同じです。Googlebotが単にそこに到達できるようになっただけです。robots.txt and added rel="canonical" to all filtered views. Within six weeks, indexed pages went from 8,000 to 24,000. Same content. Just Googlebot finally reaching it.
noindexの災い（思ったより頻繁に起こっている）
noindexの災い（思ったより頻繁に起こっている）
自分でやったことがあるから、これについて話す必要があります。最高の瞬間ではありませんでした。2021年に、ニュースサイトのステージング環境から本番環境への移行中に、WordPress設定の「読み込み」セクションで「検索エンジンがこのサイトをインデックスするのを控えるようにリクエスト」のチェックボックスを外し忘れました。サイトは全サイト規模のnoindexを付けたまま本番環境に移行しました。クライアントがオーガニックトラフィックが激減したことに気づくまでに11日かかりました。
WordPressはそのチェックボックスを誰も予想しない場所に埋め込んでいます。そして、Yoast、Rank Math、AIOSEOなどの特定のSEOプラグインは、ポストタイプレベル、タクソノミーレベル、個別ページレベルで独自のnoindexトグルを持っています。それらのどれもが、あなたのサイトの大きな部分を静かにnoindexにしてしまう可能性があります。
規模を大きくしてnoindexをチェックする方法
Screaming Frogをフルサイトで実行し、noindexディレクティブを返しているページをフィルタリングします。リストをエクスポートしてください。そして、重要なURLグループ（製品ページ、サービスページ、ブログ投稿など、ビジネスにとって重要なもの）と相互参照します。noindex directive. Export the list. Then cross-reference against your important URL groups — product pages, service pages, blog posts, whatever matters to the business.
yourdomain.com/robots.txtでyour robots.txtもチェックしてください。範囲が広すぎるDisallow:ルールを探してください。CSSとJSをブロックするDisallow: /wp-content/のようなルールを見かけたことがあります。これはGoogleがページを適切にレンダリングするために必要なものです。これはレンダリング障害を引き起こす可能性があり、インデックスの問題に見えるかもしれませんが、実際にはGooglebotが壊れたページを見ているだけです。robots.txt at yourdomain.com/robots.txt. Look for overly broad Disallow: rules. I've seen rules like Disallow: /wp-content/ blocking CSS and JS that Google needs to render pages properly — which can cause rendering failures that look like indexation problems but are actually Googlebot seeing a broken page.
カノニカルは大規模なWordPressサイトで最も狡猾なインデックス殺しです。単独で見ると正しく見えるため、規模を大きくするとだけその被害が明らかになるからです。
静かに不具合を起こしているカノニカルタグ
カノニカルは大規模なWordPressサイトで最も狡猾なインデックス殺しです。単独で見ると正しく見えるため、規模を大きくするとだけその被害が明らかになるからです。
よくあるパターンです。WooCommerceを使っているサイトの場合、商品に複数のURLパスでアクセスできることがあります。/product/red-shoes/、/product-category/footwear/red-shoes/、時には/shop/red-shoes/といった具合です。各ページにはcanonicalタグが設定されていますが、それらのcanonicalが異なるURLを指している場合（HTTPとHTTPS、末尾のスラッシュの有無、wwwの有無など）、Googleはそれを異なるページを指すシグナルと判断し、統合を拒否します。/product/red-shoes/, /product-category/footwear/red-shoes/, and sometimes /shop/red-shoes/. Each one has a canonical tag, but if those canonicals point to slightly different URLs (HTTP vs HTTPS, trailing slash vs no trailing slash, www vs non-www), Google treats them as signals pointing to different pages and refuses to consolidate.
修正方法は地味ですが必要です。
- WordPressがどのようなURL構造を生成しているかすべて監査してください。Screaming Frogでサイトをクロール→「Canonical」でフィルタ→エクスポートします。
- プロトコルの不一致、末尾のスラッシュ、サブドメインの違いをチェックしてください。
- canonicalが優先URLと完全に一致していることを確認してください。1文字も異なってはいけません。
Rank MathもYoastもcanonicalタグを自動生成しますが、どちらのプラグインも.htaccessのリダイレクトやCDNのURL正規化については把握していません。プラグインが出力していると思っているものではなく、実際に表示されるcanonicalを検証する必要があります。httpstatus.ioのようなツールでページを取得し、実際のレスポンスヘッダーとHTMLを確認してください。.htaccess redirects or your CDN's URL normalisation. You have to verify the rendered canonical, not just what the plugin thinks it's outputting. Fetch the page with a tool like httpstatus.io and inspect the actual response headers and HTML.
---
大規模サイトではXMLサイトマップが間違っていることが多い
ほとんどのWordPress SEOプラグインはサイトマップを自動生成します。しかし、サイトマップに含めたくないURLも含まれることがよくあります。ページング（/page/2/、/page/3/）、著者アーカイブ、2件のみのタグページ、添付ファイルページなどです。/page/2/, /page/3/), author archives, tag pages with two posts on them, attachment pages.
サイトマップは、最高の標準的なページの短いリストであるべきです。WordPressが生成したあらゆるURLを並べたものではなく。
実際に実行しているサイトマップ衛生管理ルール
- ページネーション付きアーカイブページは除外する。常に。
- マルチオーサーサイトでオーサーページが本物のコンテンツ価値を持つ場合を除き、オーサーアーカイブページは除外する。
- タグが編集上で管理され、意味のあるコンテンツを持つ場合を除き、タグアーカイブは除外する。
- ポスト数のしきい値を設定する — 通常、5件未満のアーカイブページはすべて除外する。
- 大規模なサイトマップをサイトマップインデックスに分割する。個々のサイトマップファイルは10MB未満で50,000URL未満に保つ。Googleはここに記録された制限を発表している。documented limits here.
この投稿の最初から登場した不動産物件一覧サイトでは、サイトマップに41,000のURLが含まれていた。そこには、すべてのタグアーカイブ、すべてのページネーションページ、そして — これでも言うのが辛いが — WordPressのログインページが入っていた。まず整理する。常に。
---
内部リンクはインデックスの問題である
人々は内部リンクをインデックスツールとして考えない。そうあるべきなのに。
ページへの内部リンクがない場合、サイトマップに含まれていても Googlebot がそもそも見つけられない可能性があります。サイトマップは Google に URL の存在を伝えます。内部リンクは Google に URL の重要性を伝えます。これらは異なるシグナルです。matters. Those are different signals.
大規模なコンテンツサイトでは、孤立したページが蔓延しています。3年前に公開されたブログ記事が、投稿アーカイブからはリンクされているものの、他のどの投稿からもリンクされていない場合、時間が経つにつれてそのクロール頻度はほぼゼロに低下します。
私は Screaming Frog の「Orphan Pages」レポート（Site Structure の下）を使用して、内部リンクがゼロのサイトマップ内のページを特定します。その後、リンクを追加する論理的な場所を見つけるためにコンテンツを遡ります。強制されたリンクではなく、実際に関連性のあるものです。時間はかかりますが、インデックス登録への影響は大きいです。
---
体系的な診断チェックリスト
これを Seahawk のジュニアデベロッパーに渡す場合、以下の順序で進めるよう指示します。
- Google Search Console の「ページ」レポートを取得し、理由コード付きのインデックス登録されていない URL をすべてダウンロードします。
- robots.txt で誤った広範な disallow がないか確認します。
robots.txtfor accidental broad disallows. - WordPress の「検索エンジンに対してサイトをインデックスしないよう要求する」チェックボックスがオフになっているか確認します。
- Screaming Frog を実行し、ページレベルの noindex ディレクティブでフィルタリングします。
- カノニカルタグを確認する — プラグイン設定ではなく、レンダリングされた出力を確認する。
- サーバーログを取得し、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 の自然なクロールに任せてください。手動検査は、特定のページがインデックスされ得ることを確認するために使用してください。すべてをインデックスに強制することではありません。can be indexed, not to force index everything.
---
正直なところ、インデックス診断は華やかな仕事ではありません。スプレッドシート、ログファイル、そして大量の待機時間です。しかし大規模なサイトでは、失われたインデックスページの20%を回復するだけでも、オーガニックトラフィックの有意義な増加につながります。そして40,000ページのプロパティ リスティングサイトであれば、それは実際の収益です。何か風変わりなものを追い求める前に、基本をしっかり固めてください。風変わりなものはほぼありません。