A sitemap generator example is a side-by-side view of a reviewed URL list and the standards-based XML file the tool returns from that list. Most readers who search for an example already know they want a sitemap and have already curated the URLs they care about — what they need is to see exactly what the input should look like, what the output will be, and which validation rules apply between those two ends.
The XML Sitemap Generator is a list-to-XML utility purpose-built for that task. It accepts one absolute HTTP or HTTPS URL per line, optionally a shared lastmod, changefreq, or priority, and produces one sitemap.xml file in your browser. It validates every line, normalises URLs with the WHATWG browser URL parser, deduplicates in first-seen order, escapes the five XML entities, and emits a UTF-8 document using the official http://www.sitemaps.org/schemas/sitemap/0.9 namespace. No URL is uploaded, no page is fetched, and nothing is submitted to a search engine — the generator only packages the list you give it into a standards-shaped file.
This article walks through the format with a realistic sample. You will see the input list, the validation rules applied to it, the structure of the rendered XML, the optional metadata fields, and the limits that govern what fits in a single file.
What a Sitemap Generator Example Looks Like in Practice
An example is only useful if it shows both halves of the transformation: the human-readable list you paste and the machine-readable file the search engine consumes. The left side is plain text — one absolute page URL per line. The right side is a UTF-8 XML document that starts with a declaration, declares the sitemaps.org namespace, and then wraps each URL in a url element with a loc child.
The example below uses a five-URL list for a small marketing site. Every URL points at the same host (example.com), all use HTTPS, none carry credentials or fragments, and none have leading or trailing whitespace. That is the cleanest possible input, and the resulting sitemap.xml is correspondingly clean.
The rest of this article expands each row of that transformation: what the validator accepts and rejects, how to run the generation, how the output is structured, how the optional fields appear when you do use them, and which limits apply to the file as a whole.
Sample Input: A URL List You Can Paste
The generator accepts one absolute page URL per line. The five lines below form a minimum working example for the host example.com:
- https://example.com/
- https://example.com/about/
- https://example.com/blog/xml-sitemap-best-practices/
- https://example.com/blog/sitemap-protocol-limits/
- https://example.com/contact/
Each nonblank line must be an absolute HTTP or HTTPS URL pointing at one host including any non-default port. Whitespace-only lines are ignored, but leading or trailing whitespace on a real URL is treated as malformed and rejected. The table below summarises which inputs the validator accepts and which it rejects so the example you paste does not surprise you.
| Input on a single line | Accepted? | Reason |
|---|---|---|
| https://example.com/blog/post/ | Yes | Absolute HTTPS URL with path |
| http://example.com/about/ | Yes | Same host, HTTP scheme |
| https://EXAMPLE.com/about/ | Yes | Uppercase host normalises to lowercase |
| https://example.com:443/about/ | Yes | Explicit default port is normalised away |
| example.com/about/ | No | Bare domain — scheme required |
| /about/ | No | Relative path — host required |
| https://example.com/about/ | No | Leading whitespace is malformed |
| https://user:[email protected]/ | No | Embedded credentials rejected |
| https://example.com/about/#section | No | Fragment rejected |
| ftp://example.com/file | No | Non-HTTP scheme rejected |
| https://example.com:8443/admin | Yes | Non-default port is part of the host |
| https://example.com:8443/ and https://example.com/ | No | Two different serialized hosts in one file |
Notice the fragment and credentials rows in particular. A fragment such as #section is rejected because fragments are not sent to the server as part of the HTTP request, so the same fetched resource should not appear twice in a sitemap. A non-default port, by contrast, identifies a different host under the Sitemap protocol, so https://example.com/ and https://example.com:8443/ cannot share a file even though they belong to the same operator.
How to Build a Sitemap Generator Example Step by Step
The following steps reproduce the end-to-end example the tool is built to produce. Paste, validate, generate, review, and download — every action happens in the browser tab.
- Open the XML Sitemap Generator. Load the tool in your browser. The editor, the optional-fields panel, and the download area all render in one tab.
- Paste one absolute page URL per line. Use HTTP or HTTPS only. Keep every URL on a single host including any non-default port you intend to publish on. The five-line list above is a good starting point.
- Decide whether to fill optional fields. Leave lastmod, changefreq, and priority blank for a loc-only sitemap. If you fill them, the same value is applied to every entry — there is no per-URL field in this list-to-XML utility.
- Click Generate. The validator runs over every line. Invalid lines are not skipped silently; the whole generation fails until you fix them. Valid URLs are serialised, deduplicated in first-seen order, and escaped.
- Review the rendered XML and the counts. Read the preview. Confirm the order of your URLs, the chosen lastmod, changefreq, and priority, and the number of unique entries before you download.
- Download sitemap.xml. The file downloads to your machine. Place it at the root of the represented host — or at any path you reference from robots.txt — and submit its location to your preferred search engines if appropriate.
If you later edit the URL list or any option, the previous download Object URL is revoked and the old XML is cleared. You cannot accidentally keep a stale file from a previous run.
Reading the Generated XML File
The downloaded file is a UTF-8 XML document. For the five-line example above with no optional fields, the result is a declaration line followed by a urlset root, then five url elements each containing exactly one loc child whose text is the serialised URL.
Three structural points are worth observing. First, the file begins with a UTF-8 declaration and a urlset element that uses the official http://www.sitemaps.org/schemas/sitemap/0.9 namespace — Google and Bing both recognise this as a standards-shaped sitemap. Second, each entry is one url element containing exactly one loc element whose text is the serialised URL. Third, the five XML entities — ampersand, apostrophe, quotation mark, greater-than sign, and less-than sign — are escaped after URL normalisation, with ampersand replaced first so generated entities are not double-escaped.
If you supplied optional metadata, the same value appears once per entry as lastmod, changefreq, or priority inside the url tag. The generator never invents per-URL values; whatever you supply is applied uniformly across the file.
Optional Metadata: lastmod, changefreq, priority
Optional fields are powerful only when the value is truthful for every URL in the file. Misleading values waste crawler attention and can erode trust in your sitemap over time.
lastmod accepts a real Gregorian date in YYYY-MM-DD form, or a complete date-time with seconds and either a Z suffix or a valid UTC offset. Calendar correctness, clock-field ranges, and timezone limits are checked; leading or trailing whitespace is rejected rather than trimmed. Use lastmod only when one shared date is a real significant modification for every entry — for example, a site-wide migration date.
changefreq accepts exactly seven protocol values. The table lists them in the order the Sitemap protocol documents them.
| changefreq value | Protocol meaning |
|---|---|
| always | The page changes on every access |
| hourly | The page changes roughly every hour |
| daily | The page changes roughly every day |
| weekly | The page changes roughly every week |
| monthly | The page changes roughly every month |
| yearly | The page changes roughly every year |
| never | The page is archived and does not change |
priority accepts a decimal from 0.0 through 1.0. These three fields are protocol hints, not crawl commands — search engines are not obligated to honour them, and they do not act as ranking signals. Invalid optional metadata fails the whole generation, so a typo in one of these fields will block your download rather than slipping through.
Limits That Apply to the Example You Build
The Sitemap protocol allows generous maxima. This browser-based generator uses intentionally lower whole-file budgets so the preview, the Blob, and browser memory are bounded, and so any limit is enforced all-or-nothing rather than by silent truncation.
| Constraint | Sitemap protocol | XML Sitemap Generator |
|---|---|---|
| URLs per file | Up to 50,000 | Up to 10,000 unique |
| File size | Up to 52,428,800 uncompressed bytes | Up to 10,485,760 UTF-8 bytes (10 MiB) |
| Characters per loc | Fewer than 2,048 | At most 2,047 serialised characters |
| Input size | Not specified | Up to 5,000,000 UTF-16 code units |
| Behaviour at the boundary | Conformant parsers accept the exact limit | Exact limit accepted; one more byte or URL rejected |
| On exceeding the limit | Truncate | Fail — no partial XML or shortened preview |
The 10,000th unique URL is accepted and the next unique URL fails; duplicate lines do not consume output slots. XML size is measured after URL serialisation, XML escaping, optional tags, indentation, and UTF-8 encoding, so a preview that looks small can still trip the limit once it is fully escaped. The download uses a temporary Object URL owned by the current result; editing the input revokes the previous URL and clears the old XML, download, and any error state.
What This Example Does Not Cover
Be explicit about what a sitemap generator example does and does not show you. The generator does not crawl your site, follow links, inspect canonical tags, read modification dates, discover redirects, verify HTTP status, determine indexability, or submit the result to a search engine. It does not create sitemap indexes, image, video, or news extensions, hreflang markup, gzip files, robots.txt rules, or Search Console submissions. The generated file is only as accurate as the URLs and optional metadata you supply.
The same input-output design also keeps the operation local: parsing and file creation happen in the current browser tab, no URL or generated XML is uploaded, and you can audit this directly. If you want a deeper look at the privacy and safety trade-offs of running a generator in the browser rather than on a server, see Is an Online XML Sitemap Generator Safe for Your Site?.
Before you publish the file on the represented site, review redirects, duplicate content, blocked pages, private pages, and any URLs you forgot to include. A clean example is the result of a clean input list — the tool's job is to package that list faithfully into a standards-shaped XML document, not to judge which pages belong there.
Related reading: Extract URLs From a Sitemap: Command Line vs Online.