去年の春、火曜日の朝、あるクライアントから電話がありました。声からは本当のパニックが伝わってきました。彼が運営していたのは不動産物件情報サイトで、約42,000ページありました。Google Search Consoleに表示されたのは、そのうちわずか5,800ページだけがインデックスされているということでした。インデックス可能なページの約86%が一夜にして消えてしまったのです。アルゴリズムアップデートもなく、手動による対応もなく、記憶にある最近のデプロイもありません。ただ…消えたのです。
重要なポイント：40,000ページのWordPressサイトで6,000ページしかインデックスされていない場合、その原因はほぼ確実にアーキテクチャにあります。つまり、ファセット化されたURL、シンテンプレート、クロール浪費が原因であり、Googleペナルティではありません。When a 40,000-page WordPress site has 6,000 pages indexed, the cause is almost always architecture: faceted URLs, thin templates, and crawl waste, not a Google penalty.
Seahawkの12,000以上のWordPress構築全体で、この正確なシナリオを何度も見てきました。そして本当にやっかいなのは、大規模サイトのインデックス喪失には通常、一つの原因ではなく、通常は3つか4つの小さな失敗が静かに複合されて、最終的に何かが崩壊するということです。WordPress builds. And the maddening thing is that indexation loss on large sites rarely has one cause. It's usually three or four small failures that compound quietly until something collapses.
ここが私が実際に診断する方法です。
---
Google Search Consoleから始める――ただし、そこで止まらないこと
私がいつも最初にすることは、Google Search ConsoleのPages レポートを開くことです。古いCoverageレポートではなく、Googleが2023年に更新した新しいPages表示を使います。これはインデックス済みと非インデックスを適切な理由コード付きで分類してくれます。1日目にスクリーンショットを撮ってください。ベースラインが必要です。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 Mediaは大規模なEコマースクライアント――約28,000の商品ページ――と仕事をしていました。Googleが1日あたり約3,000ページしかクロールしていない理由が分かりませんでした。サイトは高速でした。サイトマップはクリーンでした。表面上はすべて正常に見えました。
サイトが数千のファセット検索用URLを生成していたことが判明した——?colour=red&size=large&sort=priceといったURLがクローラブルなのに正規化されておらず、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の公式ドキュメントはクロールバジェットについて本当に一読の価値がある——彼らはその仕組みについて正直に説明している。要するに、ゴミみたいな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のログファイル分析ツールのようなツールを使えば、純粋にGooglebotのヒットだけをフィルタリングできる。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の災い（思ったより頻繁に起こっている）
自分でやったことがあるから、これについて話す必要があります。最高の瞬間ではありませんでした。2021年に、ニュースサイトのステージング環境から本番環境への移行中に、WordPress設定の「読み込み」セクションで「検索エンジンがこのサイトをインデックスするのを控えるようにリクエスト」のチェックボックスを外し忘れました。サイトは全サイト規模のnoindexを付けたまま本番環境に移行しました。クライアントがオーガニックトラフィックが激減したことに気づくまでに11日かかりました。
WordPressはそのチェックボックスを誰も期待しないような場所に隠している。そしてYoast、Rank Math、AIOSEOといった某些SEOプラグインは、投稿タイプレベル、タクソノミーレベル、個別ページレベルで独自のnoindexトグルを持っている。どれか1つでもサイト全体の膨大な部分をサイレントに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のrobots.txtもチェックしよう。あまりに幅広いDisallow:ルールがないか確認する。Disallow: /wp-content/のようなルールでGoogleがページをレンダリングするために必要とするCSSやJSをブロックしているケースを見たことがある——これはインデックス問題に見えるかもしれないが、実は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サイトで最も狡猾なインデックス殺しです。単独で見ると正しく見えるため、規模を大きくするとだけその被害が明らかになるからです。
よく見かけるパターンがこれだ：WooCommerceを使ったサイトで、商品に複数のURLパスでアクセスできる場合——/product/red-shoes/、/product-category/footwear/red-shoes/、時には/shop/red-shoes/。それぞれが正規タグを持っているが、それらの正規タグが少し異なる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 ディレクティブでフィルタリングします。
- 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 はクロールに影響します。Core Web Vitals matter for rankings, but TTFB matters for crawling.
サイトマップに含まれるページが多すぎるとインデックスに悪影響を及ぼしますか?
直接的ではありません。ただし、低品質の URL を含む肥大化したサイトマップは、Google に何が重要かについて送信するシグナルを薄めます。サイトマップに 40,000 個の URL が含まれていて、そのうち 30,000 個が薄いアーカイブページの場合、Google はサイトマップをノイズとして扱うことを学びます。サイトマップは絞り込まれた高品質のものにしてください。URL 在庫ではなく、編集キュレーションとして考えてください。
Google の URL 検査ツールを使用して手動でインデックスをリクエストすべきですか?
個別の重要なページについては、もちろんです。ただし、数千個の URL のインデックス登録をリクエストしようとしないでください。スケールしませんし、Google は手動リクエストされた URL に長期的に特別な扱いをしないと述べています。基盤となるクロールと品質の問題を修正し、Google の自然なクロールに任せてください。手動検査を使用して、特定のページがインデックス登録できることを確認するもので、すべてをインデックス登録するように強制するものではありません。can be indexed, not to force index everything.
---
率直に言うと、インデックス登録の診断は地味な仕事です。スプレッドシート、ログファイル、そして長い待機です。ただし、大規模なサイトでは、失われたインデックス登録ページの 20% を回復しただけでも、オーガニックトラフィックに大きな伸びをもたらすことができます。4 万ページのプロパティ リスティング サイトでは、それは実際のお金です。何か珍しいものを追求する前に、基本をしっかり押さえてください。ほぼ必ず珍しいものではありません。