Domain property or URL prefix: which one do I pick?
I pick a Domain property whenever I can get into the DNS. Search Console is the first thing I ask for when someone wants to hire me to fix indexing in Search Console, because it's the read-only data every diagnosis starts from, and a property that only sees half the site gives half the answer. Google's own help says a Domain property includes all subdomains, like m and www, and multiple protocols, so http, https, www and non-www all report into one place.
A URL-prefix property is narrower. It includes only URLs that start with the exact prefix you type, protocol included, so https://example.com/ and https://www.example.com/ are two different properties. That isn't always wrong. It's just blind to anything outside the prefix, and on WordPress the thing outside the prefix is often the problem.
Here's a case where it mattered. On a vacation rental site, Search Console reported the www and non-www homepages as two separate pages, with ranking signals split across both. A property that only saw one host would've shown half of that split and hidden the rest.
| What differs | Domain property | URL-prefix property |
|---|---|---|
| What it covers | Every subdomain and protocol of the domain | Only URLs starting with the exact prefix |
| How it's verified | A DNS record, and only a DNS record | HTML tag, HTML file, Google Analytics, Tag Manager or DNS |
| What can break it | Someone deleting the DNS record | A plugin, theme or file that held the token being removed |
| When I use it | Whenever I can get the DNS edited | When the DNS can't be touched yet |
How I handle Google Search Console verification with DNS
It's a short job once you know where the domain's DNS actually lives. This is the order I follow, and it doesn't change between hosts.
- Step 01
Add the property as a Domain
To add a website to Google Search Console, I click Add property, choose Domain and type the bare domain, like example.com, with no https, no www and no path. The protocol and subdomains are what the property covers, so they don't belong in the box.
- Step 02
Copy the TXT record Google gives
Search Console shows a TXT record that starts
google-site-verification=. I copy the whole value, since a record missing even one character won't verify. - Step 03
Find where the DNS is really managed
The company the domain was bought from isn't always the one serving its DNS. I check the nameservers first. If they point at a CDN or the web host, that's where the record goes, and editing the registrar's panel does nothing.
- Step 04
Add the TXT record at the root
Google says to leave the name or host field blank for a TXT record, and most DNS panels label that root
@. A new TXT record sits beside the ones already there, so the mail records don't need touching. - Step 05
Check the record is live, then click Verify
Google says a manually added record can take up to two or three days before the provider starts serving it. I look the TXT record up myself before clicking Verify, so a failed attempt tells me something I didn't already know.
- Step 06
Leave the record in place
Search Console checks the token again from time to time. If it's gone, Google sends a warning, and the permission lapses after a grace period unless the token comes back. I tell whoever manages the DNS what the record's for, so nobody tidies it away in a year's time.
Once the property is verified, the first tool I open on a problem page is URL Inspection, because it shows what Google holds for that one address.
Google also accepts a CNAME record for Domain verification. I only use it when the DNS panel won't take the TXT record, which is rare.
Can a WordPress plugin handle Search Console verification?
Yes, for a URL-prefix property, and it's the route most WordPress owners take. Each of the four plugins below puts Google's token on the site for you. None of them can verify a Domain property, because that only takes a DNS record.
| Plugin | Where the setting is | Method | If the plugin is removed |
|---|---|---|---|
| Site Kit by Google | Sign in with Google during setup | A virtual HTML file first, an HTML tag if that fails | The token goes with the plugin |
| Yoast SEO | Yoast SEO, Settings, Site connections, under Google | HTML tag | The tag goes, and so does verification after the grace period |
| Rank Math | General Settings, Webmaster Tools, Google Search Console field | HTML tag | Same as Yoast |
| SEOPress | SEO, Advanced, Advanced tab, Google site verification | HTML tag | Same as Yoast |
That last column is the catch none of the plugin guides dwell on. Switch from Yoast to Rank Math, or tidy up plugins, and the token leaves with the old one. So if a plugin verified the site, I paste the same tag into the new plugin before removing the old one, and I still add the Domain property by DNS when I can. To see which methods a property uses, open Settings, then Ownership verification.
If I can't edit the DNS yet, I still add a URL-prefix property today, because Google says data collection starts as soon as anyone adds a property. The prefix has to be the version the site actually serves. If http redirects to https and www redirects to the bare domain, I add https://example.com/ and nothing else, then add the Domain property beside it once the DNS is open.
Don't overwrite someone else's token. If a previous developer verified the site, their tag or file keeps them verified too. Add yours beside it, and remove theirs on purpose, not by accident.
Rather have me do this? One person, whole job.
Book a call on UpworkWhy does Google Search Console verification fail?
Google's help page lists errors for each method. These are the ones I actually meet on WordPress, with the check I run for each.
- i.
The TXT record wasn't found
Google says it can take a few minutes or even days after posting the record for Google to see it, and to wait a day or two. First I check the record went in at the DNS host the nameservers point to, not the registrar.
- ii.
The record didn't match
Google needs the exact value it gave you, in the value field with the host left blank. A string typed into the host field, or pasted with a missing character, fails here.
- iii.
The meta tag wasn't found
Google looks for the tag in the head of the homepage a logged-out visitor is sent to. On WordPress I view that page's source logged out, because a cache plugin can keep serving HTML from before the tag was added.
- iv.
The server timed out or looped
Timeouts, DNS lookup errors and a request redirected too many times all appear on Google's list. A slow host or a www and https redirect chain is where I look.
- v.
The site asked for a password
Google says a site that requires password authentication can return an invalid response. A coming soon or maintenance mode plugin does exactly that, so I switch it off or use DNS.
How do I give a consultant access without sharing a password?
You add them as a user in Search Console. Nobody needs your Google password, your WordPress login or owner rights to read the data. This is exactly how my diagnosis starts: a restricted user on your property, and you can remove it any time.
Only an owner can add users. In Search Console that's Settings, then Users and permissions, then Add user. You type the consultant's Google Account email, choose the level and save. To take access away, you click Remove access beside their name.
| Level | What it can do | Do I ask for it? |
|---|---|---|
| Owner | Everything, including adding and removing other users | No. I don't need it to diagnose anything |
| Full user | Views all data and can take some actions | Only if we agree I'll be doing the fixes |
| Restricted user | Views most data, can't change settings or users | Yes. It's all a diagnosis needs |
Be careful with delegated owners. Google gives a delegated owner owner-level permissions, so they can add and remove users and change settings. I won't ask for that. If nobody at the business is an owner, because a former developer set the property up under their own account, verify it yourself with your own DNS record and you become an owner alongside them.
What do I set up in the first ten minutes after verifying?
Verification only proves who owns the site. These are the checks that make the property useful, and each one takes a minute or two.
- i.
Submit the sitemap
WordPress has published a core sitemap at
/wp-sitemap.xmlsince version 5.5. If an SEO plugin writes its own, I submit that one instead, never both. The status should read Success. Couldn't fetch, or a count of errors, is the moment to fix a sitemap Google can't read. If you'd rather rule out a robots.txt block yourself first, my WordPress robots.txt guide shows how to read the file and the Sitemap line inside it. - ii.
Confirm search engines aren't discouraged
WordPress turns its core sitemaps off when the Discourage search engines setting is on. It's often ticked during a build and forgotten, and a missing sitemap is sometimes the first clue.
- iii.
Inspect the homepage
URL Inspection on the homepage shows which version Google treats as the canonical one. If it names www and the site redirects to non-www, that's worth knowing on day one, not month six.
- iv.
Add the people who need to read it
A restricted user for the consultant, and another owner inside the business if there's only one. A property with a single owner who's since left is a common and avoidable mess.
- v.
Write down the date
Google says data collection starts as soon as anyone adds a property, even before it's verified. I note that date beside the sitemap URL and the verification method, so the next person knows where the history begins.
- vi.
Leave the Pages report for later
It fills in as Google crawls. When it does, statuses like Discovered, currently not indexed have their own diagnosis, and it isn't one you'll need in the first ten minutes.
If your property's set up and you'd like someone to read what it's telling you, add me as a restricted user and I'll start from there. I don't need a password, and you can take the access back whenever you like.
Book a call on Upwork
