Summarize this article with AI
Adding a site in Google Search Console? Your first step is to pick between a Domain property and a URL-prefix property. The Google Search Console domain vs URL prefix choice decides more than how you verify. The choice shapes which subdomains and protocols appear in your reports. It also sets which tools you can run and whether two properties for the same site report matching clicks and impressions.
Short answer: a Domain property tracks every protocol, subdomain and path, and verifies by DNS only. A URL prefix property tracks only URLs that start with its exact prefix, protocol included, and offers more verification methods. Most sites are best served by both: a single Domain property for the full view, plus URL prefix properties for the specific sections or teams that need their own.
Below you'll find a decision table, why the totals don't match (with a worked example), and which tools need which property.
Google Search Console domain vs URL prefix: what each one covers
A Domain property tracks every protocol, every subdomain and every path under one bare domain, and the only way to verify ownership is a DNS record. A URL prefix property tracks only URLs that start with the exact prefix you entered (protocol included), and gives you several verification methods: an HTML file, an HTML tag (also called a meta tag), Google Analytics, Google Tag Manager and DNS. For most sites, set up a Domain property as the full-site view and add URL prefix properties for the slices you want to report on or share separately.
Here's the side-by-side.
| Feature | Domain property | URL-prefix property |
|---|---|---|
| What's included | All subdomains (www, m, blog…), both protocols, every path | Only URLs starting with the exact prefix, protocol included |
| How you enter it | example.com, no protocol, no www, no path |
The full URL with protocol and trailing slash: https://www.example.com/ or https://example.com/blog/ |
| Verification | DNS record only (unless the site is on Blogger or Google Sites) | HTML file, HTML tag, Google Analytics, Google Tag Manager, DNS |
| API ID | sc-domain:example.com |
The full URL, e.g. https://www.example.com/ |
| Crawl Stats, robots.txt report, Change of Address | Yes | Yes at the root; no on a path property |
| Disavow links tool | Not supported | Yes, one list per property, so http and https each need their own |
| Best for | The whole site in one view | A section, a subdomain, a protocol, or a slice someone needs on its own |
Domain property
A Domain property is defined without a protocol and without a path. In Google's words, it "aggregates data for all subdomains, protocols, and subpaths of the property", so a single property tracks the entire domain and every version of every URL under it.1 You can also create one for a subdomain (blog.example.com), but that child doesn't contain its parent's data, and a different suffix (example.org) is a separate property altogether.
Verification is DNS only, except for sites hosted on a Google product such as Blogger or Google Sites.1 Google has recommended Domain properties "where possible" since it launched them in 2019.
URL-prefix property
A URL prefix property tracks only URLs that start with its exact prefix.1 Google's example: a property for http://example.com/ matches http://example.com/dresses/1234, but not https://example.com/dresses/1234 (the protocol doesn't match), and not http://www.example.com/dresses/1234 (www. doesn't match). Serving both http and https versions? Each one wants its own URL prefix property. Point a prefix at a path like https://example.com/blog/ and it tracks everything under that folder, nothing above it, nothing in sibling subdomains.
You can verify a URL prefix property with any of these methods: an HTML file, an HTML tag (the meta tag option), your Google Analytics tag, Google Tag Manager, or DNS. Two useful rules sit under the DNS method: using DNS on a URL prefix property also verifies the Domain property, and once a property is verified, child properties you add later are auto-verified with the same method.2 Verifying a subdomain doesn't verify its parent.
One terminology trap. Google's docs use "domain-level property" (or "root-level property") for any property without a path, which includes a root URL-prefix property like https://example.com/. That isn't the same thing as a Domain property, and several tool limits further down are written in those terms.
Which property should you use?
Default recipe: a Domain property for the full-site view, plus URL-prefix properties for the slices that need their own tables, their own export, or their own access. Google itself suggests "a separate Search Console property for each domain or subpath that you want to track, as well as a property that contains them all".1 A single Domain property isn't always better, though. It mixes every host and section in one set of tables, and the disavow tool won't take one at all.
Pick by situation:
| Situation | What to set up | Why |
|---|---|---|
| You control DNS at the registrar or host | Start with the Domain property | Covers every subdomain and protocol in one view, and URL-prefix properties you add under it later verify automatically |
| You can't edit DNS today, or you need data from an existing GA or GTM tag | A URL-prefix property at the root, verified by HTML tag, HTML file, GA or GTM. Add the Domain property later | Gets you reporting now. DNS on the prefix later verifies the Domain property too |
| You report on a subdomain, country folder or product section on its own | Add a URL-prefix property for that slice | Its own chart and its own 1,000-row tables, so long-tail rows that the Domain property's tables cut off can surface |
| A freelancer or outside team should see one section only | Add a URL-prefix property for that section and grant access only there | Someone on the Domain property sees every host and section; someone on the slice sees just the slice |
| You need to disavow links | A URL-prefix property, one per protocol | The disavow tool doesn't support Domain properties |
| You're moving domains | Keep a root-level property for the source | Change of Address runs on root-level properties only: a Domain property, or a URL prefix at the root |
| You own only a path on someone else's domain | A URL-prefix property for that path | You can't verify a Domain property you don't control |
If a tool you use connects to only one property, give it the Domain property, since it has the widest scope. Anything a Domain property can't do (disavow, a section-only view for a collaborator) can be added later as a URL-prefix slice.
Why Domain and URL-prefix properties show different numbers
Scope is the easy half. A URL prefix property is literal about its prefix. If a URL's host, protocol or path doesn't match it, the property won't see that URL at all. Picture traffic landing on www.example.com and blog.example.com. A prefix that tracks only the www host won't see a single click on the blog.
The harder half: Google counts most of the report by property, not by URL. For the Performance chart and the Queries, Countries, Devices and Dates tables, Google says "all results for the same query that point to the same Search Console property are counted once in total".3 So when two of your hosts show for the same search, a Domain property logs one impression and, if a searcher clicks both results, one click. Two URL-prefix properties each log their own. The Pages table is the exception: it counts each URL. That's why Google notes CTR and average position are "generally higher when aggregating by property".
Put those together and the sum of your URL prefix properties won't equal the Domain property, and it can miss in both directions at once. Overlap (two hosts shown for one query) pushes the sum up. Hosts, protocols or paths with no URL prefix property of their own pull it down. Neither total is wrong. A Domain property doesn't add up its hosts; it reports performance data for the whole website as one unified set.
A worked example: the totals that don't add up
Hypothetical numbers, chosen to show the counting rule. One site, example.com, with three hosts: www.example.com, blog.example.com and shop.example.com. Three properties exist: a Domain property for example.com, plus URL-prefix properties for https://www.example.com/ and https://blog.example.com/. The shop runs without its own URL-prefix property. Pick a complete 28-day window, Web search, no filters.
Suppose the window breaks down into four query segments:
| Query segment | Searches showing it | Clicks |
|---|---|---|
| A: only a www page shows | 60,000 | 1,800 on www |
| B: only a blog page shows | 25,000 | 500 on blog |
| C: a www page and a blog page show on the same results page | 10,000 | 400 click only www, 150 click only blog, 50 click both |
| D: only a shop page shows | 5,000 | 100 on shop |
What each property reports:
| Property (chart totals) | Impressions | Clicks | CTR |
|---|---|---|---|
https://www.example.com/ (A + C) |
70,000 | 2,250 (1,800 + 400 + 50) | 3.21% |
https://blog.example.com/ (B + C) |
35,000 | 700 (500 + 150 + 50) | 2.00% |
| Sum of the two URL-prefix properties | 105,000 | 2,950 | 2.81% |
Domain property example.com (A + B + C counted once + D) |
100,000 | 3,000 | 3.00% |
Add the prefix pair and you're over the Domain property by 5,000 impressions. Segment C gets double-counted (+10,000), while the shop falls outside both prefixes (-5,000). It also shows 50 fewer clicks. The 50 people who clicked both results add 50 extra clicks to the sum, while the shop's 100 clicks are missing from it. Position follows the same rule: for segment C, the Domain property reports whichever host ranked higher, and the blog property reports the blog's own position.
Inside the same Domain property, the Pages table would show 110,000 impressions for this window (segment C counted once per URL) against the chart's 100,000. That isn't a bug: the chart counts by property, the Pages table counts by URL.
Checklist when two properties disagree
Walk through this before anything else.
- Same date range, in complete days. Daily data is Pacific Time, and the last two or three days are still arriving.
- Same scope. List the hosts, protocols and paths each property covers.
- Chart vs Pages tab. If you're comparing a Queries number to a Pages number, you're comparing property counting to page counting.
- Canonical attribution. Clicks on a duplicate URL (http vs https, www vs non-www) count toward the canonical, so a URL-prefix property for the non-canonical variant can look nearly empty while the URLs get crawled.
- 1,000-row tables. The Queries, Pages and other tables show up to 1,000 rows per property, so a Domain property truncates differently from a slice-sized URL-prefix.
- Anonymized queries. They're in the chart totals but drop out of a query filter, so filtered views don't add up to the unfiltered one.
- When each property was added. Check Date property added in Settings, and where each chart's data starts.
- The impressions anomaly. Google reported impressions inaccurately from May 13, 2025 through April 27, 2026.4 CTR and average position were affected too. Clicks weren't. If your range crosses that window, compare clicks and treat the other three metrics with caution.
For the other common "the numbers don't match" question (Search Console vs analytics), see our Search Console vs Google Analytics guide. To get past the 1,000-row cap for one property, see our Search Console bulk export guide.
Which reports and tools need which property
"Domain-level" and "root-level" in Google's docs mean any property without a path. A Domain property qualifies. So does a URL-prefix property for the host root (https://example.com/). A URL-prefix property for a path (https://example.com/blog/) does not.
| Report or tool | Domain property | URL prefix at the root | URL prefix with a path |
|---|---|---|---|
| Crawl Stats | Yes | Yes | No |
| robots.txt report | Yes | Yes | No |
| Change of Address | Yes | Yes | No |
| Disavow links tool | No | Yes (one list per protocol) | Not stated |
| Branded queries filter and Insights branded card | Yes, at the top level, with enough impressions | Not stated for a root URL-prefix | No |
| URL Inspection and Sitemaps | Yes (the URL or sitemap must be inside the property) | Yes (within that prefix) | Yes (within that path) |
| Removals (temporary) | Yes; matches all http/https and www/non-www variations, but not other subdomains | Yes | Yes |
| Page indexing | Yes | Yes | Yes |
| Links report | Yes | Yes | Yes |
| Merchant Center association | Yes | Yes | No |
| Google Analytics association (one Search Console property per web data stream) | Yes | Yes | Yes |
| Users and permissions (100 non-owners per property) | Yes | Yes | Yes |
Search Console API siteUrl |
sc-domain:example.com |
https://example.com/ |
https://example.com/blog/ |
A few things fall out of that table.
- Got only
https://example.com/blog/for that section? Crawl Stats is off limits, the robots.txt report won't run, and Change of Address can't file from a path-level property. Add a root-level property too (a Domain property or a URL prefix for the host). - Crawl Stats counts both http and https even on a URL-prefix property, and a parent property shows requests to its subdomains. If server logs are easier to get at, our log file analysis guide works through the same questions from the server side.
- The branded queries filter needs a top-level property with enough impressions. Our SEO KPIs guide shows where it fits in a reporting setup.
- Moving to a new domain? Change of Address handles the Search Console side, and our 301 vs 302 redirect guide covers the redirects and how to confirm them in Search Console.
- To slice a Domain property's Performance report by section without a new property, use the Pages filter with regex. Our Search Console regex cheat sheet has copy-paste patterns.
How to set up a Domain property and URL-prefix properties side by side
Six steps for the recommended setup. Platform clicks for WordPress and Wix verification live in our WordPress Search Console guide and our Wix Search Console verification guide.
- Add the Domain property. In Search Console, hit Add property and pick Domain. The box wants the bare domain only, no protocol, no www, no path. Google hands you a TXT record; drop it into your DNS provider. Click Verify. Hand-added DNS records can take up to two or three days to propagate, so if the first try fails, wait and retry.
- Keep the DNS record. Google is explicit that it should stay after verification succeeds. Verification lasts only while Search Console can still find the token, and if every verified owner loses access, so does everyone else on the property.
- Add the URL-prefix slices you need. Each one takes the exact URL with protocol and trailing slash. Child properties of a verified parent are auto-verified with the same method, so the Domain property's DNS record also covers the prefixes under it.
- Give users access per property. The ceiling is 100 non-owner users per property. Owners of a parent property get implicit owner rights on its children, so an outside collaborator who should see only
/blog/goes on the/blog/URL-prefix property, not on the Domain property. - Set expectations about data. Google starts collecting a property's data as soon as anyone adds it, even before verification, but the data takes a few days to appear. So a property someone else added earlier may already have history. Don't promise more than that; check Date property added in Settings and where the chart starts.
- Keep the old URL-prefix properties. Adding a Domain property doesn't replace them or merge their data. Settings stay per property too: a sitemap submitted in one property doesn't show in another, and bulk data export is set up property by property.
In practice, a multi-host site ends up with one Domain property plus a URL-prefix property for each host or section that a team, a report or a tool needs on its own.
Which property to connect to other tools
The Search Console API, and the MCP servers built on it, address a Domain property as sc-domain:example.com and a URL-prefix property by its full URL, protocol and trailing slash included.5 Paste the homepage URL where you meant the Domain property and you're asking for a different property: the root URL-prefix one, which you may not have at all. Need to pick the exact property ID for an AI assistant? Our Google Search Console MCP guide walks through it.
GA4 links a single web data stream to one Search Console property. Google says both sides need to cover the same pages. If the stream covers one subdomain only, pair it with that subdomain's URL-prefix property instead of the Domain one.
Want a whole-site view at the page level? Hand SEO Heatmap the Domain property. It reads either property type and is free for one Search Console property. Connect the Domain property and every host's pages fold into one Pages heatmap. You get clicks over week, month or quarter, growing/falling filters, and AI insights pointing out which pages are gaining or losing the most. A URL-prefix property restricts that view to its slice. SEO Heatmap works off clicks. For impressions, CTR and average position, you're back in Search Console's Performance report.
Frequently asked questions
Do I need to verify both a Domain and a URL-prefix property?
No. Stick to verifying the ones you'll actually touch. Verification often spreads between them anyway. Verify a URL-prefix property through DNS and the Domain property for that domain is verified too. Once the Domain property is verified, any URL-prefix property you add under it is verified automatically with the same method. The reverse direction is different. Verifying a subdomain leaves the parent domain unverified.
Can I switch from a URL-prefix property to a Domain property without losing data?
There's no switch. The move is just adding the Domain property next to the existing one. Your URL-prefix property stays put, data and all. Give the new Domain property a few days to start showing data. Check how far back its chart reaches before comparing the two. As long as its tables, disavow list or users still matter, hold onto the URL-prefix property.
Does a Domain property include every subdomain?
Yes. The Domain property tracks the whole domain, which means every subdomain, every path and both protocols. A different suffix is a different property, so example.com and example.org don't share one. Create a Domain property on blog.example.com, though, and its data ends at that subdomain. Its parent lives in a separate property.
Should I delete old URL-prefix properties after adding a Domain property?
No. Adding a Domain property doesn't replace them, and URL prefix properties still do jobs a Domain property can't. They hold disavow lists, which Domain properties don't support. They let you give a collaborator access to one section only. And their own 1,000-row tables can show long-tail rows that the Domain property's tables cut off.
What's sc-domain: for in the API or an MCP server?
It's how the Search Console API names a Domain property: sc-domain:example.com is the Domain property for example.com. For a URL-prefix property, the full URL goes in: protocol, trailing slash and all. In the API, that property's name is https://www.example.com/. Copy the property ID exactly. A tool that prompts for one treats the homepage address and the Domain property as different IDs, because they are.
Why can't I use the disavow tool with my Domain property?
The disavow links tool doesn't support Domain properties, so the list has to go on a URL-prefix property. A site served over both http and https needs a property and a separate list for each protocol.
Can I see a single folder's data inside a Domain property without a new property?
Yes. Head to the Performance report, then add a Page filter that catches URLs under the folder path. Several folders? One custom regex can bundle them. The Domain property's 1,000-row cap sticks even with a filter on. Chasing a folder's long tail? Spin up a URL prefix property on that path and read its own tables.
Running several hosts or sections under one domain? SEO Heatmap shows which pages are gaining or losing clicks across all of them in one heatmap. It's free for one Search Console property, so start with your Domain property.
Sources (5)
SEO Heatmap Knowledge relies on primary sources: Google's documentation, web standards, peer-reviewed research, and vendors' own pages for their pricing and features. Our editorial standards
- Google Search Console Help. “Add a website or platform property to Search Console.”
- Google Search Console Help. “Verify your site ownership.”
- Google Search Console Help. “Performance report (Search results): About the data.”
- Google Search Console Help. “Data anomalies in Search Console.”
- Google for Developers: Search Console API. “Sites: Search Console API.”
