Should you really migrate to domain properties in Search Console?

What exactly is a domain property?

A domain property automatically aggregates all variations of a domain: HTTP, HTTPS, www, non-www, subdomains. Instead of juggling multiple distinct Search Console properties, you centralize the data.

To create it, you need to prove that you control the entire domain — via a DNS TXT record. This is more demanding than a simple HTML tag verification, but it's exactly what guarantees the big-picture view.

Why is Google pushing this approach now?

The fragmentation of Search Console data is a recurring problem. Many sites use multiple protocols or subdomains without realizing it — a blog on blog.example.com, an app on app.example.com, poorly configured redirects.

The result: crawl, indexing, and performance data are scattered. Some SEOs miss critical issues simply because they are not looking at the right property. Google wants to reduce this friction.

Does this replace traditional properties?

No. Google explicitly states that you can combine both. A domain property provides an overall view, but it doesn’t always allow for fine data filtering by URL prefix.

If you want to isolate the performance of a specific subdomain or directory, you'll still need a traditional property. The two approaches are complementary — not exclusive.

• A domain property centralizes all variations (www, non-www, subdomains, protocols)
• Verification is done via DNS TXT, more stringent but more comprehensive
• It does not replace traditional properties — combining them provides more flexibility
• Particularly useful for complex sites with multiple subdomains or mixed configurations
• Simplifies the detection of global anomalies (crawl, indexing, coverage)

Is this recommendation really new?

Let's be honest: domain properties have been around for years. What Mueller is doing here is reminding everyone of a good practice often overlooked. Many SEOs still exclusively use URL prefix properties, out of habit or ignorance.

What's interesting is that Google now emphasizes 'when possible.' This implies it’s not always applicable — especially for sites where you don’t control the DNS, or in certain locked hosting configurations.

What nuances should we consider in practice?

First nuance: not all reports are the same in a domain property. Some filters available in traditional properties may be missing. If you want to analyze the performance of a specific directory (/blog/), the domain property alone may not suffice. [To be verified] — Google has never specified the roadmap for missing features.

Second nuance: DNS TXT verification can pose challenges in multi-agency environments or with registrar access restrictions. I have seen clients blocked for weeks because the IT team refused to provide DNS access. In such cases, the domain property remains a theoretical ideal.

In what cases does this approach not apply?

If you manage a site on a SaaS platform where you don't have control over the DNS (certain white-label CMSs, closed e-commerce solutions), you are stuck with traditional properties. The same goes for complex multi-site setups where different parties control different subdomains.

Another boundary case: domain migrations. During a transition, you often need to maintain two distinct domain properties to track both scopes. Automatic aggregation then becomes a bug, not a feature. Again, combining with traditional properties saves the situation.

What should you do concretely if you haven’t set up a domain property yet?

First step: access your domain's DNS. You'll need to add a TXT record provided by Search Console. If you don't have access, contact your hosting provider or IT team before starting — otherwise, you'll waste time.

Once the property is created, do not delete your existing properties. Keep them active to compare data and ensure everything is reporting correctly. Some reports may show temporary discrepancies for a few days — that’s normal.

What mistakes should be avoided during the migration?

Common mistake: creating a domain property and immediately deleting all traditional properties. You then lose the granularity needed to isolate issues by subdomain or section. Both approaches coexist — it's not one or the other.

Another pitfall: forgetting to check that all active subdomains are properly reflected in the domain property. If you have an old, semi-abandoned blog.example.com still generating traffic, it needs to appear in the data. Check the index coverage to confirm.

How to check if the configuration is correct?

In Search Console, compare coverage data between your domain property and your traditional properties. The total number of indexed pages should be consistent — with a few discrepancies related to refresh timings.

Especially monitor crawl errors and penalty messages. They should appear in the domain property if a problem affects the entire site. If you see alerts only in a traditional property, it indicates a localized issue — exactly what we want to be able to diagnose.

• Ensure you have access to the domain's DNS before starting
• Create the domain property without deleting existing traditional properties
• Compare coverage data between the domain property and traditional properties for 2-3 weeks
• Ensure all active subdomains are reflecting properly in the domain property
• Keep traditional properties for granular analysis by directory or subdomain
• Document DNS access in your process to facilitate future checks