How can you effectively manage thousands of subdomains in Search Console?

What was the problem with the 1000 property limit?

For sites using a multi-subdomain architecture, this constraint quickly became unmanageable. International e-commerce platforms with a subdomain for each country, media outlets with regional editions, or SaaS solutions with a subdomain for each client could easily exceed this limit.

Practically speaking? This forced the creation of multiple distinct Search Console accounts, fragmenting data and complicating day-to-day operations. An urgent URL removal across several subdomains required logging into different accounts, increasing the risk of error and response time. The big picture of crawling and organic performance also became fragmented.

How does domain property verification change the game?

The domain property introduced by Google resolves this issue in one fell swoop. Instead of verifying each subdomain individually (blog.site.com, shop.site.com, support.site.com), you verify the root domain just once via a DNS TXT record.

This verification automatically covers all existing and future subdomains, with no limit on the number. There’s no need to create a new property every time a subdomain is launched. Both HTTP and HTTPS versions are included, further simplifying the initial setup.

What data is aggregated in a domain property?

The domain property provides a consolidated view of all your subdomains: overall search performance, indexing coverage, mobile usability issues, Core Web Vitals. You can then filter by specific subdomain to analyze granular performance.

This is particularly powerful for identifying cross-cutting trends: an algorithm update impacting multiple geographies, a technical problem spreading across the infrastructure, or common keyword opportunities to exploit. Comparing between subdomains also becomes more straightforward without tedious export-import processes between distinct properties.

• A domain property automatically covers all current and future subdomains of the root domain
• The limit of 1000 properties per account remains applicable if you verify each subdomain individually
• Verification is done via a DNS TXT record at the registrar or hosting provider
• Data is aggregated with the possibility of filtering by subdomain in reports
• Requests for urgent URL removals can be managed from a single interface for all subdomains

Does this solution truly meet the needs of complex architectures?

For most cases, yes. The domain property drastically simplifies daily management and avoids the headache of multiple accounts. But let's be honest: it's not without trade-offs.

The main downside concerns the granularity of permissions. With individual properties, you could grant access to the France marketing team only to fr.site.com, and to the Germany team only to de.site.com. With a domain property, it's all or nothing — everyone sees all subdomains. For large organizations with siloed teams, this can pose data governance issues.

Should we abandon individual properties then?

Not necessarily. A hybrid approach remains perfectly viable: using a domain property for the overall view and maintaining individual properties for critical subdomains that require close monitoring or specific permissions.

For example, if your e-commerce subdomain generates 80% of traffic, having a dedicated property allows for more responsive monitoring and targeted alerts. [To be verified]: Google has never clearly documented whether data aggregation in a domain property introduces a time lag compared to individual properties, but feedback suggests a slightly higher latency on some reports.

Does this limit of 1000 properties highlight other structural constraints?

Absolutely. It showcases that Search Console is still designed for traditional sites rather than modern distributed infrastructures. SaaS platforms with thousands of dynamically generated subdomains are clearly not Google's priority use case.

And that’s where the friction is: even with a domain property, some functionalities remain limited. For example, URL parameters must be configured separately for each subdomain if you are using individual properties in addition. The Search Console API itself imposes quotas that can become restrictive for large-scale data extractions across multiple subdomains.

How can you concretely set up domain property verification?

The procedure is relatively simple but requires access to the DNS zone of your domain. In Search Console, select "Add property" and then choose "Domain" (not "URL prefix"). Google then provides you with a TXT record to add to your DNS configuration.

Once the record is published, DNS propagation usually takes a few minutes, but may take up to 48 hours depending on your hosting provider. Google then automatically verifies the record. Crucial point: this record must remain in place indefinitely — its removal revokes verification and access to data.

What mistakes should absolutely be avoided during migration?

The first mistake is to delete existing individual properties as soon as the domain property is active. You will lose the history of these properties, which is not retroactively merged into the domain property. Keep the old properties alongside for at least 3-6 months to compare data and validate consistency.

The second pitfall: neglecting user and permission configuration. As mentioned, a domain property grants access to all subdomains. Audit your current access before migrating and clearly document who needs access to what. In some cases, maintaining individual properties with restricted permissions remains preferable.

How can you check that the configuration works correctly after migration?

Test URL removal requests across different subdomains to confirm that the domain property adequately covers them. Also, check that performance data appears correctly for each subdomain in the report filters.

Compare key metrics (impressions, clicks, indexed pages) between your old individual properties and the new domain property filtered by the same subdomain. Minor discrepancies are normal, but significant differences indicate a configuration or scope issue.

• Obtain administrator access to the DNS zone of the root domain before starting
• Add the TXT record provided by Search Console to the DNS configuration
• Wait for full DNS propagation (checkable via tools like whatsmydns.net)
• Keep existing individual properties alongside for a minimum of 3-6 months
• Audit and reconfigure user permissions considering the broader visibility
• Test critical functionalities (URL removals, URL inspection) across multiple subdomains