A sitemap is a claim about what exists

What it is for

Discovery. It hands an engine a list rather than making it find everything by following links, which matters most for new sites and for pages that are not well linked.

It is not a ranking tool. Listing a page does not make it more likely to be stored, and a page can rank perfectly well without appearing in one.

Think of it as a statement of what you publish, and keep it accurate for the same reason you would keep any statement accurate.

It is not a ranking tool. Listing a page does not make it more likely to be stored, and a well-linked page ranks the same without one.

It matters most in two situations: a brand new site nobody links to yet, and a large site where some pages sit several clicks from anything well linked.

What belongs in it

Every page you want found, at its canonical address, returning a normal response, without a noindex instruction.

That is a narrower list than most sitemaps contain. Redirecting addresses, excluded pages, missing pages and non canonical variants all appear routinely and none of them should.

Each entry should carry a modification date reflecting when the content actually changed, which is the part most generators get wrong.

• Every page you want found
• At its canonical address
• Returning a normal response
• Without a noindex instruction
• With a modification date reflecting real content change
• And nothing else — no redirects, no excluded pages, no missing addresses

The date problem

Many tools stamp every entry with the date of the build, so an engine sees three hundred pages all modified this morning, every morning.

That is noise, and engines learn to ignore the dates entirely. You have then lost the one signal a sitemap carries beyond the address itself.

The date should come from the page's own content. If nothing changed, the date should not change either.

Many tools stamp every entry with the build date, so an engine sees three hundred pages modified this morning, every morning, and learns to ignore the dates entirely.

Size and splitting

A single sitemap holds a large number of addresses, far more than a small business will ever need. Splitting is only necessary at a scale most sites never reach.

Where a site does split, an index file lists the individual sitemaps. Having both an index and standalone files without a clear relationship confuses matters.

One file, one list, named in your robots file and submitted once, is the right answer for a few hundred pages.

Splitting is only necessary at a scale most small businesses never reach. One file, one list, named in the robots file, is the right answer for a few hundred pages.

Keeping it honest

Generate it from what actually exists rather than maintaining it by hand. Any list a person maintains drifts within months.

Check it after any deletion or restructure, because those are the moments it starts listing pages that are gone.

Search Console reports how many listed addresses it could and could not use, which is the fastest way to notice drift.

Generate it from what exists rather than maintaining it by hand. Any list a person maintains drifts within months.

Where to put it

At a predictable address on your domain, named in your robots file, and submitted once in each search console.

Resubmitting it repeatedly achieves nothing. Engines check it on their own schedule once they know it exists.

If you move it, update the robots file, because that pointer is how an engine arriving fresh finds it at all.

How ours is built

The sitemap on a site published here is rebuilt from the pages that actually exist at each release, so it cannot list something that is gone.

Each entry carries a modification date taken from the page's own content rather than from the build, so a changed date means a real change.

Every page passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards, which includes confirming that everything listed returns a normal response.

The date comes from the page's own content, so a changed date means a real change — which is the signal the field exists to carry.

Because it is rebuilt at each release from the pages that actually exist, it cannot list something that was deleted — the commonest way a sitemap goes quietly wrong.