XML sitemaps generator: a sitemap is a feed, not a file, so pick the one that rebuilds itself

Every sitemap generator produces a file that validates. The question that matters is what happens to that file six weeks later, when you have published nine pages and retired two. A sitemap built by a one off crawl is a snapshot and starts going stale the moment it is saved. A sitemap produced by the platform, or by your build, is a feed and stays correct without anybody remembering it. So the choice of generator is really a choice about how your URLs come into existence, and the four options below are not interchangeable even though their output looks identical.

The four kinds of generator

Route	How it works	Stays current	Right for
Built into the platform or a plugin	The CMS writes the file on the fly from the content it already has. WordPress does it through an SEO plugin, and Shopify, Wix and Squarespace produce one automatically	Yes, automatically	Almost every content or ecommerce site. If you have this, use it and stop reading
An online crawl generator	You enter a domain, a hosted crawler walks the links it can find, and you download the XML	No. It is a snapshot	A static site with no build step, a one off audit, or a quick comparison against what your platform produces
A desktop crawler export	A crawler on your own machine maps the site and exports a sitemap, with full control over what is excluded	No, but it is repeatable on demand	Large or messy sites where you need to see and filter the URL list before it ships
A build step or a script	Your framework or a small script writes the file from the routes and the data at deploy time	Yes, on every deploy	Any site that is compiled or rendered from a data source. The route the static content generators all support

A rule that resolves most cases: if your URLs are created by publishing something, the generator must live where publishing happens. A crawler can only find a page that is already linked from another page, which means a new post that nothing links to yet is precisely the page a crawl generator will miss, and precisely the page a sitemap exists to announce.

What the file has to contain

The format is the sitemaps.org 0.9 protocol. A minimal valid file is short:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <url> <loc>https://example.com/page/</loc> <lastmod>2026-10-20</lastmod> </url>
</urlset>

• UTF-8, and fully qualified URLs. Every location is an absolute address including the scheme and host. Relative paths are not valid here.
• One host per file, unless you have verified ownership of the others and are deliberately cross submitting.
• lastmod is the one optional field worth filling, in a valid date format, reflecting a real content change. Google's documentation is explicit that it uses the value when it is consistently and verifiably accurate, which is the same as saying it stops using it when it is not.
• changefreq and priority are ignored by Google. A generator that offers sliders for them is offering you decoration. Leave them out and the file is smaller and clearer.
• 50,000 URLs and 50MB uncompressed per file. Above either limit, split the file and list the parts in a sitemap index, which has the same two limits applied to sitemaps rather than URLs.

The four mistakes a generator will make on your behalf

• Staging and preview URLs. The commonest single defect, and it happens when a generator runs against the wrong host or picks up absolute links left in content. Search the finished file for your staging hostname before you submit it.
• URLs you have told search engines to ignore. Noindexed pages, non canonical variants, redirects and anything blocked in robots.txt. A sitemap is a list of pages you want indexed, so including a page you have excluded elsewhere is a contradiction that gets reported back to you as an error.
• Every lastmod stamped with today. Some generators date every URL with the moment the file was written. That is the one way to make the field worthless, because a file claiming the entire site changed this morning will stop being believed.
• Parameters and facets. A crawler following filter links will happily add ten thousand sorted, filtered variants of one category. Exclude parameters before the export rather than cleaning the XML afterwards.

A five minute check before you submit anything

• Open the file in a browser at its real URL. It has to be served as XML at a stable address, not downloaded from a tool's temporary link.
• Count the URLs and compare the number with what you expect. An order of magnitude difference either way tells you something before any search engine does.
• Spot check ten of them. Fetch each and confirm a 200 response and that the URL in the address bar is the one in the file, which catches redirects and canonical mismatches at the same time.
• Search the file for the three dangerous strings: your staging host, a question mark, and the word test.
• Add the Sitemap line to robots.txt. One line pointing at the file, which every engine reads, and the settings to get right in that file are covered in robots file generator.
• Then submit it and read the report, which is where the discovered count and the errors appear. The two submission methods and how to interpret the result are in how to submit a sitemap to Google.

The specialised sitemaps, and when you need one

• Image and video sitemaps. Extensions to the same format that carry extra fields about the media on a page. Worth it when images or video are the product being searched for, such as stock libraries or recipe sites, and unnecessary when they are illustration.
• News sitemaps. A separate format with a short window, for publishers posting many items a day.
• Language annotations. Alternate language versions can be declared inside the sitemap instead of in page markup, which on a large multilingual site is far easier to maintain in one generated file than across thousands of templates.
• Very large sites. Split by section rather than arbitrarily, because then the discovered and indexed counts per sitemap become a diagnostic: one section indexing at a third of the rate of the others is a question worth asking.

XML sitemap generator: the questions that come up

Do I need a sitemap at all?

A small, well linked site will be found without one. A sitemap earns its place when pages are not well linked, when the site is large, when it is new with few inbound links, or when content is added faster than a crawler would return. It is cheap enough that the question is usually academic.

Is a free online generator good enough?

For a one off file on a site that rarely changes, yes. Check two things before trusting the output: whether the crawl was capped at a number of URLs, because free tiers usually are, and whether it has invented lastmod values. Then diary a reminder to regenerate it, because nothing else will.

Where should the file live and what should it be called?

Anywhere stable on the same host. The conventional path is sitemap.xml at the root, and the name matters less than the address never changing, since that address is what sits in robots.txt and in your search console.

How often should it be regenerated?

Whenever the content changes, which is the argument for a generator that runs on publish or on deploy rather than on your memory. For a hand made file, monthly is a reasonable discipline and the first thing to skip in a busy month.

Can one sitemap cover more than one domain or subdomain?

Keep one sitemap per host as the default. Cross submission is possible where you have verified ownership of all the hosts involved, and it is a refinement for a specific setup rather than a starting point.

Does submitting a sitemap get pages indexed?

It gets them discovered, which is a different thing. Indexing is a separate decision made on the page itself, so a sitemap full of thin pages produces a sitemap report full of discovered and not indexed. The file's job is to make sure nothing is missed, not to make anything worth including.

The other list of your pages, which nobody generates

A sitemap is a complete, machine readable list of what you have published, which is exactly what makes it the most useful file on a site for anything that reads the web programmatically. What no tool produces is the matching list in the other direction: which of those pages has ever actually been retrieved and quoted when somebody asked a question about your subject. That is the real coverage figure behind a content programme, and it is usually far shorter than the sitemap. Getting a reading on it starts with asking the questions your buyers ask and seeing which pages come back. AI Knows Us runs those questions across the main assistants and reports which sources the answers were built from.