XML sitemap

What the file actually does, and what it never did

An XML sitemap is a machine-readable list of URLs you publish so that search engines stop depending entirely on your internal links to find your content. That is the whole job: discovery, plus a hint about when to come back. It is not a ranking input, it never has been, and no amount of tag tuning inside the file will move a position by a single place. What it does move is the delay between publishing a page and Google seeing it, which on a site of any real size is the difference between a page earning impressions in three days and in six weeks.

The vocabulary trips people up because the word sitemap covers two unrelated artefacts. An HTML sitemap is a page for humans, a flat index of the site, occasionally useful as an internal linking patch on a shallow architecture. An XML sitemap is a file for machines, written against the sitemaps.org 0.9 protocol, wrapped in a urlset element with its xmlns declaration, and never meant to be opened by a visitor. When someone asks whether they need « a sitemap or an XML sitemap », they are really asking two questions at once, and the answer to the machine one is almost always yes.

Almost, because there is a floor. Several 2026 technical guides make the same point we see in audits: a brochure site of twenty to twenty-five pages with clean navigation gets crawled fine without any sitemap at all. Above that, the cost of not having one is invisible rather than absent. Nothing breaks, no error appears in any tool, and important pages simply get crawled weeks late or not at all. That invisibility is exactly why the file gets neglected on sites where it matters most.

Here is a compact visual overview of the format and why engines ask for it.

Anatomy: urlset, loc, lastmod, and two dead tags

The schema is small enough to hold in your head. A standard sitemap opens with a urlset element declaring the sitemaps.org 0.9 namespace, then repeats a url block per page. Inside each block, loc carries the absolute URL and is the only mandatory child. Then come lastmod, a W3C datetime, and the two survivors of an older era, changefreq and priority.

Those last two are dead. Google has stated plainly that it ignores both, and the 2025 to 2026 commentary is unanimous on the point: only loc and lastmod carry meaning today. Setting every page to priority 1.0 does not make them important, it just tells anyone reading your file that nobody has looked at it since the plugin was installed. If your generator emits them, leaving them in is harmless; spending an afternoon calibrating them is not a good use of the afternoon.

lastmod is the interesting one, and it works on binary trust. Google says it uses the value only when it is consistently and verifiably accurate, and otherwise falls back to its own crawl signals. There is no partial credit. A 2024 HTTP Archive study, widely cited in 2026 technical SEO literature, found that 58% of XML sitemaps carried stale or missing lastmod values, so the majority of real-world sitemaps deliver no usable freshness signal at all. A Bing study reported in August 2025 puts numbers on the same problem from the engine side: among hosts with at least one URL indexed by Bing, 58% have an XML sitemap, 84% of those include lastmod, and 18% set it incorrectly.

The operational rule that follows: bump lastmod only on meaningful changes, meaning the main body copy, the structured data, or the important links on the page. A template tweak, a footer year update, or a static site generator that stamps every URL with the build timestamp will eventually get your dates discarded wholesale, and 2026 guidance suggests trust takes weeks to rebuild once lost. Also make sure the URL in loc matches the canonical version you actually declare in the head, because a sitemap that lists the non-canonical variant sends two contradictory instructions about the same document.

Beyond the standard format sit the specialised schemas, each with its own namespace: image sitemaps, video sitemaps with their duration and thumbnail fields, and news sitemaps restricted to recent articles. Multilingual sites can also declare alternates directly in the file with xhtml:link entries, which is often cleaner than managing language alternates in the head of every template. The hard limits apply to all of them: 50,000 URLs and 50 MB uncompressed per file, gzip allowed, and a sitemap index file when you exceed either.

Finding it, submitting it, reading the report

Finding an existing sitemap on a site you did not build is a thirty-second job, and it is worth doing before you accept anyone's word that one exists. Try /sitemap.xml and /sitemap_index.xml first, since virtually every CMS defaults to one of them. If that fails, open /robots.txt and look for the Sitemap: directive, which is where the file that governs what crawlers may fetch is supposed to declare it. Failing both, the Sitemaps report in Google Search Console lists whatever has been submitted historically, and a crawler like Screaming Frog will surface one referenced anywhere in the source.

Submission has narrowed. The Search Console Sitemaps report and the robots.txt declaration are the two paths that still work, and you should use both: the robots.txt line covers every engine that reads it, Search Console gives you the reporting. The old HTTP ping endpoint is gone, so there is nothing left to trigger by hand on the Google side. For Bing and the engines that consume the same protocol, IndexNow now does the notification job that ping used to.

Reading the report is where most of the value sits, and where most teams stop too early. The number that matters is the submitted-versus-indexed ratio, split by page type rather than read site-wide. Split your sitemap by template, one file for articles, one for category pages, one for programmatic pages, and the ratios immediately tell you which section is thin, which is duplicated, and which is fine. A single blended figure of « 71% indexed » tells you nothing actionable. 2026 indexing playbooks treat that per-type ratio as a core KPI on large sites, and the reasoning is sound: crawl waste is always concentrated in one or two templates, never spread evenly.

Keep URL Inspection and manual indexing requests for a handful of genuinely high-value URLs. At publishing scale, the sitemap is the mechanism, and burning your daily request quota on routine posts is a habit that produces meetings rather than indexation.

Where sitemaps matter in a netlinking operation

Two moments in a link campaign depend on crawl speed, and both are silently gated by sitemap hygiene. The first is the linkable asset: a study, a tool, a regional landing page, typically published deep in the architecture with few internal links pointing at it in its first weeks. That profile is exactly the case where 2026 guidance says sitemaps do real work, because internal linking has not yet caught up. The second is the page that just received a link. A backlink is only worth what the crawler has seen, and if the linking page sits in a stale sitemap on a site that publishes weekly, the recognition delay is measured in weeks.

That applies to the publisher side as much as the buyer side. Across the French editorial media we own and operate, every deploy regenerates the sitemap with real modification dates and pushes the URL list to the engines in the same step, which is unglamorous plumbing that shortens the delay between a client's article going live and the link being counted. If you are evaluating where to place a link, the question « does this publisher's new content get crawled within days » belongs in the same checklist as authority, and it is answerable in a minute by looking at their sitemap and a few cached dates. It is one of the reasons we publish the full catalogue of media, browsable without an account rather than a filtered list, and why what each placement costs is listed openly instead of being quoted case by case.

There is also a discovery angle that did not exist five years ago. 2026 technical SEO and GEO sources now describe XML sitemaps as part of the discovery layer feeding generative search surfaces, not just classic blue links. With AI Overviews reported by a 2026 SEO guide at roughly 48% of queries in early 2026, up 58% versus December 2025, and around 60% of Google searches ending without a click, being crawled is a precondition for being quoted. That does not make the sitemap a GEO tactic. Whether an already-crawled page actually gets cited depends far more on being mentioned and referenced across the open web, which is a separate workstream we treat under getting a brand surfaced inside AI answers. The sitemap is the same discovery prerequisite it always was, just applied to one more surface.

What we see go wrong in audits

The single most common failure is the dirty sitemap. Redirected URLs, 404s, pages carrying an explicit instruction not to be indexed, filtered listing variants, tag archives, cart and account pages: all listed, all consuming crawl attention, all contradicting signals declared elsewhere. The filter is simple and worth enforcing at generation time rather than by periodic cleanup: HTTP 200, self-canonical, indexable, and of some SEO value. Everything else is noise.

Second is the auto-stamped date. Static site generators and several CMS plugins write the build timestamp into every lastmod on every deploy, which means a site that changes one article per week tells Google that four thousand pages changed on Tuesday. That is the behaviour that gets your dates ignored, and it is the direct cause behind a good share of the 58% stale-or-missing figure from the HTTP Archive data.

Third, and more frequent than it should be: the sitemap URL declared in robots.txt while the directory containing it is disallowed, or the file itself returning a 404 after a migration nobody re-checked. Fourth, the expectation problem. Teams resubmit a sitemap for months waiting for pages to get indexed when the pages were found long ago and rejected on quality or duplication grounds. A sitemap fixes a page Google never found. It does nothing for a page Google found and declined. Discovered but currently not indexed in Search Console means the discovery job already succeeded and the problem lies in the content.

The twenty-minute sitemap audit

Open the file. Check that the URL count matches roughly what the site should have, because a sitemap listing 400 URLs on a 4,000-page site means the generator is capped or filtered somewhere. Crawl the list in list mode and count non-200 responses, non-canonical URLs, and noindex pages: anything above a rounding error is a generation bug, not a content problem. Sample twenty lastmod values against the actual publication or edit dates and see whether they hold up, then check whether they all share a single timestamp.

Then look at the split. If everything sits in one file, split by template and resubmit, because the per-type indexation ratio is the diagnostic you will use every month afterwards. Confirm the robots.txt declaration resolves, confirm Search Console shows a recent successful read, and note the submitted-versus-indexed gap per file. Twenty minutes, and you will know whether the sitemap is doing its job or quietly certifying a mess.