Vercelの自動生成ドメインがGSCの参照元に117本入っていた──*.vercel.appと「Duplicate, Google chose different canonical than user」を全351記事で実測

Vercelにデプロイしているサイトには、独自ドメインとは別に <project-name>.vercel.app という自動生成ドメインが付いてくる。これはデフォルトで誰でもアクセスでき、そこで配信されるHTMLの rel="canonical" は独自ドメイン側を指している。 その結果、Google Search ConsoleのURL Inspection APIで独自ドメインのURLを調べると、referringUrls（そのURLにリンクしている既知のURL）に自動生成ドメインが並ぶ。当サイトの記事を2026年8月14日に全数検査（検査時点で351本）したところ、referringUrls に現れたURLは延べ282件で、その内訳は www.ai-jitan-hub.com 124件 / ai-jitan-hub.vercel.app 117件 / apex（ai-jitan-hub.com）41件だった。対処は、自動生成ドメインへのアクセスを独自ドメインへリダイレクトするか、独自ドメイン以外のホストで noindex を返すこと。ただし先に書いておくと、この記事は「vercel.appが正規URLを奪った」ことを証明していない。実測値を並べたうえで、自分のデータでは因果が確認できなかったところまでを書く。

3行まとめ

1. 全351記事の referringUrls を集計すると、ai-jitan-hub.vercel.app が117件（保存が各記事先頭3件までなので下限値）。しかもその117件はすべて別々のURLで、**全部が「その記事自身のURLのvercel.app版」**だった（www側の124件は、実体は21種類のURLの重複カウント）
2. Duplicate, Google chose different canonical than user と判定された2本は、どちらも参照元がvercel.appの1本だけ。Googleが選んだ正規URLはapex、サイトが宣言した正規URLはwwwで、2本とも同じ形
3. ただし公開日コホートで割ると差は消える。2026-07-09以前のコホートでは、vercel.app参照なしが21/167＝12.6%、ありが10/84＝11.9%。vercel.app参照の有無でインデックス率はほぼ動かない

症状

1. GSCの参照元に、身に覚えのないドメインが並ぶ

URL Inspection API（POST https://searchconsole.googleapis.com/v1/urlInspection/index:inspect）の結果から、当サイトでは inspectionResult.indexStatusResult の必要なフィールドだけを抜き出して保存している。その実データの1レコードがこれだ（値は書き換えていないが、キー名は保存時に付け替えている。APIの生レスポンス側は verdict / coverageState / lastCrawlTime / robotsTxtState / googleCanonical / userCanonical / referringUrls）。

{
  "slug": "glm-5-2-zhipu-1m-context-open-source",
  "coverage": "Duplicate, Google chose different canonical than user",
  "verdict": "NEUTRAL",
  "lastCrawl": "2026-07-20T04:56:26Z",
  "robots": "ALLOWED",
  "canonicalGoogle": "https://ai-jitan-hub.com/news/glm-5-2-zhipu-1m-context-open-source",
  "canonicalUser": "https://www.ai-jitan-hub.com/news/glm-5-2-zhipu-1m-context-open-source",
  "referring": [
    "https://ai-jitan-hub.vercel.app/news/glm-5-2-zhipu-1m-context-open-source"
  ]
}

検索で貼られる文字列はここだと思うので、独立して置いておく。

Duplicate, Google chose different canonical than user

日本語版のヘルプでは「重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」と表記されている項目にあたる。verdict は NEUTRAL＝Search Console上の「除外」だ。

2. ホスト別に集計すると、自動生成ドメインの多さが見える

351件のレコードに含まれる referringUrls を全部ばらして、ホスト別に数えた結果がこれ（2026-08-14取得）。ここで先に断っておくと、取得スクリプトは referringUrls を各記事の先頭3件までしか保存していない（referring=s.get("referringUrls", [])[:3]）。したがって以下の件数はすべて下限だ。保存件数の内訳は0件141本・1件149本・2件50本・3件11本で、切り捨てが起きうるのは上限に当たっている11本だけである。

同じ「100件超」でも中身がまったく違う。www側の124件は、実体は21種類しかない（/news が41回、/guides が28回、/（トップ）が24回といった一覧ページの重複カウント）。対してvercel.app側は117件が117種類、つまり1本ずつ違うURLだ。

そして中身を見ると、117件すべてが https://ai-jitan-hub.vercel.app/news/<検査対象と同じslug> だった。例外は0件。「自分自身のvercel.app版」が、自分の参照元として記録されている。

referringUrls を「その記事自身のvercel.app版だけ」しか持たない記事は85本ある（351本中）。参照元が1件も無い記事は141本だった。

3. 自動生成ドメインは、普通に200で配信されている

$ curl -s -o /dev/null -w "%{http_code} %{size_download}\n" \
    https://ai-jitan-hub.vercel.app/news/glm-5-2-zhipu-1m-context-open-source
200 278645

レスポンスヘッダーに x-robots-tag は無く、HTMLに <meta name="robots"> も無い。robots.txt は独自ドメイン側と1バイト違わない。

$ curl -sL https://ai-jitan-hub.vercel.app/robots.txt
User-Agent: *
Allow: /

Host: https://www.ai-jitan-hub.com
Sitemap: https://www.ai-jitan-hub.com/sitemap.xml

同じホストで配信されている sitemap.xml の <loc> も、全部 https://www.ai-jitan-hub.com/... を指している。「自分は www が本体です」と自己申告しながら、自分自身は誰でも取れる状態で立っている、というのが症状の全体像だ。

原因

自動生成ドメインは「デフォルトで公開」と公式に書いてある

Vercelの Generated URLs のドキュメント（Last updated September 24, 2025）にこうある。

When you create a new deployment in either a preview or production environment, Vercel will automatically generate a unique URL in order for you to access that deployment. (中略) This URL is publicly accessible by default, but you can configure it to be private using deployment protection.

（訳：プレビュー環境でも本番環境でも、新しいデプロイを作成するとVercelはそのデプロイにアクセスするための一意なURLを自動生成する。このURLはデフォルトで公開されているが、deployment protection を使って非公開に設定できる。）

同じページには、Vercel CLIから作られるURLの構造も書かれている。

To access the URL for a successful deployment from Vercel CLI, you can save the standard output of the deploy command. The generated URL will have the following structure: <project-name>-<scope-slug>.vercel.app Once you deploy to the production environment, the above URL will point to the production deployment.

（訳：Vercel CLIから成功したデプロイのURLを取得するには、デプロイコマンドの標準出力を保存すればよい。生成されるURLは <project-name>-<scope-slug>.vercel.app の構造を持つ。本番環境にデプロイすると、上記のURLは本番デプロイを指すようになる。）

ここで注意。当サイトのホストは ai-jitan-hub.vercel.app で、上の引用にある <scope-slug> が付かない短い形だ。この形については別ページに書かれている。

When you create a deployment on Vercel, we automatically assign it a domain based on your project name and ending in .vercel.app.

（訳：Vercelでデプロイを作成すると、プロジェクト名に基づく .vercel.app で終わるドメインが自動で割り当てられる。）

「プレビュー用ドメイン」という言い方は、この件では正確でない

*.vercel.app は「プレビュー用のURL」として語られることが多いが、当サイトで参照元に出ているのは ai-jitan-hub.vercel.app ——プロジェクト名だけの形で、本番デプロイを指すエイリアスだ。これは推測ではなく、こちらのコードから逆算して確認できる。当サイトの src/app/robots.ts は、VERCEL_ENV が production でない限り disallow: / を返す実装になっている。

  const isProduction = isPublicCrawlEnvironment({
    vercelEnvironment: process.env.VERCEL_ENV,
    nodeEnvironment: process.env.NODE_ENV,
  });

  if (!isProduction) {
    return {
      rules: { userAgent: "*", disallow: "/" },
    };
  }

つまり ai-jitan-hub.vercel.app/robots.txt が Allow: / を返している時点で、そのホストを配信しているのは VERCEL_ENV=production のデプロイである（VERCEL_ENV はVercelのシステム環境変数で、公式ドキュメントには "Available at: Both build and runtime"、値は production / preview / development のいずれかと書かれている。ただし上の実装は VERCEL_ENV が空のとき NODE_ENV にフォールバックするので、厳密にはその経路も理屈上は残る）。プレビュー抑止のガードは効いているのに、そのガードの対象外に自動生成ドメインが居る、という構図になる。

もう一段、推論に頼らない裏付けも取れた。キャッシュ回避クエリを付けて両ホストの同じページを取ると、Next.jsが埋め込むビルドID（RSCペイロードの b）が HkJ_bBenukNAKhM5Y8rts で一致する。記事ページ・/news・トップの3経路で一致を確認した（2026-08-14実測）。独自ドメインと自動生成ドメインは、同じ本番デプロイを配信している。 なお最初に取ったときはvercel.app側だけ x-vercel-cache: HIT で別のビルドIDが返ったので、この確認はキャッシュを外さないと誤った結論になる。

Deployment Protection のドキュメントもこの構図と整合している。

Standard Protection: Protects all deployments except production domains.

（訳：Standard Protection は、本番ドメインを除くすべてのデプロイを保護する。）

On the Hobby plan, Vercel Authentication with Standard Protection is available. This protects your preview deployments and deployment URLs, but your production domain remains publicly accessible. To protect production domains, you need a Pro or Enterprise plan.

（訳：HobbyプランではStandard ProtectionによるVercel Authenticationが利用できる。これはプレビューデプロイとデプロイURLを保護するが、本番ドメインは公開されたままになる。本番ドメインを保護するにはProまたはEnterpriseプランが必要。）

Googleは「デモ環境がクローラーに開いたまま」を重複の原因として名指ししている

Google検索セントラルの canonicalization のドキュメント（Last updated 2026-07-10 UTC）は、重複コンテンツが生まれる理由を列挙するなかで、これを挙げている。

Accidental variants: for example, the demo version of the site is accidentally left accessible to crawlers

（訳：偶発的なバリアント：たとえば、サイトのデモ版がうっかりクローラーからアクセス可能なまま残されている場合）

そして正規URLの選定については、こう書かれている。

There are a handful of factors that play a role in canonicalization: whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel="canonical" link annotations. You can indicate your preference to Google using these techniques, but Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule.

（訳：正規化には、HTTPかHTTPSか、リダイレクト、sitemapへのURLの掲載、rel="canonical" のリンクアノテーションといった、いくつかの要因が関与する。これらの手法でGoogleに希望を伝えることはできるが、さまざまな理由でGoogleがあなたとは違うページを正規URLとして選ぶことがある。つまり正規URLの指定はヒントであってルールではない。）

Search Consoleヘルプ側の該当項目の定義も引いておく。

Duplicate, Google chose different canonical than user This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical. Google has indexed the page that we consider canonical rather than this one.

（訳：このページは一群のページの正規URLとして指定されているが、Googleは別のURLのほうが正規URLとして適切だと判断している。Googleは、このページではなく我々が正規と考えるページをインデックスしている。）

referringUrls は「リンク」だが、本文リンクとは限らない

URL Inspection APIのリファレンスは、各フィールドをこう定義している。

referringUrls[] — URLs that link to the inspected URL, directly and indirectly. googleCanonical — The URL of the page that Google selected as canonical. If the page was not indexed, this field is absent. userCanonical — The URL that your page or site declares as canonical. If you did not declare a canonical URL, this field is absent.

（訳：referringUrls[]＝検査対象URLに直接的および間接的にリンクしているURL。googleCanonical＝Googleが正規として選択したページのURL。ページがインデックスされていない場合、このフィールドは存在しない。userCanonical＝あなたのページまたはサイトが正規として宣言しているURL。正規URLを宣言していない場合、このフィールドは存在しない。）

ここは注意が要る。vercel.appで配信されているページのHTMLを実際に取って数えると、https://www.ai-jitan-hub.com を含む絶対URLは49箇所ある一方、www宛ての <a href> は0件だった。49箇所の内訳は <link rel="canonical">、<meta property="og:url">、JSON-LDの mainEntityOfPage.@id とBreadcrumbListの item、og:image などで、すべてhead側のアノテーションだ。

つまりGoogleが「リンク」として数えたのがどのアノテーションなのかは、外からは決められない。定義に "indirectly" と書いてあるとおりだ。「vercel.app版のページがwww版のURLを指している」ことは確認できるが、「Googleが正規URL選定でそれをどう使ったか」は確認できていない。

対処

以下は「取りうる手」であって、当サイトで適用して効果を確認したものではない（記事執筆時点で未適用・未検証）。

1. 自動生成ドメインを独自ドメインへリダイレクトする

当サイトの next.config.ts には、apex → www の308恒久リダイレクトがすでに入っている。

{
  source: "/:path*",
  has: [{ type: "host", value: "ai-jitan-hub.com" }],
  destination: "https://www.ai-jitan-hub.com/:path*",
  permanent: true,
}

同じ形をvercel.appのホストにも書ける。ただし、この方式は自分のプロジェクトの自動生成ドメイン名をコードに直書きすることになるうえ、プレビューデプロイ（ハッシュ付きの別ホスト名）には当たらないので、狙ったホストだけを止められているかを実際のホスト名で確認する必要がある。

2. 独自ドメイン以外のホストでは noindex を返す

X-Robots-Tag: noindex をホスト条件付きで返す方式。リダイレクトと違い、vercel.appのURLを自分の動作確認用に開いたままにできる。当サイトの robots.ts はすでに VERCEL_ENV で分岐しているが、この分岐は環境（production / preview）を見ていてホストを見ていないので、本番デプロイが配信する限りvercel.appでも Allow: / になる。ホストで分けたいならホストを見る必要がある。

3. Deployment Protection

前掲のとおり、Standard Protection は本番ドメインを対象外にする。本番ドメインまで保護するにはProまたはEnterpriseプランが要る、と公式に書かれている。

4. 何もしない

これも選択肢として残しておく。後述するとおり、当サイトのデータでは vercel.app 参照の有無とインデックス率のあいだに差が見えなかった。

踏んだ記録

いつ・どの環境で

• 計測日：2026年8月14日
• 環境：macOS 15.1.1（Darwin 24.1.0）、curl 8.7.1
• データ：Search Console URL Inspection API を全記事に対して1本ずつ叩いた結果351件（data/gsc/full-inspect-2026-08-14.json）。本文中の集計は、このJSONを自分で読んで数え直したもの
• 対象プロパティ：https://www.ai-jitan-hub.com/

全体のインデックス状態（351本）

googleCanonical と userCanonical の両方が入っていたレコードは102件。そのうち両者が食い違っていたのは3件だけだった。

重複判定の2本は、参照元がどちらも https://ai-jitan-hub.vercel.app/news/<slug> の1本だけで、形がまったく同じだった。

3本目の fable5-game-built-in-2days は逆向きで、しかも正常にインデックスされている。最終クロールが2026年6月13日——当サイトがapex → wwwの308リダイレクトを入れたコミット 8bc70bf（2026-07-10 11:49:01 +0900）より前だ。userCanonical は「いまのページの宣言」ではなく「最後にクロールされた時点でGoogleが見た宣言」であることが、このレコードから読める。

なぜCLIから直接デプロイしている環境なのか

このリポジトリは git remote -v の出力が空で（remote数0、ブランチ main）、Vercel関連は .vercel/ に project.json とVercel CLIが置く README.txt があるだけだ。Git連携ではなくVercel CLIがワークツリーから直接デプロイする構成で、next.config.ts のコメントにも「デプロイはワークツリーから直接行うため、未コミット状態でも一度は本番に出ていた可能性がある」と残っている。Environments のドキュメントにあるとおり、--prod を付けないCLIデプロイはプレビュー、付けたものは本番になり、本番デプロイが成功するとVercelが本番ドメインを新しいデプロイに向け直す。

因果を主張できない理由（ここが一番大事）

素の数字だけ見ると、vercel.app参照の有無で差があるように見える。

ただしこの差の向きは「vercel.app参照があるほうがインデックスされている」で、直感と逆だ。当サイトの別の実測では、インデックス率を最もよく説明したのは公開日（2026-07-10のapex → www移行を挟んだコホート）だった。そこで公開日で層別すると、差はほぼ消える。

コホート内で見ると、vercel.app参照の有無でインデックス率はほとんど動かない。 全体で35.9%対24.8%に見えたのは、コホートの構成比の違いによる見かけ上の差だった。

重複判定については、たしかに2本とも「参照元がvercel.appだけ」という形をしている。ただし同じ形の記事は85本あり、そのうち83本は重複判定になっていない（85本の内訳は、検出のみ69本、インデックス済み14本、重複2本）。n=2で構造を語ることはできない。

したがってこの記事が言えるのは、ここまでだ。

• 自動生成ドメインが素で200を返し、referringUrls に117本入っている（事実・実測）
• 重複判定の2本は、どちらも参照元がvercel.appの1本のみで形が同じ（事実・実測）
• vercel.app参照がGoogleの正規URL選定を非wwwに寄せた（確認できていない）

正直な但し書き

• 因果は確認できていない。 上記のとおり、コホート内での差は見えなかった。重複2本の共通点も、同じ形の非重複83本の存在で相殺される
• referringUrls の中身の解釈が確定していない。 Googleがどのアノテーション（canonical / og:url / JSON-LD）を「リンク」として数えたかは、APIのレスポンスからは分からない。定義は "directly and indirectly" とだけ書かれている
• Googleが選んだ正規URLがなぜapexなのかは分からない。 2026-08-14時点でapexは308でwwwへ恒久リダイレクトしており（curl -sI で確認）、そのうえで googleCanonical にapexが残っている。移行前の判断が残っているのか、別の理由なのかを外から確定させる手段を持っていない
• referringUrls は各記事の先頭3件までしか保存していない。 本文の参照元の件数はすべて下限である。上限に当たっているのは11本で、そのうち4本は保存された3件にvercel.appが含まれていない（anthropic-open-weights-position / claude-fable-5-complete-guide / kimi-k3-open-weights-inside / weekly-ai-news-2026-07-5）。最悪ケースとしてこの4本すべてが実際にはvercel.app参照ありだったと仮定しても、2026-07-09以前のコホートは「なし12.0%（20/166）対 あり12.9%（11/85）」で、差が消えるという結論は変わらない
• サイトが1つ、時点が1つしかない。 351件は全数だが、それは1サイトの全数であって、Vercelを使う他のサイトに一般化できる標本ではない
• 対処案は未検証。 リダイレクトも noindex も、この記事の執筆時点では当サイトに適用していない。効果を測ったら別途追記する
• Deployment Protection のプラン条件は公式ドキュメントの記述であり、当サイトの契約プランでの挙動を試したわけではない

なお、公開時点で「vercel.app canonical」「vercel.app インデックス」「vercel.app 正規URL」「vercel canonical」は、いずれもGoogleサジェスト（hl=ja）で候補が0件だった（対照として「vercel.app」単体は10件、「canonical」単体も10件返る）。日本語で誰も書いていない、というより、そもそも誰も検索していない領域である可能性のほうが高い。

Vercelのデプロイまわりの手順はVercelデプロイのエラーを減らす個人開発チェックリストに、apex → wwwの308リダイレクトを診断コマンド側が読み違えた件はcurlに-Lを付けずに308を叩くと15バイトの「Redirecting...」が返るにまとめている。

出典

• Accessing Deployments through Generated URLs（Vercel Docs）
• Deployment Protection on Vercel（Vercel Docs）
• Environments（Vercel Docs）
• Working with Domains（Vercel Docs）
• System Environment Variables（Vercel Docs）
• Method: index.inspect（Search Console API）
• UrlInspectionResult（Search Console API）
• ページ インデックス登録レポート（Google Search Console ヘルプ）
• What is canonicalization（Google 検索セントラル）