XML Sitemap Generator Free Tool

About XML Sitemap Generator

What This Tool Actually Does

The XML Sitemap Generator on this page is a browser-driven website crawler with a narrow, specific job. You give it a domain, pick a few options, and it walks through the pages of that site one at a time, collecting the addresses it finds and writing them into an XML document that follows the sitemaps.org protocol. The result is offered to you as a downloadable file named sitemap.xml.

The crawl does not happen in some distant cloud. Your browser does the orchestration. The page sends one address to this site's server, the server fetches that single page and returns the list of internal links it found, and your browser then takes the next address from that list and asks for it. This loop repeats, one page per request, until the queue runs dry, until you hit the page limit you chose, or until the hard ceiling of 50 fetched pages is reached. Each step is a separate request to this site, and each step is visible to you through a status line that shows which link is being crawled and how many links have been found so far.

What you get at the end is plain text in a scrollable box. The text starts with the XML declaration and the standard urlset wrapper, and it contains one url entry for every page the crawler actually reached. You can read that text, copy it, or click a button that builds a download link in your browser and saves the exact same text to your computer as sitemap.xml. Nothing is stored on this site's server. The file exists only in your browser until you save it.

The tool makes no attempt to render pages, run JavaScript, or behave like a full browser. It asks this site's server to fetch each page with a simple HTTP request, no custom user agent, following redirects, with a timeout of one minute. Pages that need JavaScript to show their links will appear to have no links at all. Pages that reject requests without a user agent will fail entirely. This is a link collector with a single purpose.

The four options in the form control what goes inside each url entry. The Modified date option adds a lastmod line with a date you choose or today's date from your computer. The Change frequency option adds a changefreq line with a value like weekly or monthly, lowercased. The Default priority option adds a priority line with a value from 0.0 to 1.0 in steps of 0.1. The page limit dropdown controls how many pages the crawler will fetch before it stops, though the actual ceiling is 50 fetched pages no matter what the dropdown says.

The strict failure rule determines whether the tool reports a pass or a fail. If any fetched page comes back empty, whether from a blocked request, a bot challenge, a timeout, a DNS failure, or a response that is not HTML, the server answers with a down signal. Your browser then replaces the entire XML box with a single message that reads "Either input site is not valid or offline!" and hides the save button. Every entry gathered so far is discarded. One unreachable page wipes the whole result.

That failure rule is not a theoretical edge case. The live test run for this rewrite hit it twice. A crawl of www.iana.org collected 19 links from the home page and 24 from the about page, and then the third fetch came back empty because iana.org intermittently rejects requests without a user agent. The entire result became the offline message. A Cloudflare-fronted WordPress site failed at the first step with the same message. This tool works only on sites that answer plain, user-agent-less requests reliably.

How to Use This Tool

1. Open the tool page. Find the input box above this article and the form that surrounds it.

2. Enter a domain name. Type the site you want to crawl into the text box, with or without the http:// or https:// prefix, since the tool strips any scheme you type and adds http:// when none is present.

3. Choose your date options. Leave Modified date at "Do not include" for a bare sitemap, or pick "Todays date" or "Custom date" and type a date in dd/mm/yyyy format if you choose the custom option.

4. Set change frequency and priority. Pick a value from the Change frequency dropdown and the Default priority dropdown, or leave both at "None" for the simplest possible output.

5. Select a page limit and generate. Choose how many pages you want crawled from the dropdown, then click the "Generate sitemap" button and watch the status line as each page is fetched.

6. Save or retry. When the crawl finishes, click "Save As XML File" to download the text as sitemap.xml, or click "Try New URL" to clear the result and start over with a different domain.

The form includes browser-side checks that run before any request is made. An empty domain triggers a popup that says "Enter your domain name". Choosing Custom date with an empty date box triggers a popup that says "Custom date field cannot be empty". The custom date itself is not validated beyond being non-empty. The tool simply rearranges whatever you typed from dd/mm/yyyy to yyyy-mm-dd and places it in every lastmod line.

What the Crawl Actually Collects

The crawl begins with the address you entered. This site's server fetches that one page and examines its HTML for anchor tags. It collects every href that points to the same host, with or without the www prefix, and every root-relative or plain relative path. Relative links are resolved against http://host, which means a relative link on an https site still gets an http:// prefix. Links that point to other hosts are ignored entirely. The start page itself is never added to the sitemap unless another page on the site links to it.

The server skips links that begin with #, mailto:, tel:, or javascript:. It drops duplicates and also drops a duplicate that differs only by a trailing slash, so https://example.com/page and https://example.com/page/ count as the same address once both have been seen. Every other link is kept, including links to PDF files, images, and other non-HTML resources on the same host, as long as some page links to them.

The order of the crawl is breadth-first. The server returns the links on a page in the order they appear in the HTML, your browser adds them to a queue, and the next request asks for the first address in that queue. Pages discovered on the second level are not fetched until every first-level page has been fetched. This matters for sites with many pages, because the 50 page ceiling can be consumed entirely by the first few levels of a site's structure.

Each new address is written into the XML text box as a url block as soon as it is discovered. The block contains a loc line with the full address, and it optionally contains priority, changefreq, and lastmod lines depending on the options you chose. The changefreq value is lowercased. The lastmod value is either today's date from your computer in yyyy-mm-dd format or the custom date you typed, rearranged into the same format. Every entry in the file shares the same date. There is no per-page lastmod detection.

The counter that reports progress closes the file one entry early. If you choose 50 pages, the crawl stops after at most 49 url entries have been written, and the status line reports "Sitemap generated for 50 links!" even though the file contains 49. The same pattern holds for every other choice in the dropdown. A site whose home page links to exactly one internal page produces a one-entry sitemap with a report of "Sitemap generated for 1 links!", as happened in the live test with info.cern.ch.

The live test with example.com produced a different result. The example.com home page links only to an external site, so the crawler found zero internal links and reported "Sitemap generated for 0 links!". The XML box contained the declaration and the urlset wrapper with no url entries inside. This is a valid outcome of the tool. Some sites simply have nothing for it to collect.

The Four Options and What They Do

The form offers four controls that shape the output. The first three control optional lines inside each url entry. The fourth controls how long the crawl runs.

The Modified date select has three choices. "Do not include", the default, omits the lastmod line entirely. "Todays date" inserts the current date from your computer's clock into every entry. "Custom date" inserts whatever date you type into the adjacent text box, after rearranging it from dd/mm/yyyy to yyyy-mm-dd. The tool does not check whether the date you typed is real. An impossible date such as a thirteenth month or a day above thirty-one would be accepted and written into the file unchanged.

The Change frequency select offers the standard sitemaps.org values. The default is "None", which omits the changefreq line. The other choices are Always, Hourly, Daily, Weekly, Monthly, and Yearly. The value is written in lowercase, so choosing Weekly produces weekly in the XML. Google has stated since 2015 that it ignores this field, and its documentation from the current decade repeats that position, so the field exists for other consumers of sitemaps.

The Default priority select offers "None" plus values from 0.0 to 1.0 in steps of 0.1. The chosen value is written into every entry as the priority line. Google also ignores this field. The sitemaps.org protocol defines it as a hint about the relative importance of pages, but the search engines that created the protocol have both said they do not use it for ranking decisions.

The page limit dropdown offers 50, 100, 200, 250, 500, 750, 1000, 2500, 3000, 4500, and 5000. The default is 50. This dropdown is misleading in an important way, because the code that runs the crawl stops after 50 fetched pages no matter which value you select. Choosing 5000 does not allow 5000 fetches. It only matters for sites where a single page contains more than 50 links, because the crawl can gather entries from those links without fetching each one.

The practical effect of these options is cosmetic. They change the text inside the XML file, but they do not change which pages are found or how the crawl behaves. The crawl mechanics are identical regardless of your choices. The options only control decoration of the entries.

Correcting the Old Description of This Tool

The previous version of this page made several claims about the tool that the live code does not support. This section names those claims directly so you can rely on what the tool actually does.

The old copy said the tool could "crawl up to 5000 URL" as a real capacity. The code stops after 50 fetched pages, period. The 5000 option in the dropdown does not permit 5000 fetches. It only affects the progress counter and the moment the crawl stops for link-rich pages. Choosing 5000 on a site whose pages each contain dozens of internal links will still end after 50 page fetches, and the resulting file will contain only as many entries as those 50 pages linked to.

The old copy described crawl-depth settings, path exclusion rules, and scope controls. None of those exist in the code. There is no way to tell the tool to crawl only certain directories, to avoid certain paths, to go deeper than the breadth-first queue allows, or to limit the crawl to pages matching a pattern. The only control over crawl extent is the page limit dropdown, and that is capped at 50 actual fetches.

The old copy claimed the tool respects robots.txt and skips pages marked noindex. It does neither. The server fetch ignores robots.txt entirely. A page that blocks crawlers via robots.txt will still be fetched and included if it is linked and reachable. A page with a noindex meta tag will be included without any check. The tool does not read meta tags, canonical tags, or any other HTML metadata beyond anchor hrefs.

The old copy said the tool produces a sitemap index and supports image and video sitemaps. It does not. The output is a single urlset document with plain url entries. There is no <sitemapindex> wrapper, no <image:image> block, and no <video:video> block. The sitemaps.org protocol allows image and video extensions, but this tool has no code that writes them.

The old copy described the tool as following internal links "like a search engine bot". Search engine bots tolerate individual failures. Googlebot fetches a page, notes an error, and moves on to the next URL in its queue. This tool does the opposite. One failed page ends the entire run and erases every entry collected so far. The behaviour is closer to an all-or-nothing transaction than to a resilient crawler.

The old copy implied the tool uploads or hosts the generated file. It does not. The "Save As XML File" button creates a data: link inside your browser and downloads the text from the box as sitemap.xml. The file never touches this site's server. There is no hosting, no public URL for your sitemap, and no storage of any kind.

The Strict Failure Rule

The tool's default settings can be changed without affecting its core function. If any page in the crawl comes back empty, the entire result is destroyed. The XML box is replaced with the text "Either input site is not valid or offline!", and the save button disappears. All the entries that were gathered before the failure are gone.

An empty response means different things on different sites. A server that blocks requests without a user agent returns an error page or nothing. A site behind Cloudflare often presents a bot challenge that the simple fetch cannot solve. A DNS failure means the host cannot be resolved at all. A timeout means the server took longer than one minute to answer. A response that is not HTML, such as a binary file, also counts as a failure. Any of these conditions at any point in the crawl wipes the result.

The live test run for this rewrite demonstrated the rule twice. The www.iana.org crawl succeeded for the home page and the about page, collecting 43 entries in the process, and then failed on the third fetch when the domains page came back empty. The result became the offline message. A Cloudflare-fronted WordPress site at theyumyumclub.com failed at the very first step with the same message. This site's own address also fails, because the server's fetch of its own pages is refused with a 403 response.

The consequence is that this tool suits small, stable, plain-HTML sites. A site that answers every request promptly and without bot detection will produce a usable sitemap. A site with any page that blocks or times out will produce nothing but an error message. You cannot salvage partial results, because the failure rule discards everything.

Limits of the Crawl

The crawl has a hard ceiling of 50 fetched pages. This is not a configurable limit. It is written into the code, and it applies regardless of the dropdown selection. The status line reports "Crawler Limit Reached!" when the crawl stops at this ceiling. A site with more than 50 pages will yield a sitemap that covers at most the first 50 pages the crawler reached, and the breadth-first order means those 50 pages are the ones closest to your starting address.

The one-request-per-page design means a full run takes as long as the target site is slow. Each page fetch waits for the server to respond, and the server waits up to one minute before timing out. A slow site can make a 50 page crawl take many minutes. A site that times out on one page ends the run with the offline message, so slow sites are doubly risky.

There is no support for exclusion patterns. You cannot tell the tool to skip pages whose addresses contain a certain string, to avoid a directory, or to stay within a path prefix. Every internal link the crawler finds is added to the queue and fetched, subject only to the page ceiling. A site with a large administrative section or a search results page will have those pages included if they are linked.

There is no depth control. The crawl is breadth-first, and it stops when the queue is exhausted or the ceiling is reached. You cannot tell it to crawl only the home page and its immediate children. The structure of the site determines how deep the crawl goes within the 50 page budget.

Query strings and fragments are not stripped. A link to page#top and a link to page are treated as two separate entries. A link to page?utm_source=twitter and a link to page?utm_source=facebook are also separate entries. This can inflate the entry count with duplicates that differ only in tracking parameters or anchor fragments.

Relative links receive an http:// prefix even when the site is served over https. The server resolves relative paths against http://host, so a site that uses relative links throughout will produce a sitemap full of http:// addresses even if the site actually runs on https. The same applies to links without a scheme that the server resolves. This produces mixed schemes and addresses that may not match the site's real URLs.

PDFs and other non-HTML files are included when linked. The tool does not check whether a link points to a web page, a document, an image, or any other resource. If a page on the same host links to a PDF, that PDF address becomes a url entry. The tool does not verify that the linked resource is HTML.

What the Generated File Contains

The output is a text document that follows the sitemaps.org protocol. The protocol was published in 2006 by Google, Yahoo, and Microsoft, and it defines the XML format that search engines accept for URL submission. The tool writes the XML declaration, the urlset wrapper with the standard namespace, and one url block per discovered address.

A minimal entry contains only the loc line with the full address. Depending on your options, the entry may also contain priority, changefreq, and lastmod lines. The order of these optional lines follows the order in the code, with loc first, then priority, then changefreq, then lastmod. The live test with info.cern.ch produced an entry with all three optional lines present, showing priority 0.8, changefreq weekly, and lastmod 2026-09-04.

The protocol allows up to 50,000 URLs or 50 MB uncompressed per sitemap file, with a sitemap index file for sites that exceed those limits. This tool's output will never approach either limit, because the 50 page ceiling keeps the entry count low. A page with thousands of links could theoretically produce thousands of entries without fetching thousands of pages, but the practical output for most sites is a few dozen entries.

The saved file is exactly the text shown in the box. When a URL contains an ampersand, the box writes it as & because the box is HTML. The saved file therefore contains the escaped form, which is correct for XML. The XML declaration and namespace are written correctly, and the file validates against the sitemaps.org schema as long as the source pages returned valid addresses.

The file is a snapshot of the links the crawler found at the moment of the crawl. It has no memory of previous runs. Each generation starts fresh, fetches pages anew, and writes a new file. The crawl does not cache results, and the file does not update itself.

Search Engines and This Sitemap

The sitemaps.org protocol exists so that site owners can tell search engines which URLs exist on a site. The protocol was created in 2006 by Google, Yahoo, and Microsoft, and it has remained broadly stable since. A sitemap does not guarantee that every listed URL gets indexed. It is a suggestion, a list of candidate pages, and search engines decide what to do with it.

Google accepts sitemaps through Google Search Console. Bing accepts them through Bing Webmaster Tools. Both services also accept a reference to a sitemap in a site's robots.txt file, using the Sitemap: directive. WordPress has shipped a native sitemap at /wp-sitemap.xml since version 5.5, which was released in 2020, and plugins like Yoast and Rank Math generate their own sitemaps. A file produced by this tool would be submitted through one of those channels if you chose to use it.

Google's treatment of the optional fields is worth knowing. Google has stated since 2015 that it ignores priority and changefreq, and its documentation from the current decade repeats that position. Google uses lastmod only when the dates are consistently accurate, meaning that a sitemap with wrong or stale dates can cause Google to distrust the field entirely. The tool's single shared date for all entries, whether today's date or a custom date, is exactly the kind of lastmod value that Google warns about.

The practical value of this tool's output for Google is therefore limited to the loc lines. The list of URLs is the useful part. The optional fields add protocol-valid decoration that Google mostly ignores, and the lastmod field may actively reduce trust if the dates are inaccurate. For search engines other than Google, the fields may carry more weight, but Google's dominance means most site owners care primarily about its behaviour.

The tool does not submit anything anywhere. It produces a file. Submission happens through Google Search Console, Bing Webmaster Tools, or a robots.txt directive, and those steps are entirely yours. The tool's job ends when the file is saved to your computer.

Rate Limits and Requests

This tool has no CAPTCHA and no tool-specific request cap. Each crawl step is one request to this site's server, and the crawl is sequential, so it makes one request, waits for the response, then makes the next request. The pace is set by the target site's response time, which keeps the request rate low.

A site-wide throttle applies to every page of this site. The throttle allows roughly fifteen requests within a single second from one visitor address. Exceeding that rate blocks the address for the rest of the day with a 503 response. A crawl of this tool waits for each fetch to complete before sending the next request, so a crawl stays well under the throttle. You would need to run many crawls in parallel from the same address to trigger it.

The requests that matter for the crawl go from this site's server to the target site. Those requests come from a server in Helsinki, Finland, and they carry no user agent header. Many sites treat user-agent-less requests with suspicion. Cloudflare-fronted sites often present a challenge. Some government sites and large organisations block such requests outright. Wikipedia is known to reject them. The failure rule means any of these rejections ends the crawl with the offline message.

For purely client-side operations, the tool makes no request to this site at all. The browser-side checks for an empty domain and an empty custom date field run entirely in your browser. The XML text is assembled in your browser. The save button creates a data: link in your browser. The only requests to this site are the crawl steps themselves, one per page fetched.

When This Tool Works Well

The tool performs best on small, static, plain-HTML sites that answer every request quickly and without bot detection. A personal site with a dozen pages, a documentation site built as static HTML, or a small business site with no dynamic features will likely produce a clean sitemap in a few seconds. The live test with info.cern.ch, the original home of the World Wide Web, produced a one-entry sitemap because that site's home page links to a single internal page.

Sites that use relative links throughout will produce a sitemap, but the addresses will carry http:// prefixes even if the site runs on https. The tool resolves relative paths against http://host, so the output may not match the site's real scheme. You can compensate by checking the output and editing the file before submission, but the tool will not do this correction for you.

Sites with many links on each page can produce more entries than the page ceiling might suggest. The crawl fetches at most 50 pages, but each fetched page can contribute many links to the queue. A page with 200 internal links adds 200 addresses to the queue in one step, and the crawl writes all of them into the XML as it discovers them, even if it never fetches most of those pages. The 5000 dropdown option exists for this scenario, though the 50 page fetch ceiling still applies.

The tool can be useful as a quick inventory of a small site's internal link structure. Even when the resulting sitemap is not what you submit to Google, the list of discovered URLs shows you what a simple crawler sees when it visits your site. You might spot orphan pages that no one links to, or internal links that point to http:// URLs on an https site, or duplicate entries caused by query strings. These are real findings about your site's link hygiene.

When This Tool Fails

The tool fails on any site that blocks user-agent-less requests. This includes many WordPress sites behind Cloudflare, Wikipedia, some government sites, and any site with aggressive bot detection. The failure is total. One blocked page produces the offline message and destroys the entire result. You cannot get a partial sitemap from a site that blocks even a single page.

The tool fails on JavaScript-heavy sites. A site that renders its navigation through JavaScript will appear to have no internal links, because the server fetch does not execute JavaScript. The tool will report zero links or only the links present in the raw HTML. Single-page applications, sites with client-side routing, and sites that load content dynamically will produce incomplete or empty results.

The tool fails on sites with mixed content schemes. A site that runs on https but uses relative links will produce a sitemap full of http:// addresses. A site that uses protocol-relative links will get them resolved to http://. The resulting file lists URLs that may redirect to https versions or may not work at all. Google treats http:// and https:// versions of a URL as separate, so this output can create duplicate and redirect issues.

The tool fails on sites with more than 50 pages that you actually need listed. The 50 page ceiling is absolute. The dropdown's higher values do not raise it. If your site has 500 pages, this tool will list at most the 50 it fetches, and the breadth-first order means you get the pages closest to your starting point. The rest of your site is absent from the file.

The tool fails when a site has any unreachable page among the ones it tries to fetch. A single 404 does not cause this, because a 404 page usually still returns HTML content, and only an empty body triggers the failure rule. The failure comes from empty responses: blocked requests, timeouts, DNS failures, and non-HTML responses. A site with one slow endpoint, one bot-protected directory, or one broken internal link that points to a dead host will end the entire crawl with the offline message.

Related Tools

When you need to control which pages search engines may crawl, use the Robots.txt Generator to create the companion file that sits beside your sitemap.

When you want to see how many links a page has before you decide whether a sitemap crawl is worthwhile, run the Links Counter on your home page first.

When your sitemap crawl fails with the offline message and you suspect a dead page is the cause, check your site with the Broken Links Checker to find the unreachable URLs that would wipe a sitemap run.

Practical Workflow for a Usable Sitemap

A realistic workflow starts before you open this tool. Check whether your site answers plain HTTP requests without a user agent. You can test this with a command line tool like curl from your own machine, though your machine's requests carry your network's characteristics rather than this server's. The live tests show that sites behind Cloudflare and sites that reject user-agent-less requests will fail immediately, so a quick check saves you from a wasted run.

Run the Links Counter on your home page to see how many internal links it contains. If the count is high, the crawl will spend its 50 page budget on the first level of your site. If the count is low, the crawl will move deeper. This knowledge helps you choose a realistic expectation for the output.

Enter your domain without a scheme, or with one, since the tool strips it either way. Choose your date options with care. The single shared lastmod date is a known weakness, so consider leaving Modified date at "Do not include" unless you have a reason to add dates. Google's documented distrust of inaccurate lastmod values argues for omitting the field entirely.

Choose a page limit that matches your site's size, but remember that 50 is the real ceiling. The dropdown values above 50 only matter for link-rich pages where a single fetch discovers many addresses. A site with 200 pages and 10 links per page will produce a file covering only the first 50 pages, no matter which dropdown value you select.

Click Generate and watch the status line. Each line shows the address being crawled and the running link count. A crawl that proceeds steadily through many pages is a good sign. A crawl that stops early with the offline message tells you that some page failed. You will not know which page failed, because the status line shows only the last attempted address.

When the crawl finishes with a positive link count, read the XML box before saving. Check the schemes of the listed URLs. Check for duplicate entries caused by query strings or fragments. Check that the lastmod dates are what you intended. The file is yours to edit, and a quick review catches the tool's known quirks before you submit the file anywhere.

Save the file with the "Save As XML File" button. The download is a data: link created in your browser, so the file appears in your downloads folder with the name sitemap.xml. The file is not hosted anywhere. To use it, you must upload it to your own web server and submit its URL through Google Search Console, Bing Webmaster Tools, or a robots.txt directive.

Frequently Asked Questions

Why did my crawl end with "Either input site is not valid or offline!"?

One of the pages the crawler tried to fetch came back empty. The cause could be a blocked request, a bot challenge, a timeout, a DNS failure, or a non-HTML response. The tool discards every entry it gathered and shows that message when any single page fails.

Does the 5000 option really crawl 5000 pages?

No. The crawl stops after 50 fetched pages no matter which dropdown value you choose. The higher values only affect the progress counter and the point where the crawl stops for sites whose pages each contain many links.

Will the tool respect my robots.txt file?

No. Pages that block crawlers via robots.txt are still fetched and included if they are linked and reachable. The tool also does not check for noindex meta tags or canonical tags.

Why does my sitemap contain http:// addresses for an https site?

The server resolves relative links against http://host, so any relative path on your site gets an http:// prefix even when your site runs on https. You will need to edit those addresses in the file before submission.

Does Google use the priority and changefreq fields?

Google has stated since the year of the Paris climate agreement that it ignores both fields, and its current documentation repeats that position. Google uses lastmod only when the dates are consistently accurate. The tool writes the same date for every entry, which may not meet that standard.

Where is my sitemap file stored?

Nowhere on this site. The "Save As XML File" button creates a download link inside your browser, and the file is saved to your computer. The text in the XML box is never sent back to this site's server.