Vercel DNSでSearch Consoleの所有権を確認する
この記事で学べること
- ドメインの登録事業者と、現在のDNS管理先を区別する方法
digまたはWebの確認ツールで権威ネームサーバーを特定する手順- Vercel DNSへSearch ConsoleのTXTレコードを追加し、公開DNSで確認する方法
- 既存のTXTレコードを残したまま追加するときの注意点
- 確認用の値を原稿や共有ログへ露出させずに作業するためのチェックリスト
TXTレコードを追加してもSearch Consoleで確認できなかった原因
Search Consoleの所有権確認では、確認用のTXTレコードを追加しても、設定した場所が現在のDNS管理先でなければ公開DNSへ反映されません。ドメインを購入した会社とDNSレコードを管理するサービスが異なる場合、正しい値を入力していても確認が通らないことがあります。
国内レジストラで取得したailearnplay.comとailearnplay.onlineを設定したとき、私は最初にレジストラ側へTXTレコードを追加しました。しかし、両ドメインのネームサーバーはVercelへ切り替えていたため、その設定は公開DNSの回答へ反映されませんでした。
Vercel側へ同じ確認用レコードを追加すると、Search Consoleで所有権を確認できました。この経験から、値だけでなく「どのDNSへ追加するか」を最初に確かめる必要があると分かりました。
この記事では、外部レジストラで取得し、DNSをVercelへ委任しているドメインに焦点を当てます。権威ネームサーバーの特定から、Vercel DNSへのTXTレコード追加、公開DNSへの反映確認、Search Consoleでの再確認までを順に説明します。
最後まで読むと、TXTレコードを追加すべき場所を自分で判断し、所有権確認が通らない原因を切り分けられるようになります。ドメインの移管や、Webサイト自体をVercelへ移行する手順は扱いません。
レジストラと権威ネームサーバーは異なる役割を持つ
ドメインの登録事業者（レジストラ）は、ドメインの登録と更新を担当します。権威ネームサーバーは、そのドメインの接続先やTXTレコードについて、インターネットへ正式な回答を返すサーバーです。Vercelも、ネームサーバーをDNSレコードの保持・管理先と説明しています。[2]
外部レジストラで購入したドメインでも、ネームサーバーを次の2つへ変更していれば、DNSレコードの管理先はVercelです。[2]
ns1.vercel-dns.com
ns2.vercel-dns.comこの状態では、レジストラの別のDNS編集画面へTXTを追加しても、インターネットへ返される情報は変わりません。ただし、レジストラ側でのネームサーバー指定や登録情報は引き続き必要です。現在の管理先ではない画面へ追加したレコードだけが反映されない、という切り分けになります。
最初に確認する対象は、サイトのホスティング先でも購入先でもなく、現在の権威ネームサーバーです。ここを特定すると、TXTレコードを追加すべき管理画面が決まります。
Search Consoleでドメインプロパティと確認用TXT値を取得する
ドメイン全体を対象にする場合は、Google Search Consoleで「プロパティを追加」から「ドメイン」を選びます。入力するのはexample.comのようなドメイン名で、https://や末尾のパスは含めません。[1]
Search Consoleが表示するTXT値は、次の形式です。以下は説明用の無効な例であり、実際の確認にはSearch Consoleが発行した値をそのまま使います。
google-site-verification=REDACTEDGoogleはこの値を一意の確認用レコードとして発行し、文字列が一致するかを調べます。[3] TXT値は確認のためにDNS上で公開され、誰でも照会できます。通常のAPI秘密鍵のようにサービスを操作する認証情報ではありませんが、誤用や取り違えを避けるため、公開記事、画面共有、Issue、チャットへ必要以上に複製せず、DNS管理画面へ直接入力します。
権威ネームサーバーを確認してDNSの編集先を決める
ターミナルを使える場合は、DNSを調べるdigコマンドでNSレコード（正式な回答をするネームサーバーを示す情報）を確認できます。実ドメインへ置き換えて実行してください。
dig NS example.com +short結果がVercelの2つのネームサーバーなら、TXTレコードはVercelへ追加します。Cloudflareなど別のサービスが返る場合は、そのサービス側で設定します。レジストラ自身のネームサーバーが返る場合だけ、レジストラのDNSレコード編集画面が設定先になります。
digを利用できない環境では、Googleが案内するGoogle Admin ToolboxなどのDNS確認ツールを使えます。[3] WebリクエストでDNSを照会するDNS over HTTPSを使う場合は、次の例でNSレコードをJSON形式の文字列として確認できます。[6]
curl --silent \
--header "accept: application/dns-json" \
"https://cloudflare-dns.com/dns-query?name=example.com&type=NS"この段階ではTXTを照会する必要はありません。NSだけを確認すれば管理先を判断でき、確認用の値をターミナル出力や共有ログへ出す機会を減らせます。
VercelのDomains画面でルートドメインへTXTを追加する
ルートドメインとは、wwwなどを付けないexample.comそのものです。Vercelのネームサーバーを使うドメインは、チームダッシュボードの「Domains」から対象ドメインを選び、「Advanced Settings」へ進みます。DNSレコードの入力フォームが閉じている場合は「Enable Vercel DNS」を選択してください。[4]
一方、プロジェクトの「Settings → Domains」はドメインをプロジェクトへ割り当てる画面で、チームのDomains画面とは役割が異なる場所です。
表示されたDNSレコードのフォームで新しいレコードを追加し、次のように設定します。
| 項目 | 入力内容 | 確認すること |
|---|---|---|
| Type | TXT | TXT以外を選ばない |
| Name | ルートを表す空欄または@ | Vercel画面が受け付ける表記に従う |
| Value | Search Consoleが発行した文字列 | 前後へ引用符や空白を足さない |
| TTL | 既定値 | DNSの回答を一時保存する時間。Vercelの既定値は60秒で、必要がなければ変更しない[4] |
保存後は、追加したTXTレコードが一覧へ表示されているかも確認対象です。
VercelはCLI（文字でコマンドを入力して操作する方法）向けにvercel dns addも提供しています。ただし、入力した値がシェル履歴やCI（変更のたびに自動チェックを実行する仕組み）のログへ残る可能性があります。
今回のような一度の所有権確認では、値を必要以上に複製しないダッシュボード操作の方が扱いやすいと考えています。
公開DNSでレコードを確認してからSearch Consoleへ戻る
Vercelへ保存できても、すぐにSearch Consoleから参照できるとは限りません。まず、自分の端末で次を実行します。
dig TXT example.com +short出力にSearch Consoleが発行した値が完全一致で含まれていれば、公開DNSから参照できる状態です。出力には既存の所有権確認値、SPFなど、ほかのTXTレコードも含まれることがあります。結果全体をIssueやチャットへ貼らず、自分の端末で一致だけを確認してください。
一致を確認したらSearch Consoleへ戻り、「確認」を選びます。Googleは手動で追加したDNSレコードの反映に2〜3日かかる場合があると案内し、Vercel CLIの文書は新しいレコードの反映について最大24時間待つよう案内しています。[3][5] 私が設定した2ドメインでは数分で確認できましたが、直後に失敗しても設定先と値を確認したうえで待つのが安全です。
確認に成功した後もTXTレコードは残します。Search Consoleは確認用レコードが引き続き存在するかを定期的に調べるため、Googleは所有権を維持するにはDNSレコードを削除しないよう案内しています。[3]
複数のTXTレコードは削除や上書きをせず追加する
同じルートドメインに、Google Workspace、SPF（メールの正しい送信元を示すルール）、別のSearch Console所有者などが使うTXTレコードが存在することがあります。Googleは、複数の人が同じプロパティを確認できる一方、ほかの所有者の確認用トークン（所有権を証明する一意の文字列）を上書きしないよう案内しています。[3]
既存のTXTレコードは編集せず、新しい行としてSearch Consoleの値を追加します。特にv=spf1から始まるメール送信元のルールは、Search Consoleの確認値へ置き換えてはいけません。
今回使ったレジストラの簡易DNS画面では、同じ名前と種類のレコードを追加したつもりでも、一覧上の既存値が置き換わる挙動を確認しました。これは今回観察した画面挙動であり、すべてのレジストラに共通する仕様ではありません。DNSを実際に管理しているサービスで、保存後の一覧と公開DNSの両方を確認する必要があります。
まとめ：設定先・値・反映状態を順に確認すれば原因を切り分けられる
Search Consoleが「TXTレコードで確認トークンが見つかりませんでした」と表示したら、同じ値を繰り返し保存する前に、次の順で確認します。
- Search Consoleで「ドメイン」プロパティを選び、対象ドメインに誤りがない
- 確認用TXT値の実値を記事、Issue、チャット、画面共有へ出していない
-
dig NS example.com +shortなどで現在の権威ネームサーバーを確認した - 権威ネームサーバーを運用するサービスのDNS画面へTXTを追加した
- ルートドメインではNameを空欄または
@とし、サービスが受け付ける表記を使った - 既存のTXTレコードを削除、編集、上書きしていない
- 自分の端末でTXT値の一致を確認し、照会結果全体を共有していない
- 一致しない場合は、設定先、対象ドメイン、Name、Valueを見直してから反映を待った
- Search Consoleの確認成功後も、確認用TXTレコードを残している
最初の行動は、dig NSまたはDNS確認ツールで権威ネームサーバーを確認することです。Vercelのネームサーバーが返ればVercelで編集し、別のサービスが返ればその管理画面へ進みます。Vercelがサイトを配信していても、DNSを別のサービスが管理している構成では、TXTをVercelへ追加しません。その場合も、TXTの追加先はNSレコードが示すDNS管理者です。
参考文献
- Google Search Console Help, Add a website or platform property to Search Console
- Vercel Docs, Working with nameservers, 2026年7月15日
- Google Search Console Help, Verify your site ownership
- Vercel Knowledge Base, How can I manage my Vercel DNS records?, 2026年7月27日
- Vercel Docs, vercel dns, 2026年8月21日
- Cloudflare Docs, Using JSON, 2026年5月5日
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。