sitemap.xml is the dullest file in a shop and also the cheapest way to speed up indexing. It does not lift rankings and it does not replace the SEO work itself. It does one thing: it tells a search engine which pages you have, without making it find them by following links.
For a ten-page catalogue that changes nothing. For a ten-thousand-item catalogue it matters — and that is where the difference between «the file exists» and «the file works» begins.
What it actually buys you
A crawler walks a site through links. A product with no link pointing at it from any visible page — buried deep behind a filter, an old card, a seasonal category — can go unfound for months.
| Without a sitemap | With a sitemap |
|---|---|
| the crawler discovers pages by following links | it gets the full list at once |
| deep pages wait their turn | they queue alongside everything else |
| the change date is unknown | lastmod is stated in the file |
What it does not do: it guarantees nothing about indexing and has no effect on position. It is an invitation, not an instruction — the engine still decides what to take.
The base tier: one file
In CommerCentr the Sitemap plugin builds www/sitemap.xml for free from three sources: products, categories and articles. The file is served as a static asset — no PHP runs on a crawler request, so the load on the site is zero.
For most shops that is enough, and stopping there is a perfectly good answer.
When one file stops being enough
Three situations, and in each the single file stops covering the need.
The catalogue grew. The sitemaps.org standard caps one file at 50,000 URLs and 50 MB uncompressed. A shop with options and filters reaches that sooner than it expects. The answer is an index file: a small sitemap.xml listing separate maps, with those maps carrying the URLs in portions — products in one, categories in another.
Photographs are what sell the product. Furniture, clothing, decor — the buyer arrives from image search. For pictures to get there they must be declared in the map as their own block: file address and caption. A plain <url> says nothing about images.
The shop is multilingual. The same card exists in two languages at two addresses. Without an explicit statement that these are translations of one another, a search engine sees two separate pages — and may decide one duplicates the other.
What the paid tier adds
The extension covers exactly those three cases plus two technical details:
Split files. The map is broken into several (sitemap-categories.xml and the rest) and the root becomes an index. The standard's limit stops being a ceiling.
Images. The main product photo and the additional ones enter the map as their own block, captions included. WebP versions go in too, if the shop generates them.
Video. Where a card has video attached, it is declared as video rather than as one more link.
Language alternates. Each URL carries the list of its language versions, so the engine knows these are translations, not duplicates.
Gzip and scheduling. Files are served compressed, and rebuilding happens on its own — nothing to press after a catalogue change.
How to check it genuinely works
A five-minute routine that catches most of the mistakes.
- Open
https://your-shop/sitemap.xml— it must be served with no password and no redirect. - Count the URLs. If the catalogue holds 4,000 products and the map holds 300, something is being excluded: drafts, products without a price, an entire category.
- Check the addresses themselves. They must be canonical: same domain, same protocol, no utility parameters. A URL that leads to a redirect spends a crawl for nothing.
- Submit the file in a webmaster console and look, a few days later, at how much of what you submitted got indexed. A gap of several times over is a reason to look at the pages, not the map.
- After a large import, check
lastmod. If the dates did not move, the crawler will treat the pages as unchanged.
What lastmod is, and why to state it honestly
Every URL has an optional «date last modified» field. The temptation is obvious: stamp today on everything so the engine «re-reads it all». That is a bad idea, for a practical reason.
The crawler compares the claimed date against what it sees on the page. If the map says «updated» every day while the content has not changed in months, the field simply stops being taken into account — for the whole site. You lose the one way you had to say «this card really did change, read it first».
An honest lastmod is most useful precisely on a large catalogue: after a price import or a round of rewriting descriptions, it shows which of ten thousand pages are worth attention now. That is why in CommerCentr the date comes from the entity itself and not from the moment the file was built — otherwise every regeneration would «update» the entire catalogue.
What it costs the site
The question every owner of a large catalogue asks: will generating the map take the site down.
No, and the reason is in how the file is served. The map is assembled ahead of time and lands on disk as a static file. When a crawler requests it, PHP does not execute at all — the web server hands over a ready file, like an image. The cost per request is zero, however many there are.
Load appears only at rebuild time, and it is one-off. That is why regeneration is scheduled at night rather than fired on every product change: a catalogue that changes a hundred times a day does not need a hundred rebuilds.
Separately on gzip: a compressed map is several times smaller, and for a catalogue of tens of thousands of URLs that is real traffic saved — yours and the crawler's.
Common mistakes
The map contains what should not be there. Cart pages, search results, utility filters. They carry no search value and dilute the crawl.
The map contradicts robots.txt. The classic: a URL is in the sitemap and simultaneously blocked from crawling. The robot receives two opposite instructions.
The map is not updated. Built by hand once, and the catalogue has changed threefold since. A file six months behind is worse than no file — it actively points at pages that no longer exist.
The map lists products that are out of stock and will not return. A discontinued item should either return 410 or leave the map. Otherwise you are asking, in writing, for emptiness to be indexed.
Faceted pages: when a filter becomes a landing page
A case specific to shops. The filter «sneakers + black + size 42» technically produces an address, and the catalogue holds thousands of such combinations. You cannot put them all in the map: the engine receives heaps of near-identical pages and none of them looks important.
But some of those pages are genuine landing pages. «Black sneakers» is real demand, and a page for it deserves indexing no less than a category does.
The difference between the two groups is curation. The shop itself decides which combinations are meaningful collections and which stay utility states of a filter. The curated ones go into the map, the rest do not. That line cannot be drawn automatically: it does not follow the shape of the data, it follows whether demand exists for that combination.
So in CommerCentr faceted landings are not «every combination» but an explicitly marked list. That is smaller work than it sounds: most catalogues have dozens of meaningful collections, not thousands.
What this does not do
A sitemap does not raise rankings. It affects the speed of discovery, not the assessment of quality. A product with no description and no price will not start ranking because it entered a map.
It does not replace internal linking. A page with no link to it from anywhere on the site looks unimportant to a search engine, and a map does not compensate for that.
And it does not guarantee indexing. A large catalogue is always indexed partially; what gets taken depends on the quality of the pages, not on the file.
Summary
A sitemap is infrastructure, not a promotion tool. The base tier covers the essential: every product, category and article in one file that updates itself. That is what every shop should have, and in CommerCentr it is free.
The paid tier is for when the catalogue runs into the standard's limit, when photographs are what sell the product, or when the shop speaks several languages. Outside those three cases there is nothing to pay for — and saying so plainly is more honest than selling an «extended map» to everyone.
Check your own file right now: open it, count the URLs and compare against your product count. A gap of several times over is the most common finding, and it is fixed in an evening.
See also visibility for AI agents — a different format for different readers — and GPSR and product data if you sell into the EU.