テクニカルSEO監査: クロール、インデックス登録、アーキテクチャ、Core Web Vitals

ほとんどの「テクニカルSEO監査」は200ページのPDFとなり、誰も開かないGoogle Driveフォルダに保存されます。エンジニアリングがそれを無視するのは、学術論文のように読めるからです。トリアージなし、チケットテンプレートなし、修正に紐づいたトラフィック見込みもなし、という問題の目録です。

これはIC向けのバージョンです。5つの重点領域、具体的な診断、そしてエンジニアが次のスプリントで実際に取り上げる開発チケットキューです。監査の価値はデッキにあるのではありません。マージされたプルリクエストにあります。

四半期監査を終えて47タブのスプレッドシートはあるのにコミットがゼロなら、あなたは監査ではなくリサーチプロジェクトを実施したことになります。

5領域の監査フレームワーク

私が実施するすべてのテクニカル監査は、同じ5つの領域を同じ順序でカバーします。依存関係が下流に流れるからです。Googlebotがクロールできないページでのコンバージョン最適化は意味がなく、インデックスされていないページのスキーマ修正も意味がありません。ファネルの上から順に取り組みます。

1. クロール可能性
2. インデックスカバレッジ
3. アーキテクチャと内部リンク
4. Core Web Vitals
5. 構造化データ

50,000URL未満のサイトなら、2日間の集中作業で初回パスを完了できます。それより大きい場合は1週間を計画し、ログサンプリングをより多く活用してください。

1. クロール可能性

ツール: 全クロールにScreaming FrogまたはSitebulb、Googlebotが実際に取得するデータにサーバーログ、GSCのrobots.txtテスター。

まずrobots.txtを一行ずつ読んでください。次に、ディレクトリレベルとパターンレベルでブロックされている内容を確認します。四半期に少なくとも一度は見かける典型的な自滅パターン:

• ステージング環境のルールが本番環境に漏れる。 誰かがデプロイ時にステージング環境のrobots.txtからDisallow: /を本番環境にコピーします。48時間でサイト全体が検索から消えます。修正は2文字。ダメージは6週間。
• /api/ルートが誤ってブロックされているのに、そこでコンテンツをハイドレートしている。 一部のNext.jsやNuxtアプリはISRやSSRデータのために/api/...からフェッチします。そのエンドポイントがブロックされると、Googlebotは2回目のパスで半分しかレンダリングされていないページを見ます。
• CSSとJSがブロックされている。 今でも起きます。Googlebotはページをレンダリングする必要があります。スタイルシートを読み込めない場合、モバイルフレンドリー検査が失敗して検索順位が下落します。
• ロングテールトラフィックの60%が来るファセットナビゲーションをDisallowしている。 Eコマースでよく見られます。robots.txtでパラメーターURLをブロックすると、それらを統合するはずだったcanonicalシグナルも一緒にブロックします。

robots.txtの確認後、JavaScriptレンダリングを有効にした状態でScreaming Frogの全クロールを実行します。レンダリング済みHTMLを生のHTMLと比較します。レンダリング済みの方が3,000語多い場合、JSレンダリングの問題があります（以下で詳しく説明します）。

次にサーバーログをサンプリングします。Googlebotのユーザーエージェントでフィルタリングした2週間分のアクセスログ。ステータスコードとURLパターンでグループ化します。確認すること:

• GooglebotにヒットしているHTTP 5xxエラー（サーバーがクロール速度についていけない）
• ソフト404（「ページが見つかりません」というコンテンツで200ステータスを返している）
• クロールトラップ（ファセットナビゲーションの無限パラメーターの組み合わせ、3024年まで続くカレンダーウィジェット、URLに含まれるセッションID）

クロールバジェットが問題になるのは100,000URL以上のサイトだけです。800ページのSaaSサイトなら、クロールバジェットを心配するより、その800ページのうち12ページがオーガニックトラフィックの90%を占めている理由を考えましょう。

2. インデックスカバレッジ

ツール: GSCのインデックスカバレッジ（現在はPagesレポート）、クロール済みとインデックス済みを比較するScreaming Frog。

GSCのPagesレポートを開きます。「インデックス未登録」でフィルタリングします。すべてのステータス理由を一つずつ読んでください。最も多くのリグレッションバグを生む2つ:

• 「検出済み、現在インデックス未登録」。 GoogleがURLを見つけたがまだ取得していません。通常、クロール優先度が低い（薄いコンテンツ、弱い内部リンク）か、サーバーが遅いことを意味します。
• 「クロール済み、現在インデックス未登録」。 Googleが取得してインデックスに追加しないと判断しました。これは品質シグナルです。薄いコンテンツ、ほぼ重複しているページ、Googleが低価値と見なすページがここに分類されます。これを修正するのはコンテンツの問題であり、テクニカルな問題ではありません。「クロール済み、インデックス未登録」で開発チームにチケットを起票しないでください。

定番の問題:

• 重要なページへのnoindex。 典型的な自滅パターン。誰かが/blog/ディレクトリ全体で使われているレイアウトファイルに<meta name="robots" content="noindex">を追加して、30日後にトラフィックが急落します。単一の記事をテストしていた開発者がレイアウト変更を戻し忘れたケースを見たことがあります。監査中はコードベースのnoindexを必ずgrepしてください。必ず。
• canonicalの不一致。 ページAに<link rel="canonical" href="page-b">があり、ページBに<link rel="canonical" href="page-a">がある。Googleはどちらか一方を選んでもう一方を無視しますが、どちらを選ぶかはコイントスです。修正: 意図的な統合理由がない限り、すべてのページは自分自身をcanonicalにします。
• パラメーターの処理。 UTMパラメーター、セッションID、ソート順、フィルターの組み合わせ。canonicalを設定しない限り、各バリエーションはGoogleにとって別URLです。デフォルトルール: パラメーター付きURLはすべてクリーンなベースURLをcanonicalにします。コンテンツが大きく変わるパラメーター（商品バリエーションなど）のみ上書きします。
• hreflangエラー。 多言語サイトを運営している場合、hreflangの戻りタグエラーは連鎖します。GSCの国際ターゲティングレポートに今でも表示されます。

サニティチェック: Googleでsite:yourdomain.comを検索します。表示される数値はGSCのインデックス数とおおよそ一致するはずです（20%以内）。site:が12,000を表示してGSCが4,000を表示している場合、何かがおかしく、そのギャップはたいていcanonicalを設定する前にGoogleがインデックスしたパラメーターURLです。

3. アーキテクチャと内部リンク

ツール: Sitebulb（サイトの深さの可視化で最高クラス）、Screaming Frogのクロール深度レポート。

監査で見かける頻度順に並べた3つの診断:

ホームページからの深さ。 ホームページから4クリック以上かかるページは要注意です。Screaming Frogのクロールを実行し、クロール深度の降順で並べ替えます。深さ6以上のページは通常、孤立しているか、悪いナビゲーションによって孤立しています。最も売上を生むプロダクトページが深さ5にあるなら、アーキテクチャのバグであってコンテンツのバグではありません。

孤立ページ。 内部被リンクがゼロのページ。Sitebulbには専用レポートがあります。よくある原因: キャンペーンの旧ランディングページ、どこからもリンクされていない編集チームのブログ記事、ナビゲーション更新なしにローンチされたプロダクトページ。関連するハブページからリンクするか、noindexを設定します。放置しないでください。

内部リンクの分布。 Screaming FrogでURL別の内部リンク数を取得します。分布をグラフ化します。内部リンクが0〜2件のページのロングテールを確認します。コンテンツがどれほど優れていても、そのページは検索順位で苦労します。ハブ・アンド・スポーク構造（ピラーページから関連記事のクラスターへ）が最もクリーンな修正です。各クラスター記事はピラーページにリンクし、ピラーページはすべてのクラスター記事にリンクします。

ファセットナビゲーションの罠。 Eコマースやマーケットプレイスの場合、ファセットナビゲーションで数百万のURL組み合わせが生成される可能性があります。判断基準:

• コンテンツを大きく変えるフィルター（カテゴリー、ブランド）: インデックス可能、自分自身をcanonicalにする
• 並べ替えまたはページネーションのみのフィルター: noindexまたはベースカテゴリーをcanonicalにする
• 組み合わせフィルター（カテゴリー + ブランド + 価格 + サイズ）: robots.txtでブロックするか、クロール可能なURLを生成しないAJAXを使用する

パンくずリスト。 すべてのコンテンツページにはBreadcrumbListスキーマでマークアップされた表示可能なパンくずコンポーネントが必要です。パンくずはユーザーの方向感覚を助け、Googleに追加の構造シグナルを与え、SERPでのパンくず表示を獲得します。

4. Core Web Vitals

ツール: ラボデータとフィールドデータ両方のPageSpeed Insights、繰り返し可能なラボテストにLighthouse、診断用のChrome DevToolsパフォーマンスパネル、モニタリング用のGSC Core Web Vitalsレポート。

しきい値は重要です。覚えてください:

必ずフィールドデータ（CrUX、PageSpeed InsightsとGSCの実ユーザー数値）で計測してください。ラボ数値ではありません。ラボ数値はストーリーを語りますが、フィールドデータが真実を語ります。実際のユーザーはより遅いネットワークと古いデバイスを使用しているため、ラボが合格でもCrUXが不合格の場合があります。

修正をティア分けします。各指標には作業負荷対効果の明確な優先順位があります:

LCPの修正（作業負荷対効果の順）:

INPの修正:

CLSの修正:

個別URLではなく、主要な10テンプレート（ホームページ、ブログ記事、カテゴリー、プロダクト、価格など）でPageSpeed Insightsを実行します。テンプレートで修正すれば、一度で全体に適用されます。

5. 構造化データ

ツール: GSCのリッチリザルトレポート、schema.orgバリデーター、Screaming Frogの構造化データ抽出。

カバレッジの確認。コンテンツタイプごとに適切なスキーマが必要です:

• 記事: ArticleまたはBlogPosting
• プロダクトページ: Offer付きProduct
• FAQページ: FAQPage
• 組織（ホームページとフッター）: Organization
• パンくず（全ページ）: BreadcrumbList
• ハウツーコンテンツ: HowTo

構造化データ抽出を有効にしてScreaming Frogを実行します。エラーがあるURLや対象タイプが欠けているURLでフィルタリングします。GSCのリッチリザルトレポートと照合します。これがGoogleが検証する内容の真実のソースです。

AEOの観点（アンサーエンジン最適化）は四半期ごとに重要性が増しています。LLM搭載の検索システムは、引用するコンテンツを決定する際に構造化データに大きく依存します。有効なFAQPageスキーマとクリーンな質疑応答ペアを持つFAQページは、スキーマなしの同じコンテンツよりもChatGPT、Perplexity、GoogleのAI Overviewsにはるかに高い頻度で引用されます。スキーマはもはやリッチスニペットのためだけではありません。機械があなたのページが何について書かれているかを判断する手段です。

JSレンダリングの現実

サイトがSSRやSSGなしのReact、Vue、Svelte、またはAngularで構築されたSPAなら、難易度の高い状況で戦っています。

Googlebotは2パスでレンダリングします。第1パス: 最初のHTMLレスポンスを確認します。レンダリングされていないSPAの場合、スクリプトタグが付いた<div id="root"></div>にほぼ近い状態です。第2パス: 数時間から数週間後、Googleのレンダリングキューに余裕ができたとき、再取得してJSを実行します。コンテンツはいずれインデックスされます。

「Screaming Frogでブランクページ」の診断: JSレンダリングをオフにしてScreaming Frogを実行します。ページが空の<body>で200 OKを返す場合、それが第1パスでGooglebotが見るものです。JSレンダリングをオンにして実行します。コンテンツが表示されれば、Googleもいずれそこに到達します。表示されなければ、より深い問題（認証ウォール、壊れたハイドレーション、レンダリングをブロックするJSエラー）があります。

これが重要なケース:

• ニュースとトレンドコンテンツ。 Googlebotが24時間以内にインデックスすることに依存しているなら、第2パスの遅延は致命的です。SSRまたはSSG、例外なし。
• 大規模カタログ。 クライアントサイドレンダリングで50,000商品のEコマースサイトを運営すると、クロールバジェットがレンダリングキューで消費されます。Googleはどのページが第2パスに値するかを決定します。
• 認証ゲートのあるページ。 ハイドレーションロジックが未認証ユーザー（Googlebotはこれに該当）をリダイレクトする場合、Googleはコンテンツではなくリダイレクトを見ます。

判断基準:

• コンテンツサイトであれば: SSG（Next.js、Astro、Eleventy）
• プロダクトアプリであれば: マーケティングページにSSR、アプリ本体にCSR
• 移行コストが高すぎる場合: プリレンダリング（Prerender.io、Rendertron）を暫定措置として

レンダリング失敗時のUser-Agentヘッダーをログに記録するようエンジニアリングチームに依頼してください。Googlebotが記録されていれば、スプリントプランニングに持ち込む証拠になります。

成果物を開発チケットとしてまとめる

ここでほとんどの監査が死にます。指摘事項は本物です。チケットが書かれることはありません。エンジニアリングはバックログから最も簡単なタスクを選びます。誰もあなたの監査にビジネスインパクトを添付しなかったからです。

成果物は優先度付きのチケットキューです。四半期監査の私の標準的な内訳:

• P0が3件（インデックスをブロックする問題）。これが修正されないとページは検索順位に入れません。例: 重要なページへのnoindex、インデックス可能なディレクトリのrobots.txt Disallow、404を指すcanonicalタグ。
• P1が8件（Core Web Vitalsの失敗とアーキテクチャ問題）。例: 主要テンプレートでLCP > 4秒、売上ページへの内部リンクなし、クロールトラップを生成するファセットナビゲーション。
• P2が20件: スキーマのギャップ、hreflangのクリーンアップ、メタディスクリプションの書き直し、画像のaltテキスト、マイナーなアーキテクチャの調整。

すべてのチケットに同じフィールドが必要です:

タイトル: [SEO P0] /blog/* レイアウトのnoindexメタタグ

URLパターン: /blog/* に一致するすべてのURL
再現手順:
  1. https://example.com/blog/any-post にアクセス
  2. ソースを表示
  3. <head>内に<meta name="robots" content="noindex">を確認
期待値: インデックス可能なブログ記事にnoindexタグが存在してはならない
証拠: ビューソースのスクリーンショット、GSC Pagesレポートで247URLが
  「'noindex'タグによって除外」ステータスと表示されている
推定トラフィックインパクト: 247URLが現在除外されています。そのうち上位20件は
  noindex追加前にAhrefsデータで4〜15位を記録していました。
  修正からreindex後60日以内に月間8,000〜12,000のオーガニック
  訪問が回復する見込みです。
完了基準: レイアウトファイルが/blog/*にnoindexタグをレンダリングしなくなる。
  GSC Pagesレポートの「noindexによる除外」件数が240件以上減少する。

エンジニアリングはこのように書かれたチケットを処理します。「ブログのインデックス問題を修正」というチケットは処理しません。

監査の実施サイクル

四半期に1回、5領域すべてをカバーする深い監査。2日間の集中作業と、チケットを書いてスプリントプランニングに乗せるための1週間。毎四半期。

月次インデックスカバレッジチェック。毎月第1月曜日にGSC Pagesレポートを開きます。前月のスナップショットと比較します。10%以上増加した「インデックス未登録」カテゴリーを調査します。

週次CWVリグレッションスキャン。GSCのCore Web Vitalsレポート。「良好」から「改善が必要」に転落したテンプレートは週内に調査します。CWVのリグレッションを1週間で発見すれば1時間の修正です。リリースから8週間後に発見すれば複数スプリントの掘り起こし作業になります。

サーバーログのサンプリング: ほとんどのサイトは四半期に1回で十分、500,000URL以上のサイトは月次。

監査は一度限りの成果物ではありません。運用サイクルです。最初の回は基準値を確立するため作業量が多くなります。3四半期目までには、ほとんどの時間がリグレッションスキャンと新規問題のトリアージに使われ、全体の再監査ではなくなります。

修正を届けてください。指摘事項だけでは十分ではありません。監査の価値はマージされたプルリクエストによってのみ証明されます。

あわせて読む

• ピラーページのオンページSEOチェックリスト
• B2B SaaSの内部リンク戦略
• B2B SaaSのスキーママークアップ
• GSC週次ワークフロー