XML Sitemap Generator Build a Valid sitemap.xml for Static Sites and Search Console

What this generator does

This tool takes a list of page URLs and turns them into a valid XML sitemap file ready to upload to the root of a domain. It handles the XML declaration, the URL set namespace, one URL element per line, an optional last-modification date, a default priority, and a default change frequency. It removes duplicates when the same URL appears more than once, and it reports the URL count, the duplicate count, and the uncompressed file size so you can see how close you are to the practical limits before you upload.

Everything runs inside the browser. The XML is assembled locally from the URLs you paste, and nothing is transmitted anywhere. If the AI insight button is pressed, only an anonymous summary of the URL count, the duplicate count, the default priority, the default change frequency, and whether last-mod dates were included is sent to a small serverless function that runs once and then stops. The actual URLs, the hostname, and any path detail are never included.

The generator is a starting point for a clean sitemap, not a replacement for the webmaster tools of each search engine. Use it to build the file, upload it to the root of the domain, and then submit the sitemap URL in Google Search Console and Bing Webmaster Tools so the search engines know to fetch it.

How the Sitemap Protocol is structured

The Sitemap Protocol is published at sitemaps.org and is understood by Google, Bing, Yandex, and most other major crawlers. A valid sitemap begins with an XML declaration, then a urlset element that carries the namespace of the protocol, and then one url element per page. Each url element contains a loc child with the full address of the page, and may optionally contain a lastmod date, a changefreq value, and a priority value.

Only the loc element is required. The other three are optional, and Google has stated publicly that it largely ignores both changefreq and priority, while it does pay attention to a lastmod that reflects a real content change. That said, all three are valid in the protocol, and Bing and Yandex are more likely to use the values you provide. If you include them, keep them honest.

The file must be UTF-8 encoded and served with an XML content type. It should be no larger than fifty megabytes uncompressed and no more than fifty thousand URLs per file. A sitemap can also be referenced from robots.txt with a Sitemap directive, which is a convenient way to advertise its location without submitting it in each webmaster tool separately.

What priority and changefreq actually do

The priority field is a hint between 0.0 and 1.0 that expresses how important a URL is compared with the other URLs on the same site. It is not a ranking factor and it does not affect how a page competes with pages on other sites. Google has stated publicly that it ignores the value in most cases. The field exists so that a large site can signal relative importance between its own pages when a crawler has to decide what to fetch first. If every page on the site is set to 1.0, the signal is meaningless because no page is more or less important than any other.

The changefreq field is a hint about how often a page is likely to change. Valid values are always, hourly, daily, weekly, monthly, yearly, and never. Bing and Yandex are more likely to use the value than Google. If you set every page to always, you are telling the crawler that nothing can be trusted to be stable, which is rarely true and rarely useful. Set a value that reflects reality, and leave the field out entirely if the value would be a guess.

For a small static site or a personal blog, the honest answer is often that neither field adds much value. The sitemap still serves its purpose through the loc element alone, which is what a crawler uses to discover the URL. Adding priority and changefreq because the fields exist, rather than because they communicate something real, is one of the more common small mistakes in sitemap management.

Last modified dates done properly

The lastmod field is the most useful optional field in a sitemap when it is accurate. A date that reflects a real content change helps a crawler decide whether a recrawl is worthwhile, and it helps a site owner audit which pages have gone stale. A date that updates automatically on every server build, or that reflects the date the sitemap file was generated rather than the date the page content changed, is worse than no lastmod at all because it teaches the crawler to ignore the field.

The format is W3C Datetime. The simplest valid form is the ISO 8601 date only, written as YYYY-MM-DD. A full timestamp with time and timezone is also valid, written as YYYY-MM-DDThh:mm:ss+00:00, but the date-only form is easier to keep accurate and is what most static site builders produce. If the page has a visible published date or a structured data dateModified field, keep the lastmod consistent with it so the site tells a single story about when the content changed.

This generator offers a checkbox that inserts today's date as lastmod for every URL. That is useful when you have just republished every page in the sitemap, and it is misleading when only one page has changed. Leave the checkbox off when you want to add per-URL lastmod dates by hand after generating the file, or when the URLs already have their own accurate dates on the page.

Sitemap index files for large sites

A single sitemap file may contain up to fifty thousand URLs and be no larger than fifty megabytes uncompressed. A site with more than that many indexable pages, or a site that wants to separate pages by type, uses a sitemap index file. The index lists the location of each child sitemap, plus an optional last-modification date for each, and can itself contain up to fifty thousand child sitemap entries.

A small site that has under a few thousand pages does not need an index file. A site that has grown past a few thousand pages, or that wants to report on indexing per content type in Search Console, benefits from splitting the sitemap into a small index and a set of child files. The pattern is the same for both: put the file at the root of the domain, confirm it loads publicly, and submit the top-level URL in the webmaster tools of each engine.

A worked example

Consider a small static site published on Netlify with a homepage, an about page, a services page, and a contact page. The publisher opens this generator, pastes four full URLs, one per line, all beginning with https and the canonical hostname. They leave the priority at the default 0.8, leave the change frequency at weekly, and leave the include-date checkbox off because the content is stable.

The generator returns a small XML file. The publisher copies the file, saves it as sitemap.xml in the publish directory of the site, and deploys. They then open https://example.com/sitemap.xml in a browser to confirm it loads with the correct XML content, and submit the URL in Google Search Console and Bing Webmaster Tools. A few days later, Search Console reports the sitemap as successfully processed.

Now consider a blog with two hundred published articles. The publisher pastes the homepage, the archive page, and the two hundred article URLs. This time the priority is set to 0.5 for the articles, but because the generator applies a single default, the publisher generates the file, opens it in a text editor, and edits the priorities for the two or three most important articles by hand. They leave the change frequency at monthly, which matches the publication pace, and leave the lastmod dates to be added by their build tool rather than stamping every URL with today's date.

A third example is a documentation site with over fifty thousand pages. The publisher splits the URLs into four files by section, generates each one separately with this tool, writes a small sitemap index by hand that references the four child files, and uploads the index. The total number of URLs per child file stays well under the limit, and each section can be tracked separately in Search Console.

Common mistakes

Setting every URL to priority 1.0. This removes the relative signal entirely. The priority field only carries meaning when values differ. Reserve 1.0 for the homepage, and use a small set of values for the rest of the site.

Stamping every URL with today's date. A lastmod that updates on every build teaches the crawler to ignore the field. Only add a lastmod when it reflects a real content change, and keep it consistent with any visible publication date on the page.

Listing pages that are blocked by robots.txt. A sitemap should only list URLs you want crawled. A contradiction between the two files wastes crawl resources and makes diagnosis harder in Search Console.

Listing redirects and error pages. Redirected URLs and 404 pages do not belong in a sitemap. If a page has been moved, list the new URL and use a redirect to send visitors from the old one, but do not list the old URL in the sitemap.

Using relative URLs. The loc element requires a full absolute URL. A relative path such as /about.html does not resolve and will cause the sitemap to fail validation.

Mixing www and non-www versions of the same host. Pick one canonical hostname and use it consistently. Mixing the two tells the crawler that the site is larger than it is and splits signals across two hostnames.

Forgetting to submit the sitemap. Uploading the file to the root of the domain is only half the job. Submit the sitemap URL in Google Search Console and Bing Webmaster Tools so the search engine knows to fetch it, and check the processing status a few days later.

Never regenerating the file. A sitemap is a living document. Regenerate it when the set of indexable URLs changes, and keep the file in sync with the site structure.

Where this tool stops

This generator produces a valid XML sitemap from the URLs you paste. It does not fetch or verify those URLs, does not check whether they return a 200 response, does not detect redirects, and does not confirm that the pages are indexable or free of noindex directives. It does not model how Google, Bing, or Yandex will interpret the file, and it does not know whether the URLs you have provided match the canonical tags on the pages themselves. Those checks belong to the person publishing the site and to the webmaster tools of each search engine.

It also does not build a sitemap index for you. Sites that exceed fifty thousand URLs or fifty megabytes need to split their sitemap into multiple child files and reference them from an index. This generator produces one file at a time, so you would generate each child file separately and write the index yourself, or split the URLs by section and generate one file per section.

What the tool does give you is a fast, transparent, private way to build a valid sitemap, see the file before you upload it, and copy or download the result in one step. Used together with the webmaster tools of the search engines that matter, it is a practical starting point for anyone who wants a clean, well-formed sitemap without installing a plugin or running a build script.