Sitemap.xml: what belongs in a sitemap and how not to break it

Sitemap.xml is a list of the site addresses you want in Google's index, with the date each one last changed. The map should contain only canonical pages that return 200 and are open for indexing, and everything else (redirects, noindex pages, parameter duplicates) has to go. Below we cover when an XML sitemap is genuinely needed, what a correct file looks like, what to do with lastmod, how to split large maps, how to hand the map to Google, and which mistakes usually "break" a site's own sitemap.

Why a sitemap matters and when you can live without one

Google discovers pages in two ways: through links while crawling, and through the list in the sitemap. The map does not force indexing; it only says "here are the addresses I consider important, and here is when they changed". For a small 30-page site with a sensible menu the map changes almost nothing: the crawler reaches everything in a single pass anyway. Google's own documentation states plainly that a site of up to a few hundred pages with good internal linking does not need a sitemap.

It becomes necessary when:

• there are thousands of pages, some of them buried deep (products in subcategories, filters, archives);
• the site is new and has almost no external links;
• content changes often and it matters that Google re-reads exactly the pages that changed;
• there are many images or videos that should rank on their own;
• some pages are unreachable through links (for instance, ad landing pages you still want indexed).

In practice, at Query we add a sitemap to every project, even a small one. A correct map does no harm, and the Sitemaps report in Search Console is a convenient way to see how many pages from the list are actually indexed.

What a correct sitemap.xml looks like

The format is a standard described at sitemaps.org. A minimal file for two pages:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url><loc>https://site.ua/</loc><lastmod>2026-09-10</lastmod></url>
<url><loc>https://site.ua/catalog/boilers/</loc><lastmod>2026-09-14T08:30:00+03:00</lastmod></url>
</urlset>

A few rules that are easy to break. Addresses must be absolute, with the protocol and the same domain the map lives on: a file at https://site.ua/sitemap.xml cannot contain http:// or www.site.ua if the primary host has no www. Encoding is UTF-8, special characters in URLs are escaped (& becomes &). The lastmod date follows ISO 8601: either just the day, or the day with time and timezone.

What to include in the sitemap and what to leave out

The main principle: the map holds only the addresses you want in search results, and each of them must be the very one Google will pick as canonical. Google treats a mismatch between the map and the real state of the site as noise, and over time trusts the map less.

A typical e-commerce case: the CMS drops all 40,000 filter combinations into the map, of which maybe two hundred are useful in the index. The result: Search Console shows "discovered, currently not indexed" for tens of thousands of addresses while important products wait in the queue. The map must be generated by the same rules that open or close pages for indexing, and no other way.

Honest lastmod; priority and changefreq are not needed

lastmod is the only extra field Google actually uses, and it uses it only when the value is truthful. If every page gets "today's" date daily because the generator stamps the file creation time, Google notices within a few crawls and starts ignoring the field across the whole site. Set the date of a real content change: text or price updated, the date changes. Only the "related products" block in the sidebar changed, the date stays.

Google has not read the priority and changefreq fields since 2015, which it has confirmed publicly more than once. They do no harm, but they do not help either, so in a new map it is simpler not to generate them: the file is smaller and there is less confusion.

The 50,000 URL and 50 MB limits, sitemap index files and dedicated maps

One sitemap file holds up to 50,000 addresses and weighs up to 50 MB uncompressed. Gzip compression (sitemap.xml.gz) is allowed and saves bandwidth, but the limit is measured on the unpacked size. When there are more addresses, you create several files and combine them with a sitemap index:

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap><loc>https://site.ua/sitemap-pages.xml</loc><lastmod>2026-09-14</lastmod></sitemap>
<sitemap><loc>https://site.ua/sitemap-products-1.xml</loc></sitemap>
</sitemapindex>

The index is also capped at 50,000 entries, giving a theoretical ceiling of 2.5 billion addresses, which is enough for anyone. Splitting the map is worth doing not just because of the limit but for convenience: separate files for categories, products, articles and language versions produce separate statistics rows in Search Console, and you immediately see which page type is "not getting in".

Media have their own extensions. An image sitemap adds <image:image> elements with the file address inside each <url>, and it is the only way to hand Google pictures that are loaded by script. A news sitemap (<news:news>) is for publications in Google News: it holds only items from the last two days and up to 1,000 addresses. A video sitemap carries duration, thumbnail and description. A regular business site usually needs the basic map plus images, if the catalogue relies on photos.

How to submit the sitemap to Google

Two ways, and it is best to use both:

1. In Google Search Console, in the Sitemaps section, paste the address of the file or the index. After processing you get a status ("Success", "Couldn't fetch", "Has errors") and the number of discovered addresses. We covered how to use the service itself in a separate article.
2. In robots.txt, add the line Sitemap: https://site.ua/sitemap.xml with the full address. Every search engine reads this line, and it does not depend on whether the site is verified in anyone's console.

A word on frequency: Google re-reads the map on its own, guided by the index's lastmod and its own crawl schedule. You do not need to resubmit it after every change. Google switched off the /ping?sitemap= endpoint in 2023, so any "ping after updating" instructions are out of date.

Common sitemap mistakes

This is the list of what we run into most often during technical SEO work. Most of these are invisible to the eye and surface only in reports or after a crawl.

How to check that Google reads the map

• The Sitemaps report in Search Console: the status should be "Success", the last read date recent, and the number of discovered addresses should match what you generated.
• The Page indexing report filtered to "All submitted pages": it shows how many addresses from the map are indexed and how many sit in "discovered, currently not indexed" or "page with redirect". This is where the junk in the map shows up.
• Server logs: Googlebot requests for sitemap.xml appear regularly, usually anywhere from a few times a day to a few times a week depending on the site.
• XML validity: any online validator or crawler (Screaming Frog has a sitemap check mode) will reveal a broken tag, an unescaped character or an exceeded limit.

The full list of requirements for the format, extensions and limits is in Google's documentation on building a sitemap. If your CMS does something differently, trust the documentation, not the plugin.

Where to start

1. Open /sitemap.xml and check that it exists, returns 200 and contains current addresses rather than a two-year-old file.
2. Run the addresses from the map through a crawler and remove everything that is not 200, not canonical or has noindex.
3. Check lastmod: the dates should differ and match real updates.
4. Split the map into thematic files via an index if there are more than a few thousand addresses.
5. Add the map to Search Console and robots.txt, and a week later compare "submitted" against "indexed".

A correct sitemap does not lift rankings by itself, but it removes the cheapest reason why new pages sit outside the index for weeks. It is an hour of work for a small site and a day for a large catalogue, after which the Search Console reports finally start telling the truth.