An XML sitemap is a file that lists all the addresses on your website that Google should index. It should only contain pages that return a 200 status, are canonical and not set to noindex; redirects, error pages and duplicates don't belong in it. The lastmod field should only carry a new date when the content has genuinely changed. The sitemap helps Google find pages, but it doesn't replace internal links and doesn't guarantee indexing.
Almost every CMS generates an XML sitemap automatically, and almost nobody looks inside it. Yet its content plays a part in whether Google finds new posts quickly or gets stuck dealing with redirects and deleted pages. This page explains what belongs in the file, what doesn't, and where its limits lie.
What a sitemap is and what Google does with it
The XML sitemap is a machine-readable list of all the addresses Google should index, with an optional change date for each address. Google describes it as a hint: it helps discover new and changed pages, especially on large or poorly linked websites. It is not an instruction. Google decides on each address itself, and a page isn't indexed just because it's listed in the sitemap.
Google's own documentation states that it ignores two fields from the sitemap standard: priority and changefreq. The lastmod field, on the other hand, is used by Google provided it's reliable. Each file is limited to 50,000 addresses and 50 MB; larger websites split their sitemap into several files and list these in a sitemap index file.
What belongs in it and what doesn't
| Belongs in it | Doesn't belong in it |
|---|---|
| Pages that return HTTP status 200 | Redirects (301, 302) |
| The canonical address of each page | Non-canonical variants (with parameters, http instead of https) |
| Pages that should be indexed | Pages with noindex |
| Service pages, guides, blog posts, location pages | Error pages (404), login pages, thank-you pages |
| The homepage | Tag pages, author pages, monthly archives |
| Paginated pages (page 2, 3 of the blog overview) |
The rule of thumb: the sitemap should only contain what you actually want to see in the search results. Every address you don't want to see there costs Google time and clutters up the report in Search Console. Which address is the canonical one is set by the canonical tag; the sitemap and the canonical must match, otherwise you're contradicting yourself.
lastmod: honest or not at all
The lastmod field states when a page was last changed. Google uses it to prioritise re-crawling changed pages, but only if it's accurate. Two mistakes are common:
- Every address carries the date the sitemap was generated, so it's always today's date. In that case, the field says nothing, and Google ignores it for that website.
- The date gets updated for every small change, for example when the sidebar changes. In that case too, the field loses its value.
The correct approach: lastmod changes when the main content changes. A fixed typo doesn't count, a new section does. Most CMS get this right by default, as long as no plugin interferes.
Submitting to Google
Three steps, done once:
- Find out the sitemap's address, usually example.ch/sitemap.xml. In WordPress, SEO plugins generate it; in Wix and Shopify, it's built in.
- Enter and submit the address under "Sitemaps" in Search Console. The report will then show whether Google could read it and how many addresses were found.
- Add a line "Sitemap: https://example.ch/sitemap.xml" to your robots.txt. This also helps other search engines and AI crawlers find the file.
After that, you don't need to do anything else. New posts automatically appear in the sitemap, and Google re-reads it regularly.
Common mistakes
- Pages with noindex in the sitemap: you're telling Google both "take it" and "don't take it" at the same time. Search Console flags this as an error.
- Redirects in the sitemap: typical after a relaunch, when the old sitemap keeps running. Google follows the redirect, but the file loses credibility.
- Two sitemaps with different content: for example, WordPress's built-in one and the SEO plugin's one. Switch one of them off.
- http addresses in the sitemap of an https website: this happens with old settings, and then every address is a redirect.
- Development environment in the sitemap: addresses containing "staging" or "dev" should never be included.
- Sitemap not regenerated for months: on static websites maintained by hand, all new pages are then missing.
What a sitemap cannot do
It does not replace internal links. A page that only appears in the sitemap but is not linked from any other page often stays in the status "Discovered, currently not indexed". It does not speed up indexing on its own, it does not improve ranking, and it does not fix technical blocks. If a page fails to appear despite a correct sitemap, the reason lies elsewhere; the order of actions is set out under Page is not indexed.
What to do with this
Open your sitemap in the browser once and read through twenty addresses. Is there something there that should not be in the results list, or is the latest blog post missing? Then correct the setting in the CMS. Submit the file in Search Console, add the line to robots.txt, and check the sitemap report after every relaunch and otherwise once a quarter.
Frequently asked questions
Do I need a sitemap if my website only has ten pages?
Not strictly, Google finds ten linked pages even without one. It does no harm, though, and as soon as a blog is added, it becomes useful because new posts get discovered faster through it. Since every CMS generates one automatically, there is no reason to do without it.
Where do I find my website's sitemap?
Try example.com/sitemap.xml, for WordPress without an SEO plugin example.com/wp-sitemap.xml, for Wix and Shopify also /sitemap.xml. Often there is also a line "Sitemap:" with the address in robots.txt at example.com/robots.txt. If none of these respond, your CMS is not generating one, and a plugin or setting is missing.
Should I include images and videos in the sitemap?
For most SME websites this is unnecessary, Google finds images via the pages. There are dedicated extensions for image and video sitemaps that help portals with thousands of media files. A trades business with two hundred photos does not need that.
Why does Search Console show fewer indexed pages than the sitemap contains?
That's normal. The sitemap is a suggestion, Google decides on each address itself. The difference is shown in the "Pages" report with a reason, such as "Discovered, currently not indexed" or "Duplicate". Only when the gap is large or growing is it worth investigating.