Free XML Sitemap Generator

What a sitemap generator should write, and what it should leave out.

Most generators list every URL they reach and decorate each one with a date and a priority. This one lists fewer pages and says why. Here is what goes in a sitemap, what doesn't, why this file carries no dates, and how to put it live without a plugin.

What an XML sitemap is for

An XML sitemap is a file, usually at https://yourdomain.com/sitemap.xml, that lists the pages on your site you want search engines to know about. It exists for discovery: a crawler that reads it learns about pages it might not reach by following links, such as a new article nothing links to yet or a page three menus deep. It does not rank anything, and it does not get a page indexed. Google's own documentation calls submitting one "merely a hint" that "doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site" (Build and submit a sitemap, updated 8 July 2026).

That makes the file a statement more than a lever. Every URL in it says "this is a page I want in search". When the statement is wrong, and the file lists pages that redirect, return errors or ask not to be indexed, it teaches the crawler that your list can't be taken at face value. The value of a sitemap is in its accuracy, which is why this generator spends its effort on what to leave out.

Sitemap generator: crawl a site, or format a list

The tool has two modes, because there are two situations.

• Crawl a site. You give a domain. The tool reads robots.txt, fetches the homepage, and follows same-site links breadth-first, six pages at a time, until it runs out of links or reaches a limit. Each page is checked as it arrives. This is the mode for a site that has no sitemap, or one you don't trust.
• Paste URLs. You already have the list, from a spreadsheet, an export or a site audit. The tool formats it into a valid file in your browser: it escapes the characters XML requires, removes duplicates, stops at the protocol's 50,000-URL limit and writes nothing but <loc>. Nothing is fetched, so nothing is checked: the file is only as right as the list you pasted.

One design choice in crawl mode matters more than it looks. The crawl starts at your homepage and ignores any sitemap you already have. A crawler that seeds itself from your existing sitemap and writes a new one hands you back your own file, errors included. Starting from the homepage shows you what your links actually reach, which is also roughly what a search engine finds without a sitemap. A page missing from the result is a page nothing links to, and that's worth knowing on its own.

Which pages belong in a sitemap

Google's guidance is to list the canonical URLs you want shown in search and, where the same content lives at several addresses, to pick one. In practice that rules out six kinds of page, and they are the six reasons the card counts:

One answer gets its own label instead of a place in that table. A 429 means the site is asking the crawler to slow down, a 503 that it's temporarily unavailable, and no answer at all within 12 seconds usually means a slow or busy server. None of them says the page is missing, so the card marks those pages not checked, keeps them out of the file because they couldn't be verified, and tells you to run it again later. The tool doesn't retry them in the same run: re-asking a site that just said slow down, at the pace that provoked it, is the behaviour the 429 objects to.

Two edge cases follow from reading URLs exactly. /services and /services/ are different addresses, and on most sites one redirects to the other, so only one of them is listed. And a URL with a query string, such as a sorted or filtered view, is listed like any other page if it answers 200 and names itself as canonical. If your filtered pages do that, the fix is their canonical tag, not the sitemap.

Sitemap lastmod, priority and changefreq: why this file has none

The sitemap protocol allows three optional tags per URL. Google's documentation settles two of them in one sentence: "Google ignores <priority> and <changefreq> values." The third, <lastmod>, it uses only "if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate."

A crawler can't know when your content last changed. The dates generators write come from a server header, the time of the crawl, or nothing at all, and a date that moves every time the file is rebuilt is exactly the inaccuracy Google describes. Priorities set by URL depth are guesses about your business written in your name. So this generator writes neither, the same rule Verand's product follows: a wrong date is worse than none. If your CMS knows the real modification time of each page, let it write lastmod; that is information only your site has.

A sitemap XML example, from a real crawl

This is the start of the file the tool wrote for verand.ai on 29 September 2026. The crawl reached every linked page, 130 of them, in under ten seconds, and listed 125:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://verand.ai/</loc></url>
  <url><loc>https://verand.ai/pricing</loc></url>
  <url><loc>https://verand.ai/features/article-generator</loc></url>
  [122 more entries]
</urlset>

The five pages it left out are the useful part. All five answered 404, and all five are links on our own site to pages that haven't been built yet, such as /insurance-agencies/advertising-rules. A generator that lists everything it reaches would have put them in the sitemap. This one kept them out and named them, which turns the sitemap run into a broken-link report for the pages it read.

The same day, willowdaleequity.com, a site with roughly 245 articles, filled all 150 pages with nothing to leave out, and the card said the crawl stopped at the cap with 99 same-site links still unvisited. That result is a partial list, and the card says so rather than presenting it as the whole site.

When the crawl stops early

The file is never padded and never silently partial. The card reports which of these ended the crawl, and how many links it found but didn't visit:

• Complete. Every same-site link found was followed. For a site under 150 linked pages, this is the whole site as links reach it.
• The page cap. 150 pages fetched. The cap keeps a run inside the time a free tool can hold open; the file lists only the pages that were read.
• The time limit. The crawl stops starting new requests at 40 seconds so the answer comes back inside a minute. A slow site reaches fewer pages before then.
• The site's budget. Our free tools cap the requests they send to any one site at 320 a minute and 1,200 an hour, shared by everyone using any of them. A crawl reserves its worst case before it starts; if the budget runs out partway, it stops, and if there isn't room to start, the tool says when to try again.
• Crawl-delay. If your robots.txt asks our crawler, or all crawlers, to wait between requests, the tool fetches one page at a time with that pause, up to 10 seconds, and stops before the time limit. A site with a long delay gets a short list. (Google itself ignores Crawl-delay; we honour it because it's addressed to us.)

My CMS already makes a sitemap. Do I need this?

Usually not, and the honest answer is to check before you replace anything. WordPress has served a basic sitemap at /wp-sitemap.xml since version 5.5, and SEO plugins such as Yoast and Rank Math swap in their own. Shopify, Wix and Squarespace generate /sitemap.xml for every site automatically. Static site frameworks have sitemap plugins or conventions, such as @astrojs/sitemap for Astro or a sitemap route in Next.js. A file your platform maintains updates itself as you publish, which a file you upload by hand never will.

So the better first step on those platforms is the Sitemap Checker, which finds the file you already serve, then the Sitemap Validator, which reads it for errors. Where this generator earns its place: a hand-built or legacy site with no sitemap, a platform whose generated file lists pages it shouldn't, or a quick independent crawl to compare with what your CMS claims.

How to create a sitemap without a plugin

1. Generate it. Crawl your domain above, or paste the list of pages you want listed. Read the pages left out: a 404 or a redirect in that list is usually an internal link to fix.
2. Save it as sitemap.xml, UTF-8, exactly as downloaded. Don't add dates by hand unless they're true.
3. Upload it to the root of the site, so it answers at https://yourdomain.com/sitemap.xml. On a static site that means the folder that becomes the root of the build, usually public/ or static/. A sitemap covers the URLs at or below its own location, so the root covers everything.
4. Point to it from robots.txt with one line anywhere in the file: Sitemap: https://yourdomain.com/sitemap.xml. Crawlers that read robots.txt find it there without being told.
5. Submit it in Google Search Console under Sitemaps, and in Bing Webmaster Tools if you use it. The report shows when the file was last read and how many URLs were discovered from it.
6. Regenerate it when the site changes. An uploaded sitemap is a snapshot. New pages aren't in it until you run it again.

Common mistakes

• Listing every URL the crawler reached. Redirects, error pages, noindexed thank-you pages and parameter duplicates all end up in crawl-dump sitemaps. Each one is a line that says something untrue about the site.
• Stamping every URL with today's date. It looks fresh and tells the crawler nothing, and Google says it uses lastmod only when it is consistently accurate.
• Mixing hosts. A sitemap on www.yourdomain.com should list www URLs. Paste mode keeps the lines on the host of your first URL and sets the rest aside for that reason.
• Uploading a second sitemap beside the platform's. Two files that disagree are worse than one. If your CMS has one, fix that one.
• Treating a submitted sitemap as indexed. Search Console will tell you how many listed URLs were indexed. The sitemap only made sure they were found.
• Forgetting the robots.txt line. It costs one line and lets every crawler that reads robots.txt find the file, not only the ones you submitted it to.

If your site has more than 150 pages

The file this tool writes is honest about being partial, but it is partial. For a larger site the right source is almost always the platform's own sitemap, which knows every page. Other free crawlers go further than 150 pages, and the Sitemap Validator will tell you whether what they produce lists pages it shouldn't. Past 50,000 URLs, or 50 MB uncompressed, the protocol requires splitting the list across several files joined by a sitemap index, which this tool does not write.