Property Verification Methods

Context

Before any signal moves between domains, Google needs proof you control the property. During a domain change you must verify the new domain — and keep the legacy domain verified — as the very first task of the broader Search Console Handover. The trap most teams hit is verifying the wrong kind of property: a URL-prefix property for https://www.newdomain.example/ silently excludes the bare host, the http variant, and other subdomains, so half your traffic never appears in reports. SEO engineers run this at the start of the migration window, usually the same hour DNS records are staged.

This page covers the four verification methods Google supports — DNS TXT record, HTML file upload, HTML meta tag, and Google Analytics / Tag Manager — and the decision between a domain property and a URL-prefix property.

Verification method comparison Four verification methods compared by which property type they support and whether they survive an origin migration. Verification Method vs Property Type Method Domain property URL-prefix DNS TXT record Yes Yes HTML file upload No Yes HTML meta tag No Yes Analytics / GTM No Yes Only DNS TXT covers a domain property and survives an origin migration
Only the DNS TXT method verifies a domain property and keeps working after the origin moves.

Pre-flight Checks

  • DNS edit access on the target zone (registrar console or a scoped Cloudflare API token)
  • The exact verification token copied from Search Console for the chosen method
  • Current TTL on the zone apex noted, so you can predict propagation delay
  • Confirmation of whether you need every subdomain (domain property) or one origin (URL-prefix)
  • For the HTML-file method: write access to the document root of the new origin
  • For the Analytics method: an existing GA4 property or Tag Manager container with the edit permission

Execution Steps

1. Decide Domain Property vs URL-Prefix Property

A domain property covers every subdomain and both protocols under one entry and can only be verified by DNS TXT — this is the correct default for a wholesale move. Choose a URL-prefix property only when a downstream tool cannot read domain-property data, or when you genuinely need to isolate one origin. For a domain change, verify the new domain as a domain property so the index-coverage view in Index Coverage Handoff spans the whole site.

2. Verify by DNS TXT Record (recommended)

Add the google-site-verification= TXT record at the zone apex, wait for propagation, then click Verify. This is the only method that proves domain-wide control and survives server migrations because it lives in DNS, not on the origin. The full registrar and Cloudflare-API walkthrough, including dig confirmation, is in verifying a GSC property with DNS TXT records.

3. Apply a Fallback Method for URL-Prefix Properties

If you must use a URL-prefix property, choose the HTML file upload (drop the named file at the document root) or the HTML meta tag (inject it into the <head>). Both prove control of one origin only and break if the file or tag is lost during a redeploy, so treat them as secondary. The Analytics / Tag Manager method reuses an existing GA4 or GTM snippet and is convenient when the tag is already site-wide.

4. Verify the Legacy Domain Too

Re-confirm the legacy property is still verified — ownership tokens can lapse when DNS is edited during cutover. You need both properties live for the Change of Address handled in Ownership Transfer Protocols, and to watch legacy URLs deindex. Re-add the legacy TXT record if a registrar migration wiped it.

5. Record Tokens and Lock the Method

Document which method verified each property and store the tokens in the migration runbook. Do not remove a DNS TXT record after verification — Google re-checks it periodically and will mark the property unverified if it disappears, severing access mid-migration.

Configs / Commands

Add the TXT verification record (Cloudflare API):

# name "@" places the record at the zone apex for a domain property
curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"TXT","name":"@","content":"google-site-verification=AbCdEf123","ttl":300}'

HTML file method — place and check the verification file:

# Upload the named file to the document root, then confirm it serves a 200
curl -sI https://newdomain.example/googleAbCdEf123.html | grep 'HTTP/'

HTML meta-tag method — inject into the head (Apache .htaccess + header pattern):

# For static templates, add the tag directly; this header documents the token in audits
Header set X-Verification-Token "google-site-verification=AbCdEf123"

Validation

  • dig +short TXT newdomain.example @8.8.8.8 returns the exact google-site-verification= token
  • Search Console reports “Ownership verified” with no warning banner on both properties
  • For URL-prefix: curl -s https://newdomain.example/ | grep google-site-verification finds the meta tag
  • For the HTML-file method: the verification file returns HTTP/2 200, not a redirect or 404
  • The legacy property still shows verified status after DNS edits

Rollback Triggers

  • Verification fails after 60 minutes despite a correct, propagated TXT record → re-issue a fresh token
  • A property flips to “unverified” → restore the missing TXT/file/tag within 24 hours before access is revoked
  • TTL above 3600s delays propagation beyond the cutover window → lower TTL first per TTL Optimization Strategies
  • Any subdomain missing from reports indicates a wrongly scoped URL-prefix property → re-verify as a domain property

FAQ

Which verification method is best for a domain migration? DNS TXT verifying a domain property. It is the only method that covers every subdomain and both protocols, and because it lives in DNS it survives origin and host changes — exactly the conditions a migration creates.

Can I verify the new domain before pointing DNS at the new host? Yes. The verification TXT record is independent of where A/CNAME records point, so you can verify the new domain property while traffic still resolves to the old host, then cut over traffic separately.

Why did my property become unverified after launch? The verification token was removed during a DNS or deployment change. Google re-checks tokens periodically; if the TXT record, HTML file, or meta tag disappears, the property is downgraded. Restore the token to recover access.

Do Analytics-based verification and DNS verification conflict? No, a property can hold multiple verification methods at once. Layering DNS TXT plus an Analytics token gives redundancy, so losing one does not unverify the property.

Related

← Back to Search Console Handover

Explore Sub-topics

Verifying a GSC Property with DNS TXT Records
Step-by-step guide to verifying a Google Search Console domain property with a DNS TXT record, confirmed with dig before clicking Verify.