【ITニュース解説】A Technical SEO Audit Should End in a Decision, Not a Score

システムエンジニアを目指す皆さんがWebサイト開発に携わる際、Webサイトが検索エンジンで見つけやすくなるための「SEO（検索エンジン最適化）」は避けて通れないテーマである。特に、Webサイトの技術的な側面に関する「技術的SEO監査」は、その健全性を保証する上で極めて重要となる。しかし、この記事では一般的なSEO監査が抱える課題、すなわち「スコア」に重きを置きすぎることの危険性を指摘し、真に価値のある監査は「決定」を導き出すべきだと強く主張している。

Webサイトの技術的な健全性を数値化したスコアが高いからといって、問題が一切ないとは限らない。例えば、サイトの非常に重要なページに、検索エンジンのインデックスを意図せず拒否する「noindex」という指示が設定されていたり、正規のURLを示す「canonicalタグ」が間違ったURLを指していたりするような致命的な欠陥があったとしても、他の多くの項目が正常であれば、全体スコアは高くなってしまう可能性がある。しかし、このような一つ一つの問題は、Webサイトが検索結果に全く表示されなくなるなど、システムのリリースを停止させるべきほどの重大な事態を引き起こす。スコアは異なる種類のリスクや証拠の確からしさ、さらには未解明な要素をまとめてしまうため、かえって誤った安心感を与えかねないという課題がある。

この記事が提案する理想的な監査では、単にスコアを出すのではなく、次の六つの質問に明確に答えることで、リリースに関する具体的な決定を導き出すことを目指している。一つ目は「何を正確にテストしたのか」、二つ目は「どのような証拠が観察されたのか」、三つ目は「何が未解明な点として残っているのか」、四つ目は「どの失敗がリリースを確実にブロックするのか」、五つ目は「その問題の修正と最終決定の責任者は誰なのか」、そして六つ目は「いつそのチェックを再度行うのか」である。これにより、Webサイトの品質と安定性を保証するための、より実用的で具体的なアプローチが確立される。

この「決定」を支援するために、各チェック項目には「Status（状態）」と「Severity（深刻度）」という二つの分類が適用される。「Status」は「未テスト」「適合」「不適合」「該当なし」のいずれかを示し、「Severity」は問題の重要度を「致命的」「重要」「軽微」「情報」の四段階で示す。これらの分類を基に、以下のような明確な決定ルールが適用される。もし「致命的」なチェック項目が「不適合」であるか、「未テスト」であった場合は、そのリリースは「NO-GO（中止）」となる。もし「重要」な不適合が残る場合は、「ARBITRATION REQUIRED（仲裁が必要）」な状態と判断される。それ以外の場合は、「GO WITH RESERVATIONS（条件付きで続行）」となる。このルールは、監査結果が判明する前に設定されるため、公平性が保たれ、特に「未テスト」が「適合」ではないという点が明確にされることで、未確認のリスクを放置しないという意識が促される。

監査の正確性を高める上で、証拠の質とレベルを区別することも非常に重要である。Webサイトの外部から誰でも観察できる「Public（公開情報）」な証拠（例えば、HTTPレスポンスのコード、検索エンジンのクローラーに指示を出すrobots.txtファイル、WebページのHTMLソースコードなど）と、Webサイトの所有者や検索エンジンのみが知り得る「Private（非公開情報）」な状態（例えば、Google Search ConsoleでGoogleが報告するサイトの状態、サーバーのアクセスログ、CDNやファイアウォールなどのシステム設定情報など）は、明確に分けて考える必要がある。例えば、Webページに「このページは正規のURLである」と検索エンジンに示すcanonicalタグが正しく記述されていることは公開情報で確認できるが、Googleが実際にそのcanonicalタグに従って正規URLを選んでいるかどうかは、Google Search Consoleのような非公開情報がなければ断定できない。このように証拠の範囲を明確にすることで、監査の結論に誤った確信を抱くことを防ぎ、より正確な判断を導き出すことができる。

問題が発見された際、単に「SEOに良くない」と漠然と表現するのではなく、WebサイトのURLが検索エンジンによって処理されるどの「ステージ」で問題が発生しているかを具体的に特定することが重要だ。URLは「発見（Discovery）」「クロール（Crawling）」「レンダリング（Rendering）」「インデックス（Indexing）」「配信（Serving）」という複数の明確な段階を経て処理される。例えば、サーバーがHTTPステータスコード200（成功）を返したとしても、それが即座に「検索エンジンに発見され、インデックスされ、検索結果に表示される」ことを意味するわけではない。robots.txtによってクロールがブロックされていたり、重要なコンテンツがJavaScriptの実行後に生成されるため、検索エンジンのレンダリングプロセスで適切に処理されていない可能性などがある。各ステージでどのような診断が可能で、どのような種類の証拠が有効かを理解することで、問題の根本原因を迅速に特定し、的確な修正策を講じることが可能となる。

具体的な検証方法として、サーバーがコンテンツ本体を返さずにヘッダー情報のみを返すHTTP HEADリクエストだけに頼るのではなく、コンテンツ本体を含む完全なレスポンスを要求する実際のHTTP GETリクエストから始めることが推奨されている。なぜなら、Webアプリケーション、コンテンツ配信ネットワーク（CDN）、ファイアウォールなどが、HEADとGETで異なる挙動を示す場合があるためだ。curlコマンドのようなツールを使って、最終的なHTTPステータスコード、リダイレクトの回数、最終的に到達したURL、リクエストにかかった時間などを詳細に記録することで、Webサイトの挙動を正確に把握する。この際、正常なパスだけでなく、HTTPやホスト名の異なるバリアント、過去に存在したリダイレクトURL、既に削除されたリソース、あるいは全く存在しないURLなど、様々な状況をテストすることで、意図しない挙動や潜在的な問題を網羅的に洗い出すことができる。

多くの技術的なSEOの問題は、Webサイトをより良くしようとする「正しい意図」と、その意図を実現するための「間違ったメカニズム」の組み合わせから生じる。例えば、検索エンジンのクローラーの負荷を軽減するためにrobots.txtファイルを使用する意図は正しいが、これをWebサイトへのアクセス制御の仕組みと誤解し、検索エンジンにインデックスされたくない機密情報をrobots.txtでブロックしてしまうと、クローラーはnoindexという指示を読み取ることができなくなり、意図に反してその情報が検索エンジンのインデックスに登録されてしまう危険性がある。このような「意図」「それを実現するためのメカニズム」「そのメカニズムが意図通りに機能していることを示す証拠」を常にセットで考え、メカニズムが期待通りに機能し、その結果が正確に観測されているかを確認することが重要である。

さらに、Webサイトのコンテンツがサーバーから最初に送られてくる「生HTML」の段階で存在するか、それともJavaScriptの実行後にブラウザ上で動的に生成される「レンダリングされたDOM（Document Object Model）」で表示されるのかを比較することも不可欠である。特にJavaScriptを多用する現代のWebサイトでは、「特定のフレームワークがSEOに悪い」といった漠然とした評価に惑わされるのではなく、実際の出力がどうなっているかを客観的な証拠として確認する必要がある。Playwrightのようなブラウザ自動化ツールを使って、Webページがブラウザで完全にレンダリングされた後のタイトル、見出し、canonicalタグ、robotsメタタグ、ページ内のリンク数、JSON-LD（構造化データ）の有無、主要テキストの文字数などを取得し、これらのデータを生HTMLの段階での情報やGoogle Search Consoleのデータと比較することで、検索エンジンがWebサイトのコンテンツをどのように解釈し、処理しているかをより正確に理解できる。

そして、これらの監査結果は、単なる一時的な報告書としてではなく、後で参照・比較・再実行が可能な「データ」として保存することが強く推奨されている。監査結果のデータには、ユニークなID、対象URL、観測日時、ステータス、深刻度、アクセスレベル、証拠の詳細、そして特に重要な「制限事項」や「問題の担当者」「最終的な決定」といった情報を含めるべきだ。この「制限事項」は、例えばローカル環境でのブラウザテスト結果がGoogleの実際のインデックス挙動を完全に再現するものではないことを明記するなど、誤解を防ぐ上で極めて重要な役割を果たす。

最終的に、Webサイトの品質を継続的に保証するために、安定した技術的SEOの「不変要素」をCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインに組み込むことが可能である。CI/CDは、ソフトウェア開発におけるコードの統合、テスト、デプロイといった一連のプロセスを自動化する仕組みである。このパイプラインに、デプロイごとにWebサイトの特定の不変な挙動（例えば、最終的なHTTPステータスコード、意図しないrobots.txtやnoindexの変更、canonicalタグの一貫性など）が維持されているかを自動でチェックする仕組みを組み込むことで、デプロイによる予期せぬ品質低下（リグレッション）を迅速に検出し、防ぐことができる。ただし、自動化はあくまで定義された問題の検出が主な役割であり、ビジネス上の例外判断や最終的なリリース決定は、やはり人間の責任者に委ねられる必要がある。

システムエンジニアを目指す皆さんにとって、Webサイトの技術的な健全性を維持することは、単にWebサイトが動作すれば良いというレベルを超え、それが実際にユーザーに価値を提供し、ビジネス目標に貢献するための強固な基盤を築く上で非常に重要である。次のシステムデプロイメントを控える際には、「今回取得した技術的なSEOスコアは何点だったか」という漠然とした問いではなく、「このリリースを停止させる可能性のある、適用可能な失敗は何であり、それを確実に検出するための証拠は揃っているか」という、より具体的で実践的な問いを自らに投げかける習慣を身につけることが、高品質なWebサービスを継続的に提供する上で不可欠となるだろう。