2022年のことだ。イギリスの大型ECサイト運営者からクライアントが電話をくれた。約14,000の商品ページを抱える彼らが6週間で有機トラフィックの34%を失い、激怒していた。手動ペナルティはなし。アルゴリズム更新の発表もなし。ただ静かに、ゆっくりと崩壊していたのだ。Screaming Frogで完全クロールを走らせたところ、90分以内に問題が見つかった。ページネーションが自動生成する数千の重複に近いURLにGoogleがクロールを集中させ、実際の商品ページがクロールされず、彼らのクロール予算は完全に枯渇していた。毎月、無駄になっていた。
重要なポイント：10,000ページのサイト監査は、小規模サイト監査を単に大きくしたものではありません。クロールバジェット、テンプレート、大規模インデックスといった失敗モードが生じ、チェックリストもそれに応じて変わります。
それが大規模サイトSEOの本質だ。問題そのものは難しくない。ただし規模が大きくなると、その結果は破壊的になる。20ページのサイトでカノニカルタグの設定ミスは厄介だ。14,000ページのサイトでは、静かにインデックス全体を絞め殺す。
Seahawk Mediaで私が使っているのがこの監査チェックリストだ。サイトが10,000ページの大台を超えたときに毎回実行している。重要度順ではない。大規模サイトはそれぞれ独自の「災厄の階層」を持っているから。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
キーワードではなくクロール予算から始めよ
大規模サイトの監査をランキングから始める人がほとんどです。それは間違った順序です。完全に間違っています。ランキングはインデックス登録の下流にあり、インデックス登録はクロール予算の下流にあります。操作の順序を修正してください。
クロール予算とは、簡潔に言えば：一定期間内にGooglebotがあなたのサイトでクロールするURL数のことだ。Googleの公式ドキュメントはこのテーマで読む価値がある。何がクロール予算を浪費するのかについて、かなり具体的に書かれている。
あなたの予算を何が消費していますか？
まずサーバーログを引き出すこと。GSCのデータではなく、実際のサーバーログだ。大容量ログの分析にはGoAccessを使っている。余計な処理を挟まずボリュームに対応できるからだ。何を見るべきか：
- ファセットナビゲーションURL（例：/shoes?colour=red&size=10&sort=price）
- URLに追加されたセッションID
- 無限スクロールまたは「さらに読み込む」実装が一意のパラメータ文字列を生成している
- ペジネーション済みURLの重複（/page/1と/の両方がクロール対象になっている）
- ブロックされていない内部検索結果ページ
10,000ページ以上のサイトでアクティブなファセット検索を実装していれば、ほぼ確実にクロール予算が流出している。ほぼ確実にだ。解決策は派手ではない。robots.txtでそのパラメーターパターンをdisallowするか、理想的にはGSCで適切なURL パラメーター処理を設定し、ファセットページ自体にカノニカルタグを付ける。
2021年初頭、Seahawkは23,000個の商品URLを持つ家具小売業者のクライアントがいた。表面上は問題なく見えた。だがログ分析をすると、Googlebotが検索需要ゼロ、ユニークコンテンツもゼロのファセットフィルタ組み合わせに、クロール訪問の61%を費やしていたのだ。実際の商品ページは約14日ごとにクロールされていた。ファセットパラメータをnoindex, followに変更し、robots.txtで大量の組み合わせパターンをdisallowした。6週間以内に、実商品ページの平均クロール頻度は3～4日ごとに改善された。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
インデックス監査：Googleのインデックスに実際に含まれているものは？
Google内でsite:yourdomain.comと検索すると、大まかな数値が得られます。精度については信頼しないでください。ただし、簡単な妥当性確認になります。GSCのインデックスカバレッジレポートと相互参照してください。
「インデックスに登録したいページ」と「Googleがインデックスに登録したページ」のギャップが、成果を生む部分です。大規模サイトでは、このギャップは往々にして巨大で、完全に防止可能です。
あなたが気にすべき4つの状態
- インデックス済み、問題なし。そのままにしておいて問題ない。
- 除外：noindexタグが付いている。意図したものか。確認せよ。
- 除外：クロール済み、現在インデックスされていない。これが最も警戒すべき状況だ
- 除外：発見済み、クロール未実施。クロールバジェットの問題。最初のセクションに戻って確認せよ
「クロール済み、現在インデックスされていない」は、Google の言い方では：ここに来た、見回った、手間をかける価値がないと判断した、ということです。これは通常、薄いコンテンツ、重複に近いコンテンツ、または Google が積極的にスキップすることを選択するほど弱い品質シグナルを意味します。商品ページでは、これは「この商品は複数の色で利用でき、3～5営業日以内に発送されます」という 3 文のボイラープレートの自動生成説明で起こることが多いです。Google はそのようなバージョンを千個も見ています。もう 1 つ必要ではありません。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
大規模サイトでの正規化タグ
カノニカルタグは大規模サイトでの顕著な自爆的ダメージを私が最も目にしている領域だ。複雑だからではなく、むしろシンプルだからこそ危険なのだ。10,000ページ以上のサイトでは、単一のテンプレートエラーが数千のURLに瞬時に波及する
常に見かける2つの障害：
実際には正しい場所を指していない自己参照の正規タグ。典型例：ページ/2が自分自身、またはページ/1もしくはルートカテゴリーではなく自分自身を指している正規タグを持つペジネーション済みカテゴリーページ。それを8ページのペジネーションを持つ400個のカテゴリーページで乗算すると、2,800ページ以上の壊れた正規タグシグナルが生成されます。
カノニカルチェーン。ページAがページBをカノニカライズし、ページBがページCをカノニカライズする場合だ。Googleはカノニカルチェーンをたどるが、決して熱心ではない。3ホップですら限界に近い。何年にもわたるマイグレーションと再設計で築き上げられた5ホップチェーンを持つサイトを見たことがある。Screaming FrogのCanonicalタブでこれを直接確認でき、エクスポートしてチェーンでフィルタリングできる
テンプレートタイプごとに完全な正規化監査を実行しよう。プロダクトページ。カテゴリページ。ブログ投稿。タグアーカイブ。著者ページ。各テンプレートには独自の障害パターンがあり、ランダムサンプルからすべてを見つけられない。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
XMLサイトマップ：人々が考えるより重要
10,000ページ以上になると、単一のサイトマップファイルが問題になり始める。Googleの制限はサイトマップファイルあたり50,000URLまたは50MBだが、この制限に達することが本質的な問題ではない。重要なのは、40,000URLの一枚岩型サイトマップは監視が難しく、何か問題が起きた時のデバッグも困難だということだ
分割してください。セグメント化されたサイトマップを指すサイトマップインデックスファイルを使用します：
- 製品サイトマップ
- カテゴリサイトマップ
- ブログ・エディトリアルサイトマップ
- ブランドまたはメーカーページサイトマップ（該当する場合）
セグメント化がなぜ重要か。何か障害が発生したとき、そしてそれは確実に起きるのだが、問題を特定できるからだ。Googleが新しい商品ページを急に拾わなくなったなら、GSCで商品サイトマップのクロール日時を確認して、そこからデバッグを進める。一枚岩型サイトマップでは調査の手がかりがない
また：サイトマップに含めるのは、実際にインデックスされてほしいURLだけです。当たり前のように聞こえます。驚くほど多いです。サイトマップがプラグインで自動生成され、タグページ、著者アーカイブ、添付ファイルページ、その他半ダースのURL種別を含んでいるサイトを監査しました。これらにはnoindexが設定されていました。無駄なノイズです。
構造化データも扱っている場合、GoogleのRich Results Testでサイトマップを検証し、ブラウザでサイトマップの直接配信を確認して、サーバーが200を返しているか、301チェーンになっていないか、あるいは神よ、404になっていないかを確認せよ
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
大規模サイトでの内部リンク戦略：過小評価されている重要要素
PageRankは今でも有効です。内部リンクを通じて流動します。大規模サイトでは、内部リンク構造が事実上、どのページが権威性を持つのか、どのページが隅で静かに死んでいくのかを決定します。
Seahawkは2023年、ニュースとライフスタイル領域にわたる約18,000の記事を持つ出版クライアントを抱えていた。トップファネルのカテゴリーページはまともなトラフィックを得ていた。しかし2015年から2019年のもので今なお実際の検索需要を持つ、より深いアーカイブコンテンツはほぼ見えない状態だった。コンテンツが悪いからではなく、もうそこへリンクするものが何もなかったからだ。彼らはカテゴリーナビゲーションを3度再設計し、その度に古いコンテンツはさらに一段階深くに埋もれていった
解決策は地味でした。カスタムWordPressプラグインを使った自動内部リンク戦略を構築し、キーワード関連性が高い記事を特定し、コンテキストに合ったリンクを挿入しました。アーカイブコンテンツのホームページからのクリック深度は平均7.2クリックから3.1クリックに低下しました。その後のクォーターで、それらのページのオーガニックインプレッションは28%増加しました。
大規模サイト向けの内部リンクチェックリストです。
- インデックスに登録されるべきページは、ホームページから3クリック以内であるべき
- オーファンページ（内部リンクがゼロ）は、バックログアイテムではなく緊急事態として扱うべき
- パンくずナビゲーションは内部リンクとしてカウントされる。正しく実装されており、単なる「カテゴリー > サブカテゴリー」のような汎用ラベルではなく、実際のアンカーテキストを使用していることを確認せよ
- 内部リンクが1つだけ指しているページをチェックせよ。それは孤立したページとほぼ変わらない
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
大規模な構造化データとスキーマ
10,000件以上の商品ページがあるのに、Product スキーマに Offer、Review、AggregateRating プロパティがない場合、検索結果ページの貴重な表示枠を逃しています。
ただし、大規模な構造化データはそれ自体、監査要件を生み出します。テンプレート内のスキーマエラーは、数千個の無効なマークアップインスタンスを意味します。私は2つのツールを組み合わせて構造化データをチェックします。個別URL サンプリング用の Google Rich Results Test と、Screaming Frog でのクロール レベルのスキーマ抽出（Configuration → Custom Extraction → JSON-LD ブロック用の XPath）で、すべてのページタイプ全体の一括ビューを取得します。
チェックすべき項目：
- 必須プロパティの欠落（特に Product ページの price と priceCurrency。これらはよくある漏れです）
- スキーマの不一致（スキーマでは1つの商品名、<title>では別の名前）
- 非推奨のスキーマタイプ、DataFeedElement と古い itemscope マイクロデータパターンの監査は実施する価値があります
- Google のレビュースニペットガイドラインに違反するスキーマを確認してください。ファーストパーティレビューがサードパーティとしてマークアップされている場合、または極めて小さいサンプルサイズから集約されたスコア
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
ページ速度の大規模化：修正できないものを監査しない
Core Web Vitalsは重要です。ただし、十分に語られていないことがあります。10,000ページ全体でCWVを監査して、個別のURLごとに修正しようとするのは無駄な努力です。テンプレートで監査して、テンプレートで修正するのです。
PageSpeed Insights または WebPageTest を通じて、テンプレートタイプごとに 20～30 URLs のサンプルを実行してください。プロダクトページの平均 LCP が 4.8 秒の場合、これはテンプレートレベルの問題です。修正は個別ページではなく、画像配信パイプライン、クリティカル CSS、またはサーバーレスポンスタイムにあります。
特に大規模なWordPressサイト（Seahawk Mediaが扱うほとんどのサイト）では、スケールでよくある犯人は以下の通りです。
- WebP変換なしで配信される最適化されていないWooCommerceプロダクト画像
- スコープが適切でないプラグインのenqueueから生じる、不要なスクリプトが含まれているページへの過剰なHTTPリクエスト
- サイト成長に対応できていないホスティング層。2,000 プロダクトで十分だったプランが 12,000 では往々にして機能不全に陥ります
ホスティングを最初に正しく設定してください。他は全て装飾に過ぎません。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
リダイレクト監査：マイグレーション負債の問題
大規模サイトは、古い家が不適切な配線を蓄積するのと同じように、リダイレクトチェーンを蓄積していきます。デザイン再構築、ドメインマイグレーション、URL構造変更のたびに別のレイヤーが追加されます。4〜5年経つと、4〜5ホップ深いリダイレクトチェーンが見つかることは珍しくありません。
各ホップには時間がかかります。各ホップはPageRankシグナルを希釈します。そして、一時的であるはずの非常に古い302がまだ存在して、非常に恒久的な損害を与えています。
私のプロセス：
- Screaming Frogでクロールし、すべての3xxレスポンスをエクスポートする
- チェーン（A → B → C、またはそれ以上）をフィルタリングする
- すべてのソースリンクを最終宛先に直接ポイントするように更新する
- 最終宛先が200であることを確認し、別のリダイレクトではないことを確認する
- 301であるべき302をフラグし、サーバーレベルで変更してもらう
また確認してください：XMLサイトマップのURLがリダイレクトを返していないか？これはよくあるケースです。サイトマップには200を返すURLのみが含まれるべきです。サイトマップが301で満ちていれば、あなたはGoogleの仕事をしているのであり、そして悪く実行しています。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
FAQ
10,000ページ以上のサイトに対する技術的なSEO監査にはどのくらいの時間がかかりますか？
正直なところ、サイトの計測がどれだけしっかりしているかによる。GSC が正しくセットアップされ、サーバーログがアクセス可能で、Screaming Frog がレート制限なしでクロールできるなら、徹底的な監査のデータ収集および分析フェーズだけで 3～5 営業日かかる。レポーティングはさらに 1～2 日必要だ。午前中のうちに大規模サイト監査ができると言う人間は、サンプリングをやっているに過ぎず、監査をしていない。
全ページを監査する必要がありますか？それともサンプルから作業できますか？
個別ページではなくテンプレートから作業してください。12,000 のプロダクトページを持つサイトには、おそらく 4～6 の意味のあるページテンプレートしかありません。各テンプレートタイプを代表的なサンプル（最低 20～30 URLs）で徹底的に監査すれば、その結果がテンプレート全体に適用されます。例外は孤立ページの特定とリダイレクトチェーン検出です。これらはサンプリングではなく、フルクロール範囲が必要です。
大規模サイトの大部分に対する最も影響の大きい修正は何ですか？
クローリング予算。ほぼ例外なく。具体的には、検索需要がなく独自コンテンツがないファセットナビゲーション URL をブロックまたは正規化することです。大規模カタログを持つ e-commerce サイトでは、この単一の修正が他のどの変更よりも成果を上げるのを見てきました。unglamorous な作業です。robots.txt の編集、canonical タグ、パラメータ設定ですが、コンテンツやリンクビルディングの取り組みより速い結果をもたらすことがよくあります。
大規模サイトではScreaming FrogとSitebulbのどちらを使うべきですか？
どちらも優れています。私は年単位で Screaming Frog を使用していることから、そのエクスポート形式を完全に理解していて、カスタム抽出オプションが優秀なため、クロール作業の大部分で Screaming Frog を使用しています。Sitebulb はより優れた視覚化レイヤーを備えており、監査レポートがクライアント向けに読みやすくなっています。50,000ページ以上のサイトの場合、ローカルマシンの RAM に依存しないクラウドベースのクローリングを提供する DeepCrawl（現在の Lumar）も検討してください。
大規模サイト監査で最も見逃されやすい問題は何ですか？
内部リンクの深さです。誰もが壊れたリンクと正規タグをチェックします。ホームページから6段階または7段階深いページを体系的に特定し、競争力のあるものでランク付けされると予想される理由を問う人はほとんどいません。クリック深は、クロール優先度と権限配分の代理指標です。毎回監査してください。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
大規模サイト SEO は異なる分野ではなく、結果が急速に複雑化する規模で同じ原則です。上記のチェックリストは変わりません。すべてのサイトには固有の混乱があります。ただし、クローリング予算、インデックス登録、canonical、サイトマップ、内部リンク、構造化データ、ページスピード、リダイレクトをその順序で進めていけば、単一のキーワードを見る前に、壊れているもののほぼ 80% を見つけることができます。
インフラストラクチャから始めてください。ランキングはその後についてきます。