XML Sitemap Generator & Validator

Paste a URL list to build sitemap.xml — auto-split at 50,000 URLs or 50MB with an index. Or paste an existing sitemap to validate it.

Runs in your browser

Paste a URL list — no crawl, no 500-URL cap, no signup. Over 50,000 URLs it splits automatically and adds an index file.

Saved in this browser only — clearing site data or switching devices removes it. Use Export to keep a backup.

Your list stays in this browser and is never uploaded.

Options

Google ignores this field.

Google ignores this field.

CSV mode only

Used for the index file entries and the robots.txt line.

Paste your URLs, one per line.

What an XML sitemap is actually for

A sitemap is a discovery hint, not an indexing request. It tells a search engine "these URLs exist and here is when they last changed" so the crawler does not have to find everything by following links. It does not promise that any of them will be indexed, and it does not affect ranking.

It matters most when link discovery is weak: a large site, a new site with few external links, pages that are only reachable through a search form or a filter, or content that changes on a schedule you want the crawler to notice. A ten-page brochure site with a linked navigation gains almost nothing from one.

One hard constraint follows from what a sitemap is: every URL must be on the same protocol, host and port as the sitemap file itself. A sitemap at https://example.com/sitemap.xml cannot list http:// URLs, cdn.example.com URLs, or URLs on a different port. This is the most common reason Search Console rejects a file outright.

The limits: 50,000 URLs and 50MB uncompressed

One sitemap file may hold at most 50,000 URLs and must be at most 50MB — 52,428,800 bytes — uncompressed. Both limits apply at once, and the byte limit bites first more often than people expect: long URLs with query strings, or entries carrying several hreflang alternates, can cross 50MB well before 50,000 URLs.

Gzipping the file does not raise the limit. The 50MB is measured before compression, so a 12MB .xml.gz that expands to 60MB is still over. Compression is still worth doing — it cuts transfer time — but it is not a way around the cap.

Past either limit you split the file and list the parts in a sitemap index. This page does that automatically: it counts bytes as it writes and closes a file the moment the next entry would cross either line, so you never get a file that is one URL over.

lastmod: the only optional field Google actually uses

Google uses <lastmod> only when the value is, in its own words, "consistently and verifiably accurate" — that is, when the date matches what actually changed on the page. If it can verify a few dates and they hold up, it uses the field to decide what to re-crawl first. If it cannot, it stops trusting the field for the whole sitemap.

Which means the worst thing you can do is regenerate every lastmod to today on every deploy. Bumping a copyright year in the footer, or rebuilding a static site with no content change, is not a modification worth reporting. A file where all 40,000 dates are identical is a strong signal that the dates are generated rather than real.

The format is W3C Datetime: 2026-09-06 or 2026-09-06T10:00:00+09:00. 2026-9-6, 06/09/2026 and Sep 6, 2026 are all invalid and will be reported as errors. If you include a time, include a timezone offset with it — a bare local time is ambiguous.

changefreq and priority are ignored by Google

Google's own sitemap documentation says it plainly: Google ignores <priority> and <changefreq> values. Setting every page to priority 1.0, or marking your blog "hourly", changes nothing at all in Google Search. The fields are part of the 2005 protocol and predate the crawl scheduling that engines actually use now.

They are not harmful, and Bing and some smaller engines still read them, so an existing sitemap that uses them does not need rewriting. But they are also not a lever: the effort people spend tuning priority values is better spent on lastmod accuracy and on removing URLs that should not be in the file at all.

That is why this page leaves both fields off by default. Turn them on if a specific engine in your market reads them; otherwise a smaller file with accurate lastmod values is strictly better.

Escaping URLs in XML: the five characters

A sitemap is XML, so five characters cannot appear raw inside a <loc>: & becomes &amp;, < becomes &lt;, > becomes &gt;, " becomes &quot; and ' becomes &apos;. The one that breaks real files is & — every URL with two query parameters has one.

  • Wrong: <loc>https://example.com/s?q=a&page=2</loc> — the parser reads &page as the start of an entity and gives up.
  • Right: <loc>https://example.com/s?q=a&amp;page=2</loc> — the crawler still requests the URL with a single &. Escaping is about the XML file, not about the URL.

Non-ASCII characters are a separate question. A path such as /검색 must be percent-encoded as /%EA%B2%80%EC%83%89 before it goes into the file; this page does that for you and leaves already-encoded URLs untouched, so nothing gets double-encoded.

Sitemap index files

A sitemap index is a sitemap of sitemaps. Its root element is <sitemapindex>, each child is a <sitemap> holding a <loc> that points at a sitemap file, and optionally a <lastmod> for that file. You submit the index to Search Console and the engine follows it to the parts.

The index is subject to the same limits: at most 50,000 <sitemap> entries and 50MB. In practice that ceiling — 2.5 billion URLs — is not one you will meet. What you will meet is the same host rule: the sitemap files listed in the index must be on the same host as the index itself.

Splitting by section rather than by arbitrary chunks pays off later: sitemap-products.xml, sitemap-blog.xml, sitemap-categories.xml. Search Console reports indexing coverage per submitted file, so a meaningful split turns the report into a diagnosis instead of a number.

Multilingual sitemaps with hreflang

Instead of putting hreflang tags in every page's <head>, you can declare the whole language cluster in the sitemap. Add xmlns:xhtml="http://www.w3.org/1999/xhtml" to <urlset>, then inside each <url> list every language version as <xhtml:link rel="alternate" hreflang="ko" href="..."/>.

Two rules decide whether Google uses the cluster at all. Every URL must list itself among its alternates — the self-reference — and every URL in the set must list every other URL. If page A points at B but B does not point back at A, Google may discard the whole group, not just the broken link.

The code format is language, or language-region, or language-script: ko, en-GB, zh-Hans. Language is ISO 639-1, region is ISO 3166-1 alpha-2, script is ISO 15924. A region on its own is not valid — gb means nothing without a language. Use x-default for a language-picker or auto-redirecting entry page.

Submitting your sitemap

There are two ways, and doing both costs nothing. Add a line to robots.txt — Sitemap: https://example.com/sitemap.xml, with an absolute URL, anywhere in the file, applying to every crawler — and submit the file in Search Console under Sitemaps. The robots.txt line is what engines other than Google find it through.

If you split into parts, submit the index file, not each part. Search Console will still report coverage for each child file. Bing Webmaster Tools has the same submission flow and also reads the robots.txt line; Naver and Daum have their own webmaster consoles for the Korean market.

After submission, expect a "Couldn't fetch" status for a while — that usually means the fetch has not happened yet, not that something is broken. The statuses worth acting on are parse errors and "URL not allowed", which is the same-host rule catching a URL from another domain.

How to use

  1. Paste your URLs, one per line — or a CSV with url, lastmod, changefreq and priority columns.
  2. Set lastmod if you know the real change dates. Leave changefreq and priority off — Google ignores them.
  3. Download sitemap.xml. Over 50,000 URLs or 50MB you get a ZIP with split files and a sitemap index.
  4. Copy the Sitemap: line into robots.txt and submit the file in Search Console.

FAQ

I submitted a sitemap and my pages are still not indexed. Why?

A sitemap gets pages discovered, not indexed. Google decides indexing separately, based on whether the page is worth storing: duplicates, thin pages, and pages that canonicalise to another URL are all found and then not indexed. Check the page's status in the URL Inspection tool — "Discovered, currently not indexed" means the sitemap worked and the decision was made afterwards.

Should I put noindex or blocked URLs in the sitemap?

No. A sitemap should list the canonical URLs you want crawled. Including a URL that is noindexed, redirected, or blocked in robots.txt sends contradictory signals and shows up in Search Console as a sitemap error. Remove them before generating.

Should I gzip my sitemap?

You can — engines accept .xml.gz — but it does not raise the 50MB limit, which is measured uncompressed. Gzip is worth it for a large file on a slow origin. This page does not produce .gz because browsers cannot compress reliably without an extra library; use your server's gzip or a build step.

How do image sitemaps work?

Add the http://www.google.com/schemas/sitemap-image/1.1 namespace and put <image:image><image:loc>…</image:loc></image:image> inside the <url> of the page the image appears on. At most 1,000 images per URL. Google removed caption, title, license and geo_location from its documentation, so only image:loc is worth writing now.

Is a plain text sitemap good enough?

For many sites, yes. A text sitemap is one absolute URL per line, UTF-8, and Google supports it. You lose lastmod, which is the one field worth having, so use XML if your change dates are real and text if they are not. RSS and Atom feeds also count as sitemaps.

Related tools

More SEO & Web tools: SEO & Web

Send feedback

Found a bug or have an idea? Tell us — it helps make the tools better.

Only needed if you would like a reply.

Page: /seo/sitemap-generator/