概要
ほとんどの技術SEO監査は多くの発見事項を提示しますが、しばしば実行されないままになります。これはクライアント側の問題であることもありますが、多くの場合、監査自体に問題があるためです。発見事項が検証されていなかったり、ツールの基準で深刻度が評価されたり、開発者が対応できない形で書かれていたりすることが原因です。
1つ目の間違いは、JavaScript実行を有効にせずにクローリングすることです。Screaming FrogのようなツールでJavaScriptレンダリングをオンにすると、レンダリング前後のHTMLを比較できます。JavaScript実行後にのみ表示されるコンテンツはインデックスされにくい可能性があり、ほとんどのAIクローラーはJavaScriptを実行しません。この問題の確認には、Search ConsoleのURL検査ツールが有効です。
2つ目は、Search Consoleのページインデックス登録レポートを無視することです。このレポートは、URLがGoogleにどのように扱われているかを直接示します。「インデックス登録されませんでした」に含まれるすべてのURLが問題というわけではなく、正規化されたページやnoindexタグによる除外は正常です。調査すべきは、ランキングさせたいのに「クロール済み - インデックス未登録」や「検出 - インデックス未登録」にあり、その数が増加しているURLです。
3つ目は、URLをランダムにサンプリングし、テンプレートごとにサンプリングしないことです。ほとんどの技術的問題はテンプレートに起因するため、ページタイプ（商品ページ、カテゴリページ、ブログ記事など）でサンプリングすることで、広範囲の問題を一度に特定し、修正コストを抑えることができます。
4つ目は、単一のデータソースから監査を行うことです。各ツールには盲点があります。クローラーは孤立したページを見落とし、Search ConsoleはGoogleの判断を示すものの理由は示しません。サーバーログは、GooglebotやAIクローラーからのすべてのリクエストとその応答を確認できる唯一のソースです。レート制限や一時的な5xxエラーなどはここでしか見つかりません。サーバーログがない場合はSearch Consoleのクロール統計レポートを使用し、開発チームに渡す前には、少なくとも2つのソースで調査結果を確認することが推奨されます。
5つ目は、ツールの分類を事実として扱うことです。クローラーは、高速なクローリングにより、実際には問題がないページのタイトルやH1の欠落、429/503ステータスコードを誤って報告することがあります。報告書に含める前に、手動でページを確認し、curlコマンドでステータスコードを検証することで、開発者が存在しない問題に時間を費やすのを防ぎます。
6つ目は、原因ではなく症状を文書化することです。「サイトに12,000の重複URLがある」は症状であり、その原因（ファセットナビゲーションの問題やセッションIDなど）を特定することが重要です。根本的な原因を解決しなければ、問題は再発します。
7つ目は、ツールの深刻度ではなくビジネスインパクトで優先順位を付けることです。クローラーはビジネスの優先順位を考慮しないため、重要度の低い警告が上位に来る一方で、利益率の高い製品テンプレートにおけるレンダリング失敗のような重要な問題が見過ごされることがあります。クライアントに優先度の高い製品、コンバージョンページ、今後のリリースについて質問し、その回答に基づいて発見事項の優先順位を決定すべきです。
8つ目は、サイト構造を理解せずに変更を推奨することです。リダイレクト、正規化の変更、URLの削除、noindexディレクティブはすべて二次的な影響を及ぼします。推奨事項を出す前に、対象ページに何がリンクしており、そのページが何にリンクしているかを把握し、ナビゲーション、サイトマップ、パンくずリストでの表示を確認することが重要です。
9つ目は、開発者が実行できないような推奨事項を書くことです。「サイト速度を改善する」のような漠然とした指示ではなく、影響を受けるURLやテンプレート、根本原因、期待される結果、および作業を見積もるのに十分な詳細を含める必要があります。例えば、「PDPテンプレートのLCP要素は、遅延読み込みスクリプトを介して読み込まれているヒーロー画像であるため、loading="lazy"を削除し、fetchpriority="high"を追加し、LCPを2.5秒未満にする必要があります」のように具体的に記述します。
10つ目は、実装方法を指示するのではなく、結果を指示することです。達成すべき結果と制約（例：「ページネーションのあるページのカノニカルは自己参照にする必要がある」、「主要な製品コンテンツは初期HTML応答に含まれる必要がある」）を明確にし、具体的な実装方法は開発者に任せます。これにより、開発者はフレームワークの制限や既存のコードベースの計画を考慮して最適な解決策を決定できます。受け入れ基準を設定することで、開発者は何を構築し、どのようにテストすべきかを明確にできます。
クローラーは短時間で問題リストを作成しますが、クライアントが対価を払うのは、その問題が本当に存在するかを確認し、ビジネスにとって何が重要かを判断し、各修正にかかるコストを見積もるその後の人間による作業に対してです。
解説
このブログ記事は、技術SEO監査の真の価値が、単にツールが示す問題リストを超えたところにあることを示唆しています。ツールは「症状」を見つけますが、「原因」を特定し、「ビジネスインパクト」に基づいて優先順位を付け、開発者が実行可能な「具体的な解決策」を提示するのは人間の専門知識です。
特に、「1. JavaScript実行を有効にせずにクローリングする」は、現代のウェブサイトでは避けて通れない問題です。多くのサイトがJavaScriptに依存しているため、適切にレンダリングされたページをクロールしないと、Googleが認識している状態と監査結果が大きく乖離する可能性があります。Search ConsoleのURL検査ツールを常に活用し、Googleの視点を確認する習慣をつけましょう。
「4. 単一のデータソースからの監査」や「5. ツールの分類を事実として扱う」は、多くのSEO担当者が陥りがちな罠です。Search Console、サーバーログ、そして手動での確認（curlコマンドやブラウザでの検証）を組み合わせることで、より信頼性の高い監査結果が得られます。特に、開発者に修正を依頼する前に「少なくとも2つの場所で確認する」というルールは、無駄な作業を減らし、信頼を築く上で不可欠です。
「6. 原因ではなく症状を文書化する」と「9. 開発者が実行できない推奨事項を書く」、そして「10. 実装方法を指示するのではなく結果を指示する」は、開発者との効果的なコミュニケーションに直結する項目です。開発者は具体的な指示と期待される結果を求めています。根本原因を突き止め、具体的な解決策の方向性と明確な受け入れ基準を示すことで、チケットがバックログに埋もれることなく、迅速に実行される可能性が高まります。
「7. ツールの深刻度ではなくビジネスインパクトで優先順位を付ける」は、SEOがビジネスに貢献していることを示す上で最も重要なポイントかもしれません。クライアントや社内のステークホルダーにSEOの価値を理解してもらうためには、技術的な問題をビジネス目標と結びつけ、その影響度に基づいて優先順位を明確にすることが不可欠です。
「8. サイト構造を理解せずに変更を推奨する」は、SEO施策がサイト全体に与える影響を深く理解する必要があることを示しています。安易なリダイレクトやnoindexが、サイトの重要な部分のクロールやインデックスを阻害する可能性があるため、影響範囲を事前に十分に調査することが、より安全で効果的なSEO戦略の策定につながります。これらのポイントを実践することで、単なる問題報告に終わらない、真に価値のある技術SEO監査を提供できるようになるでしょう。
- 掲載元: Search Engine Land
- 公開日: 2026-09-01T14:00:00+00:00
10 technical SEO audit mistakes that lead to bad recommendations
