Domain vs URL-prefix property in Search Console: which to use

A Domain property in Google Search Console (example.com) covers every subdomain and every protocol, so www, m., http and https all land in one set of data, and the sole way to verify it is a DNS record. A URL-prefix property (https://www.example.com/) covers nothing but URLs that begin with that exact string, protocol included, and can be verified several ways: an HTML file, a meta tag, Google Analytics, Google Tag Manager or DNS. If you can edit the domain’s DNS, start with a Domain property, then add URL-prefix properties for any section you want to report on by itself.

What each property type covers

	Domain property	URL-prefix property
Written as	example.com (no protocol, no www)	https://www.example.com/
Subdomains	All of them: www, m, shop, blog	None beyond the one in the prefix
Protocols	http and https together	The one in the prefix
Paths	The whole domain	Everything under the prefix, such as /blog/
Verification	DNS record	HTML file, HTML tag, Google Analytics, Google Tag Manager, DNS
In the Search Console API	sc-domain:example.com	https://www.example.com/

Google’s own example, from its help page on adding a property, makes the difference concrete. A Domain property for example.com includes http://example.com/dresses/1234, https://example.com/dresses/1234, http://www.example.com/dresses/1234 and even http://support.m.example.com/dresses/1234. A URL-prefix property for http://example.com/ includes the first of those and none of the others: not the https version, not the www version.

Two details trip people up. A Domain property is entered without “www”; Google says not to include it. And a Domain property for a subdomain does not reach upwards: fish.example.com contains no data about example.com, because a child domain does not contain its parent.

How to verify a Domain property

1. Open the property selector at the top of any Search Console page and choose “Add property”.
2. Pick Domain and enter the bare domain, for example example.com.
3. Search Console gives you a DNS record to add. Depending on how your domain is set up, it is a TXT record or a CNAME record.
4. For some domain providers, Google can add the record for you after you sign in to the provider. Otherwise, add it yourself in your DNS settings.
5. Click Verify. Google warns that a provider can take two or three days to start serving a new record, so if it fails, wait a day and try again.
6. Leave the record in place. Google’s help is explicit: to stay verified, do not remove it after verification succeeds.

Data starts to appear in a new property within a few days.

How to verify a URL-prefix property

A URL-prefix property accepts every method, which is why it is the usual choice when DNS is out of reach:

• HTML file. Upload a file Google gives you to the site. Deleting it later loses you the verification.
• HTML tag. A meta tag in the <head> of the homepage. You need to be able to edit the page source, and the homepage has to load for logged-out visitors.
• Google Analytics. Works if the homepage carries an analytics.js or gtag.js snippet and you have edit rights on that Analytics account, signed in with the same Google account.
• Google Tag Manager. Needs Publish or Admin permission on the container, again with the same Google account.
• DNS record. The same method as a Domain property, and Google notes that using it on a URL-prefix property verifies you for the Domain property as well.

File and tag tokens are tied to the person who placed them. Several people can verify the same property by different methods, and Google asks owners not to overwrite each other’s tokens. Google’s verification help has the details for each method.

Which should you choose?

For a site you own and whose DNS you control, a Domain property is the sensible default. It catches the traffic that leaks into the versions of your site you forgot about: the http copy, the www copy, the staging subdomain someone left open. It also saves you reconciling four properties that each hold a slice of the truth.

URL-prefix properties earn their place in three situations. When you cannot touch DNS, because the client’s IT team owns it or the registrar login is lost. When you want a section on its own, because a /blog/ property gives the blog its own reports, its own sitemaps and its own row limits in exports. And when you want to give someone access to one part of a site without the rest.

Google’s help suggests a separate property for each domain or subpath you want to track, and adding them is cheap: once a parent property is verified, child properties you add are verified automatically with the same method. One account can hold up to 1,000 properties.

Remember that properties overlap. A Domain property’s numbers already include its URL-prefix children, so never add them together in a report. If you want to split a Domain property by path without creating more properties, a page filter in the Performance report does it.

The agency version

If you work on client sites, the cleanest setup is this: the client verifies a Domain property themselves with a DNS record, then adds you as a user. You never need their registrar login, and they never have to trust you with it. How to add a user to Search Console walks through the roles and which one to ask for.

Two things are worth saying to the client out loud. First, the DNS record has to stay. Verification lasts as long as Search Console can find the token, and if every verified owner loses verification, every other user loses access after a grace period, agency included. Second, sitemaps belong to the property they were submitted in. A sitemap submitted to the old https://www. property will not appear in the new Domain property, so resubmit it there. How to submit a sitemap to Google covers the rest.

How properties appear in API-based apps

Every third-party Search Console app, ours included, reads properties through Google’s Search Console API, and the API names them differently from the interface. A Domain property comes back as sc-domain:example.com. A URL-prefix property comes back as the full URL with its trailing slash, https://www.example.com/. Each also carries your permission level: siteOwner, siteFullUser, siteRestrictedUser or siteUnverifiedUser.

So if you see both sc-domain:example.com and https://www.example.com/ in an app’s list, that is two properties for one site, and their numbers overlap exactly as they do in Search Console. An app that reads the API, like ours, cannot verify a property for you; do that in Search Console first, and the property appears in the app once your account has access.

Search Console has also begun rolling out a third kind, platform properties, which track how a creator’s content on Instagram, TikTok, X or YouTube performs in Google Search. Google says the rollout is gradual. For a website, the choice is still Domain or URL-prefix.

Where QueryWatch fits

QueryWatch lists every property your Google account can see, Domain and URL-prefix alike, with real numbers on each and no site limit on the free tier. For agency lists, client tags and colours are free too, so a client’s Domain property and its section properties can sit together under one tag. Pro adds multiple Google accounts, for the properties a client granted to a different login. Verification itself stays in Search Console. QueryWatch for agencies has the full picture, and managing 20+ client properties covers the day-to-day. QueryWatch is an independent app, not affiliated with Google.