The first sitemap I ever hand-wrote had a bug that took me a week to notice. One of my URLs had a query string with an ampersand in it — something like ?id=1&sort=name — and I had pasted it straight into a <loc> tag. Google Search Console flagged the whole sitemap as invalid, but the error message was vague enough that I assumed the problem was elsewhere. It was not. A raw ampersand is illegal in XML; it has to be written as &. One character broke the entire file, and every page in it went unsubmitted while I hunted for a problem I did not understand.
That experience shaped how I think about sitemaps, and eventually about why I added an XML Sitemap Generator to toolz.dev. A sitemap is not conceptually hard — it is a list of URLs wrapped in tags — but the format is unforgiving, and the parts that trip people up are exactly the parts a machine should handle: escaping reserved characters, validating that every URL is absolute, catching duplicates, and staying under the protocol's size limits. Between running the SEO for my own projects and building the WordPress plugin WP Adminify, I have generated more sitemaps than I can count, and the same handful of mistakes recur every time. This guide walks through what a sitemap actually is, what belongs in it, and how the generator removes the sharp edges.
TL;DR: An XML sitemap is a list of your site's important URLs in the sitemaps.org format, so search engines can crawl them efficiently. Each
<url>needs a<loc>and can carry optional<lastmod>,<changefreq>, and<priority>tags. A single file is capped at 50,000 URLs and 50 MB. The XML Sitemap Generator takes a plain list of URLs, escapes them correctly, removes duplicates, warns at the limits, and produces a valid sitemap.xml you can download and submit — all in your browser.
What is an XML sitemap, and do I need one?
An XML sitemap is a file that lists the URLs on your site you want search engines to know about. It follows a small, well-defined standard published at sitemaps.org and supported by Google, Bing, and every other major engine. The file wraps each URL in a <url> element inside a single <urlset>, and declares a namespace so parsers know which version of the protocol it speaks.
The minimal valid sitemap looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/</loc>
</url>
</urlset>
That is the whole shape. Everything else — dates, frequencies, priorities — is optional decoration on top of the one required element, <loc>.
Do you need one? Search engines find pages primarily by following links, so a small, well-linked site is often discovered fine without a sitemap. But a sitemap earns its keep in several common situations: a large site where crawlers might not reach every page in a reasonable number of hops; a new site with few external links pointing at it; a site with pages that are not well connected internally, like deep archive content; or a site that changes often and wants to signal freshness. A sitemap does not guarantee indexing — it is an invitation, not a command — but it makes your important URLs easy to find, and it gives you a clean channel to tell Google about pages it might otherwise miss.
What information goes in each URL entry?
Beyond the required <loc>, the protocol defines three optional child tags, and there is a lot of folklore about how much they matter. Here is the honest version.
<loc> is the page URL. It must be absolute — starting with http:// or https:// — fully qualified, and XML-escaped. This is the tag my old ampersand bug lived in, and the generator escapes the five XML special characters automatically so you never hit it.
<lastmod> is the date the page last changed, in W3C Datetime format: either a plain 2026-07-25 or a full timestamp like 2026-07-25T14:30:00+00:00. This one genuinely matters. Google has said it uses lastmod as a signal for when to recrawl a page, provided the value is accurate and consistent. If you stamp every page with today's date on every build, you are lying to the crawler and it will learn to ignore you. Use a real modification date.
<changefreq> hints how often the page changes — always, hourly, daily, weekly, monthly, yearly, or never. Google has been clear that it largely ignores this tag, treating it as a weak hint at best. It does no harm to include, but do not agonise over it.
<priority> is a number from 0.0 to 1.0 suggesting a page's importance relative to other pages on your own site. It does not affect your ranking against other sites, and Google mostly ignores it too. The common mistake is setting every page to 1.0, which makes the tag meaningless. If you use it at all, reserve the high values for your genuinely most important pages.
The generator lets you apply changefreq, priority, and lastmod globally to every URL, and cleanly omits any tag you leave blank — so if you want a bare sitemap of just <loc> entries, which is a perfectly valid and increasingly popular choice, you get exactly that.
How do I create a sitemap.xml file?
The workflow is built to be fast and to eliminate the format errors that plague hand-written sitemaps.
Start by pasting your URLs into the input, one per line. You can paste a list exported from your CMS, a crawl, or a spreadsheet column. Blank lines are ignored, and any line beginning with # is treated as a comment, so you can annotate or temporarily disable URLs without deleting them. Every line is run through the WHATWG URL parser: if it is not a valid, absolute http or https URL, it is skipped and reported, so a stray relative path or a typo never silently corrupts the output.
Next, set the defaults. Choose a change frequency from the dropdown, set a priority if you want one, and toggle the last-modified date on — it defaults to today but you can pick any date. Then decide on cleanup: enable de-duplication to drop repeated URLs (on by default, because duplicate <loc> entries are a common copy-paste artefact), and optionally sort the list alphabetically so it is easier to scan and diff against a previous version.
The output updates live as you change anything. When it looks right, copy the XML or download it directly as sitemap.xml. The tool also reports how many URLs made it in, the file size, and any lines it skipped and why — so you get a clear account of exactly what went into the file, not just a blob of XML you have to trust.
Where do I put the sitemap and how do I submit it?
Generating the file is half the job; the other half is making search engines aware of it.
First, upload sitemap.xml to your site's root so it is reachable at https://yoursite.com/sitemap.xml. The location matters more than people expect: a sitemap can only contain URLs from the same directory level or below where it sits, so putting it at the root lets it cover the whole site. Most hosts and CMS platforms let you drop a static file in the web root, or you can serve it from a route.
Second, submit the sitemap URL in Google Search Console under Indexing → Sitemaps, and in Bing Webmaster Tools under the equivalent section. You paste the full URL and the engine fetches it, reports how many URLs it read, and flags any errors. This is also where you will see whether Google actually indexed the pages, which is separate from whether it read the sitemap.
Third — and this is the step most people skip — add a reference in your robots.txt. A single line, Sitemap: https://yoursite.com/sitemap.xml, lets any crawler discover your sitemap automatically without you submitting it anywhere. It is the belt-and-braces move, and it pairs naturally with the robots.txt generator on the site, which can produce that file with the sitemap line already in place. The two tools are designed to be used together: robots.txt tells crawlers what they may access, and the sitemap tells them what exists.
What are the size limits, and what happens when I exceed them?
The sitemaps.org protocol caps a single sitemap file at 50,000 URLs and 50 MB uncompressed. These are hard limits — a file that breaches either one is rejected — and they exist so that parsers do not have to load unbounded files into memory.
For most sites this is a non-issue; you will run out of pages long before you run out of room. But large e-commerce catalogs, news archives, and user-generated-content sites blow past 50,000 URLs routinely. When that happens, the answer is a sitemap index: you split your URLs across several sitemap files (each under the limit) and create one index file that lists them. The index uses a <sitemapindex> wrapper instead of <urlset>, and search engines fetch the index first, then each child sitemap.
The generator counts your URLs and the byte size of the output as you build, and warns you the moment either limit is crossed, with a plain-language note telling you to split into multiple files behind an index. That early warning is deliberate — the worst time to discover you are over the limit is after you have submitted a file that Search Console then rejects. Knowing your count as you go turns a failure into a planning decision.
A comparison: what belongs in your sitemap, and what does not
A sitemap is a statement of intent — "these are the canonical pages I want indexed" — so what you leave out is as important as what you put in. Padding it with junk sends mixed signals and can dilute how much Google trusts it.
| Include | Exclude |
|---|---|
| Canonical, indexable pages you want ranked | Duplicate or non-canonical URLs |
| Important content and category pages | Pages blocked by robots.txt or noindex |
| Fresh pages you want recrawled | Redirects (3xx) and error pages (4xx/5xx) |
| Pages weakly linked internally | URLs with tracking parameters or session IDs |
The guiding principle is that every URL in your sitemap should return a 200 status, be canonical, and be a page you would be happy to see in search results. Listing a URL does not force Google to index it, and listing pages you have told Google to ignore elsewhere — via a noindex tag or a robots.txt block — is contradictory. A focused sitemap of your best pages consistently outperforms an exhaustive dump of everything the crawler could theoretically reach.
Where does a sitemap generator fit in an SEO toolkit?
I build toolz.dev as a connected set of utilities rather than a pile of unrelated gadgets, and the technical-SEO tools are designed to work as a group. The sitemap generator pairs most directly with the robots.txt generator — the two files are the standard handshake between your site and a crawler, one saying what may be accessed and the other listing what exists. On the page level, the Meta Tag Generator produces the title, description, and Open Graph tags that determine how each of those sitemap URLs appears in search results and social shares. And when you are building the URLs themselves, the Slug Generator turns page titles into the clean, readable paths that make a good sitemap in the first place.
The thread connecting them is that each does one job precisely and locally, without uploading your data. That last point is not incidental for a sitemap tool: your URL list is effectively a map of your entire site structure, including pages you might not have launched yet, and it should not be sent to a third-party server just to be wrapped in tags. Everything here runs in your browser, which makes it safe to use on staging sites and client work under NDA — a privacy stance I wrote about at length in the guide on keeping your data private with client-side tools. It is the same building philosophy I bring to every utility on the site, which I unpacked in the web developer toolkit guide: small, sharp, honest tools beat bloated all-in-one platforms that want your data as the price of admission.
Common mistakes when building a sitemap
The recurring errors are worth naming so you can avoid them. First, unescaped special characters — the ampersand bug I opened with. Raw &, <, and > characters in a URL break the XML. The generator escapes all five reserved characters automatically, but if you hand-edit the file afterwards, keep it in mind.
Second, relative or protocol-relative URLs. A <loc> must be absolute and include the scheme. /about or //example.com/about are both invalid; only https://example.com/about works. The tool rejects and reports anything that is not a proper absolute URL rather than passing it through.
Third, including non-canonical or non-indexable URLs — redirects, noindexed pages, or duplicates with tracking parameters. These send contradictory signals and waste crawl budget. Keep the sitemap to canonical 200-status pages.
Fourth, stale or dishonest lastmod dates. Stamping every page with the current date on every deploy teaches Google to distrust the tag entirely. Use real modification dates, or leave lastmod off rather than faking it.
Fifth, forgetting to resubmit or reference the sitemap. Generating the file does nothing on its own — you have to upload it, submit it in Search Console, and ideally point to it from robots.txt. A sitemap sitting on your server that no crawler has been told about is just a file.
Frequently asked questions
What is an XML sitemap?
An XML sitemap is a file that lists the important URLs on your site so search engines can find and crawl them efficiently. It follows the sitemaps.org protocol, wrapping each URL in a <url> element with an optional last-modified date, change frequency, and priority. Submitting one helps search engines discover pages that are not well linked internally.
How do I create a sitemap.xml file?
Paste your site's URLs into this generator, one per line, set the change frequency and priority you want, then copy or download the result as sitemap.xml. Upload that file to your website's root directory so it lives at https://yoursite.com/sitemap.xml, and submit its URL in Google Search Console. The whole process takes a couple of minutes.
What do changefreq and priority actually do?
changefreq hints how often a page changes and priority (0.0 to 1.0) suggests its importance relative to other pages on your site. Both are hints, not commands — Google has said it largely ignores them and relies on its own signals. They do no harm, so set changefreq roughly and reserve priority 1.0 for your most important pages.
How many URLs can one sitemap contain?
A single sitemap file is limited to 50,000 URLs and 50 MB uncompressed. If your site is larger, split the URLs across several sitemap files and list those files in a sitemap index. This tool warns you as soon as either limit is crossed so you know when to break the file up.
What format should the lastmod date be in?
Use W3C Datetime format: either a plain date like 2026-07-25 or a full timestamp like 2026-07-25T14:30:00+00:00. This generator accepts both and defaults to today's date when you enable lastmod without entering one. Accurate lastmod values help search engines prioritise recrawling pages that have genuinely changed.
Do I need to include every page in my sitemap?
Include the canonical, indexable pages you want ranked, and leave out duplicates, redirects, error pages, and anything blocked by robots.txt or a noindex tag. Listing a URL does not guarantee indexing, and padding the file with low-value URLs sends mixed signals. A focused sitemap of your best pages works better than an exhaustive one.
Where do I submit my sitemap after generating it?
Upload sitemap.xml to your site root, then submit its full URL in Google Search Console under Indexing → Sitemaps and in Bing Webmaster Tools. You can also add a "Sitemap: https://yoursite.com/sitemap.xml" line to your robots.txt file so any crawler can discover it automatically.
Is my URL list kept private?
Yes. The entire sitemap is built in your browser with plain JavaScript. Your URLs — which can expose your whole site structure — are never transmitted, logged, or stored, and the tool keeps working with no network connection once the page has loaded.
