Vercelの変更が反映されないとき｜URL・コミット・キャッシュの確認順

Vercelへデプロイした変更が見えないときは、再デプロイを繰り返す前に「見ているURL」「配信中のコミット」「古いのがHTMLかデータか」を確認します。ビルド成功と、本番ドメインがその成果物を配信していることは別です。

URLとコミットを一組で記録する

Vercelのデプロイ管理を開き、対象のDeployment、Gitコミット、環境、本番ドメインの割当を確認します。プレビューのURLだけを確認して本番反映済みとしないでください。

確認時刻:
本番URL:
期待するコミット:
実際に割り当てられたDeployment:
変更が分かる本文の一文:

本番URLとDeployment固有URLで同じ一文を探します。固有URLだけが新しいなら、本番への割当や昇格を確認する段階です。

古い場所で次の操作を選ぶ

取得内容を確認する例です。example.comは自分のURLへ置き換えます。

curl -i https://example.com/

ステータスだけでなく、本文の変更点、Cache-Control、転送先を記録します。共有したログへCookieや認証ヘッダーを含めないでください。

ブラウザーだけ古い場合

別のブラウザープロファイルで同じURLを開きます。Service Workerを使うサイトでは、以前の配信が残っていないか開発者ツールで確認します。サイトデータの削除は保存済み入力やログイン状態も消す可能性があるため、先に必要なデータを保存します。

データだけ古い場合

取得先そのものが新しい値を返すか確かめてから、使用中のNext.jsバージョンのキャッシュ設定を確認します。HTMLのキャッシュとデータのキャッシュを同一視せず、Next.jsのキャッシュ資料で採用している仕組みを照合します。理由なく全データをキャッシュ無効にすると、負荷と速度も変わります。

戻す前に影響範囲を確認する

直前のDeploymentへ戻す場合も、DB変更や外部設定が同時に戻るとは限りません。比較用のURLで確認できるなら先に比較し、本番を戻すときは互換性を確認します。

修正後は最初に記録した本番URLで変更文と主要操作を再確認します。URL・コミット・観測結果を残すことで、次に同じ症状が出てもキャッシュ削除からやり直さずに済みます。