XML sitemap: the site map Google actually reads

What a sitemap is for, and what it is not for

“Sitemap XML” is searched 1,000 times a month in France. In our study, 18% of small business websites do not publish one at all.

A sitemap does three things: it makes known pages that internal links are not enough to reveal (a new site, a large catalogue, deep pages), it flags changed pages so they are recrawled sooner, and it gives a clean list that Search Console compares with what it has indexed.

It does not make a page rank, nor does it force indexing. A weak page listed in the sitemap is still a weak page. And a page that no internal link points to stays poorly understood even if it appears in the sitemap.

The format: what Google reads, what it ignores

A minimal sitemap fits in a few lines:

• <?xml version=“1.0” encoding=“UTF-8”?>
• <urlset xmlns=“http://www.sitemaps.org/schemas/sitemap/0.9”>
• <url><loc>https://www.example.com/compact-pushchairs</loc><lastmod>2026-10-14</lastmod></url>
• <url><loc>https://www.example.com/how-to-choose-a-pushchair</loc><lastmod>2026-09-30</lastmod></url>
• </urlset>

Google uses two tags: loc (the full URL, with https and the exact version, with or without www) and lastmod. It ignores the priority and changefreq values, so there is no point setting them page by page. One file holds at most 50,000 URLs or 50 MB; beyond that, split it into several files brought together by a sitemap index.

lastmod: the date of the content, never the date of the build

This is the most common mistake, and the costliest. Many sites (and many plugins) put today’s date in lastmod every time the site is generated. The result: every page seems to change every day, Google sees that this is not true, and stops trusting the date.

Google is explicit: it uses the lastmod value if it is consistently and verifiably accurate, for example by comparing it with the last modification of the page. And lastmod should reflect the date of the page’s last significant update: a change of text, price or information. Not a copyright date in the footer or a new version of the theme.

On all our sites the rule is written down: the sitemap date is the date of the page’s content, stored with the content itself, never the date the site was built. It is also the rule on this site: every guide carries its publication or update date, and the sitemap uses it.

1. 1
   Store the date with the content: an “updated on” field in the database or in the page file, changed only when the content really changes.
2. 2
   Generate the sitemap from that field, not from the server clock.
3. 3
   Show the same date on the page (“Updated on …”) and in the article’s structured data.
4. 4
   Check: two successive sitemap generations with no content change must give identical dates.

Which pages to put in the sitemap

The sitemap is the list of pages you want to see in Google. Anything that does not belong there weakens it.

• Yes: product and category pages on sale, service pages, guides and articles, useful pages (delivery, returns, contact).
• No: noindex pages, redirected pages, pages returning a 404 or 410 error, filter and sort URLs, internal search results, cart, account, checkout.
• No: several URLs for the same page (with and without a parameter, with and without a trailing slash). Only the canonical URL goes in the sitemap.
• A permanently sold-out product page leaves the sitemap as soon as it is removed or redirected. In our study, 21% of sites do not even declare a canonical URL on the home page.

Split by page type to see what is indexed

On a site with more than a few dozen pages, a single large sitemap hides what matters. Split it by page type: one file for products, one for categories, one for guides, one for service pages. The sitemap index brings them together.

The benefit shows in Search Console: the indexing report can be filtered by sitemap. You then see, type by type, the share of pages indexed. A product page sitemap that is half indexed tells a different story from a guide sitemap that is almost fully indexed. This is what we do after every pruning: new sitemaps per segment, submitted again, to follow the recovery segment by segment.

• <sitemapindex xmlns=“http://www.sitemaps.org/schemas/sitemap/0.9”>
• <sitemap><loc>https://www.example.com/sitemap-products.xml</loc></sitemap>
• <sitemap><loc>https://www.example.com/sitemap-guides.xml</loc></sitemap>
• </sitemapindex>

Submit the sitemap to Google and Bing

1. 1
   Declare it in robots.txt, on a line of its own: Sitemap: https://www.example.com/sitemap.xml. Every search engine finds it that way.
2. 2
   Submit it in Google Search Console, under “Sitemaps”: the status “Success” confirms the file is read, then the number of discovered pages appears.
3. 3
   Submit it in Bing Webmaster Tools, which also feeds other search engines. Bing lets you import a site already verified in Search Console.
4. 4
   Announce new pages straight away with IndexNow: a single call notifies the participating engines (Amazon, Bing, Naver, Seznam.cz, Yandex, Yep) of a new or changed URL, up to 10,000 URLs per submission. Google does not take part: for Google, the sitemap and links do the job.
5. 5
   Review the indexing report by sitemap every month, and first fix the pages that are listed but not indexed and that need to sell.