What this tool does
This sitemap generator turns a list of URLs you paste into a valid sitemap.xml — the file search
engines read to learn which pages exist on your site. It removes duplicates, refuses relative
paths, escapes the characters that break XML, and warns you when the file grows past what the
format allows.
It will not crawl your site for you. Fetching pages from another domain requires a server, and this tool has none — everything happens in your browser and nothing you paste is uploaded. To get the list of URLs, export it from your CMS, pull it from a crawler you already run, or copy it out of your framework's route table.
How to use it
- Paste one URL per line. Every URL must be absolute, including the scheme.
- Set a default
lastmod, or press Use today. Leave it empty if you do not have real dates. - Give one URL its own date by writing it after a comma:
https://example.com/a,2026-01-15. - Download the file, upload it to the root of your domain, and declare it in
robots.txt.
What Google actually reads
Of the four elements the protocol defines, only two carry weight.
| Element | Required | What Google does with it |
|---|---|---|
<loc> | Yes | The URL itself. Must be absolute, escaped, and on the host serving the file. |
<lastmod> | No | Used, if it is credible. It is a strong signal for recrawl scheduling. |
<changefreq> | No | Ignored. |
<priority> | No | Ignored. |
The word doing the work in that table is credible. A lastmod that updates on every URL every
night, because the sitemap is regenerated by a build step, tells Google that the dates are a
side-effect of your deployment pipeline rather than a record of content changing. Once the file
loses that trust, the dates stop being consulted at all — and you have thrown away the only
element in the file that could have earned you faster recrawls.
So: set lastmod to the date the page's content last changed in a way a reader would notice.
Fixing a typo is not that. Rewriting three sections is. If you cannot produce honest dates, leaving
the element out entirely is better than filling it with today.
The 50,000 limit, and the sitemap index
One file holds 50,000 URLs or 50 MB uncompressed, whichever comes first. Above that you split the list and publish an index — a second file, in a different format, listing the sitemaps rather than the pages:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-pages.xml</loc>
<lastmod>2026-09-04</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-blog.xml</loc>
<lastmod>2026-09-04</lastmod>
</sitemap>
</sitemapindex>
Splitting by section rather than by arbitrary batches of 50,000 is worth the small extra effort: Search Console reports coverage per sitemap, so a file per content type turns "1,400 pages not indexed" into "the product pages are fine, the tag archive is not".
Where to declare it
Two places, and they do different jobs. In robots.txt, one absolute URL per line — this is how
every crawler that is not Google finds the file, and it costs one line:
Sitemap: https://example.com/sitemap.xml
The robots.txt generator writes that line for you. Then submit the file once in Search Console, which is the only way to see the per-URL coverage report. Submitting is a one-off; Google re-fetches on its own schedule afterwards, and pinging it on every deploy has been a no-op since the ping endpoint was retired in 2023.
Mistakes this generator refuses to make for you
Relative URLs. /about is dropped, not silently prefixed. A <loc> is an absolute URL by
definition, and guessing the host would produce a file that validates and points at nothing.
Duplicates. The same URL twice is not a stronger hint; it is an invalid file. The first
occurrence wins, including its lastmod.
Unescaped ampersands. A URL like ?q=a&b=1 written literally makes the XML unparseable, and
the whole file is rejected rather than the one URL. Every &, <, >, " and ' is escaped
here.
Mixed hosts. A sitemap covers the host that serves it. URLs on a second domain are kept but flagged, because they will be ignored unless you cross-submit the file in Search Console.
What belongs in the file
Canonical, indexable URLs, and nothing else. A URL that redirects, returns a 404, carries a
noindex, or canonicalises to a different page sends a contradictory signal: the sitemap says
"crawl this, it matters" and the page says the opposite. Search Console reports these as errors,
and enough of them reduce how much the file is trusted overall.
Pagination, filtered listings and tracking parameters are the usual culprits. If you tag campaign links with UTM parameters, keep those out — the UTM builder explains why those URLs should never be the ones you ask to have indexed.