Domain vs URL-prefix properties

Choose the right property type for complete reporting or a deliberately scoped view.

Partially automatable Beginner

A Search Console property defines the URLs, data, settings, and users you can examine. Choosing the wrong property does not harm rankings, but it can hide important data or mix parts of the site that should be managed separately.

For websites, the two property types are Domain and URL-prefix. Google generally recommends a Domain property when you can verify through DNS because it gives the broadest coverage. URL-prefix properties are still valuable for protocol, host, or directory-level reporting and access.

Domain property

A Domain property is defined without a protocol and without a path. For example:

example.com

That property covers the registrable domain across all subdomains, supported protocols, and paths, including:

http://example.com/
https://example.com/
https://www.example.com/
https://shop.example.com/products/
https://support.eu.example.com/guides/

Do not enter www. Search Console normalizes a Domain property such as www.example.com to example.com, covering both www and non-www versions.

A Domain property can also begin at a subdomain. A property defined as shop.example.com includes that host and its child subdomains, but not the parent example.com or sibling support.example.com.

Domain verification

Domain properties require DNS verification, except for some automatically verified Google-hosted properties. You add the token Search Console provides to the domain's DNS configuration, usually as a TXT record. This proves control at the domain level and is why the property can include every protocol and subdomain.

URL-prefix property

A URL-prefix property includes only URLs that begin with the exact prefix. The protocol, host, optional port, path, and trailing slash matter.

For example:

https://www.example.com/blog/

Includes:

https://www.example.com/blog/article-one
https://www.example.com/blog/guides/seo
https://www.example.com/blog/?page=2

Does not include:

http://www.example.com/blog/ because the protocol differs.
https://example.com/blog/ because the host differs.
https://www.example.com/news/ because the path does not start with /blog/.
https://shop.example.com/blog/ because the subdomain differs.

Always copy the complete canonical prefix and include the final slash for a directory property. A prefix such as /shop/ is safer than /shop, which could also match unrelated paths beginning with the same characters.

URL-prefix verification

URL-prefix properties support several methods, including DNS, HTML file, HTML meta tag, Google Analytics, Google Tag Manager, and supported hosted-platform verification. The available methods and requirements appear in the verification wizard.

Side-by-side decision factors

Coverage

Domain: All protocols, subdomains, and paths below the defined domain.
URL-prefix: Only URLs that start with the exact defined prefix.

Verification

Domain: DNS record only.
URL-prefix: DNS or several site-level methods.

Best default use

Domain: Organization-wide coverage, migrations, host changes, protocol mistakes, and a single health baseline.
URL-prefix: A specific protocol, host, directory, brand, locale, or team scope.

Access control

Permissions are property-specific. A path-level URL-prefix property can give a regional or product team access to only its reporting property. However, a verified owner of a containing parent property has implicit owner rights on child properties, so a child property is not isolation from the parent owner.

Report eligibility

Some reports require a root-level property. Crawl Stats, for example, is available for a Domain property or root-level URL-prefix property, not a path-only prefix. Do not create only directory properties and expect every technical report to be available.

When to choose a Domain property

Use a Domain property when:

You need a reliable total across HTTP and HTTPS.
The site uses www, non-www, or multiple subdomains.
New subdomains can appear without centralized SEO oversight.
You are monitoring a host, protocol, or subdomain migration.
Teams need a complete safety-net property in addition to their scoped views.
You want root-level crawling and site-health reports.

Domain coverage prevents a common failure: reviewing https://www.example.com/ while important data is recorded under https://example.com/, http://, or a subdomain.

When to choose a URL-prefix property

Use a URL-prefix property when:

You cannot modify DNS but can verify through the site or an existing Google product.
You need a view for one locale such as /es/.
A team manages only /support/, /docs/, or a particular storefront.
You need to separate one subdomain or protocol operationally.
You want to link a deliberately scoped property to another product.
You want stable directory reporting without rebuilding filters for every analysis.

URL-prefix properties do not change canonicalization or tell Google to treat a directory independently. They only define reporting and management scope.

Why many sites should create both

A practical architecture is:

One Domain property as the comprehensive source of truth.
A root HTTPS URL-prefix property when product associations or operational workflows benefit from that exact scope.
A small number of path or subdomain URL-prefix properties for durable business units, countries, or access boundaries.

This provides full coverage without forcing every user to work in an unmanageably broad property.

Do not create a property for every temporary campaign or content folder. Search Console allows up to 1,000 properties per account, but the more important costs are permissions, ownership tokens, integrations, dashboards, and maintenance.

Filters versus separate properties

Use a Performance page filter when you only need an ad hoc analysis and everyone can access the parent property. Use a separate URL-prefix property when the segment is durable and one or more of these apply:

Different people need access.
An integration must use that scope.
The segment needs its own persistent report history and messages.
Teams repeatedly make the same scoped analysis.
A property-specific setting or workflow is required.

Remember that many reports show examples rather than a complete export. A path filter in Performance and a path-level property are not interchangeable with a full crawler or database inventory.

Canonical attribution can cross your intended boundary

Performance is normally credited to Google's selected canonical. If a URL under /fr/ canonicalizes to a URL outside the /fr/ URL-prefix property, the scoped property may not receive the expected page-level data.

Before concluding that a directory has no visibility:

Inspect representative URLs.
Check the Google-selected canonical.
Confirm that the canonical falls inside the property.
Compare with the Domain property.

Read Canonical URL data attribution for the full reporting rule.

Adding a property and data availability

Adding a property does not alter how the site appears in Google. Google says data collection begins when anyone adds the property to Search Console, even before verification, and it takes a few days for data to accrue.

A new property is not guaranteed to contain historical data from before it was added. Create important parent and segment properties before a migration or launch rather than waiting for an incident.

Common setup mistakes

Creating only http:// when the site runs on HTTPS.
Forgetting www or another active host in a URL-prefix property.
Trying to include a path in a Domain property.
Assuming a Domain property is the same as a root URL-prefix property.
Creating so many properties that ownership and integrations become ungovernable.
Giving owners of the parent property access without realizing that child ownership is inherited.
Comparing properties with different scopes as if their totals should match.
Ignoring canonical URLs that fall outside a directory property.
Deleting verification tokens during a deployment cleanup.

Decision checklist

List every active protocol, host, and business-critical path.
Create a Domain property when DNS access is available.
Identify durable segments that need separate users, integrations, or monitoring.
Create exact URL-prefix properties for only those segments.
Verify at least two appropriate organizational owners.
Document the property scope and purpose.
Review access and verification tokens quarterly.
Revisit the model during migrations, acquisitions, and international expansion.