Should you really place your sitemap at the root of your domain?

What is the default scope of a sitemap placed in a subdirectory?

Mueller's statement highlights a lesser-known rule: a sitemap file stored in a subdirectory has a limited scope by default. Specifically, if you place sitemap.xml in example.com/blog/, this file can only reference URLs starting with example.com/blog/.

This restriction is due to considerations of security and permissions. Google assumes that a file located in /blog/ doesn't have the authority to declare URLs that are located at the root or in other directories. A subfolder cannot ‘pretend’ to represent the whole domain without explicit validation.

How does Search Console change this limitation?

Mueller indicates that physical placement becomes secondary if the sitemap is correctly configured in Google Search Console. Once manually declared in GSC, the file can reference any URL in the verified domain, regardless of its physical location.

This flexibility is particularly useful in complex architectures where different subdirectories are managed by distinct teams or systems. A technical sitemap can reside in /seo-tools/ while covering the entire site, provided it is registered in GSC with the appropriate permissions.

Does this rule also apply to the robots.txt file?

The declaration via robots.txt follows exactly the same logic. If you specify “Sitemap: https://example.com/blog/sitemap.xml” in your robots.txt at the root level, you are explicitly granting permission for this file to cover the entire domain.

Without this explicit declaration (robots.txt or GSC), the sitemap remains confined to its subdirectory. This double layer of validation—physical location AND explicit declaration—serves as a security mechanism against malicious sitemap injections.

• A sitemap in a subdirectory only covers that subdirectory by default
• Declaration in Search Console or robots.txt expands this scope to the entire verified domain
• This restriction aims to prevent partial server access from manipulating global indexing
• Physical placement matters little once the GSC configuration is correctly done
• The same rule applies for image, video, or news sitemaps

Is this limitation really enforced in practice?

Field tests confirm that Google strictly applies this rule for automatically discovered sitemaps. If Googlebot finds a sitemap.xml in /resources/ without an explicit declaration, it will ignore the URLs located outside of that directory. I have observed this behavior in multiple audits where root URLs were not crawled despite their presence in an 'orphaned' sitemap.

On the other hand, the flexibility of Search Console is real. Once the sitemap is manually registered in GSC, Google respects the declared scope regardless of the physical path. This approach allows for hybrid configurations that are useful for large sites with distributed architecture.

What pitfalls await ill-informed SEOs?

The classic trap: deploying a sitemap in a subdirectory, indexing it correctly in GSC, then changing the URL without updating the declaration. The new file will be discovered but limited to its subdirectory, creating a gap in indexing coverage. [To verify] on sites with multiple sitemap migrations.

Another common confusion: believing that presence in robots.txt is sufficient. If robots.txt points to /blog/sitemap.xml but that file lists root URLs, Google will crawl them... but could apply a reduced trust compared to a sitemap declared from the root AND in GSC. This double validation strengthens the legitimacy of the file.

Does this rule vary according to the types of sitemaps?

The logic applies equally to index, image, video, and news sitemaps. A video sitemap in /media/video-sitemap.xml can only reference URLs /media/* unless explicitly declared. This consistency simplifies SEO governance for large sites.

Interesting point: dynamically generated sitemaps (for example: /sitemap.php?type=blog) follow the same rule based on their apparent URL, not their server logic. If the displayed URL is /blog/sitemap.php, the limitation applies even if the PHP script generates global URLs. Only the URL as Google sees it matters.

Where should you actually place your sitemap files?

The best practice remains placing it at the root of the domain: example.com/sitemap.xml for the main sitemap, with index sitemaps as necessary. This approach avoids any ambiguity and works even if the GSC configuration is accidentally removed.

For multi-section architectures (blog, e-commerce, documentation), prioritize an index sitemap at the root pointing to thematic sitemaps: /blog/sitemap.xml, /shop/sitemap.xml. Declare each file individually in GSC to ensure complete and trackable coverage.

How can you check that the current configuration is correct?

In Search Console, under the Sitemaps section, check that all declared sitemaps show a “Success” status with a consistent number of discovered URLs. A sitemap that lists 5000 URLs but only retrieves 200 likely indicates a scope issue.

Use a crawler like Screaming Frog or OnCrawl to cross-check the URLs present in your sitemaps with those that are actually indexed. A significant gap between submitted URLs and indexed URLs may indicate an undetected scope limitation, especially if the missing URLs are outside the sitemap’s directory.

What mistakes should you absolutely avoid?

Never deploy a sitemap in a subdirectory without explicit validation in GSC or robots.txt. This silent configuration fails without generating any visible alerts, creating indexing gaps that are hard to diagnose. Google won't notify you that 60% of your sitemap is being ignored.

Also, avoid multiplying redundant sitemaps in different directories. The same set of URLs declared in /sitemap.xml and /blog/sitemap.xml creates confusion for crawl budget and dilutes priority signals. Each URL should appear in only one canonical sitemap.

• Place the main sitemap at the root of the domain (example.com/sitemap.xml)
• Explicitly declare each sitemap in Google Search Console
• Ensure that the robots.txt file correctly references the sitemaps in use
• Regularly audit the consistency between submitted URLs and indexed URLs
• Avoid orphaned sitemaps in subdirectories without GSC declaration
• Document the architecture of sitemaps to facilitate maintenance by teams