Vercel上のAdSense不調を切り分ける手順

広告が出なくなった直前にVercelやNext.jsの更新があっても、時間的な一致だけでは原因を確定できません。確認するべきなのは「どの環境の、どのURLで、何が読み込まれ、何が失敗したか」です。

この記事は、現在のVercelドメインを維持したまま、原因候補を一つずつ分ける手順です。広告表示や収益の回復を保証するものではありません。

1. 対象環境と変更点を固定する

VercelはLocal、Preview、Productionを別の環境として扱います。Vercelの環境説明を確認し、次を記録します。

• 問題が起きるProduction URL
• 正常だった最後のdeployment
• 問題が始まった最初のdeployment
• その間に変わったコード、環境変数、依存関係

Previewで広告を意図的に無効化しているなら、「Previewで広告が出ない」は不具合ではありません。ProductionとPreviewを混ぜて比較しないことが最初の切り分けです。

2. 初期HTMLとネットワークを別々に確認する

Productionの広告対象記事を一つ選び、ページソースと開発者ツールのNetworkを確認します。

1. AdSenseの外部スクリプトが初期HTMLまたは想定した時点で一度だけ要求される
2. publisher IDがサイトの設定と一致する
3. 同じスクリプトをlayoutとpageの両方で読み込んでいない
4. コンソールに初期化エラーがない

Next.jsのScriptは配置場所とstrategyで読込時期が変わります。公式のScript Component資料と実装を照合します。App Routerだから自動的に二重実行される、と決めつけてはいけません。

3. /ads.txtを独立して検査する

Googleのads.txtガイドに従い、登録サイトのルートにある/ads.txtを直接確認します。

curl -i https://対象ホスト/ads.txt

記録する項目は、最終HTTP状態、Content-Type、本文のpublisher ID、転送先です。HTMLのエラーページやログイン画面がHTTP 200で返っていないかも本文で確かめます。

4. robotsとAdSenseクローラーを確認する

GoogleはAdSenseクローラーを検索用クローラーとは別に説明しており、robots.txtの影響も受けます。AdSenseクローラの公式説明と/robots.txtを照合します。

• 広告対象ページを不意にブロックしていない
• ログインやCookie同意がないと本文へ到達できない構成ではない
• 広告コードを置いた正規URLがHTTP 200で本文を返す

canonicalやSearch Consoleの状態だけで、広告不調の原因と断定することはできません。

5. 一度に一要因だけ戻す

復元する前に、DBスキーマや外部サービスの設定が旧コードと互換かを確認します。デプロイを戻してもDBや外部設定は同時には戻りません。

正常だったdeploymentへ戻せる場合は、短時間の比較で「更新前は正常、更新後は失敗」を再現します。戻せない場合は、広告スクリプト、環境変数、middleware、ヘッダーの順に一要因ずつ比較します。

差分が見つかるまで複数の設定を同時に変えない方が、再現条件を失いにくくなります。

6. Vercelプランの条件を別問題として確認する

VercelのHobbyプラン資料は、Hobbyを非商用の個人利用向けと説明しています。AdSenseが技術的に読み込めることと、利用プランの条件を満たすことは別です。

収益化サイトが現在の契約条件に合うかは、最新のプラン文書と契約条件をサイト所有者自身で確認してください。この記事は契約上の判断を代行しません。

公開ホストを一つの記録で照合する

確認用メモには、AdSense登録ホスト、ブラウザーで開いた最終ホスト、VercelのProductionドメイン、ads.txt取得先を同じ行に並べます。Previewで正しくても登録ホストで認証画面になるなら、審査用公開状態の確認は終わっていません。

独自ドメインへ移す場合は、先に新ホストの本文・canonical・ads.txt・転送を確認し、その後にAdSense側の登録状態を確認します。旧URLを消すだけでは移行になりません。ドメイン購入やプラン変更の前に、現在の設定で何が満たせていないかを特定してください。

結論

「Vercelの更新が原因」という仮説は、deployment差分で再現できるまで仮説のままです。環境、実HTML、ネットワーク、ads.txt、クローラー、プラン条件を分けて記録すれば、修正対象をコード・配信設定・アカウント条件のどこに置くべきか判断しやすくなります。