技術SEO監査チェックリスト：クロール、インデックス、レンダリング、パフォーマンスの20項目
1. 技術監査を4つの象限に分ける理由
多くの人は技術監査といえばPageSpeed Insightsを一度走らせ、GSCのエラー数を眺めるだけです。しかし技術SEOには4つの層があります。Googleがクロールできるか（クロール）、クロール後にインデックスするか（インデックス）、内容は正しいか（レンダリング）、速く動くか（パフォーマンス）です。どれか1つでも問題があれば、上の作業はすべて無駄になります。
直感に反する判断：登録率100%は目標ではありません。1000ページのサイトで900ページが薄いコンテンツ、パラメータページ、検索結果ページなら、Googleがすべて登録しても全体の品質評価を下げるだけです。正しいやり方は、低品質なページを自分からnoindexにして、クロール予算を本当に価値のある100ページに集中させることです。
| 象限 | 核心的な問題 | 問題が起きたら | 構成比 |
|---|---|---|---|
| クロール Crawling | Googlebotがあなたのページに到達できるか | ページがまったく訪問されない | 基盤層、一発失格 |
| インデックス Indexing | クロール後にインデックスするか | ページがGoogleのデータベースに入らない | 基盤層、一発失格 |
| レンダリング Rendering | クロールしたHTMLが完全な内容か | 内容は正しいのにGoogleが読めない | 現代のサイトで多発 |
| パフォーマンス Performance | ページが速く動くか | 順位が下がるかユーザーが離脱する | 順位要因の1つ |
4つの象限は段階的につながっています。まずクロールできることを確保し、次にインデックスできることを確保し、さらに正しくレンダリングされることを確保し、最後にパフォーマンスを最適化します。順序は逆にできません。robots.txtが重要ページをブロックしていれば、LCPをいくら最適化しても無駄です。Google SEO他のモジュールとの関係：技術監査は土台であり、構造化データSchemaは土台の上に家を建てることで、Core Web Vitalsの最適化はパフォーマンス象限の詳細展開です。
2. クロール象限：5項目のチェック
クロール象限が最も根本的な問題です。Googlebotがあなたのページに到達できなければ、その後の作業はすべて無意味になります。
| # | チェック項目 | 合格基準 | ツール | よくある質問 |
|---|---|---|---|---|
| 1 | robots.txtによる誤ったブロックなし | 重要ページがDisallowされていない | GSCのrobotsテストツール | リニューアル時にDisallow: /と誤記 |
| 2 | XML Sitemapがアクセス可能 | 200を返し、エラーなし | GSCのSitemapレポート | Sitemapのパス誤記または未送信 |
| 3 | クロールエラー4xx/5xx < 1% | 404/500エラーの割合が1%未満 | GSCのクロール統計 | リニューアル後に大量の404を301処理せず |
| 4 | クロールバジェットが無駄になっていない | パラメータページ/重複ページでクロールを浪費していない | GSCのクロール統計 + ログ分析 | 検索結果ページが無限にクロールされている |
| 5 | 内部リンクに切れがない | すべての内部リンクが200を返す | Screaming Frogでのクロール | 旧記事が削除済みページにリンク |
事例1：サイトリニューアル後、技術チームがrobots.txtをDisallow: /と書いたまま戻し忘れました。3週間後、GSCの「クロール済み – インデックス未登録」が200から2000に増加。発見方法：カバレッジレポートの「クロール済み – インデックス未登録」が異常に増えたら、まずrobots.txtを確認します。修正後はURL検査ツールで手動インデックス登録をリクエストし、1〜3日で回復します。
クロールバジェット：Googleが各サイトをクロールする頻度には限りがあります。パラメータ付きURL（例：/products?sort=price&filter=red）が大量にあると、Googlebotはこうした重複ページのクロールに多くの時間を費やし、本当に重要な商品ページが後回しになります。解決策は、robots.txtでパラメータ付きURLをブロックするか、canonicalで正規版を指定することです。
三、インデックス象限：5項目のチェック
Googleがあなたのページをクロールしたからといって、インデックスに登録されるとは限りません。インデックス象限で確認するのは、登録すべきページが登録されているか、登録すべきでないページが登録されていないかです。
| # | チェック項目 | 合格基準 | ツール | よくある質問 |
|---|---|---|---|---|
| 6 | 重要ページがすべてインデックスされている | 主要な商品ページ/記事ページのインデックス率 > 95% | GSCのカバレッジレポート | 新商品ページをSitemapに未送信 |
| 7 | noindexの誤設定なし | 公開ページにnoindexタグなし | Screaming Frog + GSC | 開発環境のnoindexを削除し忘れ |
| 8 | 重複コンテンツなし | 同一コンテンツの複数URLバージョン < 5% | Siteliner + Screaming Frog | HTTP/HTTPS、wwwの有無による重複 |
| 9 | canonicalタグが正しい | 各ページに自己参照canonicalがある | GSC + URL検査ツール | canonicalが誤ったページを指している |
| 10 | インデックスカバレッジが適切 | インデックスページ数と価値あるページ数が一致 | GSCのカバレッジレポート | 薄いページが大量にインデックスされている |
事例2：B2Bサイトの商品一覧ページに50通りの絞り込み組み合わせがあり、それぞれがURLを生成していました（/products?category=valve&material=steel）。Googleがそれらをすべてインデックスし、インデックス総数が200から2000に増加。その結果、サイトは重複した薄いコンテンツが多いと判定され、全体の品質スコアが下がり、商品詳細ページの順位まで下落しました。修正方法：パラメータ付きの絞り込みURLにnoindexを付けるか、robots.txtで直接ブロックします。
noindex の設定ミスは最も多く、最も致命的な問題です。開発段階でテストサイトを Google に公開しないよう、チームがサイト全体の head に noindex を追加し、公開後に削除し忘れるケースが典型です。公開から3か月経っても、Google でブランド名を検索しても公式サイトが見つかりません。確認方法は、Screaming Frog でクロールした後に「Meta robots contains noindex」で絞り込み、本番ページが0件になることを確認します。
四、レンダリング象限：5項目のチェック
現代のサイトは JS レンダリング（React、Vue、Next.js のクライアントサイドレンダリング）を多用しています。Googlebot は JS を実行できますが、リアルタイムではありません。まず生の HTML を取得してキューに入れ、数日後に Chrome のレンダリングキューで実行します。この遅延とレンダリング失敗が SPA サイトの SEO 最大の落とし穴です。
| # | チェック項目 | 合格基準 | ツール | よくある質問 |
|---|---|---|---|---|
| 11 | Googlebot が JS をレンダリングできる | URL 検査ツールで「レンダリング済み」と表示される | GSC の URL 検査ツール | JS エラーでレンダリングが失敗する |
| 12 | 主要コンテンツが HTML ソース内にある | title、H1、本文の冒頭段落が生の HTML にある | ページのソースを表示（F12 ではない） | 完全なクライアントサイドレンダリングで、ソースが空 |
| 13 | レンダリングエラーなし、コンソールにエラーなし | Chrome DevTools の Console に Error がない | Chrome DevTools | API 呼び出しの失敗でコンテンツが空になる |
| 14 | 構造化データが解析できる | Rich Results Test でエラーなし | リッチリザルトテスト | JSON-LD が JS で動的に注入されている |
| 15 | hreflang が正しく設定されている | 多言語ページが相互に正しく指定されている | GSC と hreflang チェックツール | hreflang の循環、または誤った言語を返す |
重要な判断ポイントは、「ページのソースを表示」（Ctrl+U、F12 ではない）で生の HTML を確認することです。title、H1、本文の冒頭段落が生の HTML にあれば、SSR または SSG であり、Google は最初のクロールでコンテンツを読み取れます。生の HTML に div#app と大量の script タグしかなければ、完全なクライアントサイドレンダリング（CSR）であり、Google は Chrome のレンダリングキューを待たなければ読み取れません。
多言語サイトの hreflang エラーはよくあります。ドイツ語ページが英語ページを指す、英語ページが自分自身を指す、x-default が欠けているなどです。設定方法はHreflangの多言語対応をご覧ください。構造化データを JS で動的に注入する場合、Google は最終的にレンダリングできますが、クロールキューで見落とされることが多いため、JSON-LD は生の HTML に書くのが最善です。構造化データSchemaの検証フローはここに対応しています。
五、パフォーマンス象限：5項目のチェック
パフォーマンスは Core Web Vitals の3つの主要指標に、モバイルでの使いやすさと HTTPS を加えたものです。パフォーマンスは単に「速く動く」だけでなく、Google のランキング要因です。2021年から Core Web Vitals は正式にランキングシグナルになりました。
| # | チェック項目 | 合格基準 | ツール | よくある質問 |
|---|---|---|---|---|
| 16 | LCP（最大コンテンツ描画） | 2.5秒以内 | PageSpeed Insights + CrUX | ファーストビューの画像が未圧縮、フォントがブロックしている |
| 17 | INP（交互到下一次绘制） | ≤ 200ミリ秒 | PageSpeed Insights + CrUX | サードパーティスクリプトがメインスレッドをブロックしている |
| 18 | CLS（累积布局偏移） | 0.1以下 | PageSpeed Insights + CrUX | 画像にサイズ指定がなく、広告枠が確保されていない |
| 19 | モバイルでの使いやすさ | 使用を妨げるレイアウトエラーがない | GSC のモバイルでの使いやすさレポート | タップ要素が小さすぎる、横スクロールが発生する |
| 20 | HTTPS でサイト全体に混在コンテンツがない | すべてのリソースが HTTPS 経由 | ブラウザのコンソールと GSC | 画像や CSS が依然として HTTP リンクを参照している |
事例3：B2BサイトでPageSpeedのLCPが4.2秒、INPが350ミリ秒。診断の結果、ファーストビューのバナーが3MBの未圧縮PNGで、トップページが8つの第三者トラッキングスクリプトを読み込んでいた。対策として画像をWebPに変換して200KBまで圧縮し、スクリプトはTag Managerで遅延読み込みに。2週間後、LCPは1.8秒、INPは120ミリ秒まで改善。最適化の方法はこちらCore Web Vitalsの最適化。
優先順位：LCP、次にINP、最後にCLS。LCPが基準を満たさない場合は、まずファーストビューの画像（圧縮、遅延読み込み、preload）とTTFBを確認し、その後レンダリングを妨げるリソースを調べる。CDNによるグローバル高速化海外向けサイトのTTFBとLCPを直接改善します。
FAQ よくある質問
テクニカルSEO監査はどのくらいの頻度で行うべき？
インデックス率は高いほど良い？
React/VueのSPAサイトはSEOをどう対策する？
クロール予算とは？無駄遣いされているかどうかの判断方法は？
LCPが基準を満たさない場合、すぐにできる最適化は？
noindex の誤設定はどう見つけて直す？
最後に
テクニカル SEO 監査はすべての SEO 作業の土台です。コンテンツがどれだけ良くても、被リンクにどれだけ費用をかけても、Google がページをクロールできない、あるいは空の JS シェルしか取得できなければ、すべて無駄になります。20 項目のチェックは一度きりの作業ではなく、四半期ごとに必ず行うものです。
実行は 3 ステップです。今週は GSC のカバレッジレポートとクロール統計をエクスポートし、20 項目のチェックと照らし合わせて一つずつ確認します。来週は不合格項目を優先度順に並べます。まずクロールとインデックスを修正し（一発失格）、次にレンダリングを修正し、最後にパフォーマンスを最適化します。3 週目は修正後に URL 検査ツールと PageSpeed で再テストします。
覚えておきたい一言：テクニカル SEO は複雑なほど良いのではなく、クリーンなほど良いのです。Googlebot が速くクロールし、正確にインデックスし、正しくレンダリングし、安定して動作する。この 4 つを実現すれば、あとはコンテンツと被リンクに任せましょう。