An XML sitemap built from a URL list is a sitemap.xml file where each absolute page address you supply becomes a single entry, validated and serialized under sitemaps.org protocol rules rather than discovered by a crawler. The list-to-XML workflow treats each pasted URL as a deliberate editorial decision: a page you have already reviewed and decided should appear in search-engine discovery. Because the URLs are entered by hand, the resulting file reflects your judgment about which paths exist, which are indexable, and which are worth surfacing, instead of relying on automated link discovery that can sweep up redirects, thin pages, or blocked resources.
This approach fits teams that maintain a CMS export, a spreadsheet of canonical page paths, or a hand-curated inventory of marketing landing pages. The conversion step is straightforward in principle — wrap each line in tags inside a root — but sitemaps.org protocol rules and XML escaping make a hand-typed draft slow and error-prone. A purpose-built tool that runs in the browser can handle URL serialization, deduplication, entity escaping, and UTF-8 byte measurement in one pass, which keeps the editorial list at the center of the workflow instead of buried under escaping mistakes.
What "URL List to XML Sitemap" Actually Means
The phrase describes a deterministic conversion: every line you supply becomes exactly one entry in the output file, after validation, normalization, and deduplication. Nothing is fetched, no links are followed, and no canonical tags are inspected. The tool is a list-to-XML utility, not a crawler, and the produced file is only as accurate as the URLs and any optional metadata you provide.
The workflow is well suited to three recurring situations:
- You already have an inventory exported from analytics, a CMS, or a hand-maintained spreadsheet.
- You want strict control over which paths appear, excluding tag pages, internal search results, or staging URLs.
- You need a sitemap for a site a crawler cannot reach, such as a static export, a single-page application with restricted routes, or a documentation site behind authentication.
List-Based Generator vs a Crawler
Crawler-based sitemaps reflect whatever a bot can discover, including redirects, paginated archives, blocked resources, and parameter variants. A list-based generator reflects only what you paste. For sites with editorial gates, faceted navigation, or large amounts of low-value URL patterns, that editorial control is usually more valuable than automated discovery.
| Aspect | List-to-XML generator | Server-side crawler |
|---|---|---|
| Source of URLs | Pasted lines, hand-curated | Links found while fetching pages |
| HTTP requests made | None | One or more per page |
| Includes redirects | Only if you list them | Possibly, depending on redirect handling |
| Reads canonical tags | No | Often |
| Detects status codes | No | Yes |
| Privacy of the URL list | Stays in the browser tab | Submitted to the crawler service |
| Best for | Reviewed inventories, restricted sites, static exports | Broad discovery on crawlable sites |
Because the list and the generated XML stay in the same browser tab, the URL inventory does not leave your device during conversion. For teams handling confidential launch pages or compliance-restricted sections, this is a meaningful difference.
Preparing Your URL List Before Generation
Three preparation rules keep generation smooth and the output protocol-compliant. Skipping them is the most common reason an otherwise valid list fails the validator.
One host per file
The sitemaps.org protocol requires a single host per file, including any non-default port. The generator enforces this: mixing example.com and example.com:8443 fails because the port is part of the serialized host. HTTP and HTTPS URLs for the same host are accepted in one file because the protocol rule is one host, not one origin.
Absolute URLs only, one per line
Each non-blank line must be an absolute URL beginning with http:// or https://. Bare domains, relative paths, FTP URLs, and fragments cause rejection rather than silent fixing. Leading or trailing whitespace on a non-blank line is treated as an error instead of being quietly trimmed, so a stray space from a copy-paste surfaces immediately instead of being hidden.
Decide whether optional metadata applies
lastmod, changefreq, and priority are optional protocol hints, not crawl commands. The generator only includes them if you supply a value that applies truthfully to every URL in the batch. If half your pages were updated yesterday and the rest last month, do not invent a shared lastmod; leave the field blank and let the protocol default apply.
For a walkthrough of preparing a clean URL inventory from a CMS or spreadsheet, see the manual URL-list to sitemap workflow.
Generating the Sitemap File
The generation flow converts your list into a single sitemap.xml file, ready to upload to the represented site's root or to submit through Search Console.
- Paste one absolute HTTP or HTTPS URL per line, using one host (including any non-default port) per file. Blank lines and whitespace-only lines are ignored.
- Leave the optional fields blank for a -only XML, or supply a shared lastmod, changefreq, or priority that applies truthfully to every entry.
- Generate the file and review the rendered XML, the count of unique URLs, the duplicate count, and any per-line errors before downloading.
- Download sitemap.xml, publish it on the site it represents (commonly at the document root), and reference it from robots.txt or submit it via Search Console.
Editing any input revokes the previous download and clears the preview, so the file you keep is always consistent with the lines and options currently on screen. The XML Sitemap Generator runs every step — line splitting, URL serialization, deduplication, escaping, byte measurement — in the current tab without uploading the list anywhere.
Optional Metadata: lastmod, changefreq, and priority
The three optional fields are protocol hints only. Search engines may use lastmod as a recency signal and treat changefreq and priority as soft suggestions. None of them guarantee crawling, indexing, or ranking.
| Field | Allowed values | Validation rule | What it is not |
|---|---|---|---|
| lastmod | YYYY-MM-DD or full date-time with seconds and Z or UTC offset | Real Gregorian date with leap-year and timezone checks | A command to recrawl |
| changefreq | always, hourly, daily, weekly, monthly, yearly, never | Exactly one of seven values | A ranking signal |
| priority | 0.0 through 1.0 | Decimal within range | A way to force a page to rank higher |
If any optional value fails validation, generation fails as a whole rather than silently dropping the bad field. That all-or-nothing behavior protects the file from accidentally mixing entries with and without metadata, and it surfaces the mistake before you publish.
Protocol Limits and Tool Budgets
The sitemaps.org protocol permits up to 50,000 URLs and 52,428,800 uncompressed bytes per file, with each loc shorter than 2,048 characters. A browser-side generator uses lower budgets to bound preview memory, Blob allocation, and parser pressure without pretending to be the protocol itself.
| Constraint | Protocol maximum | This tool's budget |
|---|---|---|
| Unique URLs per file | 50,000 | 10,000 |
| File size (uncompressed) | 52,428,800 bytes | 10,485,760 bytes (10 MiB) |
| Characters per loc | fewer than 2,048 | 2,047 maximum |
| Input size | Not specified | 5,000,000 UTF-16 code units |
To translate the byte budget into a per-URL allowance, divide the cap by the URL cap: 10,485,760 bytes ÷ 10,000 unique URLs = 1,048.576 bytes per URL on average. Real entries vary; short homepages use far less than that allowance, while deep paths with many query parameters cluster closer to the limit. The calculation is a rough average; the exact figures for your file come from the generator's preview.
Every limit is enforced as all-or-nothing. The 10,000th unique URL is accepted and the next unique URL fails. The exact 10,485,760-byte boundary is accepted; one additional byte causes the whole generation to fail. No shortened XML, ellipsis, or partial download is returned. Duplicate lines do not consume output slots, so copy-paste noise from your source list is counted but never expands the published file.
What to Review Before Publishing the File
The generator does not verify where the sitemap will be hosted or whether cross-site submission permissions exist. A short pre-publication checklist keeps the file aligned with the live site:
- Reconcile the URL list against the live site, removing any redirects, blocked pages, private pages, or 404s the inventory still contains.
- Confirm one host per file. If marketing pages live on a separate domain or port, generate one file per host.
- Verify the file size and URL count fit both protocol maxima and the tool's browser budget if you are iterating in the same tab.
- Reference the file from robots.txt with a Sitemap: line, or submit it through the search engine's preferred route.
For the search-engine side of the submission process, the Google Search Central guide on building and submitting a sitemap covers host rules, sitemaps indexes, and resubmission timing. The WHATWG URL Standard is the reference for the browser-style normalization the generator applies — lowercase hosts, default-port removal, root-slash insertion, and percent-encoding of non-ASCII characters.
Treat the generated file as a starting point, not a final artifact. A sitemap reflects editorial intent, and editorial intent drifts. Revisit the URL list whenever the information architecture, the redirect map, or the indexable sections of the site change.