About XML Sitemaps
What is an XML sitemap?
An XML sitemap is a machine-readable list of the pages on a site that you want search engines to know about, usually annotated with when each was last changed. It is written for crawlers rather than people, which is why it looks like a data file instead of a page.
It is a hint, not an instruction. Listing a page does not guarantee it will be indexed, and omitting one does not prevent it. What a sitemap does is remove the discovery problem: rather than finding your pages by following links and hoping the path is short enough, a crawler is handed the list. An XML sitemap generator produces that list by crawling your site the way a search engine would, which also has the useful side effect of showing you which pages are actually reachable.
That last point is worth dwelling on. A page missing from a generated sitemap is usually missing because nothing links to it, and an orphan page is a problem the sitemap cannot solve on its own.
Do XML sitemaps still matter in 2026?
For a small, well-linked site they add little. Search engines are good at following links, and a fifteen page site is not a discovery challenge.
For everything else they remain valuable, and for three distinct reasons. Large sites have pages buried too deep to be crawled promptly. Sites publishing frequently need new content noticed quickly. And any site with archives has pages that no longer receive internal links but still deserve to be indexed.
They are also the cheapest diagnostic available. Comparing the number of URLs submitted against the number indexed exposes problems that nothing else surfaces as clearly, which is often reason enough to run an XML sitemap generator even on a site that does not strictly need one.
How sitemaps relate to AI search
AI crawlers face the same discovery problem as search crawlers, and a sitemap is the same shortcut. Content that is hard to reach by following links is content that may simply never enter the pool a model draws on.
The last-modified dates carry more weight here than they used to. Freshness is a strong signal when a system is choosing between several sources on a subject that changes, and an accurate modification date is one of the few pieces of provenance a site can state directly.
That makes honesty about those dates more valuable than keeping them recent. A site that resets every date on every build is telling crawlers nothing, and teaching them to disregard the field.
Sitemap best practices
- Include only canonical, indexable URLs that return a 200 status.
- Leave out redirects, blocked pages and anything marked noindex; contradictory signals get disregarded.
- Keep last-modified dates accurate rather than resetting them on every deployment.
- Split into multiple files with an index once you pass 50,000 URLs or 50MB uncompressed.
- Reference the sitemap from robots.txt and submit it in Search Console.
- Regenerate it when the site changes structurally, not once at launch and never again.
Common mistakes
- Listing URLs that redirect, which wastes crawl effort and muddies the canonical picture.
- Including noindexed pages, telling a crawler to fetch something you have told it to ignore.
- Mixing protocols or hostnames, so the sitemap disagrees with your canonical URLs.
- Letting it go stale until it describes a site structure that no longer exists.
- Treating submission as the goal. A submitted sitemap that is never checked against index coverage tells you nothing.
Using the XML sitemap generator
Enter your domain and the tool crawls the site, following links to build a list of reachable pages, then produces a standards-compliant XML file to download and upload to your domain root.
Read the results before you publish them. Pages you expected and cannot see are usually orphans, and pages you did not expect are often duplicates thrown off by parameters or pagination. Both are worth fixing at the source rather than editing out of the file, since the sitemap is a symptom of the site structure rather than a substitute for it.
Where to go next