Sitemap Generator

An XML sitemap is a file listing the URLs on a site that you would like search engines to know about, written in the sitemaps.org 0.9 protocol — a small, stable format that Google, Bing and others have supported for years.

At its simplest it is one root element and one entry per page:

That is a complete, valid sitemap. Everything else the format offers is optional.

It is worth being precise about what a sitemap is for. It is a discovery aid — it tells a crawler which URLs exist so they do not all have to be found by following links. It does not control crawling, it does not force indexing, and it is not a ranking factor. A well-linked site of thirty pages may see no measurable difference from adding one.

Crawlers find pages primarily by following links. That works well when every page is linked from somewhere reachable, and less well in several common situations:

• Large sites, where a crawler may not reach every corner within the effort it is prepared to spend.
• New sites with few or no inbound links, where there is little to follow in the first place.
• Poorly linked pages — archives, deep pagination, anything reachable only through a form or a search box.
• Sites that change often, where an accurate lastmod tells a crawler what is worth revisiting.

What a sitemap does not do is increase crawl budget. It helps direct the effort a search engine was already going to spend; it does not buy more of it. Nor does listing a URL oblige anyone to crawl or index it.

Every sitemap has the same shape: an XML declaration, a urlset root carrying the namespace, and a url element per page. Inside each url, only loc is required.

Notice the second entry. It has a lastmod and nothing else — no empty changefreq, no placeholder priority. That is deliberate and it matters: an empty element such as <changefreq></changefreq>is not “no preference”, it is invalid against the schema, and a validator will reject the file for it. This generator omits optional elements entirely rather than writing them blank.

Three other requirements are easy to miss. The file must be UTF-8. The child elements must appear in schema order — loc, lastmod, changefreq, priority. And the whole file must be valid XML, which is where escaping comes in.

The only required child of a url element, and the one with the most rules attached.

• Absolute. It must begin with a protocol — https://example.com/about, never /about.
• Under 2,048 characters. Rarely a problem outside heavily parameterised URLs.
• XML-escaped. The five reserved characters must be written as entities.
• Canonical. List the version you want indexed, and only that version.

Escaping is where hand-written sitemaps most often break, and the failure is total rather than local — a single raw ampersand makes the whole file unparseable, so one bad URL takes the other forty-nine thousand with it. A query string demonstrates it:

The & between the two parameters is written &. The generator above does this for you, along with the four other reserved characters. It also rejects control characters outright, because those have no entity at all — there is no way to write them into XML, only a way to leave them out.

The date the page’s content last meaningfully changed, in W3C Datetime format. This tool writes the date-only form, 2026-08-17, which is what almost every sitemap uses.

Of the three optional elements, this is the one worth getting right. Google has said it uses lastmod — but only when the values are consistently accurate.

Which is where most sitemaps go wrong. A build process that stamps every page with today’s date on every deploy is not reporting modification, it is reporting deployment. Once the dates are visibly unreliable they stop being trusted, and you have lost the one signal in the file that was being read. If you cannot produce an honest date, leaving lastmod out is better than filling it in.

A hint about update frequency, taking one of exactly seven values:

always</code>, <code>hourly</code>, <code>daily</code>, <code>weekly</code>, <code>monthly</code>, <code>yearly</code>, <code>never

Two are special in the specification: always describes a page that changes on every access, and never describes an archived URL. Neither is an instruction — the protocol itself calls the element a hint, and says crawlers may treat it as such.

In practice they largely do not treat it at all. Google has stated publicly that it ignores changefreq. It costs nothing to include and other crawlers may read it, so there is no harm in setting it — but no crawl schedule is going to change because you did.

A number from 0.0 to 1.0 saying how important a URL is relative to other URLs on the same site. The default is 0.5, so setting that value explicitly conveys nothing.

The comparison is strictly internal. It has no bearing on how your pages rank against anybody else’s, and setting every page to 1.0 — a common instinct — communicates exactly as much as setting them all to 0.5, which is nothing.

Google has stated it ignores priority as well. Like changefreq, it is part of the protocol, harmless to include, and not something to spend time tuning.

The protocol sets two ceilings on a single sitemap file:

• 50,000 URLs per file.
• 50 MB uncompressed. Sitemaps may be gzipped, but the limit applies to the file before compression.

Whichever comes first is the one that binds, and on sites with long URLs it is usually the byte limit rather than the count. A sitemap index is subject to the same ceilings, counted in sitemaps rather than URLs — so the theoretical maximum through one index is 2.5 billion URLs, which is not a limit anybody meets.

The generator above does not stop you exceeding these. It warns, shows the running byte count, and leaves the decision to you — silently truncating somebody’s list would be far worse than telling them it is too long.

When one file is not enough, you split the URLs across several and list those files in a sitemap index — a sitemap of sitemaps.

The root element is sitemapindex rather than urlset, and each entry is a sitemap rather than a url. Only loc and lastmod are permitted inside — changefreq and priority are not part of this schema at all, which is why the index mode in the tool above does not offer them.

Submit the index and search engines follow it to each sitemap, so there is only one URL to register. Splitting by section — pages, posts, products — is the usual arrangement, and it has a practical benefit beyond the size limit: when a search console reports errors, they are attributed to a specific sitemap rather than to one enormous file.

Both live at the root of a site and both talk to crawlers, which is where the similarity ends. They do opposite jobs.

• A sitemap is an invitation. Here are URLs that exist and are worth looking at.
• robots.txt is a restriction. Please do not request these paths.

They connect in one place: robots.txt is the standard location to declare where your sitemap is, with a line reading Sitemap: https://example.com/sitemap.xml. Any crawler that reads robots.txt — which is all of them — picks it up without you registering anything.

A contradiction to avoid: do not list a URL in your sitemap that robots.txt blocks. That tells a search engine to look at something and then forbids it from doing so, and it shows up as an error in search consoles. A robots.txt generator handles the other half of the pair.

1. Upload the file. Usually to the root, as https://example.com/sitemap.xml. A sitemap can only contain URLs at or below its own location, so the root avoids that restriction entirely.
2. Serve it with an XML content type. application/xml or text/xml. Serving XML astext/html is a common cause of a sitemap that looks fine in a browser and fails in a search console.
3. Reference it from robots.txt. One line: Sitemap: https://example.com/sitemap.xml.
4. Submit it in a search console. Google Search Console and Bing Webmaster Tools both accept the URL directly, and both report parse errors and how many URLs were discovered — which is the fastest way to find out something is wrong.

Then leave it alone. Resubmitting an unchanged sitemap achieves nothing, and submitting a sitemap is not a guarantee that anything in it will be indexed — discovery and indexing are separate decisions, and the second one is not yours.

• Listing non-canonical URLs. Including both a page and its duplicates contradicts the canonical tags you already set.
• Unescaped ampersands. The single most common cause of a sitemap that will not parse. One bad URL invalidates the entire file.
• Listing pages robots.txt blocks. Contradictory instructions, reported as an error.
• Including redirects and 404s. Every URL should return 200. A sitemap full of redirects wastes crawl effort on pages that are not there. The HTTP status code reference covers what the others mean.
• Including noindex pages. Asking a search engine to discover something you have told it not to index.
• Meaningless lastmod dates. Stamping every page with the deploy date destroys the only metadata Google reads.
• Setting every priority to 1.0. A relative scale on which everything is equal carries no information.
• Letting it go stale. A sitemap listing pages that no longer exist is worse than one that is merely incomplete.
• Mixing hosts. Entries for a host you have not verified are generally ignored. One sitemap per host.