What the tool builds
A sitemap is an XML file, defined by the sitemaps.org protocol, that lists URLs you want search engines to discover. Paste one URL per line and the generator wraps each one in a <url> element inside a <urlset> declared with the http://www.sitemaps.org/schemas/sitemap/0.9 namespace. Only valid http:// or https:// URLs are kept; any other line is skipped and listed in a warning, repeated URLs are written once with a note saying how many were removed, and the heading shows how many URLs made it in. Each URL is written in its normalised form, so spaces and non-ASCII characters are percent-encoded (/a b becomes /a%20b), and characters that are special in XML, such as the ampersand in a query string, are escaped as & for you. Download it as sitemap.xml or copy it.
Worked example
Pasting https://example.com/ and https://example.com/about with weekly, 0.8 and a last-modified date of 2026-10-06 entered gives, for each URL:
<url>
<loc>https://example.com/about</loc>
<lastmod>2026-10-06</lastmod>
<changefreq>weekly</changefreq>
<priority>0.8</priority>
</url>Which tags actually matter
| Tag | Status |
|---|---|
<loc> | Required. The absolute URL, which should be the canonical version. |
<lastmod> | Used by Google when it is consistently accurate, meaning the date the page content last meaningfully changed. |
<changefreq> | Ignored by Google. |
<priority> | Ignored by Google. It only ever described relative importance inside your own site. |
The tool applies one change frequency and one priority to every URL, and offers them because the protocol defines them and some consumers still read them. For Google, the best output is often just <loc> and an honest <lastmod>. The last-modified field is empty by default, so no <lastmod> is written unless you enter a date (a "Use today" button fills in the current one). The date applies to every URL, so use it only when that is true: stamping everything with the current date teaches crawlers that your lastmod values are unreliable. You can set the change frequency and priority to "(omit)" to leave those tags out.
Limits and mistakes
- Size. A single sitemap may hold at most 50,000 URLs and 50 MB uncompressed. Past 50,000 URLs on one host the generator splits that host's list into numbered files and makes a sitemap index pointing at them on the same host; submit the index. For a single-host list the names are
sitemap-1.xml,sitemap-2.xmland so on, withsitemap.xmlas the index. When the list covers several hosts, each host's index issitemap-<host>.xmland its chunks aresitemap-<host>-1.xml,sitemap-<host>-2.xmland so on. If two names would clash, a counter such as-2is added to the host part, and the index entries always match the files. It does not measure the 50 MB size, so very long URLs could still need a smaller split. - List only indexable URLs. Leave out redirects, 404s, noindex pages and URLs blocked by robots.txt. A sitemap full of those wastes crawl attention and clutters Search Console reports.
- One host per sitemap. A sitemap should only list URLs on the same host and scheme as the file itself, because search engines ignore entries from other hosts. You can paste a mixed list anyway: the tool groups the URLs by scheme and host and writes a separate file for each, named after the host (
sitemap-example.com.xmlandsitemap-blog.example.org.xml, with the scheme added only when the same host appears over both http and https). Upload each file to the root of its own host and reference it in that host's robots.txt. A list with a single host keeps the plainsitemap.xmlname. Exact duplicates are removed. - It is a hint, not a guarantee. Listing a URL does not force indexing, and URLs not listed can still be found through links.
Upload the file to your site root, add a Sitemap: line using the robots.txt generator, and submit it in Google Search Console. For multilingual sites see the hreflang tag generator, and use the broken link checker and the guide to finding and fixing broken links to prune dead URLs before listing them.