When you add a property to Google Search Console, the first decision is whether to verify it as a Domain property or a URL prefix property. The two look similar but cover different scopes, support different verification methods, and have different implications for what data you'll see in reports.
The short answer: domain property is the recommended default. URL prefix property is appropriate when you need fine-grained control over which subdomain or URL path is tracked separately.
The Core Difference
| Aspect | Domain Property | URL Prefix Property |
|---|---|---|
| Scope | All subdomains + HTTP & HTTPS | Exactly the URL prefix you enter |
| Verification | DNS TXT record only | HTML file, meta tag, GA, GTM, or DNS |
| Data unified across protocols/subdomains | Yes | No — each prefix is separate |
| Best for | Most sites (recommended) | Subdomain segmentation, language paths, parts of a larger site |
| Setup complexity | Higher (requires DNS access) | Lower (file or tag-based options) |
What "Scope" Actually Means
A domain property for example.com covers:
http://example.comhttps://example.comhttp://www.example.comhttps://www.example.comhttps://blog.example.comhttps://shop.example.com- Any other subdomain you create
All data from all of these appears under a single property in GSC.
A URL prefix property for https://example.com/ covers only:
https://example.com/*— URLs starting with that prefix
That excludes the HTTP version, the www subdomain, blog subdomain, and any other subdomain. Each variation needs its own URL prefix property if you want to track it.
When to Use Each
Use a Domain Property When:
- You want consolidated reporting across all subdomains and protocols (most common case)
- You're not sure which subdomains will exist in the future and want automatic coverage of new ones
- You have or can get DNS access to add a TXT record
- You want access to the latest GSC features — many newer features (like the November 2025 native branded queries filter) require a domain property
Use a URL Prefix Property When:
- You don't have DNS access and need to verify via HTML file, meta tag, GA, or GTM
- You want to track a specific subdomain or URL path separately from the rest of the site (e.g.,
example.com/blog/tracked apart from the main domain) - You're an agency verifying access to a specific portion of a larger client site
- You manage international or multi-language sites where each country path needs its own performance view
The Practical Pattern: Both
Many sites benefit from having both a domain property (for site-wide overview) and URL prefix properties for specific paths or subdomains (for granular tracking). For example:
example.com— Domain property, site-wide viewhttps://example.com/blog/— URL prefix, blog-specific performancehttps://shop.example.com/— URL prefix, e-commerce-specific trackinghttps://example.com/en-gb/— URL prefix for UK-specific data
The domain property gives you the big-picture report. The URL prefix properties give you isolated views for parts of the site that have different stakeholders, different performance dynamics, or different SEO ownership.
Where the Choice Affects Your Data
Branded Queries Filter
Google's native branded queries filter (launched November 2025) is only available on eligible domain-level properties. Per Google's announcement, URL prefix properties are not eligible. If you want the native branded/non-branded split, you need a domain property.
Cross-Subdomain Reporting
A domain property shows you queries that drove clicks to any subdomain in a single report. A URL prefix setup forces you to look at each subdomain separately and manually combine the data — which produces incorrect totals if a single query drove clicks to multiple subdomains (impressions get counted in each prefix's report).
BigQuery Export
The BigQuery bulk data export can be enabled on either property type. For domain properties, the export contains data for all subdomains under that domain. For URL prefix properties, the export contains data only for URLs matching that prefix. If you want unified historical data across all subdomains, the domain property is the clean source.
Granular Geographic / Language Tracking
For international sites with separate URL paths per country/language (/en-gb/, /fr/, /de/), URL prefix properties give you per-market reporting that's awkward to extract from a domain property's aggregated view. This is the strongest case for using URL prefix properties deliberately alongside a domain property.
Migration: Switching From URL Prefix to Domain
If you originally set up GSC as URL prefix and want to move to domain property:
- Add the domain property in addition to the existing URL prefix property
- Verify it via DNS TXT record
- The domain property starts collecting data going forward (no historical migration)
- Keep the URL prefix property as well — it preserves access to your existing historical data
- If you have a BigQuery export on the URL prefix property, set up a new export on the domain property too
Don't delete the URL prefix property when you add the domain property — they complement each other rather than replacing each other.
Common Mistakes
- Setting up multiple URL prefix properties for variations that should be one domain: Adding
http://,https://,http://www., andhttps://www.as four separate URL prefix properties when one domain property would cover all four - Verifying via Google Analytics when DNS is available: The GA verification is the fastest but the most fragile (it breaks if the GA tag is later removed or if account permissions change). For long-term stability, DNS-based domain property verification is more robust.
- Not knowing the property type until it matters: Some features check property type and either work or don't. Check your existing properties before requesting features that depend on domain-level verification.
For Agencies Specifically
Agency-side, the recommendation is to ask clients to set up DNS-verified domain properties as the primary GSC configuration, then grant the agency Full user access via User Management.
This pattern:
- Avoids the agency holding Owner-level access (which complicates offboarding)
- Gives consolidated reporting across all client subdomains by default
- Provides eligibility for newer GSC features that require domain-level verification
- Avoids the access loss that happens when GA or GTM verification breaks during a site redesign
Our agency-specific post on multiple GSC properties goes deeper into the operational patterns at scale.
The choice between property types is a one-time decision but a load-bearing one. Getting it right at setup saves you from migration work later and ensures you have access to the GSC features that progressively require domain-level verification.