A sitemap is for discovery, not for ranking
A sitemap tells a search engine which URLs exist. That is the whole of its job. It does not ask for those URLs to be indexed, it does not argue that they are important, and it has no influence on where they rank once they are in.
Which means a sitemap solves exactly one problem: pages that are hard to find by following links. Deep archives, a page nothing links to, a large site whose navigation does not reach everything, a brand-new site with no inbound links at all. If a page is reachable in two clicks from your homepage, a sitemap adds almost nothing to its chances.
The disappointment people report — submitted a sitemap, nothing happened — is nearly always this. The pages were already discoverable. Discovery was never the constraint.
What belongs in it
One entry per page, in the exact form you want indexed. Canonical URLs, returning a 200, indexable, on the same protocol and hostname as the sitemap itself. Mixed http and https entries are treated as different sites.
What stays out is the more useful list, because a sitemap full of URLs a crawler rejects teaches it to trust the file less:
- Anything that redirects. List the destination.
- Parameter variants and tracking URLs. One canonical address per page.
- Pages carrying
noindex. The sitemap says look here and the tag says do not; the tag wins and the contradiction is noise.
- Pages blocked in robots.txt, which cannot be fetched to be assessed.
- Thin pages you would not want ranking. A sitemap listing every tag archive on a blog is mostly a list of pages that will be ignored.
Two elements that do nothing
A sitemap entry can carry four things: a location, a last-modified date, a change frequency and a priority. Google has stated publicly, and for years, that it ignores changefreq and priority entirely.
They are still emitted because the format allows them and validators expect the shape, not because they achieve anything. Setting every page to priority 1.0 is not a mistake so much as a no-op, and the hours some people spend tuning these values across a large site are entirely wasted.
The date is different. lastmod is used, conditionally, and the condition is that it has proved honest. Google leans on it to decide what is worth recrawling on sites where it has learned the value is accurate, and disregards it on sites where every URL claims to have changed today.
Which makes the dates the part that needs care
The [msm_tool slug="sitemap-generator"] stamps today's date on every entry, which is true only if you have just updated all of them. Correct it before submitting.
The date should be when the content changed in a way a reader would notice. Rebuilding a page from a template, touching a stylesheet, or regenerating the file with no edits are not modifications. A sitemap whose dates all move whenever the file is regenerated is a sitemap whose dates are ignored, and the loss is permanent enough to be worth avoiding on the first submission.
Limits and the index file
Fifty thousand URLs and fifty megabytes uncompressed, per file. Beyond either, split into several sitemaps and list them in a sitemap index, which is a small XML file pointing at the others. Gzip is permitted and the size limit applies to the uncompressed content.
Splitting is worth doing below the limits too, by section — products, articles, categories — because Search Console reports coverage per sitemap. A separate file per section turns a vague site-wide indexing figure into a specific one, and that is where a sitemap earns most of its keep.
Ampersands in URLs must be written as &, because the file is XML and a bare ampersand makes it invalid. An invalid sitemap is usually rejected whole rather than partially.
Submitting it, and reading the result
Put the file at a stable URL, add a Sitemap: line to robots.txt pointing at it, and submit it in Search Console. Bing Webmaster Tools takes the same file.
Then use the coverage report, which is the actual payoff. It tells you which submitted URLs were indexed, which were not, and the reason for each: discovered but not crawled, crawled but not indexed, duplicate without a canonical, excluded by a tag. That is a diagnostic list you cannot get any other way, and it is more valuable than the discovery function most people submit the file for.
Do you need one at all
WordPress has generated a sitemap since version 5.5, at /wp-sitemap.xml, and Yoast, Rank Math and SEOPress each replace it with their own. If you are on any of those, the file already exists and is kept current automatically, which is strictly better than a hand-built one that goes stale.
Building one by hand makes sense for a static site, for a platform that generates nothing, or for a deliberately chosen subset of URLs you want to watch in the coverage report. Outside those cases, the effort is better spent making sure the pages are linked to from somewhere on the site — which helps discovery and ranking both, where a sitemap only ever helped with one of them.