2022年、あるクライアントから電話がかかってきた。イギリスを拠点とするeコマース事業者で、商品ページが約14,000ページあり、わずか6週間でオーガニックトラフィックが34%も減少したというものだった。怒り心頭だった。手動ペナルティはない。アルゴリズム更新の発表もない。ただ静かに、緩やかに、崩壊していたのだ。Screaming Frogで完全クロールを実行したところ、90分以内に問題が判明した。彼らのページネーションが自動生成する数千のほぼ重複URLをGoogleが実際の商品ページではなくそれらをクロールしていたのだ。クロールバジェットは完全に消費されていた。毎月、無駄になっていた。
重要なポイント：10,000ページのサイト監査は、小規模サイト監査を単に大きくしたものではありません。クロールバジェット、テンプレート、大規模インデックスといった失敗モードが生じ、チェックリストもそれに応じて変わります。Auditing a 10,000-page site is not a bigger small-site audit: the failure modes are crawl budget, templates, and indexation at scale, and the checklist changes accordingly.
大規模サイトのSEOの難しさはそこなのだ。問題の理解は難しくない――ただ、その結果が、破壊的なほど大きいだけだ。20ページのサイトでcanonicaltタグが設定ミスされていたらウザいだけで済む。14,000ページのサイトなら、静かにインデックス全体を絞め殺す可能性がある。
これが、Seahawk Mediaでサイトが10,000ページの大台を超えたときに使う監査チェックリストだ。重要度の順ではない――大規模サイトはそれぞれ独自の災厄の階層を持っているから。Seahawk Media when a site crosses the 10,000-page mark. In no particular order of importance -- because every large site has its own hierarchy of disasters.
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
キーワードではなく、クロールバジェットから始めよ
大規模サイトの監査をランキングから始める人がほとんどです。それは間違った順序です。完全に間違っています。ランキングはインデックス登録の下流にあり、インデックス登録はクロール予算の下流にあります。操作の順序を修正してください。
クロールバジェット――シンプルに説明すれば、Googlebotが一定期間内にあなたのサイトでクロールするURLの数だ。Googleの公式ドキュメントはここで本当に価値がある――何がそれを無駄にするのか、かなり具体的に書いてある。Google's own documentation on crawl budget is genuinely worth reading here -- they're quite specific about what wastes it.
あなたの予算を何が消費していますか？
サーバーログを引き出せ。GSCのデータではなく、実際のサーバーログだ。大容量ログファイルの高速分析にはGoAccessを使っている。大量のデータをへこたれずに処理できるからだ。探すべきもの：GoAccess for quick analysis on large log files because it handles volume without crying. What you're looking for:
- ファセットナビゲーションURL（例：/shoes?colour=red&size=10&sort=price）
/shoes?colour=red&size=10&sort=price) - URLに追加されたセッションID
- 無限スクロールまたは「さらに読み込む」実装が一意のパラメータ文字列を生成している
- ペジネーション済みURLの重複（/page/1と/の両方がクロール対象になっている）
/page/1and/) both being crawled - ブロックされていない内部検索結果ページ
10,000ページ以上あり、アクティブなファセット型ナビゲーションを持つサイトは、ほぼ確実にクロールバジェットを流出させている。ほぼ確実だ。修正法は派手ではない――パラメータパターンに対するrobots.txtのdisallow、または理想的には、GSCを通じた適切なURLパラメータ処理とファセット付きページ自体のcanonical設定の組み合わせだ。proper URL parameter handling via GSC combined with canonical tags on the faceted pages themselves.
2021年初頭、Seahawkは23,000個の商品URLを持つ家具小売業者のクライアントがいた。表面上は問題なく見えた。だがログ分析をすると、Googlebotが検索需要ゼロ、ユニークコンテンツもゼロのファセットフィルタ組み合わせに、クロール訪問の61%を費やしていたのだ。実際の商品ページは約14日ごとにクロールされていた。ファセットパラメータをnoindex, followに変更し、robots.txtで大量の組み合わせパターンをdisallowした。6週間以内に、実商品ページの平均クロール頻度は3～4日ごとに改善された。noindex, follow and disallowed the heavy combinatorial patterns in robots.txt. Within six weeks, average crawl frequency on real product pages dropped to every 3-4 days.
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
インデックス監査：Googleのインデックスに実際に含まれているものは？
Google内でsite:yourdomain.comと検索すると、大まかな数値が得られます。精度については信頼しないでください。ただし、簡単な妥当性確認になります。GSCのインデックスカバレッジレポートと相互参照してください。 in Google gives you a rough figure. Don't rely on it for precision, but it's a quick sanity check. Cross-reference with GSC's Index Coverage report.
「インデックスに登録したいページ」と「Googleがインデックスに登録したページ」のギャップが、成果を生む部分です。大規模サイトでは、このギャップは往々にして巨大で、完全に防止可能です。
あなたが気にすべき4つの状態
- インデックス登録済み、問題なし――よし、そのままにしよう -- fine, leave it
- 除外：noindex -- 意図的ですか？ 確認してください -- intentional? Confirm it is
- 除外：クロール済み、現在インデックスされていない -- これは警戒すべき項目です -- this is the one that should alarm you
- 除外：発見済み、クロールされていない -- クロール予算の問題です。セクション 1 に戻ってください -- crawl budget problem, come back up to section one
「クロール済み、現在インデックスされていない」は、Google の言い方では：ここに来た、見回った、手間をかける価値がないと判断した、ということです。これは通常、薄いコンテンツ、重複に近いコンテンツ、または Google が積極的にスキップすることを選択するほど弱い品質シグナルを意味します。商品ページでは、これは「この商品は複数の色で利用でき、3～5営業日以内に発送されます」という 3 文のボイラープレートの自動生成説明で起こることが多いです。Google はそのようなバージョンを千個も見ています。もう 1 つ必要ではありません。I got here, I looked around, and I decided not to bother.That usually means thin content, near-duplicate content, or a quality signal so weak Google is making an active choice to skip it. On product pages, this often happens with auto-generated descriptions that are three sentences of boilerplate. Google has seen a thousand versions of "This product is available in multiple colours and ships within 3-5 working days." It doesn't want another one.
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
大規模サイトでの正規化タグ
正規化タグで最も劇的な自損を見たのは大規模サイトです。複雑だからではなく -- 複雑ではありませんから -- 10,000 ページ以上になると、単一のテンプレートエラーが数千の URL に一瞬で広がるからです。
常に見かける2つの障害：
実際には正しい場所を指していない自己参照の正規タグ。典型例：ページ/2が自分自身、またはページ/1もしくはルートカテゴリーではなく自分自身を指している正規タグを持つペジネーション済みカテゴリーページ。それを8ページのペジネーションを持つ400個のカテゴリーページで乗算すると、2,800ページ以上の壊れた正規タグシグナルが生成されます。Classic example: a paginated category page where page/2 has a canonical pointing to itself instead of page/1 or the root category. Multiply that by 400 category pages with 8 pages of pagination each and you've got 2,800+ pages with broken canonical signals.
正規化チェーン。ページ A が ページ B に正規化され、ページ B が ページ C に正規化されます。Google は正規化チェーンを辿りますが、積極的ではありません。3 ホップでもすでに限界です。数年のマイグレーションと再設計で構築された 5 ホップチェーンのあるサイトを見たことがあります。Screaming Frog の「Canonical」タブでこれを直接確認できます -- エクスポートして、チェーンをフィルタリングしてください。Page A canonicalises to Page B, which canonicalises to Page C. Google follows canonical chains, but it's not enthusiastic about them. Three hops is already pushing it. I've seen sites with five-hop chains built up over years of migrations and redesigns. Screaming Frog's "Canonical" tab will show you this directly -- export it, filter for chains.
テンプレートタイプごとに完全な正規化監査を実行しよう。プロダクトページ。カテゴリページ。ブログ投稿。タグアーカイブ。著者ページ。各テンプレートには独自の障害パターンがあり、ランダムサンプルからすべてを見つけられない。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
XMLサイトマップ：人々が考えるより重要
10,000 ページ以上の場合、単一のサイトマップファイルは問題になり始めます。Google の制限はサイトマップファイルあたり 50,000 URL または 50MB です -- ただし、その制限に達することが問題ではありません。40,000 URL の一枚岩型サイトマップは監視が難しく、何か問題が発生したときのデバッグが難しいということが問題です。
分割してください。セグメント化されたサイトマップを指すサイトマップインデックスファイルを使用します：
- 製品サイトマップ
- カテゴリサイトマップ
- ブログ・エディトリアルサイトマップ
- ブランドまたはメーカーページサイトマップ（該当する場合）
セグメンテーションが重要なのはなぜでしょうか？ 何か壊れたときに -- そして壊れます -- 問題を特定できるからです。Google が突然新しい商品ページを拾わなくなった場合、GSC で商品サイトマップのクロール日付を確認して、そこからデバッグします。一枚岩型サイトマップでは、何を調べればよいのかわかりません。
また：サイトマップに含めるのは、実際にインデックスされてほしいURLだけです。当たり前のように聞こえます。驚くほど多いです。サイトマップがプラグインで自動生成され、タグページ、著者アーカイブ、添付ファイルページ、その他半ダースのURL種別を含んでいるサイトを監査しました。これらにはnoindexが設定されていました。無駄なノイズです。only include URLs you actually want indexed in your sitemap.This sounds obvious. You'd be surprised. I've audited sites where the sitemap was auto-generated by a plugin and included tag pages, author archives, attachment pages, and half-a-dozen other URL types that had noindex on them. Pointless noise.
構造化データも扱っている場合は、Google の Rich Results Test でサイトマップを検証してください -- また、ブラウザでサイトマップの直接配信を確認して、サーバーが 200 を返しているか、301 チェーンではなく、まさか 404 ではないかを確認してください。Google's Rich Results Test if you're also dealing with structured data -- and check raw sitemap delivery in a browser to confirm your server is returning a 200, not a 301 chain or, god forbid, a 404.
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
大規模サイトでの内部リンク戦略：過小評価されている重要要素
PageRankは今でも有効です。内部リンクを通じて流動します。大規模サイトでは、内部リンク構造が事実上、どのページが権威性を持つのか、どのページが隅で静かに死んでいくのかを決定します。
Seahawk は 2023 年にニュースおよびライフスタイル業界で約 18,000 の記事を持つ出版クライアントを抱えていました。彼らのトップファネルカテゴリページはまともなトラフィックを得ていました。しかし、彼らのより深いアーカイブコンテンツ -- 2015 年から 2019 年の古い記事で、まだ真正な検索需要があったもの -- はほぼ見えませんでした。コンテンツが悪かったからではありません。もう誰もそこにリンクしていなかったからです。彼らはカテゴリナビゲーションを 3 回再設計していて、毎回、古いコンテンツはもう 1 段階深く埋もれていったのです。
解決策は地味でした。カスタムWordPressプラグインを使った自動内部リンク戦略を構築し、キーワード関連性が高い記事を特定し、コンテキストに合ったリンクを挿入しました。アーカイブコンテンツのホームページからのクリック深度は平均7.2クリックから3.1クリックに低下しました。その後のクォーターで、それらのページのオーガニックインプレッションは28%増加しました。WordPress plugin that identified articles with relevant keyword overlap and inserted contextual links. Click depth on their archival content dropped from an average of 7.2 clicks from the homepage to 3.1. Organic impressions on those pages rose 28% over the following quarter.
大規模サイト向けの内部リンクチェックリストです。
- インデックスに登録されるべきページは、ホームページから3クリック以内であるべき
- オーファンページ（内部リンクがゼロ）は、バックログアイテムではなく緊急事態として扱うべき
- パンくずナビゲーションは内部リンクとしてカウントされる——正しく実装され、実際のアンカーテキストを使用していることを確認する。「カテゴリ > サブカテゴリ」といった汎用ラベルではなく。
- 内部リンクが1本だけ指しているページをチェックする——これは孤立ページとほぼ変わらない。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
大規模な構造化データとスキーマ
10,000件以上の商品ページがあるのに、Product スキーマに Offer、Review、AggregateRating プロパティがない場合、検索結果ページの貴重な表示枠を逃しています。Product schema with Offer,Review, and AggregateRating properties, you're leaving SERP real estate on the table.
ただし、大規模な構造化データはそれ自体、監査要件を生み出します。テンプレート内のスキーマエラーは、数千個の無効なマークアップインスタンスを意味します。私は2つのツールを組み合わせて構造化データをチェックします。個別URL サンプリング用の Google Rich Results Test と、Screaming Frog でのクロール レベルのスキーマ抽出（Configuration → Custom Extraction → JSON-LD ブロック用の XPath）で、すべてのページタイプ全体の一括ビューを取得します。
チェックすべき項目：
- 必須プロパティの欠落（特にProduct ページの price と priceCurrency ——よくある漏れ）
priceandpriceCurrencyon Product pages -- these are common omissions) - スキーマの不一致（スキーマでは1つの商品名、<title>では別の名前）
<title>says another) - 廃止予定のスキーマタイプ——DataFeedElement と古い itemscope マイクロデータパターンの一部は監査して削除する価値がある。
DataFeedElementand some olderitemscopemicrodata patterns are worth auditing out - Google のレビュースニペットガイドラインに違反するスキーマをレビューする——ファーストパーティレビューがサードパーティとしてマークアップされている、または小規模なサンプルから集計されたスコアの場合。Google's review snippet guidelines -- first-party reviews marked up as third-party, or aggregated scores from tiny sample sizes
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
ページ速度の大規模化：修正できないものを監査しない
Core Web Vitalsは重要です。ただし、十分に語られていないことがあります。10,000ページ全体でCWVを監査して、個別のURLごとに修正しようとするのは無駄な努力です。テンプレートで監査して、テンプレートで修正するのです。 matter. But here's the thing that doesn't get said enough: auditing CWV across 10,000 pages and trying to fix every individual URL is a fool's errand. You audit by template, then fix by template.
テンプレートタイプごとに 20～30 個の URL をサンプルとして PageSpeed Insights または WebPageTest で実行する。プロダクトページの平均 LCP が 4.8 秒の場合、それはテンプレートレベルの問題だ。修正は画像配信パイプライン、クリティカル CSS、またはサーバーレスポンスタイムにある——個別ページに手を加えるわけではない。WebPageTest. If your product pages have an average LCP of 4.8s, that's a template-level problem. The fix is in your image delivery pipeline, your critical CSS, or your server response time -- not in touching individual pages.
特に大規模な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 URL）で徹底的に監査すれば、その結果はテンプレート全体に適用される。例外は孤立ページの特定とリダイレクトチェーンの発見——これらは全クロール対象が必要で、サンプリングでは不十分だ。
大規模サイトの大部分に対する最も影響の大きい修正は何ですか？
クロールバジェット。10 回中 9 回はそれだ。具体的には、検索需要がなく、ユニークなコンテンツもないファセットナビゲーション URL をブロック、またはカノニカル化する。大規模カタログを持つ e コマースサイトで、この 1 つの修正だけでコンテンツやリンク構築による努力よりも大きな効果が出ているのを何度も見た。地味な作業だ——robots.txt の編集、canonical タグ、パラメータ設定——だが、多くの場合コンテンツやリンクビルディング施策よりも高速な結果をもたらす。
大規模サイトではScreaming FrogとSitebulbのどちらを使うべきですか？
どちらも優れています。私は年単位で Screaming Frog を使用していることから、そのエクスポート形式を完全に理解していて、カスタム抽出オプションが優秀なため、クロール作業の大部分で Screaming Frog を使用しています。Sitebulb はより優れた視覚化レイヤーを備えており、監査レポートがクライアント向けに読みやすくなっています。50,000ページ以上のサイトの場合、ローカルマシンの RAM に依存しないクラウドベースのクローリングを提供する DeepCrawl（現在の Lumar）も検討してください。DeepCrawl (now Lumar)for cloud-based crawling that doesn't depend on your local machine's RAM.
大規模サイト監査で最も見逃されやすい問題は何ですか？
内部リンクの深さです。誰もが壊れたリンクと正規タグをチェックします。ホームページから6段階または7段階深いページを体系的に特定し、競争力のあるものでランク付けされると予想される理由を問う人はほとんどいません。クリック深は、クロール優先度と権限配分の代理指標です。毎回監査してください。
大規模サイトのSEOは別の分野ではなく、無視した結果が急速に複合する規模での同じ原則です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス登録、カノニカル、サイトマップ、内部リンク、構造化データ、ページ速度、リダイレクトをその大まかな順序で進めれば、キーワードを1つ見ていなくても、壊れている80%を見つけることができます。
大規模サイトのSEOは別の学問ではありません——それは、怠慢の結果が急速に複合する規模での同じ原理です。上記のチェックリストは静的なままではありません。すべてのサイトには独自の混乱があります。しかし、クロールバジェット、インデックス、canonical、サイトマップ、内部リンク、構造化データ、ページスピード、リダイレクトをその大まかな順序で進めていけば——単一のキーワードを見る前に、壊れている80%を見つけることができます。
インフラストラクチャから始めてください。ランキングはその後についてきます。