Opening in a browser is only the start
A browser displaying a document does not prove that the sitemap contains the right pages. The sitemap protocol specifies XML structure and encoding, while HTTP Content-Type describes the representation delivered by the server. Build your validation around three layers: the response, the parsed document, and the URL inventory. A file can pass one layer and fail another. For example, well-formed XML might list preview URLs, or a correct local file might be replaced by an HTML challenge when requested from the public website.
Parse instead of searching for tags
Use an XML parser to read the deployed response. Check the expected root element and namespace, then extract locations as structured values. A text search for '<loc>' can miss malformed nesting, encoding problems, or unexpected namespaces. Escaping deserves special attention when URLs contain query parameters: XML syntax and URL encoding solve different problems. Keep test fixtures with an ampersand, non-ASCII text, and a normal path. The goal is not exotic coverage for its own sake, but catching the characters editors and imported content can realistically introduce.
A hypothetical deployment failure
Imagine a build produces a valid sitemap containing every published article. On production, an overly broad application route catches /sitemap.xml and serves the homepage instead. A browser still shows a working page, and the HTTP status may look successful, but the submission is not a sitemap. A validator that checks the response body with an XML parser exposes the problem immediately. The correct repair belongs in routing or asset delivery. Regenerating the same XML repeatedly would not address the deployed response that search engines actually receive.
Check locations against expectations
Compare extracted URLs with the canonical production inventory. Flag duplicates, unexpected hostnames, non-HTTPS variants, and routes that are no longer published. Fetch a representative sample or all entries when the collection is small enough, and record final status and destination. Keep missing inventory entries separate from listed URLs that fail delivery, because those require different repairs. If your system uses a sitemap index, perform the same process recursively for each child file. A valid top-level index is insufficient if one referenced file is missing or contains unrelated output.
Make the result useful to editors
Produce a concise report showing expected count, actual count, missing URLs, unexpected URLs, and fetch failures. Avoid a single green 'SEO passed' label that overstates what validation establishes. The check proves a set of technical conditions at a particular moment; it cannot determine whether every article is valuable or whether search engines will index it. Run it after publishing infrastructure changes and meaningful content imports. Save enough detail to reproduce a failure, including the requested sitemap URL and response timestamp, so editors do not have to guess which deployment was inspected.
Preserve the exact failed response when troubleshooting. A saved body and headers can reveal a temporary challenge page or routing fallback that disappears before another developer reproduces the issue.
Validate the XML structure, the HTTP response, and the meaning of the listed URLs as separate checks.
Sources & further reading
Official documentation informs this guide. Examples are illustrative, and product interfaces or limits can change.
From search signals to a useful first draft.
SERP.so is in development. Join the waitlist for a workspace that connects research, content review, and publishing.
Join early access ↗