テクニカルSEO監査：検索を妨げる問題を見つける

テクニカルSEO監査で確認する項目

一つのテクニカルSEO監査は、フォーカスされたエビデンス重視のレビューで、検索エンジンがあなたのページを検出、レンダリング、インデックス化、理解できるようにする仕組みを点検します。目的は、可視性を下げ、クロール予算を浪費し、ユーザー体験を壊す、またはランキングの不確実性を生む技術的障害を見つけることです。

主要な確認ポイント

• Discovery and crawlability — robots.txt, サーバーの応答、サイトマップのカバレッジ、内部リンク、リダイレクト
• Indexing signals — meta robots、X-Robots-Tag ヘッダー、canonical タグ、noindex の使用
• Rendering and JavaScript — サーバーサイドとクライアントサイドのレンダリング、リソースのブロック、レンダリング時の見た目を評価
• サイトのパフォーマンスとページ体験 — Core Web Vitals のフィールドデータ、サーバー応答時間、リソース読み込み
• 重複コンテンツとURLのカノニカリゼーション — パラメータ処理、末尾スラッシュのバリエーション、ページネーション
• 構造化データとSERP機能 — マークアップの正確性とリッチ結果の適格性
• 国際化とhreflangの正確性
• セキュリティとアクセシビリティ — HTTPS カバレッジ、mixed content、セキュアなヘッダー

テクニカルSEO監査の実行方法（ステップバイステップ）

1. 範囲と成功指標を定義する

まず、監査するサイトの範囲とその理由を決めます。例：ドメイン全体、サブディレクトリ、大きな製品カテゴリ、あるいは一連のランディングページ。計測可能な成功指標を決める（canonical ページのインデックス化、サーバーエラーの減少、Core Web Vitals のパーセンタイル改善、特定の URL グループの可視性など）。

2. インベントリを作成する

サイトマップ、Analytics、サーバーログ、内部リンク、既知のランディングページから代表的な URL リストを集めます。これは監査の対象面です — スプレッドシートやcrawlerプロジェクトに保存して、作業中に URL をタグ付け・フィルタできるようにします。

3. クロールと比較（外部クロール + サーバーログ）

外部クロールを実行して検索エンジンのページ発見を模擬します。クロール結果をサーバーログと組み合わせて、検索エンジンが実際にどの URL をリクエストしているかを確認します。サーバーログはクローラーがページをどれくらい取得しているか、リダイレクトやソフト404、頻発するエラーが本番で発生しているかを示します。

ヘッダーだけを確認するには: curl -I https://example.com/page でステータスやヘッダフィールドを確認します。特定の user-agent が受け取る HTML を取得するには: curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com/page として出力を保存し、比較に使います。

4. インデックス可能性とカノニカルの意図を確認する

所有ページについては、Google Search Console の URL Inspection を使って Google が URL をどのようにインデックスしたか、インデックスの問題が検出されているかを確認します。第三者のページ（出版社やパートナーサイト）については外部チェックを行います：view-source、curl、Chrome DevTools によるレンダリング後の DOM チェック、site: 演算子などの公開インデックスシグナル（確証にはならない）を参照します。

5. レンダリングと JavaScript の挙動をテストする

Chrome DevTools でページを開き、Elements と Network パネルを使ってリソースが読み込まれてブロックされていないか確認し、JavaScript によって注入されたコンテンツのレンダリング後の DOM をチェックします。重要なコンテンツがユーザーの操作後やレンダリングライフサイクルの遅い段階でしか出現しない場合は、可視性リスクと再現手順を記録してください。

Rich Results Test と Schema Markup Validator（schema.org）を使って構造化データを検証し、リッチ結果の適格性を阻害するエラーを検出します。

6. ページ体験とパフォーマンスを計測する

Search Console からのフィールド指標（Core Web Vitals）と、Lighthouse やローカルテストによるラボプロファイルを収集します。フィールドデータは実際のユーザーを反映し、ラボデータはローカルで問題を再現するのに役立ちます。検索可視性に重要なページの実ユーザーメトリクスに影響する修正を優先してください。

検証とトラブルシューティング

トラブルシューティングは探偵プロセスです：症状を再現し、変数を切り分け、修正をテストします。公開ツールと所有者専用ツールを組み合わせて使います。

有用な検証手順

• サーバー応答を確認：curl -I で HTTP ステータス、content-type、X-Robots-Tag ヘッダーが見えます。
• 配信された HTML を検査：curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com/page とブラウザ取得を比較してコンテンツ差分を検出します。
• レンダリング後の DOM チェック：Chrome で URL を開きキャッシュを無効化して Elements を使い、重要なコンテンツがユーザー操作なしで DOM に存在するか確認します。
• インデックスの証拠（所有ページ）：Google Search Console の URL Inspection でインデックス状況と除外理由を確認します。
• 構造化データ：Rich Results Test と Schema Markup Validator を実行してパース結果とエラーを確認します。
• フィールドパフォーマンス：Search Console の Core Web Vitals で実ユーザーメトリクスを確認し、Lighthouse やラボ実行で遅いケースを再現します。
• クロール活動：サーバーログ内のクローラーリクエストをサイトマップや既知のページと比較し、ギャップや低価値 URL への過剰なクロールを特定します。

よくあるミスと誤解

• ツールの警告をそのまま監査とみなす：クローラーは多くのシグナルを表面化します。監査はそれらの警告のうち、ビジネスゴールにとって重要なものを解釈することです。
• クロールとインデックスを混同する：クローラーに取得されただけではページがインデックスされる、あるいはランク付けされる保証にはなりません。
• site: を決定的な証拠とする：site: は有用な公開シグナルですが権威あるものではありません。所有ページは Search Console の URL Inspection を使ってください。
• 重要なアセットのブロック：robots.txt やサーバールールで CSS/JS を阻止すると Google のレンダリングが変わり、Core Web Vitals や構造化データ検出に影響することがあります。
• 間違った canonical やリダイレクトチェーン：canonical が非カノニカルコンテンツを指す、あるいは長いリダイレクトチェーンは曖昧さを生みクロールを遅くします。
• rel="nofollow" を完全に無価値とみなす：Google は rel="nofollow" をヒントとして扱っており、その扱いは単純なオン/オフではありません。
• 出版社やパートナーのページのインデックス可能性を無視する：backlink や言及は、対象ページがインデックス不可、または認証の背後に隠されている場合は役に立ちません。

有料掲載やスポンサードコンテンツが関わる場合は、Google のガイダンスに従ってください：有料/報酬付きリンクは rel="sponsored" または rel="nofollow" でマークし、ユーザー生成リンクには rel="ugc" を使います。注意：rel="dofollow" 属性は存在しません。標準のリンクは rel=nofollow/sponsored/ugc が付いていないリンクです。Google の linkspam ガイダンスは、ランキング操作を目的としたリンクは link spam と見なされ得ると示しているため、外部掲載では編集上の文脈、インデックス可能性、透明性を確保してください。

チェックリスト：影響の大きい項目とその確認方法

この簡潔なチェックリストで、最も一般的で影響の大きい技術的問題を検証します。各項目に対して適切な検証ツールを示しています。

1) カノニカルの意図：canonical タグは一貫しており、望ましい URL を指しているか？（検証：view-source、HTTP ヘッダーとの比較、外部クローラーの利用）

2) HTTP ステータスとリダイレクトチェーン：重要なページは 200 を返し、余計なリダイレクトやエラーがないか？リダイレクトは最小限か？（検証：curl -I とサーバーログ）

3) Robots と meta robots：重要なアセットやページが意図せずブロックされていないか？（検証：robots.txt の取得、curl -I による X-Robots-Tag ヘッダー、HTML 内の meta robots）

4) インデックスの異常：noindex、別を指す canonical、ソフト404 など技術的理由でページが除外されていないか？（検証：所有ページは Google Search Console の URL Inspection、外部ページは HTML と公開インデックスシグナルの比較）

5) レンダリング後のコンテンツ整合性：検索エンジンが見る HTML にユーザーが見る重要コンテンツと同一のものが含まれているか？（検証：適切な UA を使った curl、Chrome DevTools のレンダリング後 DOM）

6) 構造化データの正確性：構造化データは有効で最新か？（検証：Rich Results Test と Schema Markup Validator）

7) Core Web Vitals と読み込みパフォーマンス：主要ページのフィールド指標に問題はあるか？（検証：Search Console の Core Web Vitals レポートと Lighthouse によるラボテスト）

優先順位付け：効果が出る修正を選ぶ

作業の優先順位は次の三つを組み合わせて決めます：ビジネス目標への関連性（どのページが検索トラフィックやコンバージョンに重要か）、技術的深刻度（インデックス阻止、頻繁なエラーを引き起こすか）、修正の工数。短期的効果としては misconfigured な noindex タグの修正、トラフィックが多いページのリダイレクトチェーンの解消、レンダリングに影響する重要な CSS/JS のブロック解除などが典型的です。

報告と監視

問題を優先度別に整理し、事例と再現手順を示し、推奨されるロールアウト計画を含む監査レポートを提供します。回帰監視を追加してください：サーバーエラー、Search Console によるインデックス変化、Core Web Vitals のフィールド指標を追跡します。修正をデプロイしたら、監査で使った検証手順を再実行して解決を確認します。

よくある質問

クロールはインデックス化やランキングとどう違うのか？

クロールは URL を発見して取得するプロセスです。インデックス化はページのコンテンツの一部または全部を検索インデックスに保存する決定です。ランキングはクエリ発行時の結果の並び順です。ページはクロールされてもインデックスされないことがあり、インデックスされていても高いランキングを保証するものではありません。それぞれの段階には別個のシグナルとチェックがあります。

Googlebot としてページを取得したときに HTML が異なる場合は？

まず、その差分が意図したものか（デバイス最適化されたコンテンツ）それとも偶発的なものか（サーバーの誤設定や user-agent による出し分け）を確認してください。Googlebot に似た UA を使って curl で HTML を保存し、通常のブラウザ取得と比較し、UA やヘッダーによって出力を変えるサーバー側ロジックを点検します。クローラーとユーザーに対して大幅に異なるコンテンツを返すことは避けてください。

backlink を含む出版社のページがインデックス可能かどうかはどう確認する？

外部からは、ページの HTML を見て meta robots を確認し、curl -I で X-Robots-Tag ヘッダーを検査し、ページが 200 ステータスを返すことを確認します。ブラウザのレンダリング後 DOM を使って、リンクが静的またはレンダリング後の HTML に存在するかを確認します。site: 演算子は公開インデックスのシグナルを示すことがありますが決定的ではありません。

技術的な問題を修正すればランキングが確実に上がるか？

単一の技術的修正でランキング向上が保証されるわけではありません。技術的対応は障害を取り除き、強力で関連性の高いコンテンツが競える可能性を高めます。修正後はインデックス化やパフォーマンスのシグナルを監視し、技術改善をコンテンツや関連性の改善と組み合わせてください。

Google がモバイルファーストインデックスを採用している場合、まず何をチェックすべきか？

Google はモバイル版を主な基準としてクロールとインデックス化を行います。2024年7月以降、Google はデフォルトで Googlebot Smartphone によるサイトのクロールを行っています。モバイル HTML がデスクトップ版と同じ重要コンテンツ、メタデータ、構造化データを公開しているかを確認し、モバイルでのパフォーマンスとレスポンシブな振る舞いが許容範囲にあることを確かめてください。