SEO・技術
Vercel dplと
検索インデックス
— Skew Protection の副作用と、next.config.ts での対処
Vercel にデプロイしたサイトで、アセットのURLに ?dpl= というパラメータが付くことがあります。これは Skew Protection という有用な機能によるもので、正常な挙動です。ただし副作用として、デプロイのたびに中身が同じアセットが「別のURL」として発行され、Google Search Console（GSC）の「クロール済み - インデックス未登録」に積み上がることがあります。
この記事は、その仕組みと、当社サイトで実際に行った Next.js / Vercel 固有の技術対処に絞って整理します。GSCの「クロール済み - インデックス未登録」を調べる手順の全体像は、兄弟記事「クロール済み - インデックス未登録の調べ方」にまとめています。本記事は、原因が ?dpl= だと分かった後の直し方を扱います。
この記事の要点
Skew Protection はデプロイ間のバージョン整合を守る有用な機能で、?dpl= の付与は正常な挙動です。副作用として、同一アセットがデプロイごとに別URL化し、GSCの「クロール済み - インデックス未登録」に積み上がることがあります。
増えているのはアセットURLで、実際のコンテンツページではありません。当社の実測では、1,000件サンプルのうち実コンテンツページは1件のみでした。数（総件数）に驚く前に、失っている検索露出の大きさを見ます。
対処は、これらのアセットに X-Robots-Tag: noindex を付けることです。robots.txt の Disallow ではなく noindex を使うのは、レンダリングに必要なフェッチを妨げないためです。next.config.ts の headers() に設定します。
— 01
Skew Protection と ?dpl= の役割
新しいデプロイを公開すると、ページを開いたままのユーザーが手元では古いHTMLを表示していることがあります。その状態で新しいデプロイのJSやCSSを取りに行くと、バージョンがずれてエラーになることがあります。Skew Protection は、このずれ（skew）を防ぐ機能です。
仕組みとしては、各リクエストがどのデプロイのものかを ?dpl=<デプロイID> という形でアセットURLに添えて、その閲覧が始まったときのバージョンのアセットへ確実に到達できるようにします。デプロイをまたいでも表示が壊れないための、意図された正常な挙動です。この機能自体は、公開を頻繁に行うサイトの安定性に寄与します。
— 02
なぜGSCに別URLとして積み上がるのか
中身が同じアセットでも、?dpl= の値はデプロイごとに変わります。Googleから見ると、デプロイのたびに「新しいURL」が発行されているのと同じです。Googleはそれをクロールし、内容としてインデックスするほどではないと判断して「クロール済み - インデックス未登録」に分類します。デプロイ回数に比例して増えるため、放置しても自然には減りにくい性質があります。
| URLの種類 | 件数 | 比率 |
|---|---|---|
| JSバンドル（/_next/static/chunks） | 639件 | 63.9% |
| フォント等（/_next/static/media） | 288件 | 28.8% |
| favicon.ico の別URL | 70件 | 7.0% |
| opengraph-image ルート | 2件 | 0.2% |
| 実際のコンテンツページ | 1件 | 0.1% |
これは当社サイト（netsujo.jp）のGSCで、「クロール済み - インデックス未登録」のドリルダウンCSV1,000件サンプルを実測した内訳です（2026-07-21）。1,000件中994件が ?dpl= を含み、ユニークなデプロイIDは100個でした。対処前には、本番HTML全体で ?dpl= が163箇所出現していました。別サイト（miyakodeit.com）でも、同種のアセットURLが83件蓄積していることを確認しています。
ここで大切なのは、増えているのはアセットのURLであって、実際のコンテンツページではないという点です。1,000件のうち実コンテンツページは1件だけでした。総件数の大きさそのものは、検索での損失の大きさとは一致しません。損失の測り方は、この記事の最後で扱います。
— 03
検出はドリルダウンCSVから始める
原因を ?dpl= だと特定するには、未インデックスURLの母集団を実際に見る必要があります。ここには落とし穴があります。
GSCの Search Analytics API は、表示回数（impressions）が0より大きいURLしか返しません。アセットURLには通常 impressions が付かないため、API経由では ?dpl= 付きURLがそもそも見えません。APIで見える範囲だけを調べると、母集団に含まれない別の原因（古いCMS由来のURLなど）を主犯と取り違えてしまいます。当社でも一度、この見落としで原因の特定を誤りました。
正しい手順は、GSCの管理画面で「クロール済み - インデックス未登録」の行をクリックして開き、ドリルダウンCSV（最大1,000件）をエクスポートして、URLの中身を直接確認することです。?dpl= を含むアセットURLが支配的であれば、原因はSkew Protectionの副作用だと判断できます。この調べ方の全体像（他の分類理由の切り分けを含む）は、兄弟記事に譲り、本記事は ?dpl= と分かった後の対処に進みます。
— 04
next.config.ts での対処
これらのアセットは、そもそも検索インデックスに載せる必要がありません。方針は、robots.txt でクロールを止めるのではなく、X-Robots-Tag: noindex でインデックス対象からだけ外すことです。robots.txt の Disallow はクロール自体を止めてしまい、ページのレンダリングに必要なアセット取得まで妨げるおそれがあります。noindex はフェッチを妨げないため、表示への影響なくインデックスからのみ除外できます。
/_next/static/:path*
JS・CSS・フォントなどビルドアセット全般。?dpl= が付くURLの大半（実測で約93%）がここに含まれます。
favicon.ico / icon.png / apple-icon.png / icon.svg
上の /_next/static/ ルールの対象外だったため、個別ルールで補いました。ドリルダウン実測で favicon が7.0%（70件）を占めていたためです。
/:path*/opengraph-image
OG画像ルートも ?dpl= で別URL化されます。同じく個別ルールで noindex を付けています。
netsujo-web.vercel.app（ホスト単位）
Vercelのデプロイ用ドメイン全体を noindex にし、本番ドメインとは別URLでインデックスされないようにしています。
当社の next.config.ts では、これらを headers() の中で X-Robots-Tag: noindex として付与しています。最初は /_next/static/ だけを対象にしていましたが、ドリルダウン実測で favicon（7.0%）と opengraph-image（0.2%）が対象外だと分かり、個別ルールを追加しました。
注意したいのは、これはURLを即座に消す対処ではない点です。noindex ヘッダを読んだGoogleが、次にそのURLを再クロールしたときにインデックス対象から外します。したがって効果は、新規の発生を止めることと、既存分が再クロールに伴って徐々に別バケットへ移ることの2段階で現れます。
— 05
対処後に何を観測するか
対処が効いているかは、総件数の増減だけでは判断できません。次の順で確認します。
- 1本番HTMLから ?dpl= が消えているか：本番のトップ・/blog・/services/signal の各HTMLで ?dpl= の出現数を数えます。当社では対処後、これらのページで0箇所を確認しました（対処前は本番HTML全体で163箇所）。
- 2アセットのレスポンスヘッダに noindex が付いているか：/_next/static/ 以下のアセットへリクエストし、レスポンスに X-Robots-Tag: noindex が返るかを確認します。ヘッダが付いていれば、Googleは再クロール時にインデックス対象から外します。
- 3新規の ?dpl= クロールが止まっているか：GSCのクロール記録で、?dpl= 付きURLの最終クロール日が更新されていないかを見ます。当社の観測範囲では、対処後の2026年7月7日を最後に新規のクロールが止まっています。
- 4GSCのバケット間で移動が起きているか：再クロールが進むにつれ、既存の ?dpl= 付きURLは「クロール済み - インデックス未登録」から「noindex タグによって除外」へ移っていく見込みです（当社でも移動と整合する推移を観測していますが、件数の因果までは確定していません）。総数ではなく、この移動が始まっているかを見ます。
総件数をKPIにしない
「クロール済み - インデックス未登録」の総数（当社では約1,437件）を成果指標にすると、判断を誤ります。検索露出への実害は、未インデックス扱いかつ過去に表示回数のあるURL（＝影響候補）で見るのが実態に近い測り方です。当社の実測では該当42件・548 impressions で、サイト全体の表示回数の約0.63%にとどまりました。見るべきは総件数ではなく、サイトマップ掲載ページのインデックス率と、表示回数がありながら未インデックスになっているページの数です。
この記事の著者
飯田 友広
代表取締役
Netsujo株式会社 代表取締役。京都発のWeb3・AI実装スタートアップを2023年6月に創業。Webサイトを営業基盤として捉え、経営・営業・検索・生成AI・コンバージョン・計測を横断して課題と改善優先順位を整理する「Netsujo SIGNAL」を設計・運営。京都ビッグデータ活用プラットフォーム参画(小規模企業会員・ベンチャー)、同プラットフォーム発のワーキンググループ「Chain Up KYOTO」参画(2026-03-10)、IVS2026サイドイベント「なぜ京都でWeb3.0ビジネスなのか」を京都府庁旧議場で開催(2026-07-02・Netsujoとして主催、企画・登壇・運営／京都府デジタル政策推進課は共催)。京都美術工芸大学での講義・龍谷大学でのセミナー実績、ITコミュニティ「みやこでIT」(connpassメンバー609名・イベント162回以上・2019年2月から運営)運営。NPO法人NEMTUS理事、BAR KRYPTO運営。ソーシャル企業認証「S認証」認証企業(2026年2月認証・2026年4月公表)。技術領域はWeb3/ブロックチェーン/DID/NFT/生成AI/コミュニティ運営。
プロフィールを見るこの記事が向いている方
Next.js を Vercel で運用し、GSCの「クロール済み - インデックス未登録」が増えている担当者・ITエンジニア
?dpl= 付きのアセットURLがGSCに大量に出ていて、対処すべきか判断したい方
未インデックスの総件数に驚いたが、どこまでが実害かを切り分けたい方
— 壁打ち相談
読者のよくある相談
記事を読んだ後に「自分の状況だとどう判断すべきか」を整理するための壁打ち相談を受け付けています。下記のような相談例が当てはまる方は、お気軽にご連絡ください。
Q. うちのサイトでも ?dpl= が原因か、どう確かめればよいですか？
GSCのドリルダウンCSVを取得し、?dpl= を含むアセットURLが支配的かを確認します。API経由では見えない点に注意します。
Q. noindex を入れれば総件数はすぐ減りますか？
すぐには減りません。新規発生が止まり、再クロールに伴って既存分が別バケットへ移る、という段階的な効果になります。
Q. 未インデックスが1,000件超あります。放置して大丈夫ですか？
総件数ではなく、失っている検索露出の大きさで判断します。実害の範囲を一緒に切り分けます。
上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。
Web営業基盤｜Netsujo SIGNAL
自社サイトの現状を、まず無料で確認する
無料診断でAI可視性スコアの参考値と根拠付きの最優先課題3件を確認できます。GA4・Search Consoleの共有は不要です。検索順位やAI回答への掲載を保証するものではありません。