Skip to the tool
OnPageKit

XML Sitemap Generator

Turn a list of URLs into a valid sitemap.xml.

one URL per line

Add a date to a single URL by writing it after a comma: https://example.com/a,2026-01-15

YYYY-MM-DD
0 URLs
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
</urlset>

Everything runs in your browser. Nothing you type is sent to a server.

Found a bug in this tool? Report it.

Share this tool

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

  1. Paste one URL per line. Every URL must be absolute, including the scheme.
  2. Set a default lastmod, or press Use today. Leave it empty if you do not have real dates.
  3. Give one URL its own date by writing it after a comma: https://example.com/a,2026-01-15.
  4. 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.

ElementRequiredWhat Google does with it
<loc>YesThe URL itself. Must be absolute, escaped, and on the host serving the file.
<lastmod>NoUsed, if it is credible. It is a strong signal for recrawl scheduling.
<changefreq>NoIgnored.
<priority>NoIgnored.

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.

Frequently asked questions

Does a sitemap make Google index my pages?

No. A sitemap is a discovery hint, not an instruction. It helps Google find URLs it might otherwise reach slowly — deep pages, pages with few internal links, a site that has just launched. Whether a URL gets indexed still depends on whether the page is worth indexing.

What is the difference between a sitemap and robots.txt?

They answer opposite questions. A sitemap says which URLs exist and are worth crawling; robots.txt says which paths a crawler must not fetch. Listing a URL in one and blocking it in the other is the contradiction Search Console reports as "Indexed, though blocked by robots.txt".

How many URLs fit in one sitemap file?

Fifty thousand, and 50 MB uncompressed. Past either limit you split the list into several files and publish a sitemap index that points at them. The index itself holds up to 50,000 sitemaps, so the format scales further than any site needs.

Should I set changefreq and priority?

Google ignores both, and has said so publicly for years. They remain valid elements, so nothing breaks if you include them, but they buy you nothing. Bing treats them as weak hints at most. Spend the effort on lastmod instead, which is read.

Where do I submit the finished file?

Upload it to the root of your site, add a Sitemap: line to robots.txt pointing at the absolute URL, and submit it once in Search Console. After that Google re-fetches it on its own schedule; resubmitting on every deploy achieves nothing.

Related tools

Updated