What Belongs in a Sitemap, and the Two Fields Google Ignores Entirely

A sitemap is a list of URLs you would like a search engine to know about. That is the whole idea, and almost everything written about it goes wrong in the same direction: treating it as a ranking mechanism.

The primary sources are unusually clear on this, which makes it a good topic to be precise about.

What a sitemap is for

Google’s own documentation states the purpose without ambiguity: “A sitemap helps search engines discover URLs on your site, but it doesn’t guarantee that all the items in your sitemap will be crawled and indexed.”

And on submission: “submitting a sitemap is merely a hint: it doesn’t guarantee that Google will download the sitemap or use the sitemap for crawling URLs.”

Discovery, not ranking. Those two sentences are the entire conceptual foundation, and both are hedged twice over. A sitemap increases the chance that a crawler learns about a URL. It does not increase that URL’s position.

One consequence worth knowing before you submit anywhere: you might not need one at all. Google documents that a site that is “small” — around 500 pages or fewer — may not need a sitemap, because a crawler following internal links will find everything.

That threshold is more generous than most people expect. A content site with a few hundred articles and a working navigation structure is squarely in the category where a sitemap is optional rather than essential.

The two fields that do nothing

A sitemap entry can carry three optional fields. Two of them are ignored by the largest search engine, in a documented and slightly blunt way:

“Google ignores <priority> and <changefreq> values.”

That is the wording in Google’s build-sitemap documentation. Not “treats as a weak signal,” not “may consider” — ignores.

The sitemaps.org specification is softer but points the same direction. It describes changefreq as “considered a hint and not a command,” noting that crawlers may crawl pages marked hourly less often than requested and yearly pages more often. On priority, it states the value “is not likely to influence the position of your URLs.”

So the common practice of assigning priority values — 1.0 for the homepage, 0.8 for category pages, 0.6 for articles — is work that no documented consumer uses. It is not harmful, and it is not free either: it is a field to generate, maintain, and get subtly wrong.

If you are generating a sitemap, consider omitting both. The specification allows it.

The one field that matters, and its condition

lastmod is the field Google documents using, with a condition attached:

“Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.”

Read the shape of that. It is a conditional signal. Google will use it when it can verify it — typically by re-crawling and comparing what changed. If your lastmod values are not accurate, the signal is worth nothing, and worse, it is a signal that can teach a crawler to distrust your sitemap.

This is where most generated sitemaps fail. The common implementation stamps lastmod with the build time, so every URL claims to have changed on every deploy. That is a value that says “everything changed” every time, which conveys no information and is trivially falsified by the next crawl.

Accurate implementations set lastmod from a per-page source: the frontmatter date if it is genuinely the last edit, or the file’s modification time. Both are honest. The build timestamp is not.

Format requirement: lastmod must be a W3C Datetime value. A YYYY-MM-DD date is acceptable.

The limits, which are two limits

Limit	Value
URLs per sitemap file	50,000
Uncompressed size per file	50 MB
Entries per sitemap index file	50,000
Size per index file	50 MB
Maximum <loc> length	2,048 characters

Two details that catch people:

Gzip does not raise the ceiling. Compression is allowed, but the documented requirement is that the decompressed content stays within 50 MB. Zipping a 90 MB sitemap does not make it legal.

An index file can only list sitemaps on the same site. You cannot use a sitemap index to aggregate sitemaps across multiple domains.

Also required: UTF-8 encoding, and entity-escaping for values — a URL containing & must escape it, which is a common source of validation errors in generated sitemaps.

What to include, and what not to

Include	Exclude
Canonical URLs only	Redirects — list the destination
Indexable pages	Noindexed pages
Both www and apex? No — pick one	Draft and preview URLs
Paginated pages (no official guidance found)	Internal search result pages
Images, if you use an image sitemap	URLs blocked by robots.txt

Two rows deserve a note.

Never list a URL that robots.txt blocks or that carries a noindex directive. A sitemap is a request to crawl; listing a URL you have told the crawler not to index is a contradiction, and crawlers treat it as one. This is the most common substantive error in generated sitemaps, usually because the generator enumerates all output files without consulting the robots rules.

Paginated pages are genuinely ambiguous. I could not find official guidance on whether page 2, page 3 and onward belong in a sitemap. The defensible reasoning is: they are distinct, indexable, canonical URLs that internal linking may not reach as effectively as page one, so including them helps discovery. But that is reasoning, not a documented recommendation, and you should describe it as such rather than citing a rule that does not exist.

Submission: two routes, one difference

You can list the sitemap in robots.txt with a Sitemap: directive, or submit it in Search Console, or both.

The difference is feedback. A robots.txt directive is a passive announcement — the crawler reads it and decides. Search Console shows you whether the sitemap was fetched, how many URLs it contained, and what errors were found. That reporting is the reason to submit rather than just announce.

One documented detail on the robots.txt route: there is no limit on the number of Sitemap: lines.

And one practical note on freshness: at 500 pages or fewer you may not need a sitemap at all, but if you have one, keep it current. A sitemap that lists URLs that 404 is a documented negative — the documentation notes that a sitemap containing many broken URLs may be treated as low quality.

A generation checklist

1. Pick one hostname. www or apex, matching your canonical. Mixing them means half your sitemap points at redirects.
2. Exclude anything not indexable. Noindexed pages, drafts, internal search results, and anything robots.txt blocks.
3. Set lastmod from a real per-page date. Not the build time.
4. Omit priority and changefreq unless you have a reason a documented consumer uses them.
5. Escape entities. A single unescaped & can invalidate the file.
6. Verify after every structural change. Fetch the deployed sitemap and count the entries against your expected page count — the check I use on this site is one line:

curl -s https://example.com/sitemap.xml | grep -c "<loc>"

7. Confirm the count matches reality. A sitemap with a mismatched count is the first sign that a generator is picking up files it should not.

When to skip the sitemap entirely

If you are under about 500 pages and your navigation reaches everything, a sitemap adds a build step, a validation surface, and a file that can go stale. The documented position is that you may not need it.

The case for having one anyway is diagnostic: Search Console’s sitemap report is a convenient check that your URLs are discovered, and a mismatch count is a fast signal that a build produced something unexpected. That is a reasonable reason to keep it — just be honest that the reason is monitoring, not ranking.