Sitemap XML generator
Built in your browser · nothing is uploaded
Generates a valid urlset from a list of URLs. The changefreq and priority elements default to omitted because Google says outright that it ignores both. Only lastmod is read, and this form applies it to every URL at once, which is a reason to leave it empty more often than not.
How to use the sitemap xml generator
Two of the four optional elements do nothing. Google’s sitemap documentation states flatly that it "ignores <priority> and <changefreq> values", so both are omitted by default here and filling them in is effort with no return. They stay in the form because the sitemaps.org schema allows them and some other consumers still read them.
lastmod is the one that counts, and it counts conditionally: Google uses it "if it’s consistently and verifiably accurate", verifiable meaning it can compare the claim against the page. A sitemap where every URL asserts today’s date fails that test in one pass, and the element is then discounted across the whole file, so untrue dates cost you the benefit on the pages where the date was true. It should mark a significant change to the page rather than a redeploy or a rebuilt footer.
This generator applies one lastmod to every URL in the list, because there is a single field and it is written into each <url> block unchanged. That is exactly the pattern Google discounts, so use it only when the batch really does share a date, as after a genuine bulk publication. For a mixed set, leave it blank: a sitemap with no lastmod at all is treated as unremarkable, while a sitemap of identical dates is treated as unreliable, and the second is worse.
Location decides scope, with one exemption that the shortened version of the rule usually loses. Google’s sentence is that "unless you submit your sitemap through Search Console, a sitemap affects only descendants of the parent directory", so a file at /blog/sitemap.xml that a crawler simply finds can list pages under /blog/ and nothing above it — while the same file, submitted in Search Console, is not held to that. Putting it at the site root is what makes the scope stop mattering either way, and it is what the robots.txt reference relies on, since a crawler reaching it that way has submitted nothing.
Cross-site listings are allowed but conditional. One sitemap may carry URLs across several hosts and domains, provided you either verify ownership of every site in Search Console or, for a centrally hosted file, have each site’s own robots.txt reference the sitemap that covers it. Without one of those, the foreign URLs are simply ignored.
Two limits and two formalities. A single file is capped at 50,000 URLs or 50 MB uncompressed; past either, a sitemap index pointing at several sitemaps is the answer, and gzip is permitted because the cap is measured before compression. The file must be UTF-8, and all tag values must be entity-escaped, so an ampersand in a query string has to become &. This tool escapes what you paste, so a URL carrying parameters comes out valid rather than breaking the XML.
What a sitemap is not: a request. Google describes submitting one as "merely a hint", with no guarantee that it will even download the file, let alone crawl or index what is in it. Pages sitting in a sitemap and out of the index are ordinary, and the reason is almost always the page rather than the sitemap. The place a sitemap does earn its keep is discovery on a site whose internal linking is thin, on a large site where deep pages are rarely linked, and as a diagnostic: Search Console will tell you which submitted URLs it declined and why, which is a far more useful list than the sitemap itself.
What people use it for
- Submitting a list of URLs after a launch
- Turning a spreadsheet of pages into a valid urlset
- Producing a sitemap for a site with no CMS to generate one
- Building a section sitemap for a folder whose pages are barely linked
- Getting a valid, escaped urlset out of URLs full of query parameters
Questions
Not for Google, which states that it ignores both. They remain valid in the sitemaps.org schema, so other consumers may read them, but nothing in Google Search does.
lastmod, and only where it is "consistently and verifiably accurate", meaning the claimed date survives comparison against the page itself.
Google discounts the element across the file, so you lose the benefit on the pages where the date was correct. A blank lastmod is better than a uniform one.
Because it has a single field and writes it into every url block. Use it for a batch that genuinely shares a publication date, and leave it empty for a mixed list.
A substantive edit to the content. Rebuilding a template, bumping a copyright year or redeploying the site does not qualify, and treating it as though it does is what makes the element unreliable.
W3C Datetime, so a plain date such as 2026-06-04 is valid and a full timestamp with a timezone offset is valid too. Mixed formats within one file are legal but harder to audit.
50,000, or 50 MB uncompressed, whichever comes first. Past either, use a sitemap index pointing at several files.
Yes, and it is worth doing on a large file. The 50 MB limit applies to the uncompressed size, so compression saves bandwidth rather than headroom.
At the site root. Google’s rule is that unless you submit the sitemap through Search Console, it affects only descendants of its own parent directory, so a discovered file at /blog/sitemap.xml cannot cover pages outside /blog/. At the root the question never arises.
Yes, if you have verified ownership of every site in Search Console, or if each site’s robots.txt references the sitemap covering it. Without that, the foreign URLs are ignored.
No. Google calls a submitted sitemap "merely a hint" and does not promise to download it, crawl the URLs or index them.
Discovery. It helps most on large sites, on pages that internal linking barely reaches, and on new sites with few inbound links. On a small, well-linked site the benefit is close to nothing.
No. Listing a URL you have disallowed or marked noindex sends two contradictory signals and shows up as an error in Search Console. Sitemaps should list pages you want indexed.
Take them out. A sitemap full of URLs that no longer resolve reduces the trust placed in the whole file, and Search Console reports them individually.
Yes. Every loc must be a full URL including the scheme, and it must match the canonical form of the page, so pick one of trailing slash or no trailing slash and be consistent.
They must be entity escaped, so & becomes &. This tool escapes what you paste, which is what keeps a URL with query parameters from breaking the XML.
Yes. A Sitemap line in robots.txt applies to the whole file regardless of user-agent group, and it is how crawlers that never see Search Console find it.
Not with this tool. Those need extra XML namespaces on the urlset. This one emits the plain sitemaps.org schema, which is what the majority of sites need.
No, and there is no fixed schedule. Resubmitting after a large publication run is reasonable; resubmitting daily achieves nothing.