XML Sitemaps: How to Get Them Right
An XML sitemap lists the URLs worth crawling. Get the format, the sitemap index and the submission step right, or search engines mostly ignore it.
An XML sitemap is a file that lists your URLs so a search engine can discover and prioritise them, formatted to the sitemaps.org protocol, capped at 50,000 URLs or 50MB per file, and submitted through Search Console or Bing Webmaster Tools. It is a hint, not a guarantee of indexing.
Sitemaps are one line on the wider technical SEO checklist: easy to generate once and easy to leave stale for years afterward, which is worse than not having one.
On this page
What does an XML sitemap actually do?
It tells a search engine which URLs you consider worth crawling, and gives each one a rough signal of freshness through a lastmod date. That is the entire job: discovery and prioritisation, not a ranking factor and not a promise of indexing [2].
A sitemap earns its keep most on a large site, a new site with few external links, or a site where pages are hard to find by following internal links alone — a big catalogue with orphaned filter pages, for example. A small, tightly linked site can be fully crawled without one, though it still helps a crawler know what changed recently.
What it cannot do is override a quality decision. A URL can sit in a perfectly formed sitemap and still go unindexed if the crawler judges the page thin or duplicate once it gets there — that is a separate problem, covered in our piece on indexing problems, and a sitemap will not fix it.
Think of it as a priority queue rather than a guest list. Every URL you have already linked internally can usually be discovered by following links alone, so a sitemap's real value is telling a crawler which of those thousands of known URLs deserve attention first, and which ones changed since the last visit. That framing matters because it changes what "success" looks like: a sitemap working correctly does not mean every URL in it gets indexed, it means the crawler spends its limited attention on the URLs you actually consider worth that attention.
What has to be in each URL entry?
Four possible tags per <url> block, only one of which is required.
loc — required
The full, absolute URL, using the canonical version exactly as it should be indexed: correct protocol, correct trailing slash convention, no tracking parameters.
lastmod — recommended
An ISO 8601 date for when the page's content last meaningfully changed. Keep it honest — a lastmod that updates on every deploy regardless of content changes teaches crawlers to ignore the signal entirely.
changefreq and priority — largely ignored
Google has said for years that it does not use these two fields. They are harmless to include for other consumers of the protocol, but do not spend time tuning them.
Extensions for images, video and news
Dedicated namespaces let you attach `image:` or `video:` entries to a URL so that media on the page can be discovered alongside it, useful for image-heavy catalogue or media pages.
There is one more field worth naming even though the protocol does not require it: consistency between lastmod and what actually changed. A template that stamps every page with the current date on every deploy, regardless of whether the content moved, teaches a crawler that the field is meaningless for your site specifically, and it will start ignoring it. The fix is almost always in the build pipeline rather than the sitemap generator — lastmod should come from the content's own edit timestamp, not from when the site was last rebuilt.
What happens once you pass 50,000 URLs?
You stop submitting one file and start submitting an index of files. The protocol caps a single sitemap at 50,000 URLs or 50MB uncompressed, whichever comes first [4]; a sitemap index is itself a small XML file that lists the locations of several child sitemaps, and you submit the index rather than each child individually.
| Situation | What to submit |
|---|---|
| Under 50,000 URLs, under 50MB uncompressed | One sitemap.xml file |
| A catalogue or blog past either limit | A sitemap index pointing at several child sitemap files |
| Blog posts versus static marketing pages | Separate segments, e.g. sitemap-blog.xml and sitemap-pages.xml |
| Product or listing pages that change often | Their own segment, regenerated on a tighter schedule than the rest |
| Images or video tied to a page | image: or video: entries inside that page's existing URL block |
Splitting by content type is worth doing well before you hit the hard limit, because it gives you a smaller, faster-changing file for the section that actually updates often, instead of regenerating one enormous file on every publish.
How do you submit and confirm it is being used?
Point at it from robots.txt with a Sitemap: line, and submit it directly in each search engine's webmaster tool.
Add a Sitemap line to robots.txt
This is how a crawler that has never visited Search Console still discovers the file's location, and it is worth doing even if you also submit manually.
Submit it in Google Search Console
Under Sitemaps, enter the path and submit. Check back after a few days for the coverage numbers: submitted versus indexed, and any listed errors.
Submit it in Bing Webmaster Tools separately
Bing does not read Google Search Console submissions, and its own tools report crawl and index status independently [3].
Recheck coverage after any large content change
A migration, a bulk noindex rollout or a big pruning pass should be followed by a fresh look at the sitemap coverage report, not assumed to have gone smoothly.
Resubmitting the same file repeatedly does nothing extra. What matters is that the file itself updates automatically as pages are added, changed or removed, and that it stays reachable at a stable URL.
What mistakes make a sitemap actively harmful?
The most common one is a sitemap that disagrees with the rest of the site. Listing a noindex page, a redirected URL, or a URL blocked by robots.txt sends a crawler a contradictory signal and spends its attention confirming a page you already told it to skip.
A stale sitemap is the quieter version of the same mistake. A generator that ran once at launch and was never wired into the build pipeline slowly drifts from reality: new pages missing, removed pages still listed, lastmod frozen on a date from months ago. None of that breaks the site visibly, which is exactly why it survives so long unnoticed.
Does a sitemap actually change how much of a site gets crawled?
Indirectly, yes. A sitemap does not increase how often a search engine crawls your site overall — that ceiling is set elsewhere, by factors covered in our piece on crawl budget — but it does influence which URLs get whatever crawl attention is available.
The sitemap is the fastest way to tell a crawler what you actually care about, on a site where that isn't obvious from links alone. It's a much cheaper fix than most crawl-budget problems, and it's the first thing I check before touching anything more structural.
This matters most on large or messy sites, where thousands of low-value URLs — filtered views, tag pages, paginated archives — compete with the pages that actually earn revenue or rankings. A sitemap that lists only the URLs worth crawling, and excludes the rest, is a cheap way to point limited crawl attention at the right targets without touching the site's architecture at all.
How does a sitemap interact with canonicals, redirects and mobile pages?
It should only ever list the canonical version of a URL. If a page has a canonical tag pointing somewhere else, the sitemap entry should be the canonical target, not the page carrying the tag — mixing the two is one of the more common canonical tag mistakes on larger sites, and it teaches a crawler to distrust the file.
Redirects follow the same rule for a different reason: a sitemap full of 301s wastes a crawl on the old URL just to be told to go somewhere else. Once a migration or a URL structure change is final, run your redirect list against the sitemap and remove anything that now redirects — the same cleanup pass belongs in any 301 redirect project, not just a sitemap refresh.
Mobile is mostly a non-issue today because responsive design means one URL serves every device, so one sitemap entry covers it. The exception is a site still on separate mobile URLs, where each version needs its own correct entry rather than assuming the desktop sitemap covers both. If load time on those pages is the bigger concern, our guide to mobile page speed covers that separately from discovery.
Questions people also ask
Does a sitemap force Google to index every URL in it?
No. A sitemap is a hint about which URLs exist and are worth crawling, not an instruction to index them. Google still applies its own quality and crawl-priority judgment to every URL the sitemap lists.
How many URLs can one sitemap file hold?
Up to 50,000 URLs or 50MB uncompressed, whichever limit is reached first. A site past either limit needs a sitemap index file that points at several smaller sitemap files instead of one large one.
Should noindex pages be in the sitemap?
No. Listing a noindex page in your sitemap sends a contradictory signal — the sitemap says crawl and consider it, the meta tag says do not index it — and it wastes crawl attention on a URL you have already excluded.
Do I need to resubmit my sitemap every time I publish a page?
No, as long as the sitemap file itself updates automatically and search engines already know its location. Resubmitting the same URL in Search Console repeatedly has no extra effect; what matters is that the file's contents stay current.
Is a sitemap still worth having on a small site?
Yes, though the case is weaker. A small, well-linked site gets crawled fine without one, but a sitemap still gives you a lastmod-based way to prioritise which pages should be revisited first after an update.
Sources
- Build and submit a sitemap — Google Search Central (checked 22 September 2026)
- Sitemaps overview — Google Search Central (checked 22 September 2026)
- Sitemaps - Bing Webmaster Tools — Bing Webmaster Tools (checked 22 September 2026)
- sitemaps.org protocol — sitemaps.org (checked 22 September 2026)
Get your sitemap and crawl setup checked together
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Jeremy ZavaCo-founder
Leads growth and client partnerships.
Works on: CRO, SEO
Reviewed before publishing by Ibrahem Helal, Co-founder.
- Technical SEO: the complete checklist for 2026Technical SEO makes sure search engines and AI crawlers can reach, render and index your pages. This checklist covers every layer, in the order to fix it.
- Indexing Problems: Why Pages Stay OutPages stay unindexed for a handful of reasons: low quality, a blocked crawl path, a wrong canonical, or Google simply choosing not to bother yet.
- SEO Audit Template: What to Check and HowA working SEO audit template covering access, indexing, content, links and speed, with what to check in each layer and how to tell pass from fail.
- Robots.txt Rules for AI CrawlersA working robots.txt for AI crawlers names GPTBot, ClaudeBot and PerplexityBot explicitly and never blocks the ones your citations depend on.