ビルドは成功、でも SEO は壊れている：テストでは気づけないデプロイの落とし穴

金曜日にデプロイした。ビルドは成功し、テストも通り、プレビューも問題なく、サイトは誰が開いても正常に動いている。ところが3週間後、Google 経由の登録が3分の1も減っていることに誰かが気づく。

原因はたいてい小さなものです。レイアウトの1行、ステージング環境からコピーした設定、急いで追加したリダイレクト。訪問者が気づくものではなく、ビルドやテストが確認するものでもありません。どちらも、検索エンジンと同じ見方でページを見ていないからです。

この記事では、私たちがよく目にする変更と、それぞれの見分け方、そして本番へのデプロイのたびに行う短い確認手順をまとめました。

テストで見つからない理由 #

テストが確認するのは、ページが動くかどうかです。ボタンを押せば送信される、金額が合っている、ページが 200 を返す。一方、検索エンジンが読むのは別のもので、主に <head> の中身と、JavaScript が動く前にサーバーが送る HTML です。人にとっては完璧に動くページが、Google には「インデックスしないでください」と伝えていることもあります。

しかも、Google が教えてくれるのは遅れてからです。インデックスから外れたページは数日かけてアクセスを失い、Search Console に表示されるのはさらに数日後です。その頃には、原因の変更はほかのデプロイに埋もれています。

サイトは壊さずに検索だけを壊す8つの変更 #

1. ステージングから紛れ込んだ noindex #

SEO で最も高くつく1行です。

<meta name="robots" content="noindex">

よくある経路は、本番でも有効になっているステージング用の設定、環境変数がないときにこのタグを追加するコンポーネント、非公開ページからコピーしたテンプレートです。同じ指示は HTTP ヘッダーの X-Robots-Tag: noindex として送られることもあり、この場合はページのソースを見ても見つかりません。

2. 意図より広くブロックしている robots.txt #

ステージング用のつもりだった Disallow: / や、想定より多くのパスにかかってしまった新しいルールです。見た目以上に厄介な点が2つあります。robots.txt でブロックされたページはクロールされないため、Google はその中身も noindex も読めません。また、Google は robots.txt 内の noindex をサポートしていないので、そこに書いても効果はありません。

3. 別の場所を指している canonical #

canonical タグは、どのアドレスが正式なものかを Google に伝えます。デプロイ後、これが全ページでトップページを指していたり、my-project-git-main-team.vercel.app のようなプレビュー用のアドレスを指していたり、https:// ではなく http:// になっていたりすることがあります。Google は canonical を強いシグナルとして扱うため、誤っていると、検索順位が誰も訪れないアドレスに移ってしまうことがあります。

4. JavaScript の実行後にしか表示されないコンテンツ #

リファクタリングで商品一覧や記事本文の表示がサーバーからブラウザに移ると、見た目は同じでも、サーバーが送る HTML はほとんど空になります。Google も JavaScript を実行しますが、後回しになり、すべてを処理するとは限りません。見つけてほしい内容は、サーバーの HTML に含めておくのが確実です。

5. リダイレクトとステータスコード #

以前は 200 を返していたページが 404 を返すようになった、トップページにリダイレクトされるようになった、あるいは3回リダイレクトしてやっと目的のページに着く。恒久的な移転なら、最終的なアドレスへ 301 か 308 で1回で転送するのが正解です。5xx 系のエラーが何日も続くと、Google はクロールを減らし、やがてページをインデックスから外します。

6. ページが抜け落ちたサイトマップ #

新しいルーティングや CMS の変更によって、アクセスを集めている URL の一部がサイトマップから消えたり、リダイレクトするようになったアドレスが含まれたりします。サイトマップは順位を決める要素ではありませんが、Google が新しいページをすばやく知る手段であり、Search Console でページごとのインデックスの問題を確認する手がかりにもなります。

7. 初期値に置き換わったタイトル、説明文、見出し #

共通レイアウトが各ページのタイトルをサイト名で上書きするようになった、全ページに同じ説明文が入るようになった、といったケースです。1ページだけなら大した問題ではありませんが、アクセスの大半を集める20ページで起きれば実害が出ます。

8. 互いを指さなくなった言語版 #

複数言語のサイトでは、hreflang のリンクが、どの言語版を誰に表示すべきかを Google に伝えます。このリンクは相互でなければなりません。日本語のページが英語のページを指しているなら、英語のページも日本語のページを指し返す必要があります。ある言語の URL を変えるデプロイをすると、この対応が崩れ、Google が検索結果で違う言語のページを表示することがあります。

1ページを2分で確認する方法 #

抜き取りで確認するだけなら、ツールは要りません。ターミナルで次を実行します。

# Status code, redirects and the X-Robots-Tag header
curl -sIL https://www.example.com/pricing | grep -iE "^HTTP|^location|x-robots-tag"

# robots meta tag and canonical in the server HTML
curl -sL https://www.example.com/pricing | grep -ioE '<meta[^>]+robots[^>]*>|<link[^>]+canonical[^>]*>'

# robots.txt as it is now
curl -s https://www.example.com/robots.txt

主なコンテンツがサーバーの HTML に含まれているかを確かめるには、ページをページのソースを表示で開き（JavaScript 実行後のページを表示する検証ツールではありません）、本文中の一文を検索します。Search Console の URL 検査ツールを使えば、Google が取得・レンダリングしたページと、インデックス登録が許可されているかどうかを確認できます。

本番デプロイのたびに行う確認手順 #

すべてのページを手作業で確認するのは現実的ではないので、重要なページに絞ります。

1. 上位のページを書き出す。 Search Console で検索パフォーマンスを開き、過去3か月のページをクリック数順に並べて、上位10〜20ページを選びます。検索からのアクセスの大半はこれらのページです。
2. デプロイのたびに、そのページで上記の確認を行う。 ステータス、タグとヘッダーの noindex、canonical、タイトル、そしてサーバーの HTML に本文の一文が含まれているか。
3. ルーティング、CMS、フレームワークを変えたときは、robots.txt とサイトマップも確認する。
4. 各ページの「正常な状態」を記録しておく。 ステータスは 200、canonical は自分自身、タイトルは何か。記録があれば、変化にすぐ気づけます。
5. その後1週間は Search Console に注意を払う。 ページレポートと上位ページのクリック数に、見落とした問題が表れます。

この手順の大部分は、きちんとしたホームページの月額保守にも含まれています。違いはタイミングです。デプロイ直後に確認すれば、問題は1つのコミットを戻せば済む段階で見つかります。3週間分のアクセスを失ってからではありません。

Hawk Delta は、私たちが保守している Vercel のサイトでまさにこれを行うために作りました。本番へのデプロイのたびに重要なページを直前の正常なバージョンと比較し、何が壊れたか、どれだけの検索流入に影響するか、どう直せばよいかをメールでお知らせします。現在、無料のプライベートベータを実施しています。