Domain property or URL prefix is the first choice Google Search Console makes you commit to, and most guides stop at “use a Domain property if you can.” That is the right default, but it skips the part that actually trips people up: when a URL-prefix property on top of a Domain property genuinely pays off, and why the “URL is not in property” error you will eventually hit traces straight back to this one decision.
Here I will walk through what each type really covers, how you verify them, which one to pick, and when running both on the same account is the smarter setup. I run both types on my own site, so the screenshots here are from a real account, not a mockup.
Key Takeaways
- A Domain property covers every subdomain and both protocols of your site in one view, verified by a single DNS record.
- A URL-prefix property covers only one exact protocol and prefix, but it accepts many easier verification methods.
- Use a Domain property as your main property unless you cannot edit DNS, or you specifically want to isolate one section’s data.
- Running a URL-prefix property on top of a Domain property is worth it for a permanent section view and for granting someone access to only part of the site.
- The “URL is not in property” error is almost always a property-scope mismatch, and a Domain property removes it for good.
- Domain and URL prefix are still the two website property types; platform properties are a separate, newer class.
What a Search Console property actually is
A property is just Google’s word for one thing you can look at or manage in Search Console. In Google’s own documentation, a website property “represents a website: that is, all pages that share the common domain or URL prefix that you specify.”
That definition is the whole ballgame, because the two website property types differ only in how wide they draw that boundary. A Domain property draws it around your entire domain. A URL-prefix property draws it around one exact address. Everything else, the verification, the data you see, the errors you avoid, follows from that one difference.
Domain property vs URL prefix: the core difference
A Domain property, verified by a DNS record, captures every subdomain, protocol, and path of your site in one place. A URL-prefix property captures only one exact protocol and prefix, but it accepts many easier verification methods. As a rule, reach for the Domain property first and add a URL-prefix property only when you have a reason to.
Google describes the Domain type as one that “Includes all subdomains (m, www, and so on) and multiple protocols (http, https, ftp),” while a URL-prefix property “Includes only URLs with the specified prefix, including the protocol.” So https://example.com and https://www.example.com are two different URL-prefix properties, but a single Domain property on example.com quietly covers both, plus blog.example.com, the http versions, and anything else under that root.
The table below lays the two types side by side on the things that actually decide your setup.
| Domain property | URL-prefix property | |
|---|---|---|
| What it covers | Every subdomain (m, www, and so on) and both protocols under the root domain | Only URLs that match one exact prefix, including the protocol |
| How you enter it | Just the root domain, no protocol and no path (example.com) | The full address including protocol (https://www.example.com/) |
| Verification | DNS record only | Many methods (HTML file, HTML tag, Google Analytics, Tag Manager, or DNS) |
| Best for | Your main, catch-everything view of the whole site | Isolating one section, protocol, or subdomain, or when you cannot edit DNS |
Which property type should you use?
Use a Domain property as your main property. It captures the whole site in one view, so you never miss data sitting on a subdomain or the wrong protocol, and it removes a whole class of scope errors. The only real reasons to reach for a URL-prefix property instead are that you cannot edit your DNS, or you deliberately want to look at just one slice of the site.
DNS access is the common blocker. A Domain property can only be verified with a DNS record, so if your domain is locked inside a host or registrar you cannot touch, that route is closed and a URL-prefix property is your fallback, because it accepts an HTML file, a meta tag, Google Analytics, or Tag Manager instead.
The other reason is focus. A Domain property pools everything together, which is great for the big picture but blunt when you want to study one part of the site on its own. That is where a second, narrower property earns its place, and it is the part most guides skip.
Do you actually need both a Domain and a URL-prefix property?
Sometimes, yes. Adding a URL-prefix property on top of your Domain property is worth the extra setup in two specific situations: when you want a permanent, no-effort view of one section, and when you need to give someone access to only part of the site. Both are things a Domain property alone cannot do cleanly.
On my own account I run both at once, a Domain property on wpconsults.com and a URL-prefix property on https://www.wpconsults.com/, and you can see them sitting together in the property switcher below.
Take the section view first. Google itself gives you two ways to isolate part of a Domain property’s data: “Add a page filter in the Performance report to see data for specific protocols or subdomains,” or “Create additional URL-prefix properties for segments of the Domain property.”
The filter works, but you re-apply it every visit. A dedicated URL-prefix property for a section like https://www.example.com/blog/ or a shop.example.com subdomain gives you that segment as its own permanent dashboard, no filter to remember, which is handy when you watch one section closely.
The second reason is the one nobody writes about: permission scoping. When you grant someone access to a Domain property, they can see the whole domain. But if you create a URL-prefix property for /blog/ and grant access to that, a freelance writer or a contractor sees only their section and nothing else. That is a genuine, practical use for a second property that has nothing to do with data and everything to do with who gets to see what.
How to verify each property type
Verification is where the two types feel most different. A Domain property gives you exactly one option, a DNS record, while a URL-prefix property, in Google’s words, offers “Many possible methods.” That single DNS step is the only part of the Domain setup that trips people up, so here is the flow start to finish.
Verifying a Domain property with DNS
- Open Add property and choose the Domain panel
- Enter just your root domain, no https and no path
- Copy the TXT record Google gives you
- Paste it into your domain’s DNS settings at your registrar
- Come back to Search Console and click Verify
A URL-prefix property is more forgiving. If you already have Google Analytics or Tag Manager on the site, verification is often a single click, which is why it feels quicker for a first-time setup. Two small limits are worth knowing: you can hold up to 1,000 properties in one account, and you cannot verify a public suffix like a bare blogspot.com-style host as a Domain property, since those are shared across many owners.
Whichever type you choose, the reports read the same way once you are in. If you want a sanity check on what those numbers mean, I wrote separately about why impressions can spike while clicks stay flat, which is the report people misread most.
Can you switch from URL prefix to a Domain property, and will you lose data?
You do not really switch, you add. Creating a Domain property does not delete your existing URL-prefix property or its history, so there is no risk in setting one up alongside what you already have. Keep the old property, add the Domain property, and use whichever view fits the question you are asking.
The one honest caveat is that Search Console does not merge the two into a single combined history for you. Each property holds its own data, and the Domain property builds its aggregated view from when it can see the site, not by importing the URL-prefix property’s past reports. In practice I keep both and treat the Domain property as the master view, with the URL-prefix property as a focused lens on one part.
Why the “URL is not in property” error traces back to this choice
If you inspect a URL and Search Console refuses with “URL is not in property,” the property type you picked is usually the cause. The URL Inspection tool only checks URLs inside the property you have open, so a www URL inspected inside a non-www property, or an https URL inside an http property, gets rejected even though the page is perfectly fine.
A Domain property makes that error almost impossible, because every variant of your URL already lives inside it, so nothing you inspect can fall outside the boundary. This is the upstream decision that prevents a symptom I have written full fixes for: the plain URL not in property error and its cousin, the canonical URL not in property error. Pick the right property type up front and you rarely meet either one.
Search Console is no longer just two property types
For years the choice was binary, Domain or URL prefix. That is still the choice for your website, and those remain the two website property types. But Search Console is no longer a two-property tool at all, because a separate class of property arrived in 2026 for the social and video accounts whose domain you do not own.
These platform properties let you connect accounts like Instagram, TikTok, X, and YouTube and see how they perform in Google, which is a different job from tracking your own site. They are not a third way to track your website, so they do not change the Domain-versus-URL-prefix decision, but it is worth knowing they exist. I covered the setup and the data in a separate guide on Search Console platform properties.
So, which Search Console property type should you use?
In my view, make a Domain property your main property on every site you can, and treat the DNS step as a small one-time cost that pays back by covering the whole domain and killing the property-scope errors. It is the setup I use for every project, and it is the one I would set up first.
Then add a URL-prefix property only when you have a real reason: a section you watch closely and want as its own permanent view, or a contractor you need to give access to just one part of the site. That is not two tools competing, it is a broad view and a focused lens doing different jobs, and using both deliberately beats picking one and living with its blind spot.
Common questions about Search Console property types
Does the property type I choose affect my rankings?
No. Domain and URL prefix only change what data you see and how you prove ownership. Neither one touches how Google crawls, indexes, or ranks your pages, so you can add or switch types with zero ranking risk.
Will adding a Domain property split or delete my existing data?
No. Your existing URL-prefix property and its history stay exactly as they are. The Domain property just gives you a wider, combined view next to it, so you gain a report rather than losing one.
Can I verify a Domain property without editing DNS?
Not currently. A Domain property is verified by a DNS record and nothing else. If you cannot reach your DNS settings, a URL-prefix property is the way in, because it also accepts an HTML file, a meta tag, Google Analytics, or Tag Manager.
Why does my Domain property show different numbers than my URL-prefix property?
Because they cover different scopes. A Domain property adds up every subdomain and protocol, while a URL-prefix property counts only the one exact address you entered. The Domain totals usually run higher simply because they include more of your site.
Is a Domain property the same as the sc-domain property I see in tools and the API?
Yes. A Domain property shows up as sc-domain:example.com in the Search Console API and in most SEO tools, while a URL-prefix property appears as the full https://www.example.com/ address. They are just two labels for the two types you already chose between.
Not sure how your Search Console is set up?
If your property setup feels tangled, or a scope error keeps coming back, feel free to contact us or email me and I will help you get it clean. A tidy Domain property makes every other Search Console job easier.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
