A sitemap generator for WordPress turns a curated list of page URLs into a standards-compliant sitemap.xml file you can upload to the site root, no plugin required. The output is the same XML format that Yoast SEO, Rank Math, or All in One SEO produce — a UTF-8 file with a `` root and one `…` block per entry — but every URL passes through human review before it ships. WordPress sites with custom post types, gated membership areas, redirected slugs, or pages excluded by editorial policy benefit from that workflow: the tool accepts absolute WordPress permalinks as typed, validates the serialized host, rejects URL fragments and embedded credentials, deduplicates by first occurrence, entity-escapes XML data, and emits a single downloadable sitemap.xml that you place where you choose. Parsing, normalization, and file creation happen entirely inside the current browser tab; neither the URLs nor the generated XML is uploaded to a server.
Standalone list-to-XML generators keep WordPress installs lean, avoid plugin update chains, and let editorial teams keep a tangible audit trail of which URLs they want indexed and which they deliberately left out. The role of the tool is narrow and transparent: parse the input, serialize each URL, deduplicate, entity-escape, and download. Everything outside that scope — discovering pages, checking HTTP status, validating indexability, and submitting the result to search engines — stays with the WordPress administrator who curates the URL list and publishes the resulting file.
Why WordPress Users Reach for a Standalone Sitemap Tool
The WordPress ecosystem ships with mature plugin options. Yoast SEO, Rank Math, All in One SEO, and Jetpack each include a sitemap module that crawls the WordPress database, groups URLs by post type, and emits virtual XML accessible at /sitemap.xml or /sitemap_index.xml. For most publishers that hands-off model is the right default. Several recurring situations, however, push a WordPress team toward a standalone sitemap generator workflow.
Editorial review is the most common reason. Marketing teams often want to approve exactly which pages appear in the sitemap before it ships, especially when launches, redesigns, or seasonal content coexist with evergreen archives. A reviewed URL list — typed or pasted from a spreadsheet — is auditable in a way that a plugin-generated virtual file is not. Editors can defend omissions: drafts, gated members-only pages, internal search results, thin tag archives, and legacy 404 targets can all stay out of the file rather than slipping in.
Performance and footprint come second. Each sitemap plugin adds database queries, option pages, and update hooks. Static export workflows such as Simply Static, WP2Static, or a headless decoupled frontend cannot run PHP at request time, so they need a pre-built sitemap.xml baked into the static output. A list-to-XML generator produces exactly that file, ready for download and inclusion in the static bundle.
Multisite and staging builds create a third use case. A WordPress network with several subsites can share a single human-reviewed list and produce per-host sitemap.xml files in one pass, avoiding a per-site plugin installation just to manage XML. Migration projects — moving a site from one domain to another, switching from WordPress.com to self-hosted, or staging a redesign — frequently need a frozen sitemap.xml to publish during the cutover window when the plugin stack is not ready yet.
Preparing a Reviewed WordPress URL List
Before opening the generator, the URL list itself deserves attention. WordPress makes it easy to assemble: pull Posts, Pages, and Custom Post Types from the WordPress admin, copy each canonical permalink, and assemble the result into a plain text file with one absolute URL per line. Pulling from the database directly — wp-admin → Posts → expand Screen Options → copy permalinks — is faster and more accurate than scraping the rendered site.
Decide on canonical forms in advance. If a WordPress post is reachable at both https://example.com/post-name/ and https://example.com/2024/post-name/, list the version that matches the canonical tag declared in the page head. If a redirect chain exists, such as a legacy slug pointing at a new permalink, list the final destination the user reaches after redirects — never the pre-redirect URL. The tool does not verify redirects, HTTP status, canonical tags, or indexability; it accepts the URLs as typed. Filtering draft posts, private posts, password-protected pages, attachment pages, author archives, tag archives, and search-result pages is the curator's responsibility before the file ever reaches the tool.
For a clean review, two checks are worth scripting in a spreadsheet rather than relying on the generator to catch mistakes: every line must start with http:// or https://, and every host after normalization must equal the single target host for the file. A non-default port, such as example.com:8443, is part of the serialized host and must be identical on every line. Mixing example.com and example.com:8443, or mixing https://example.com/ with https://www.example.com/, will fail the file at generation time. The single-host rule that governs every generated file is described in detail in the sitemap protocol rules when building from a URL list.
Generate sitemap.xml From a WordPress URL List
- Export the reviewed WordPress URL list as plain text with one absolute URL per line, encoded in UTF-8 with no trailing commas and no leading or trailing whitespace on any nonblank line.
- Open the XML Sitemap Generator in the current browser tab and paste the list into the URL editor — split LF, CRLF, and CR line endings are all accepted, and whitespace-only lines are ignored.
- Leave the optional lastmod, changefreq, and priority fields blank for a loc-only file, or fill each field with one truthful value that can be applied uniformly to every entry in the file.
- Click Generate and read the counts panel: confirmed unique URLs, duplicate-line count, rejected-line count, and the resulting UTF-8 byte size of the XML.
- Inspect the XML preview — the `` declaration, the `` root with the official sitemaps.org/0.9 namespace, and one `…` block per accepted entry.
- Click Download to save sitemap.xml from the temporary Object URL owned by the current result — pasting new URLs or changing an option immediately revokes the previous download link, so download after the list is final.
- Upload sitemap.xml to the WordPress site root via SFTP, the host's cPanel File Manager, or the equivalent — typically the public_html directory — so the file is reachable at https://example.com/sitemap.xml.
- Add a `Sitemap: https://example.com/sitemap.xml` line to robots.txt, following the Google Search Central guidance on building and submitting a sitemap, and submit the same URL through Google Search Console for indexing discovery.
URL Validation Rules for WordPress Sitemaps
The generator validates each nonblank line against a fixed rule set tied to the Sitemaps XML protocol and the WHATWG URL Standard normalization rules. Anything that does not match fails the line rather than being silently dropped, and the file generation fails when any line fails. The table below covers the inputs WordPress publishers tend to paste, including the cases that are easy to overlook during review.
| Input form | Accepted | Reason |
|---|---|---|
| https://example.com/about/ | Yes | Absolute HTTPS URL with an explicit root slash on a single host. |
| http://example.com/post-name/ | Yes | HTTP and HTTPS variants of the same serialized host may coexist in one file; the scheme is not treated as part of the host comparison. |
| https://example.com:8443/page/ | Yes | Non-default ports are part of the serialized host and must appear on every line of that file. |
| https://user:[email protected]/page/ | No | Embedded credentials are rejected so usernames or passwords cannot leak into a public sitemap. |
| https://example.com/page/#section | No | Fragments are not sent to the server as part of the HTTP request and are not allowed in sitemaps. |
| example.com/page/ | No | Bare domains without a scheme are rejected; absolute URLs are required. |
| /relative-path/ | No | Relative paths are rejected; resolvable absolute URLs only. |
| ftp://example.com/file | No | Only HTTP and HTTPS schemes are accepted. |
| " https://example.com/ " (leading or trailing space) | No | Whitespace at either end of a nonblank line is an error rather than being silently trimmed. |
| https://example.com/%2 | No | Malformed percent escapes are rejected during URL parsing. |
After parsing and normalization the tool deduplicates accepted lines in first-seen order. An uppercase host, its lowercase form, an explicit default port, and its normalized form all represent the same URL; the first occurrence is kept and later occurrences increment the duplicate counter rather than producing a second entry. Duplicate lines do not consume output slots toward the per-file limit, but every additional valid URL does — once the file reaches 10,000 unique URLs the next unique URL fails the entire generation with no truncation and no partial download. A normalized location may contain at most 2,047 characters; the whole-file budget is 5,000,000 UTF-16 input code units and exactly 10,485,760 UTF-8 XML bytes, accepted at the boundary and rejected one byte over. XML size is measured after URL serialization, XML escaping, optional tags, indentation, and UTF-8 encoding.
Optional lastmod, changefreq, and priority
Three optional fields can be applied to every entry in the file. They are applied uniformly: one shared value affects all entries or none of them. lastmod accepts a real Gregorian YYYY-MM-DD calendar date or a complete date-time with seconds and either a Z suffix or a valid UTC offset; leap years, calendar dates, clock fields, and timezone limits are checked, and leading or trailing whitespace is rejected rather than trimmed. changefreq accepts one of seven protocol strings: always, hourly, daily, weekly, monthly, yearly, or never. priority accepts a decimal value from 0.0 through 1.0.
These fields are protocol hints, not crawl commands or ranking guarantees. They communicate editorial intent only when the shared value is truthful for every entry — for example, a lastmod that matches the real significant modification time of every WordPress page in the list, or a changefreq of never for a static archive that genuinely never changes. Filling these fields with placeholder values teaches search engines to ignore the file as a whole. The safest default is to leave them blank and produce a loc-only XML; the sitemap protocol explicitly permits that. Invalid optional metadata fails the whole generation.
Publishing and Submitting the Sitemap
Once sitemap.xml is downloaded, the WordPress publication workflow is straightforward. Upload the file at the document root of the site — typically the public_html directory — so it is reachable at https://example.com/sitemap.xml. WordPress permalinks do not need reconfiguration, because Apache or Nginx serve the static file ahead of rewrite rules for paths that actually exist on disk. For a static export workflow, drop the file into the build output directory at the same path before generating the static bundle.
Reference the sitemap from robots.txt with a `Sitemap: https://example.com/sitemap.xml` directive — multiple lines are permitted when several sitemaps exist. The robots.txt file itself must live at the site root, not inside /wp-content/ or any other subdirectory. Then submit the sitemap URL through Google Search Console under Sitemaps: pasting the URL of the file, not the site root, is sufficient. The submission is an editorial signal, not a guarantee of indexing; pages blocked by robots, marked noindex, or returning non-200 HTTP responses remain outside the index regardless of sitemap content.
Reviewed-list sitemaps do not need regeneration on every WordPress edit. Update the URL list and rerun the generator whenever a meaningful section launches, a legacy redirect chain is retired, or an editorial policy changes which posts are indexable. The per-file limit of 10,000 unique URLs is well below the protocol's 50,000 cap; large WordPress networks that exceed the cap should split the list into a sitemap index with multiple sitemap.xml files named distinctly per host section, while the standalone generator itself produces only single-file outputs and does not create sitemap indexes.