Part of the SiteMap Series
In the previous three modules, you built a complete understanding of how XML sitemaps work. Module 1 covered what sitemaps are and the principles behind them. Module 2 covered the workflow of building, submitting, validating, and maintaining a sitemap. Module 3 covered the four specialised sitemap types (image, video, news, hreflang) and the alternative formats. Across twenty-nine lessons, the focus was on the rules: what the spec says, what the engines respect, what good practice looks like.
This module starts from a different angle. The rules are the same, but the application differs by site type. An e-commerce catalogue with faceted navigation does not produce a sitemap the same way a content blog does. A JavaScript-heavy single-page app does not surface its URLs the same way a server-rendered site does. A site mid-migration has different sitemap concerns than a stable site. The sitemap principles do not change, but the decisions you make around them do.
This lesson sets up the module by walking through why site type matters, where Modules 1 to 3 left assumptions that real sites force you to question, and what the next seven lessons will address. You will leave with a working understanding of where the friction between sitemap theory and sitemap practice tends to show up, and why each of the upcoming applied scenarios deserves its own treatment.
Where Modules 1 to 3 left you
Modules 1 to 3 taught the sitemap protocol as the spec describes it.
You know what a sitemap is, why it exists, and what the search engines do with it. You can build one through any of the three main paths (WordPress plugin, manual XML, static site generator). You can submit it to Google Search Console and Bing Webmaster Tools, validate it, fix the common errors, and maintain it over time. You can extend it with image, video, news, and hreflang elements for specialised content. You understand the alternative formats (RSS, Atom, plain text) and when they help. You can architect the whole thing for sites of different sizes, knowing when to combine inline and when to separate into a sitemap index.
That is a complete grasp of the spec. It is enough to set up a working sitemap on most sites. But it leaves a layer of decisions that the spec does not address: the decisions that come from your specific site type, your content model, your team structure, and the constraints of your platform.
These decisions are not optional. Real sites have to make them. A general-purpose sitemap tutorial cannot make them for you because they depend on context that varies by site.
Why those fundamentals need adaptation in practice
Three concrete examples make the friction clear.
The “include canonical URLs” principle, applied to an e-commerce site with faceted navigation
The spec is straightforward: include the URLs you want indexed and exclude the URLs you do not. In practice, an e-commerce site with faceted navigation generates URLs by the thousand. Filtering by colour creates a URL. Filtering by size creates another. Filtering by price range creates another. Combining three filters creates yet another. Most of these are not canonical pages, but some are (a “red trainers” filter page might be a legitimate landing page for that search intent). Deciding which faceted URLs go into the sitemap and which do not is a content strategy decision that the spec does not help you with.
The “include accurate lastmod” principle, applied to a JavaScript-heavy single-page app
The spec says lastmod should reflect when the page content meaningfully changed. On a server-rendered site, that is a tracked event (the CMS records it). On a single-page app where routes are rendered client-side and content is fetched from APIs, “when did the page change” is harder to answer. The route exists permanently in the build, but the content shown at that route changes when the underlying data changes. Lastmod could mean the build date, the data update date, or something in between. The spec does not tell you which to use.
The “remove URLs that no longer exist” principle, applied during a site migration
The spec says your sitemap should reflect URLs that currently exist on your site. During a migration, that becomes complicated. You might have new URLs that already work but are not fully promoted yet. You might have old URLs that 301 to new ones but are still appearing in search. You might have a brief window where both versions of a URL coexist. The order in which you update the sitemap, the redirects, and the canonical tags affects how the engines process the migration. The spec is silent on this orchestration.
In each case, the underlying principle from Modules 1 to 3 is correct. The application is not obvious. That is what Module 4 addresses.
The site types this module addresses
Seven lessons in this module take the fundamentals from Modules 1 to 3 into specific scenarios.
- E-commerce sites (Lesson 2). The friction between sitemap principles and the realities of product catalogues, faceted navigation, out-of-stock handling, sale collections, and category-product hierarchies. The lesson that addresses the most common technical SEO consulting question across the industry.
- JavaScript sites and single-page apps (Lesson 3). How sitemaps work when client-side routing controls the URL space, how rendering timing affects discovery, and how to handle dynamic routes that the build process does not enumerate.
- Site migrations (Lesson 4). Sitemap strategy during URL changes, 301 redirects, lastmod signalling, and the timing of sitemap updates relative to the rollout. The high-stakes scenario where small sitemap decisions can preserve or sacrifice rankings.
- Multi-region and subdomain architecture (Lesson 5). How sitemaps work across multiple subdomains, regional setups (ccTLDs, subdirectories, subdomains), and the relationship with hreflang from Module 3 at scale.
- Crawl budget and sitemaps at scale (Lesson 6). What happens when a site has millions of URLs and the sitemap setup becomes a generation pipeline, a delivery infrastructure consideration, and a crawl budget signalling tool.
- AI crawlers and your sitemap (Lesson 7). How GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and the other AI crawlers interact with sitemap data. What they extract, what they ignore, and how llms.txt fits alongside the sitemap conversation.
- The sitemap audit framework (Lesson 8). The synthesis closer. A structured audit framework that brings Modules 1 to 4 together into a checkable process you can apply to any site.
A framework for thinking about sitemaps in your specific context
Three questions cut through most of the friction between sitemap theory and sitemap practice. You will see these three questions reappear in every lesson of this module, asked through the specific lens of each site type.
What URLs should appear in your sitemap?
This is the canonical question. For a content blog, the answer is straightforward (the published posts and pages). For an e-commerce site, it depends on which faceted variations you treat as canonical landing pages. For a JavaScript site, it depends on which dynamic routes you can enumerate at build time. For a migration, it depends on where you are in the cutover process. The answer always starts with the same principle (include what you want indexed) but the application varies.
How fresh do the freshness signals need to be?
Lastmod is supposed to reflect when content meaningfully changed. For a static blog, that is the publish date or the most recent edit date. For an e-commerce site, content changes constantly (prices, stock, reviews, descriptions) and not all changes warrant a lastmod update. For a news site, lastmod might need to be accurate to the minute during the 48-hour news window. For an enterprise site at scale, generating accurate lastmod for every URL on every change becomes a pipeline problem.
Where does sitemap responsibility sit in your team and platform?
In a WordPress site with Yoast or Rank Math, the SEO plugin owns sitemap generation. In a static Next.js site, the build process owns it. In a headless CMS with a custom frontend, ownership is split between the CMS and the rendering layer. In an enterprise setup with multiple subdomains and a content network, ownership might be spread across multiple teams. Knowing where sitemap decisions are made (and where they should be made) determines what changes are even possible.
These three questions are not exhaustive, but they catch most of the decisions Module 4 will help you work through.
Where this leaves us
You now have the orientation for Module 4. The next seven lessons will take the fundamentals from Modules 1 to 3 into specific applied scenarios where sitemap setup actually matters most.
E-commerce sites come first. They are the highest-traffic source of sitemap questions in Technical SEO consulting work, partly because the friction between sitemap principles and product catalogue realities is so visible. Faceted navigation generates URLs that the spec does not know how to categorise. Out-of-stock products raise the question of when to remove a URL versus keep it indexed. Sale and seasonal collections create temporary canonical landing pages. The next lesson walks through the decisions e-commerce sitemaps actually require.
Up next: How to Create a Sitemap for an E-commerce Site →
This is Module 4: Lesson 1 of The Sitemap Series, a Technical SEO series on sitemaps from first principles, built for the AI Search era.