Search Console Domain Property: Verifying Sites With DNS
In this article
A Search Console domain property covers a whole domain: every subdomain, plus both http and https. You verify it with a DNS record, not with a file or tag on your server. Got several sites sitting behind a reverse proxy, or moving to a new server? Then this is the setup you want, because your access stays put no matter where the A record points. The TXT record lives at your own DNS provider, so Search Console never has to reach your origin to confirm you own the domain.
What does a Search Console domain property cover?
A single Domain property collects data for the root domain and all of its subdomains and subpaths, over http, https and ftp. www and non-www come bundled in. Type www.example.com and Search Console quietly creates example.com instead. But coverage only runs downward: a property for fish.example.com knows nothing about its parent, example.com. The public suffix counts as part of the name too, so example.org needs its own property, separate from example.com. When you add the property, enter just the root domain or a subdomain. No protocol, no path, no www. Google spells out the full rules in its help page on property types.
Domain property vs URL prefix property: which one fits a proxied site?
A URL prefix property matches only URLs that start with the exact protocol, subdomain and path you typed in. Nothing else. Set one up for https://example.com/pets/ and it ignores http://example.com/pets/ and m.example.com, which means every protocol and subdomain needs a property of its own. URL prefix properties do accept several verification methods. A Domain property accepts one: DNS record verification (the exception is a site hosted on a Google product like Blogger or Google Sites). So when does a URL prefix property next to your Domain property make sense? Only when you want a separate view of one slice of the site, say a country folder or an m. subdomain. And honestly, a page filter in the Performance report often gets you the same view without a second property.
How DNS TXT verification works, step by step
Search Console hands you a TXT record value, you publish it at your DNS provider, and Search Console checks that it’s there. That’s the whole idea. In practice:
- Add a new property and enter the bare domain, for example example.com.
- Copy the TXT value that Search Console shows you.
- At your DNS provider, create a TXT record for the root domain with that value.
- Wait until the record is publicly visible.
- Go back to Search Console and click Verify.
Once verification goes through, leave the TXT record alone. It’s your ongoing proof of ownership, not a one-time ticket. Setting up DNS records for a proxy at the same time? Then do both in one sitting at your provider and save yourself a second login.
Why DNS verification survives a move to a proxy or a new server
The TXT record and the A record are separate entries. So pointing a domain at a reverse proxy or a new origin doesn’t touch your proof of ownership at all. File and meta tag verification on a URL prefix property is a different story. Google has to find that file or tag on whatever server happens to be answering, and a migration can easily wipe it out (it’s the kind of thing nobody remembers to copy over). Before you move, run through this quick list:
- Check that the TXT record still exists at your DNS provider.
- Change only the A record, and leave the TXT entry as it is.
- Open the property in Search Console after the change and confirm you still have access.
Changing the domain name itself? That’s another case entirely. A new name means a new property, so if you’re planning a domain name change, treat Search Console as part of that project, not an afterthought.
Managing Search Console for multiple sites
Each root domain, and each public suffix, gets its own Domain property and its own TXT record. No shortcuts here. For a group of sites, a setup that stays manageable looks like this:
- one Domain property per domain,
- URL prefix properties only for the segments you actually track,
- a TXT record at each domain’s DNS provider,
- a spreadsheet listing each domain and where its DNS is hosted.
That spreadsheet sounds boring. It is. It’s also the thing you’ll be glad to have the day a domain’s DNS turns out to live somewhere you forgot about. Once DNS verification is in place, strip any old HTML verification meta tags out of your templates. The post on leftover verification tags as footprints explains why they’re worth the cleanup. Keep in mind that redirecting traffic and verification are two separate jobs: you can point domains from one panel while every TXT record stays with its DNS provider.
Where to go from here
A Search Console domain property backed by a TXT record gives you one view of http, https, www and every subdomain, and it keeps working whatever the A record points to. Set it up once per domain. Keep the record in place. After that, moving servers or adding a proxy doesn’t mean verifying all over again. For related topics, browse the Search Console and DNS guides.
FAQ
Can I add www.example.com as a Domain property?
No. Enter www.example.com and Search Console creates the property as example.com anyway. That property already covers both the www and non-www versions, so there’s no need for a separate one for www.
Do I need a new verification after pointing my domain at a reverse proxy?
Not for a Domain property. The DNS TXT record isn’t tied to the A record, so changing where the domain points leaves verification intact. A URL prefix property verified with a file or meta tag is another matter: it only stays verified if the new server still serves that file or tag.
Does a Domain property for example.com include example.org?
No. The public suffix is part of the property name, so example.com and example.org are two separate properties. Each one needs its own TXT record at its DNS provider.
