XML Sitemap Validator

Check sitemap XML structure, entries and last-modified dates.

What Is an XML Sitemap Validator?

An XML sitemap validator helps check whether a website’s sitemap follows the XML Sitemap protocol and uses a structure that search engines can read. Sitemap validation focuses on details such as XML syntax, the required tags and namespace, URL locations, and date formatting. Finding these issues before submitting a sitemap can prevent avoidable parsing problems. However, a valid sitemap does not prove that every listed page is accessible, canonical, or indexed by Google.

XML Sitemap Validator

Check sitemap XML structure, entries and last-modified dates.

Validate a sitemap file

Paste XML or a URL list Or choose a sitemap XML file Or load a public website URL (optional)

Checks well-formed XML, sitemap vocabulary, URL values, duplicate entries and lastmod formatting for up to 3000 entries. Sitemap indexes are validated as indexes, without automatically downloading their child sitemaps. This is not a Google indexing or crawl confirmation.

Rate this tool 5.0 out of 5 from 1 rating

How to Check an XML Sitemap and Fix Errors That Matter

A sitemap is a discovery file, not an instruction to index every URL. It tells search engines which pages you consider important and can include a reliable last-modified date. That makes it especially useful for large websites, new sites, and content libraries where some pages are difficult to reach through ordinary links.

Before submitting or resubmitting a sitemap, review both its XML structure and the quality of the URLs it lists. These are separate checks: a file can be perfectly formatted while pointing to redirects, duplicate pages, or URLs that should not appear in search results. This guide explains the Sitemap protocol, common errors, what a validation result can and cannot establish, and a practical workflow for WordPress and other websites. The exact checks performed by any validator depend on its implementation.

Read Full GuideShow Less

First, Identify Whether You Have a Sitemap or Sitemap Index

There are two related XML documents. A regular sitemap contains page addresses. A sitemap index contains the addresses of other sitemap files, making it easier to manage a large collection of URLs. They use different root elements, so an apparently missing <url> tag might be completely normal in a sitemap index.

Document	Root element	Required entry structure	Typical use
XML sitemap	`<urlset>`	`<url>` with `<loc>`	Lists individual page URLs
Sitemap index	`<sitemapindex>`	`<sitemap>` with `<loc>`	Lists individual sitemap files

Many WordPress SEO plugins generate a sitemap index that links to separate post, page, category, or other content sitemaps. Check the child files as well as the index; a correctly formed index does not prove that every linked sitemap is correct.

The XML Rules Search Engines Expect

A standard XML sitemap uses UTF-8 encoding and the namespace http://www.sitemaps.org/schemas/sitemap/0.9. Each <url> entry needs a <loc> containing an absolute URL with its scheme, such as https://example.com/services/. The <lastmod>, <changefreq>, and <priority> elements are optional.

XML reserves characters with special meanings. For example, a query-string separator must appear as & in the source XML rather than a bare ampersand. Tags must be correctly nested and closed. The sitemap should list URLs from the permitted site and directory scope; mixing unrelated hosts is not valid under the ordinary Sitemap protocol.

A Small Sitemap You Can Read Line by Line

This example shows the minimum useful structure, with an optional modification date:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/services/</loc>
    <lastmod>2026-10-25</lastmod>
  </url>
  <url>
    <loc>https://example.com/contact/</loc>
  </url>
</urlset>

Both entries contain a complete location. The date is optional and should reflect a meaningful change to the corresponding page. The filename itself does not make the XML valid; the document’s content and structure do.

Common Sitemap Problems and How to Correct Them

Problem	Why it matters	What to do
Malformed XML or unescaped `&`	The file may fail XML parsing.	Correct the XML and encode ampersands in URLs as `&`.
Missing or incorrect namespace	The file may not match the Sitemap protocol.	Use the official namespace on the root element.
Missing, relative, or empty `<loc>`	The location cannot be interpreted as a complete page URL.	Supply a full HTTP or HTTPS URL for every entry.
Unreliable or invalid `<lastmod>`	Dates can be rejected or ignored.	Use a valid W3C date or datetime reflecting an actual change, or omit it.
Repeated, redirected, or noncanonical URLs	The sitemap may send inconsistent discovery signals.	Prefer one final, indexable canonical URL for each intended page.
Too many URLs or an oversized file	The file exceeds Sitemap protocol limits.	Split it into smaller sitemaps and reference them in an index.

A validator’s warning categories vary. An XML syntax error is different from a website accessibility problem, and a warning about an optional tag does not necessarily mean that Google will reject the entire sitemap.

What the Last-Modified Date Really Means

The <lastmod> value is the date when the page last changed meaningfully, not the date your sitemap file was regenerated. Updating every timestamp daily without changing the underlying pages makes that signal less trustworthy. Google says it may use this field when it is consistently accurate, and it ignores <changefreq> and <priority> values for crawling decisions.

For a product page, a genuine change to pricing information, specifications, or substantial page content may justify updating the date. A routine footer change across the site generally should not cause every listed page to claim newly modified content. If your publishing system cannot maintain accurate dates, omitting the optional field can be better than inventing timestamps.

Valid XML Does Not Mean Good Sitemap URLs

A technically valid sitemap can contain URLs that return HTTP errors, redirect elsewhere, use a noindex directive, or declare a different canonical URL. Those issues require checks beyond the XML itself. Use a bulk HTTP status and redirect checker to review final responses, and a canonical tag checker when preferred URL selection is unclear.

Review whether the listed URLs use the preferred HTTPS host, consistent trailing-slash policy, and the final destination rather than an outdated address. Important pages should also be reachable through useful internal links. A sitemap supplements navigation; it does not replace it. An indexability review helps investigate pages that are intentionally or accidentally excluded from search.

When One Sitemap Is Too Large

The standard limit is 50,000 URLs and 50 MB uncompressed per sitemap. A sitemap index also has an entry limit of 50,000 referenced sitemap files. For larger sites, produce multiple smaller sitemaps and group them in a sitemap index. Gzip compression can reduce transfer size, but it does not remove the uncompressed-size requirement.

Separating large files by content type can make changes easier to diagnose. For example, keep product URLs apart from blog articles if your content management system supports that arrangement. You can also use a sitemap comparison tool to investigate URLs added or removed between two generated versions.

Why Google Search Console Can Still Report a Problem

A local XML check cannot guarantee that Googlebot can retrieve the live sitemap. Search Console may report Couldn’t fetch when Google cannot obtain the file, or Has errors when it retrieves a sitemap but encounters problems processing it. Confirm the public sitemap URL works without a login, check server availability, and review whether robots rules or security controls interfere with access.

Submit the sitemap through the Sitemaps report for the appropriate Search Console property. After submission, compare the reported status with the actual sitemap address, then inspect important URLs separately in the Page indexing report. Successful sitemap processing means the file could be read; it does not mean every URL was crawled, indexed, or selected as canonical.

A Practical WordPress Sitemap Review

Find the sitemap URL published by your SEO plugin or WordPress installation, often a sitemap index.
Check that the file loads publicly and that its XML root matches its type.
Review required locations, namespace, entity escaping, and date values.
Inspect the individual sitemaps referenced by an index.
Spot-check important URLs for redirects, canonical mismatches, and indexability restrictions.
Correct issues in the original plugin settings or content records, not only in a temporary XML copy.
Regenerate or refresh the sitemap, check it again, and review the result in Search Console.

If the sitemap is missing altogether, consider building one with an XML sitemap generator. If the site already has a working automatic sitemap, do not publish a competing duplicate without a clear reason.

Three Questions Worth Asking Before Submission

Can a sitemap contain pages that are not indexed?

Yes. A sitemap is a discovery signal. Google still evaluates crawling access, canonical selection, content quality, and other indexing factors independently.

Should every URL have a priority value?

No. Priority is optional, and Google does not use it to determine crawling priority. Accurate URL selection and meaningful internal linking deserve more attention.

Does a sitemap index need every child sitemap checked?

Yes, for a complete review. A correctly formed index establishes the format of its own entries, not the contents or accessibility of the child files it references.