XML sitemap generator

What this XML sitemap generator takes as evidence

A sitemap is an inventory, so the quality of the result starts with the source of that inventory. This tool accepts three local sources: one absolute URL per line, a CSV export with a named URL column, or a CreatorValet current-page link manifest. Each source means something different. A hand-curated list can represent the pages you deliberately chose. A crawl export can represent what that particular crawl found. A current-page manifest represents one page that was already open in your browser and its visible HTTP or HTTPS link targets. None of them silently becomes proof that every page on a site was discovered.

There is no website-URL box that starts a hidden crawl. The browser does not request any listed page, follow a redirect, inspect a canonical tag, or look for a response status. That boundary is visible in the receipt. If your source came from a crawler, export the chosen URL and modification-date columns, review them, and load the file here. If you are building a smaller hand-maintained site, a plain text list is usually the clearest source.

Why the target origin is explicit

The Sitemap protocol expects locations in one sitemap to belong to one host. The form asks for that origin before it accepts rows, rather than guessing from whichever address happens to appear first. A mixed-host row, URL containing credentials, non-web protocol, or fragment is called out with its source row and omitted from the model. Duplicate URLs are normalized and counted separately. The receipt therefore distinguishes rejected input from harmless repetition instead of returning a smaller file with no explanation.

Fragments are excluded because https://example.com/guide#install and https://example.com/guide#usage identify places inside the same document. A sitemap location describes the document. Query strings remain when they are genuinely part of the canonical page URL, and characters such as ampersands are escaped in XML without changing the decoded address.

lastmod is source data, not the time you clicked Generate

A CSV can supply a lastmod column. The generator accepts a real calendar date such as 2026-08-12 or a timezone-qualified timestamp. Impossible dates stop the package instead of rolling into another month. A blank value stays absent. The tool never substitutes the file modification time, crawl time, manifest export time, or current date, because those values describe collection rather than the page’s last significant change.

The form deliberately omits priority and changefreq. Google’s current sitemap documentation says it ignores both. Adding a high priority to every row would make the XML longer without creating a ranking instruction. A concise location list with trustworthy modification dates is easier to review and maintain than a larger file filled with invented crawl hints.

Escaping is checked by reading the XML back

The serializer writes deterministic UTF-8 XML with LF line endings and one final newline. It escapes location text before placing it inside <loc>. A second, purpose-built XML reader then starts from the serialized text, checks the exact Sitemap 0.9 namespace and allowed element order, decodes entities, and compares every recovered location and date with the typed source model. The byte count in the receipt is calculated from the same text offered for copy and download.

That is a local format check, not a search-engine certificate. It proves that the generated bytes can be read back under this finite protocol profile. It cannot prove that a URL returns a successful response, is canonical, permits crawling, contains useful content, or will be indexed. After publishing, use your hosting environment and search-engine tools to inspect the real file and its submitted location.

When one file has to become a package

The protocol limits one uncompressed sitemap to 50,000 locations or 52,428,800 bytes. The generator measures both. When either boundary would be crossed, it splits only between complete URL entries. It does not estimate bytes from JavaScript character counts, which would be wrong for Unicode. Each part is independently reparsed and remeasured.

A sitemap index must contain the absolute published addresses of its part files. Those addresses cannot be derived from a local download name. Multi-file output therefore requires the publication directory you actually intend to use, such as https://example.com/sitemaps/. The tool creates an index only from that explicit value and keeps it on the target origin. It does not upload the ZIP, create directories, or verify that the future addresses are live.

How this route differs from the nearby tools

The URL extractor inventories addresses in pasted material or one already loaded page; it does not produce Sitemap XML. That current-page manifest can be handed to this generator with its one-page limitation intact. The JSON formatter and HTML formatter work on different syntaxes and do not apply Sitemap namespace or host rules. The Google ranking diagnostic explains ranking evidence, but a clean sitemap alone is neither a score nor a ranking signal.

Checking an existing sitemap is also a different direction. A checker must accept arbitrary pasted XML, sitemap indexes and local files, then separate namespace and limit errors from questions that require visiting live URLs. This generator validates only the files it creates from the visible source model. Keeping those jobs separate prevents a green generation receipt from being mistaken for a remote crawl, a submission, or a promise that every important page has been found.

Use the sitemap validator when you already have XML or an XML.GZ file and want namespace, entry, size, date and declared publication-scope checks without fetching the published URL or any listed page.