Sitemap Checker: XML Sitemap Validator

You give it one sitemap URL. It fetches the file, parses it in a single pass, and reports whether it is well-formed XML that follows the sitemap protocol. If the file is a sitemap index, it reads the first five child sitemaps in the order the index lists them and validates each one the same way.

Next it reads robots.txt on the sitemap’s host and looks for a Sitemap: line that points to the file you entered. Last, it takes every URL it read, picks ten of them spread evenly across the list (the first, the last and eight in between), and fetches each one the way a crawler would. For each sampled URL it records the status code, whether it redirected, whether it carries noindex in a meta robots tag or an X-Robots-Tag header, and where its canonical points.

Each file may be up to 5 MB and gets 10 seconds to arrive. A bigger file stops the check with “The response is too large for this free check.”; check one of its child sitemaps instead. Sample URLs are fetched three at a time, and the whole check stops at 45 seconds. A sample URL it could not reach in time is listed as “Not checked: the time limit was reached.”, so you know it was skipped rather than healthy.

The sitemaps.org protocol sets the format, and Google’s sitemap documentation adds how Google treats the optional fields. The checker turns each rule into an error, a warning or a note.

One rule the checker shows rather than flags: Google does not support a sitemap index inside another sitemap index. If one of the child files in the report is labelled Sitemap index instead of URL sitemap, its URLs are not counted, and Google will not follow it either. List the inner index’s children directly, or submit the inner index separately.

The headline has three states. “Sitemap has errors” means at least one file could not be fetched, or a file has an error-level problem such as broken XML. “Sitemap has warnings” means there are no errors, but robots.txt does not list this sitemap, at least one sampled URL failed, or a file has a warning-level problem. “Sitemap looks healthy” means none of those.

Sitemap is the final address after redirects; if yours redirected, the first file card says “… redirects here. Submit and list the final URL.” For an index, Child sitemaps shows how many it lists and how many were checked, and URLs listed counts only the files that were read. The robots.txt line reads Lists this sitemap, Does not list this sitemap or Could not read robots.txt, with the sitemaps robots.txt does declare shown underneath.

File checks has one card per file: its type, how many entries it holds, how many have a lastmod, and its findings, each marked as an error, a warning or a note. The sample table gives each URL its final status code and a plain verdict: OK, “Returns 404: remove it from the sitemap or fix the page.”, “Redirects to …: list the final URL instead.”, “noindex: a sitemap should list only indexable URLs.” or “Canonical points to …”.

The canonical comparison is strict. A canonical that differs from the fetched URL only by a trailing slash, by http versus https, or by www is reported, because the sitemap and the canonical then disagree about which version is real.

Since WordPress 5.5, core serves its own sitemap index at /wp-sitemap.xml, with child files such as /wp-sitemap-posts-post-1.xml, /wp-sitemap-posts-page-1.xml, /wp-sitemap-taxonomies-category-1.xml and /wp-sitemap-users-1.xml. It has no settings screen and holds up to 2,000 URLs per file. Since WordPress 6.5 it adds lastmod to post entries, but not to category, tag or user entries. It switches itself off when “Discourage search engines from indexing this site” is ticked under Settings → Reading.

SEO plugins replace it with their own. Each one turns the core sitemap off while its own sitemap feature is on, and core’s comes back if you turn the plugin’s feature off. That last part catches people out: switch off Yoast’s sitemap to “simplify things” and /wp-sitemap.xml quietly starts serving again, while Search Console still holds /sitemap_index.xml.

Menu paths as of October 2026. They move between major plugin versions.

The symptoms: the robots.txt line says Does not list this sitemap and shows a different file underneath, robots.txt declares two sitemaps from two generators, or Search Console still holds a sitemap from the SEO plugin you replaced, which now returns 404.

Two sitemaps are not an error in themselves. The trouble is drift: one drops a deleted post, the other keeps it, and the stale file sends Google to redirects and 404s long after the site moved on.

Google may reject a file that is not well-formed, so XML errors come first. These are the messages this checker prints, with the WordPress cause behind each one most of the time.

Re-run the check after each fix. The checker reports the first XML error it meets, so a file with two problems shows the second one only after you fix the first.

A failing sample URL is rarely a one-off. Sitemaps are generated from settings, so one bad URL in ten usually means a whole group is affected. Work out which group, then fix the setting rather than the page.

Redirects usually mean the sitemap is built from an old address. If the sample shows http:// URLs redirecting to https://, or example.com redirecting to www.example.com, check that Settings → General → WordPress Address and Site Address both use the final form, then clear the cache that holds the old sitemap. A redirect on one post usually comes from a forgotten rule in a redirect manager; remove the rule.

A 404 in the sitemap means the file lists a page that no longer exists. Plugin sitemaps drop deleted posts on their own, so a 404 usually points to a cached or static sitemap, or to a custom post type whose single pages are not public.

noindex in the sample means the sitemap and your robots settings disagree. A common WooCommerce case: WooCommerce marks the cart, checkout and my-account pages noindex, and a sitemap that lists every page can include them. Exclude those pages from the sitemap; in Yoast SEO, set “Allow search engines to show this Page in search results?” to No in the page’s Advanced tab, which removes it too.

A canonical pointing elsewhere means the sitemap asks Google to index a URL that names another URL as the real one. Either the sitemap lists the wrong version, such as the one without a trailing slash, or the page was merged into another and should leave the sitemap.

Google says it uses lastmod only when the value is consistently and verifiably accurate, for example when it matches the page’s real last change. It also says the date should reflect a significant update, such as a change to the main content, the structured data or the links, and not a copyright year rolling over. Once Google learns that a site’s dates are noise, it stops relying on them.

A lastmod not in W3C Datetime format is a warning, and so is a date more than a day ahead, often a time zone or server clock problem. A file with no lastmod, or with more than 20 URLs that all share one date, gets a note: dates stamped at generation time are likely ignored.

WordPress SEO plugins use each post’s modified date, which is accurate by default. It goes wrong when something touches every post at once: a bulk edit in the Posts screen, an import, or custom code that sets the sitemap date to the current time. If every date in your sitemap is the day you last ran a bulk action, that is why.

Illustrative values. A Rank Math site moved from a staging host to www.example.com and switched to HTTPS the same week. The owner submits https://www.example.com/sitemap_index.xml in Search Console, which reports Has errors, and runs it through the checker.

The fix took three changes: both addresses in Settings → General set to https://www.example.com, the page cache purged, and the staging Sitemap: line replaced in robots.txt. The re-run showed Sitemap looks healthy, and the owner resubmitted the index in Search Console.

In Search Console, open Indexing → Sitemaps. Submit the final sitemap address, exactly as this checker shows it after redirects. The status column reads Success, Has errors or Couldn’t fetch. Has errors means Google read the file but some of it failed; Couldn’t fetch means it could not load the file at all.

Click a sitemap to see its details, then See page indexing. That opens the Page indexing report filtered to the URLs that sitemap lists, which is the full-site version of this checker’s sample. The statuses Page with redirect, Excluded by ‘noindex’ tag, Not found (404) and Alternate page with proper canonical tag are the same four problems the sample looks for. After a fix, those counts should fall over the following weeks as Google recrawls.

For a single URL, URL Inspection shows under Discovery which sitemaps list it. Google retired its sitemap ping endpoint in 2023, so as of October 2026 the ways to tell Google about a sitemap are the Sitemaps report, the Search Console API and a Sitemap: line in robots.txt. Resubmitting does not force a recrawl; it tells Google the file is there.

If you checked a child sitemap such as post-sitemap.xml and robots.txt lists the index above it, Does not list this sitemap is expected. Google finds the child through the index.

Off-host URLs are fine when they are deliberate: a sitemap hosted on one of your domains that lists URLs on another, with both verified in Search Console. The checker cannot see your verification, so it warns anyway.

The notes are not problems. A single sample URL that timed out or returned a 5xx once may be a slow server rather than a sitemap fault; run the check again before you change anything.

You may not need a sitemap at all. Google says a site of roughly 500 pages or fewer that is well linked internally, without many media files, can do without one. Every WordPress SEO plugin makes one anyway, so aim for a clean one, not a bigger one.