A sitemap validator checks whether an XML sitemap uses the expected structure and supported field values. Screpy examines one document and highlights errors, warnings and source evidence so you can repair the sitemap generator. A clean result applies to the checked scope: it does not prove that the listed pages work or that Google has indexed them.
Choose the document you want to validate
Enter the exact public XML address, such as https://example.com/sitemap.xml, to check the published file. This fictional address illustrates the format. A homepage may return HTML instead; use Sitemap Checker if you need to find the sitemap first.
Choose pasted XML to check source before publishing or examine a saved document. Copy the raw XML, not a browser's styled table. There is no file-upload control. The optional base URL supplies context for comparing origins; it does not repair relative locations. Even with https://example.com/ as the base, <loc>/products/</loc> still needs a full HTTP or HTTPS address.
Without a base URL, pasted content has no origin context for that comparison. This does not prevent checking its supported structure and field values.
Repair the root, namespace and XML escaping
A page sitemap needs a urlset root in the standard sitemap namespace, with a loc inside each url. This fictional one-entry document shows the required structure:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/products/blue-mug/</loc>
</url>
</urlset>
Keep the namespace URI exactly as shown, including http. It identifies the XML vocabulary; changing it to https does not improve security and changes that identifier. An index uses a different root, explained below. The Sitemaps protocol defines both structures.
Inside XML, write a URL's & as &: for example, ?color=blue&size=m. Fix escaping in the generator rather than removing a needed URL parameter. Missing closing tags, unsupported content or a DOCTYPE declaration can stop the check before a detailed findings report. A failed check is not a passed validation.
Turn each finding into a source change
Read the outcome and coverage badges together. Red marks errors; yellow marks warnings or partial coverage; green indicates no findings requiring attention in the checked scope. Text and icons accompany the colors. Use the evidence and an entry's opening line to locate its XML block, then correct the source that generates it.
| Finding | Example problem | Source change |
|---|---|---|
| Invalid location | /products/ or a blank loc |
Supply the intended absolute HTTP or HTTPS URL. |
| Invalid optional value | lastmod of 2026-02-30 or priority of 1.2 |
Correct the value, or omit an optional field you cannot maintain. |
| Repeated field | Two loc fields inside one entry |
Emit one value for that field; this is an error. |
| Repeated location | The same address in two entries | Deduplicate the source list; this is a warning. |
| Unexpected element | priority inside an index entry |
Keep fields appropriate to the document type. |
The duplicate check compares trimmed location strings. It does not establish that different URLs share content or choose a canonical URL. A repeated address elsewhere in another file is also outside this single-document check.
“Entries needing review” counts entries with errors, not every warning or document-level fault. You can therefore see zero there alongside a root or namespace error. Read the findings rather than treating that metric as a validity score. Multiple findings may refer to the same entry.
Check date meaning as well as date format
lastmod, changefreq and priority are optional in a page sitemap. Their absence is not a field error. If you provide a date, use a valid value such as 2026-09-01 or 2026-09-01T14:30:00Z. A valid-looking format cannot make an impossible calendar date correct.
For a page, lastmod should reflect its significant modification, not each sitemap rebuild. A generator that replaces every date with today can produce syntactically valid but misleading data. Compare the source date with actual page changes; this validator cannot verify modification history.
Google's sitemap guidance says it uses consistently accurate, verifiable modification dates and ignores priority and changefreq. Correcting those two fields repairs supplied metadata; it does not create a ranking boost. If retained, priority must be between 0 and 1, and change frequency must use a supported lowercase value, such as weekly.
Read an index as a list of files
A sitemapindex contains sitemap entries. Each loc points to a child sitemap file; an optional lastmod describes that file's modification. It does not describe every page inside the child. An index listing three files therefore has three entries, not three website pages.
Screpy validates the submitted index itself. It does not open those child files. Validate each relevant child separately when investigating an error inside it. For a downloadable inventory, XML Sitemap Parser extracts entries rather than turning an index into a combined page list.
An origin warning compares the entry's scheme, hostname and port with the fetched document's final URL, or the base supplied for pasted XML. Check an unexpected http, alternate host or port before changing addresses. A difference calls for review, not an automatic verdict that the submission is invalid.
Google permits configured cross-site sitemap submissions with the appropriate ownership or site-specific sitemap references. This tool cannot verify those settings. Confirm the intended submission arrangement before replacing legitimate addresses simply to remove a warning.
Recheck the corrected file within the reported scope
The protocol's per-file ceiling is 50,000 entries and 50 MiB of uncompressed content. Screpy accepts up to 256 KiB of pasted XML or 50 MiB of remote decoded XML. These limits measure bytes, not characters.
Validation stops at 50,000 processed entries; the complete total and XML well-formedness can remain unknown. At most 1,000 rows are retained, and response-size limits can reduce the result further. Reading more entries than you see does not make the displayed list complete. Check coverage before interpreting totals or sharing a report.
CSV and TXT contain retained entries; JSON contains the bounded report. An export from a partial result is not an assured complete inventory. Extension elements can also produce partial coverage: this tool checks supported core fields, not complete extension schemas or full XSD conformance.
Repair the generator, template or source records, regenerate the XML and check the corrected published address again. Editing a generated file alone may be undone by the next rebuild. For a large file, validate smaller source sitemaps individually and track which completed.
Finally, investigate page behavior separately. Bulk HTTP Status Checker helps examine responses and redirects for listed URLs. Passing XML checks does not establish page status, canonicalization, noindex or indexing. After submission, review Google's sitemap processing and page-indexing evidence rather than treating this report as proof of search visibility.