Common XML Sitemap Errors and How to Fix Them

A login page, CDN challenge, branded 404, or application error can return status 200 while the body is HTML. Check the final response URL, status, content type, and first bytes of the body. Search engines need the XML document, not a page that visually explains an error.

Unescaped ampersands, mismatched tags, invalid control characters, and text before the XML declaration can break parsing. Generate XML with a serializer and escape values at output time instead of concatenating strings.

A sitemap should contain final canonical destinations. Redirects waste crawl requests and send mixed signals; 404 and 410 URLs do not belong; alternate tracking or parameter URLs can compete with the preferred page. Resolve each loc and compare it with the page's canonical before publishing.

A deployment timestamp applied to every URL says that all pages changed together, even when only application code changed. Repeatedly inaccurate dates reduce the signal's usefulness. Source lastmod from the content record or omit it when you cannot prove a meaningful page change.

A sitemap cannot exceed 50,000 URLs or 50 MB uncompressed. Split larger inventories and use a sitemap index. Validate child files independently, because one broken child should not prevent you from diagnosing the rest of the inventory.

For fetch errors, capture the exact submitted URL, redirect chain, status, and body outside your logged-in session. A 404 suggests a wrong or removed route; 403 can indicate access rules; 429 and 5xx suggest rate limits or temporary server failures. A browser showing styled XML is not itself an error: inspect the downloaded document beneath the stylesheet.

For parse errors, run xmllint --noout on the downloaded, decompressed file and use the line and column it reports. Fix encoding or serialization in the generator. Encoding a query separator as %26 changes the URL; escaping it as & preserves the separator in XML. Avoid double-escaping already serialized values.

Checker checks XML syntax, its supported root and namespace, required absolute HTTP(S) loc values, duplicates, multiple hosts, dates, metadata values, and entry and byte limits. It reports date coverage and future-date counts. It is not a complete XSD validator and cannot infer whether a Google cross-site submission has verified ownership.

Pasted XML is checked locally in the browser without fetching pages. URL mode checks HTTP statuses for the first 10 entries of a valid urlset using HEAD requests. An index is checked as a document without recursively validating children. That sample does not inspect canonical tags, meta robots, content quality, or Google's indexing state. Test children separately and use a page audit for those questions.

URL mode requires bot verification and currently allows three requests per hour per IP. Remote transport has a 10 MiB response ceiling, below the protocol's 50 MB limit. A fetch-size failure does not prove the file exceeds the protocol limit; validate a downloaded file or audit smaller children instead.

Separate file processing from Page indexing reasons such as noindex, a different selected canonical, or crawled-but-not-indexed. Use URL Inspection for an affected entry and compare it with an eligible page from the same template. A sitemap cannot override noindex, guarantee canonical selection, or establish content quality.

After fixing the generator, fetch the deployed file again and retest a previously failing entry. Compare counts against the intended published set. Reports need time to reflect changes; keep before-and-after evidence rather than treating a later indexing increase as proof that the sitemap fix caused it.

Test transport first, XML second, individual URL quality third, and Search Console processing last. This order prevents you from chasing a report symptom caused by a basic response or serialization failure.