Part of the SiteMap Series
In the previous lesson, you saw how sitemaps need to coordinate with redirects and canonical tags during a migration. Multi-region and subdomain sites introduce a different kind of friction: the URL space is split intentionally across multiple subdomains or domains, and the sitemap setup has to work across that split rather than against it.
The challenge has a specific constraint at its core. A sitemap can only list URLs on the domain or subdomain where the sitemap itself is hosted. Search Console rejects sitemap entries that point to URLs outside the property the sitemap is submitted to. This rule, which most documentation mentions in passing, shapes every other decision about multi-region and subdomain sitemap architecture. If you have a site split across three subdomains, you need at minimum three sitemaps, one per subdomain. If you have a multi-region site on three ccTLDs, you need three sitemaps, one per ccTLD. The split is structural; the sitemap follows the same split.
This lesson covers why multi-region and subdomain sites need a different sitemap setup, the cross-domain rule that drives the architecture, how to handle the three main multi-region patterns (ccTLDs, subdomains, subdirectories), how subdomain architecture beyond regions works (blog, app, docs splits), and how robots.txt fits into multi-property sitemap discovery.
Why multi-region and subdomain sites need a different sitemap setup
Three properties of multi-region and subdomain architecture create the sitemap complications.
The URL space is split across multiple origins. A traditional single-domain site has one origin (https://www.example.com) and one sitemap covers everything. A multi-region site might have three origins (example.de, example.fr, example.com) or three subdomains (de.example.com, fr.example.com, www.example.com). Each origin is a separate entity from the search engine’s perspective, and each needs its own sitemap.
Search Console treats each origin as a separate property (with one exception). Properties can be URL-prefix properties (https://blog.example.com/) or Domain properties (example.com, covering all subdomains and protocols). A URL-prefix property for https://www.example.com/ does not include URLs from https://blog.example.com/. The exception is the Domain property type, which covers everything under the apex domain, but even then, sitemap submission is still per-subdomain (you cannot submit a single sitemap covering all subdomains).
Relationships between regions or subdomains need explicit signalling. The engines do not assume that example.com/fr/ and example.fr/ are alternate versions of the same content. The relationship between a sitemap entry on one domain and a related entry on another domain has to be signalled through hreflang (for region relationships) or implicit content equivalence (which is unreliable). The sitemap is one of the places where those signals can be set.
The rest of this lesson works through how each architectural pattern handles these properties.
The cross-domain sitemap rule
The single most important rule for multi-region and subdomain sitemaps is this: a sitemap can only list URLs on the same domain or subdomain where the sitemap is hosted.
A sitemap hosted at https://www.example.com/sitemap.xml can only list URLs starting with https://www.example.com/. It cannot include URLs from https://blog.example.com/ or https://example.de/. If you include cross-domain URLs in a sitemap, Search Console flags them as outside the property and ignores them.
This rule exists because sitemap submission is tied to property ownership in Search Console. You can only submit a sitemap for a property you have verified, and the engines only accept sitemap signals for URLs the property covers. Cross-domain entries would let anyone signal canonical URLs for domains they do not own.
The practical implication: every distinct subdomain or domain needs its own sitemap, hosted on that subdomain or domain, submitted to a Search Console property for that subdomain or domain. There are no shortcuts that consolidate this into fewer files.
Two clarifications worth noting.
First, the rule applies per submission, not per file. A sitemap index file at https://www.example.com/sitemap_index.xml can reference multiple sub-sitemap files (https://www.example.com/sitemap-posts.xml, https://www.example.com/sitemap-products.xml), but all the sub-sitemaps must also be on www.example.com. The index cannot reference sub-sitemaps on different subdomains.
Second, hreflang in xhtml:link elements is the exception. A sitemap on www.example.com can include xhtml:link elements pointing to example.de URLs as hreflang variants. The xhtml:link does not act as a canonical signal for those URLs; it acts as a relationship signal connecting them to the canonical entries that live in the example.de sitemap. This is how hreflang from Lesson 5 of Module 3: How to Use Hreflang in Sitemaps for International SEO works at scale across multi-region sites.
Setting up sitemaps for the three main multi-region patterns
Multi-region sites use one of three URL patterns, each with its own sitemap setup.
1. ccTLDs (separate top-level domains)
Sites like example.de, example.fr, example.es are entirely separate domains from the engines’ perspective. Each domain has its own Search Console property, its own sitemap, and its own robots.txt.
The sitemap setup: each ccTLD has a sitemap at the standard location (example.de/sitemap.xml, example.fr/sitemap.xml, and so on). Each sitemap is submitted to the Search Console property for that domain. The hreflang relationships between the ccTLDs are declared either in the HTML head of each page or, more centrally, through xhtml:link elements in each sitemap.
The trade-off: ccTLDs are the most explicit signal of regional targeting (the engines treat them as regionally bound by definition) but they are also the highest maintenance setup. Each ccTLD is its own SEO entity with its own authority profile, its own sitemap, and its own Search Console.
2. Subdomains per region
Sites like de.example.com, fr.example.com, es.example.com use subdomains to separate regional content. From a sitemap perspective, this is structurally similar to ccTLDs because each subdomain is a separate property.
The sitemap setup: each regional subdomain has its own sitemap at the standard location (de.example.com/sitemap.xml, fr.example.com/sitemap.xml). Each sitemap is submitted to a Search Console property for the subdomain. Hreflang relationships between subdomains use xhtml:link elements in each subdomain’s sitemap.
The Search Console nuance: you can use URL-prefix properties (one per subdomain) or a Domain property (which covers all subdomains under example.com). Either works, but the Domain property is usually cleaner for sites with many subdomains. With either property type, the sitemaps are still per-subdomain; the property type only affects how reporting is grouped.
3. Subdirectories per region
Sites like example.com/de/, example.com/fr/, example.com/es/ use subdirectories to separate regional content. From a sitemap perspective, this is the simplest setup because everything is on the same domain.
The sitemap setup: one sitemap covers all regions, or a sitemap index references separate sub-sitemaps per region (one for /de/, one for /fr/, and so on). Hreflang relationships are declared through xhtml:link elements in the single sitemap or across the sub-sitemaps in the index.
The trade-off: subdirectories share the domain’s authority profile (which can help launch a new region) but the regional targeting signal is weaker than ccTLDs or subdomains. The sitemap setup is easier; the SEO signalling is less explicit.
How subdomain architecture beyond regions works
Subdomains are used for splits other than regions. blog.example.com for content marketing. app.example.com for the product interface. docs.example.com for documentation. shop.example.com for e-commerce. Each of these is a separate subdomain with its own sitemap.
The cross-domain sitemap rule applies the same way. Each subdomain has its own sitemap, hosted at that subdomain, submitted to a Search Console property for that subdomain.
Two patterns are worth being explicit about.
Blog on a subdomain, main site on www. This is common for sites that started with a separate blog platform (a WordPress install at blog.example.com while the main site is at www.example.com). The blog has its own sitemap; the main site has its own sitemap. They are two separate properties in Search Console.
The decision to consolidate (moving the blog to www.example.com/blog/) is covered in Lesson 4 of this module: How to Handle Your Sitemap During a Website Migration as a subdomain consolidation migration. From a sitemap perspective, the consolidation transforms two sitemaps into one (or one sitemap index covering everything).
Docs and app on separate subdomains. docs.example.com and app.example.com each have their own sitemap. Some docs sites have substantial content worth indexing; the docs subdomain’s sitemap covers all the doc pages. App subdomains often have very few indexable pages (most of the URLs are behind authentication), so the sitemap for the app subdomain is typically small or absent entirely.
The principle across all subdomain architectures: each subdomain that has content you want indexed needs its own sitemap. Subdomains that are entirely behind authentication or that serve no indexable content do not need a sitemap.
How robots.txt and sitemap discovery work across subdomains
Each subdomain has its own robots.txt file. The robots.txt at www.example.com/robots.txt applies only to www.example.com. The robots.txt at blog.example.com/robots.txt applies only to blog.example.com.
The Sitemap: directive in each robots.txt should reference the sitemap on the same subdomain. The robots.txt at www.example.com/robots.txt declares Sitemap: https://www.example.com/sitemap.xml. The robots.txt at blog.example.com/robots.txt declares Sitemap: https://blog.example.com/sitemap.xml.
You cannot declare cross-subdomain sitemaps in a robots.txt and expect the engines to treat them as canonical signals for the target subdomain. A Sitemap: directive in www.example.com/robots.txt pointing to blog.example.com/sitemap.xml would be technically valid syntax but the engines will not treat it as authoritative for blog.example.com. The sitemap needs to be referenced from the subdomain it covers.
The practical implication: when setting up a multi-subdomain architecture, configure each subdomain’s robots.txt to reference that subdomain’s sitemap. Audit each robots.txt independently to confirm the Sitemap: directive is correct.
For ccTLDs, the same rule applies at the domain level. example.de/robots.txt references example.de/sitemap.xml. example.fr/robots.txt references example.fr/sitemap.xml.
Common gotchas to avoid
Five issues come up regularly in multi-region and subdomain sitemap implementations.
1. Trying to list URLs from another subdomain in your sitemap
The most common mistake. A sitemap hosted at www.example.com/sitemap.xml includes some URLs starting with blog.example.com. Search Console flags these as outside the property and ignores them. The fix is to host a separate sitemap on the blog subdomain and submit it to a separate property.
2. One sitemap index referencing sub-sitemaps on different subdomains
A sitemap index at www.example.com/sitemap_index.xml references sub-sitemaps at blog.example.com/sitemap-posts.xml, docs.example.com/sitemap-docs.xml, and www.example.com/sitemap-main.xml. The engines reject the cross-subdomain references. The fix is to have a separate sitemap index per subdomain, each referencing only sub-sitemaps on the same subdomain.
3. Missing Search Console property for one of the subdomains
A site has www.example.com, blog.example.com, and docs.example.com. The www and blog subdomains have verified Search Console properties; the docs subdomain does not. The docs sitemap is hosted and the URLs are accessible, but no sitemap submission exists for them. The engines may still find the docs URLs through internal links, but the explicit sitemap signal is missing. The fix is to verify a property for every subdomain that has content you want indexed.
4. Broken hreflang implementation across multi-region sitemaps
Each regional sitemap declares hreflang relationships, but the implementations are inconsistent. The German sitemap references the French version with hreflang="fr", but the French sitemap is missing the back-reference to German. The hreflang relationship breaks (per Module 3 Lesson 5, bi-directional confirmation is required) and the regional targeting signal weakens. The fix is to verify hreflang consistency across all regional sitemaps in one sweep.
5. Sitemap on one subdomain getting stale while others stay current
A site with separate sitemaps on www.example.com and blog.example.com. The www sitemap is generated automatically on every deploy. The blog sitemap requires a manual regeneration step that gets forgotten. Over time, the blog sitemap falls behind, missing new posts and including retired ones. The fix is to automate sitemap generation on every subdomain that has content updates, with the same deployment trigger across all of them.
Where this leaves us
You can now set up sitemaps across a multi-region site, a multi-subdomain architecture, or any combination where the URL space is split intentionally. The cross-domain rule is the constraint that drives every other decision. Hreflang from Module 3 is the bridge that connects related URLs across the split. The structural sitemap-per-subdomain pattern is the operational consequence.
Crawl budget at scale comes next. Once a site has multiple subdomains, regional setups, or significant URL volume, the sitemap stops being just a discovery signal and becomes a tool for influencing how crawl budget is spent. The engines have finite crawl resources for any site; the sitemap is one of the few mechanisms you have for shaping how those resources get allocated across your URL space. The next lesson covers how sitemap structure, lastmod accuracy, and submission patterns affect crawl behaviour on large sites.
Up next: How Sitemaps Affect Your Crawl Budget at Scale →
This is Module 4: Lesson 5 of The Sitemap Series, a Technical SEO series on sitemaps from first principles, built for the AI Search era.