【ITニュース解説】Running SEO Checks in a CI Pipeline: What to Automate

システム開発において、ウェブサイトの検索エンジン最適化（SEO）は非常に重要な要素だ。しかし、システムを開発し、新しい機能を追加したり修正したりするデプロイの過程で、SEOに関する問題が静かに発生し、気づかないうちに検索エンジンの評価を下げてしまうケースが少なくない。通常の単体テストや結合テストでは、コードの機能や動作は確認できるものの、検索エンジンがウェブページをどのように認識するかといった視点でのチェックは行われないため、こうした問題は見過ごされがちである。

SEOに関する問題がデプロイ時にひっそりと発生する理由はいくつかある。例えば、ステージング環境でのみ使用するはずだった「noindex」というタグが本番環境のウェブページに誤って含まれてしまう場合や、検索エンジンのクローラー（ウェブページを巡回するプログラム）に対してアクセスを制限する「robots.txt」というファイルに、本番環境の全ページへのアクセスを禁止するような記述が誤って含まれてしまう場合がある。また、正規のURLを示す「canonical」タグが開発環境のURLを指していたり、ページ固有のタイトルや説明文といった重要なメタ情報が、レイアウトの変更によって意図せず削除されてしまったりするケースもある。さらに、ウェブページのURLを変更した際に、古いURLから新しいURLへの自動転送（リダイレクト）設定を忘れてしまい、古いURLにアクセスしたユーザーがエラーページに遭遇することや、構造化データ（JSON-LD）の記述ミス、そしてサイトマップ（ウェブサイトのページ一覧）に存在しないURLが掲載され続けるといった問題も起こりうる。これらの問題は、ウェブサイトの表示や機能には影響しないため、手動でテストするだけでは発見が難しく、検索流入の減少といった形で気づく頃には手遅れになっていることが多い。

こうした事態を防ぐために、継続的インテグレーション（CI）パイプラインにSEOチェックを組み込むことが有効だ。CIパイプラインとは、開発者がコードを変更するたびに、自動的にビルド、テスト、デプロイといった一連の処理を実行する仕組みのことである。ここにSEOチェックを組み込むことで、問題が本番環境にデプロイされる前に、開発の早い段階で検出できるようになる。

しかし、すべてのSEOチェックを自動化すべきではない。自動化すべきは、結果が常に同じで、高速に実行でき、合否が明確に判断できるようなチェック項目だ。例えば、特定のタグが存在するかどうか、URLが正しいHTTPステータスコードを返すかどうかといったものだ。これらは、問題があればビルドを停止する「ゲート」として機能させるのに適している。一方、Lighthouseのパフォーマンススコアのように実行ごとに結果が変動したり、実際のユーザーの利用状況に依存したりするチェックは、ビルドをブロックするのではなく、継続的に「監視」する形で扱うのが良い。そして、コンテンツの品質やユーザーの検索意図、キーワードの選定、魅力的なタイトル作成といった、人間の専門的な判断が必要な項目は、自動化に任せるべきではない。

SEOチェックをCIパイプラインに組み込むには、主に四つの層で考えることができる。

最初の層は、「プルリクエストのゲート」だ。これは、開発者がコードの変更を提案するプルリクエストの段階で、ビルドされたHTMLファイルに対して基本的なSEOタグの不備や破損がないかをチェックする層である。このチェックは数秒で完了し、最終的に検索エンジンが見るであろうHTMLの出力に対して行われるため非常に重要だ。具体的なチェック項目としては、ページごとに重複せず、かつ適切な長さの「title」タグが一つだけ存在するかどうか、コンテンツの概要を説明する「meta description」が存在し、適切な長さであるか、そして正規のURLを示す「canonical」タグが本番環境の絶対URLを指しているか、誤って「noindex」タグが設定されていないか、h1タグが適切に配置されているか、HTML要素に言語を示すlang属性が付与されているか、画像に「alt」属性（代替テキスト）が設定されているか、Open Graphタグなどのソーシャルメディア用の情報が正しいか、そして構造化データ（JSON-LD）の構文が正しく、必要な項目が含まれているか、といった点が挙げられる。また、自サイト内のリンク切れがないかを確認することも、この段階でlycheeのようなツールをオフラインモードで実行することで高速に行える。この層で問題が発見されれば、開発者は本番環境にデデプロイする前に修正できるため、手戻りが少なくなる。

二つ目の層は、「主要テンプレートでのLighthouse CI」だ。Lighthouseはウェブページの品質を診断するGoogleのツールだが、すべてのページに対して実行すると時間がかかり、パフォーマンススコアも実行環境によって変動することがある。そのため、ウェブサイトの全ページではなく、ホームページ、記事ページ、サービスページなど、ウェブサイトを代表する３〜５つの主要なテンプレートに限定してLighthouseを実行するのが効果的だ。Lighthouseのレポートの中でも、SEOに関する項目は比較的決定論的（例えば、クロール可能なリンク、有効なhreflang属性、ドキュメントタイトルなど）なため、そのスコアが低い場合はビルドをエラーとして扱うことができる。一方で、パフォーマンスに関するスコアはCI環境の速度によって変動しやすいため、こちらは警告として扱い、ビルドを中断しないように設定するのが現実的である。複数回実行して中央値を採用することで、変動によるノイズを抑えることも可能だ。

三つ目の層は、「デプロイ直後の本番環境チェック」だ。開発中のコードでは検出できない、ライブサーバー特有の問題は少なくない。例えば、「robots.txt」ファイルの内容や、ウェブサーバーやCDN（コンテンツ配信ネットワーク）の設定で追加される「X-Robots-Tag」ヘッダーなどは、コードリポジトリではなくサーバー環境で管理されている場合がある。そのため、本番環境へのデプロイが成功した直後に、ライブサーバーに対してこれらの設定が意図しないものになっていないかをチェックすることが不可欠だ。具体的には、「robots.txt」がすべてのクローラーに対してウェブサイト全体をブロックする設定になっていないか、主要なページが「X-Robots-Tag」ヘッダーやメタタグで「noindex」を送信していないか、古いURLから新しいURLへのリダイレクトが正しく（恒久的な301または308リダイレクトで）設定されており、リダイレクト先のページが正しく表示されるか、そしてサイトマップに記載されているすべてのURLが正しく応答し、サイトマップに含まれるURLの総数が急激に減少していないか、といった点を検証する。これらのチェックを自動化するスクリプトは、デプロイ後のCIパイプラインの最終ステップとして実行される。

最後の層は、「スケジュール監視」だ。これは、開発サイクルとは独立して、定期的に実行されるチェックのことである。コードの変更とは直接関係なく発生する問題や、時間をかけて徐々に変化する問題に対応するために用いられる。例えば、外部サイトへのリンクが時間と共に切れ、404エラーを返すようになる「外部リンク切れ」のチェックは、オンラインモードのリンクリチェッカーで週に一度など定期的に実行されるべきだ。また、Google Chromeユーザーエクスペリエンスレポート（CrUX）APIを利用して、実際のユーザーが体験するウェブサイトの速度や安定性を示すCore Web Vitalsのフィールドデータ（実測値）を監視したり、Google Search Console APIを通じてインデックスカバレッジ（検索エンジンにインデックス登録されているページの割合）の変化を追跡したりすることもこの層の役割となる。これらの監視はビルドをブロックするものではなく、問題があれば関係者にアラートを出すことで、長期的な視点でのウェブサイトの健全性維持を支援する。

自動化はウェブサイトの技術的なSEOの土台を強固にするが、自動化すべきではない領域も存在する。コンテンツの品質やユーザーの検索意図に合致しているかといった本質的な部分、キーワードの選定戦略、魅力的なタイトルやメタディスクリプションの作成、そしてサイト全体の内部リンク構造の最適化といった領域は、依然として人間の専門家による判断と創造性が必要とされる。Lighthouseのパフォーマンススコアをすべてのページで厳格なゲートとして設定することも避けるべきだ。変動しやすいスコアでビルドが頻繁に失敗すると、開発チームはパイプラインを信頼しなくなり、結果的に本当に重要な問題も見過ごされる可能性が高まる。自動化はあくまで最低限の品質を保証する「フロア」を上げるものであり、優れたユーザー体験を生み出す「シーリング」を上げるのは人間の仕事だ。

CIパイプラインにSEOチェックを導入する際には、開発チームにスムーズに受け入れられるよう配慮が必要だ。最初はすべてのチェックを「警告」モードで実行し、既存の問題を修正する期間を設けるのが良い。その後、安定したチェック項目から「エラー」に昇格させていく。特定のページ（例えば404ページや検索結果ページ）は意図的にnoindexにすべきなので、そのような例外をリストアップする「許可リスト」を用意することも重要である。エラーメッセージは、どのページでどのようなルールに違反し、どのように修正すべきか具体的に示すことで、開発者が迅速に対応できるようになる。そして、各チェック項目には担当者を割り当て、ルールが誤って機能した際には誰が修正すべきか明確にしておくべきだ。

これらの多層的なSEOチェックをCIパイプラインに組み込むことで、システムエンジニアは開発プロセスの中でウェブサイトのSEO健全性を維持し、意図しない問題の発生を未然に防ぐことが可能となる。これは最終的に、検索エンジンからの評価を高め、ユーザーにとってより良いウェブサイトを提供するという目標達成に貢献する。