How to Check an XML Sitemap for Errors

2026-07-06

TL;DR

You submitted your sitemap weeks ago. Google Search Console shows it was read. Yet new pages still aren't appearing in search results. The sitemap looks fine from the outside.

Most guides tell you to submit and move on. They treat submission as the finish line. A sitemap can pass submission and still fail at the URL level, the structural level, and the compliance level simultaneously.

The Check Sequence in this article gives operations managers, site owners, and consultants a three-step audit framework: Structure Check, URL Check, Compliance Check. Each step catches a different failure class. Run all three before submission and you remove the problems that cause silent indexing failures. You do not need a developer to do this correctly.

* * *

How do I check if my XML sitemap has errors?

Open the sitemap file directly in a browser. Then run it through a free XML linter to confirm structural validity. After that, test a sample of URLs inside the file for status codes and index eligibility using Google Search Console's URL Inspection tool. Structural validity and functional correctness are separate checks, and both are required.

* * *

Why a Broken Sitemap Does More Damage Than No Sitemap at All

Submitting a sitemap feels like completing a task. It is not.

A sitemap with malformed URLs or incorrect encoding can cause Google Search Console to report fetch errors across every URL listed. The crawler reads the file, finds it unreliable, and walks away without processing any of it. You spent crawl budget on a file that returned no usable data.

Stop treating submission as proof of completion. Start treating the sitemap as infrastructure that requires verification before it goes live.

That is the false assumption most site owners carry for months. The sitemap was submitted, so it must be working. Meanwhile, pages sit unindexed and the gap between publishing and ranking quietly grows.

A broken sitemap also sends a signal. Crawlers infer site quality partly from how well-structured your technical signals are. A sitemap returning XML parse errors or pointing to non-existent URLs communicates that the site structure is not under control. No sitemap at all is a neutral absence. A broken sitemap is an active negative.

Most guides on this topic spend the majority of their space explaining what an XML sitemap is. This article skips that. You already know what it is. What you need is a repeatable audit sequence that catches errors before Google does.

The Check Sequence covers three distinct failure layers: structural, functional, and compliance-based. Each layer catches problems the others miss. Running them in order is the point.

* * *

Step One: Confirm the File Structure Before You Check a Single URL

The most expensive debugging mistake is diagnosing URL problems inside a file that is already broken at the structural level. Fix the container first.

An XML sitemap must open with a proper XML declaration. The first line of the file should read:

``` <?xml version="1.0" encoding="UTF-8"?> ```

This confirms encoding and XML version. Google expects UTF-8. A file saved in ISO-8859-1 without declaration can produce character encoding errors on extended characters, breaking the entire file silently.

Below the declaration, the file requires a correct namespace declaration inside the `urlset` opening tag:

``` <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> ```

Missing this namespace is one of the most common structural errors. The file may look fine to a human reader, but an XML parser will reject it.

Structure Check: What to confirm before moving forward

XML declaration present on line one
Encoding set to UTF-8
`urlset` opening tag includes correct `xmlns` attribute
Every `<url>` block contains at least one `<loc>` tag
All opened tags are properly closed
File ends with a closing `</urlset>` tag

A sitemap missing the closing `</urlset>` tag will fail W3C XML validation entirely. Every downstream check becomes meaningless at that point. There is no value in testing URLs inside a structurally invalid file.

Run the file through the W3C Markup Validation Service or any free XML linter before proceeding. Both tools return specific line numbers for errors. Fix every structural error before moving to Step Two.

One practical note: if you are generating the sitemap through a plugin or CMS, regenerate a fresh copy after any major configuration change. Plugins occasionally output malformed XML during version transitions. Do not assume the output is clean because it was clean last month.

* * *

Step Two: Run URL-Level Checks for the Errors Most Guides Skip

A structurally valid sitemap is not automatically a working sitemap. This is where most beginner guides stop, and where most indexing failures begin.

Structural validity means the XML file parses correctly. Functional correctness means the URLs inside that file are actually indexable. These are two different things.

Here is what survives structural validation but still blocks indexing:

Redirects instead of canonical destinations. A URL in your sitemap that returns a 301 or 302 redirect is not wrong, but it is inefficient. The sitemap should list the final destination URL, not the redirecting one. Listing redirect URLs wastes crawl budget and signals poor site hygiene.

URLs blocked by robots.txt. Including a URL in your sitemap that is also blocked in robots.txt sends conflicting instructions. The sitemap says "crawl this." The robots.txt says "do not crawl this." Google will typically respect robots.txt and skip the URL, but the conflict itself can cause that page to be deprioritized in the crawl queue.

Noindex directives on listed URLs. A URL carrying a `noindex` meta tag should not appear in the sitemap. The sitemap tells Google a URL is worth indexing. The noindex tag tells Google to ignore it. Including it creates a contradiction that Google resolves by following the noindex directive. The URL stays out of the index and you have wasted a slot in your sitemap file.

Non-canonical URLs listed instead of canonical versions. If page A has a canonical pointing to page B, page A should not appear in the sitemap. Only the canonical version belongs there.

<table class="border-collapse w-full my-4 table-auto mx-4 max-w-4xl sm:mx-auto" style="min-width: 75px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th class="border border-border px-4 py-3 bg-muted font-semibold text-left" colspan="1" rowspan="1">Check Type</th><th class="border border-border px-4 py-3 bg-muted font-semibold text-left" colspan="1" rowspan="1">Structurally Valid File</th><th class="border border-border px-4 py-3 bg-muted font-semibold text-left" colspan="1" rowspan="1">Functionally Correct File</th></tr><tr><td class="border border-border px-4 py-3" colspan="1" rowspan="1">XML parses without errors</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Yes</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Yes</td></tr><tr><td class="border border-border px-4 py-3" colspan="1" rowspan="1">All URLs return 200 status</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Not checked</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Required</td></tr><tr><td class="border border-border px-4 py-3" colspan="1" rowspan="1">No noindex conflicts</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Not checked</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Required</td></tr><tr><td class="border border-border px-4 py-3" colspan="1" rowspan="1">No robots.txt blocks</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Not checked</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Required</td></tr><tr><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Canonical URLs only</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Not checked</td><td class="border border-border px-4 py-3" colspan="1" rowspan="1">Required</td></tr></tbody></table>

The table above is the core distinction this step makes. Passing structural validation puts you in the left column. You need to be in the right column before submission.

Use Google Search Console's URL Inspection tool to test a sample of URLs from the sitemap. Check for index eligibility, canonical confirmation, and coverage status. For larger sites, a crawl tool like Screaming Frog can batch-check status codes across every URL in the file and flag redirects, blocks, and noindex conflicts in a single pass.

A reasonable sample for manual checking is 10 to 15 URLs drawn from different sections of the site. If errors appear in the sample, run the full set through a crawl tool before continuing.

* * *

Step Three: Confirm Compliance Before You Submit to Google Search Console

Structural validity is confirmed. URL-level problems are cleared. The final step runs a compliance pass against Google's published guidelines before the file goes live.

Google enforces specific limits on sitemap files. A single sitemap file cannot exceed 50,000 URLs or 50MB uncompressed. A sitemap listing 60,000 URLs in a single file will not be processed fully. The fix is a sitemap index file that references multiple child sitemaps, each staying within the limits. This is a straightforward split, but it requires knowing the limit exists before you hit it.

Date formatting in `lastmod` tags. The `lastmod` value must follow W3C Datetime format. Acceptable formats include `2024-03-15` and `2024-03-15T10:30:00+00:00`. A date written as `03/15/2024` or `March 15 2024` will fail validation. Many CMS plugins output correct formatting automatically, but manually edited sitemaps frequently carry formatting errors here.

Session IDs and tracking parameters in URLs. A URL like `https://example.com/page?sessionid=abc123` should not appear in a sitemap. Session IDs create duplicate URL variations that Google treats as separate pages. Tracking parameters create the same problem. List only the clean, canonical URL without query strings that serve no indexing purpose.

HTTPS consistency. Every URL in the sitemap should use HTTPS. A sitemap listing HTTP URLs on an HTTPS-configured site creates a mismatch. Google reads the sitemap as describing a different version of the site than the one it sees in the browser. Confirm every `<loc>` value begins with `https://` before submission.

Compliance Check: Final pass before submission

File size stays under 50MB uncompressed
URL count stays at or below 50,000 per file
`lastmod` dates follow W3C Datetime format
No session IDs or tracking parameters in any listed URL
Every URL begins with `https://`
If over 50,000 URLs, a sitemap index file is in place

The Check Sequence closes here: Structure Check, URL Check, Compliance Check. Three separate layers. Three different failure classes. Running all three in order means you are not discovering problems inside Search Console's Coverage report after the fact.

Submit the sitemap through Google Search Console's Sitemaps tool once all three steps pass. After submission, monitor the Coverage report over the following two to four weeks. If errors surface post-submission, the Coverage report will identify which URLs are affected and what the error type is. The Check Sequence reduces what you find there, but the Coverage report remains the confirmation layer.

One implementation caveat worth stating directly: if you run the Check Sequence and find errors at Step One, do not proceed to Steps Two or Three. Fix the structure, then restart from the beginning. A structural fix can change how URLs render inside the file, which means URL-level checks from before the fix may no longer be accurate.

* * *

Three Checks Before Submission Beats One Fix After Indexing Fails

The Check Sequence works because it treats three failure layers as distinct problems requiring distinct solutions. Structural errors, URL-level conflicts, and compliance violations do not overlap. Each step catches what the others cannot see.

Most indexing failures are not mysterious. They trace back to a file that was never audited before submission. A single pass through the Check Sequence before submitting removes the most common causes: broken XML structure, noindex conflicts, redirect chains in the sitemap, and limit violations that prevent full processing.

Running these three checks takes less time than diagnosing a coverage error six weeks after launch. The sitemap is infrastructure. Treat it accordingly.

Submit only after Structure Check, URL Check, and Compliance Check all pass.

* * *

FAQ

How to check for errors in XML?

Open the XML file in a browser to catch immediate parse errors. Then run the file through the W3C Markup Validation Service or a dedicated XML linter, which returns specific line numbers for structural problems. Fix every reported error before doing any further checks on the content inside the file.

What are some common errors found with XML sitemaps?

The most frequent errors include missing or incorrect namespace declarations, URLs returning 301 redirects instead of 200 status, noindex directives on listed URLs, and `lastmod` dates in non-standard formats. Non-canonical URLs appearing in the sitemap and URLs blocked by robots.txt are also common and often go undetected without a dedicated URL-level audit.

How do I validate an XML sitemap?

Run the sitemap file through the W3C Markup Validation Service or an XML linter to confirm structural validity. After that, use Google Search Console's URL Inspection tool to verify that individual URLs inside the file are eligible for indexing. Structural validation and URL-level validation are separate steps and both are required.

What is a 404 error on a sitemap?

A 404 error means a URL listed in your sitemap returns a "not found" response when Google tries to fetch it. The page does not exist at that address. This wastes crawl budget and tells Google the sitemap contains outdated or incorrect information. Remove any URL returning a 404 from the sitemap and either restore the page or redirect it to a valid equivalent.

How to inspect XML?

Open the file directly in a browser to see the raw XML structure. Most browsers display XML in a readable tree format and will flag parse errors immediately. For a deeper inspection, paste the file contents into an XML linter or use the W3C Markup Validation Service to get a full error report with line-level detail.

How to check for errors in data?

For XML sitemap data specifically, run the file through a structural validator first to confirm the file itself is well-formed. Then audit the data inside the file by checking URL status codes, canonical tags, and robots.txt rules for each listed URL. Batch checking with a crawl tool is faster for sitemaps with more than a few hundred URLs.

How to find error in XML?

Use an XML linter or the W3C Markup Validation Service. Paste the file contents or provide the file URL. The tool will return a list of errors with specific line numbers. Common findings include unclosed tags, missing namespace declarations, and encoding issues on special characters.

How to fix sitemap error?

Identify the error type first. Structural errors require fixing the XML file itself, such as closing open tags or correcting the namespace declaration. URL-level errors require updating which URLs appear in the sitemap, removing redirects, noindex conflicts, and blocked URLs. Compliance errors require adjusting file size, URL count, date formatting, or removing tracking parameters. Fix errors in the order the Check Sequence presents them: structure first, then URLs, then compliance.