A sitemap checker reads the file that lists your page URLs and identifies problems in its XML, entries and metadata. Use it when a sitemap cannot be read, after changing your sitemap generator, or before submitting a new file. Read the coverage statement before the verdict: a clean result applies to the files inspected, and does not confirm that Google has indexed your pages.
Which URL should you enter?
Enter the website's homepage, such as https://example.com/, to look for its sitemap. Screpy reads the Sitemap: declarations in robots.txt. If there are no declarations, it tries /sitemap.xml, /sitemap_index.xml and /sitemap-index.xml. These are discovery locations, not required filenames. A missing optional location does not invalidate a file found elsewhere.
If you already know the address, submit the exact sitemap URL:
https://example.com/sitemap.xmlfor a file containing page URLs.https://example.com/sitemap-index.xmlfor an index containing child sitemap addresses.https://example.com/products-sitemap.xmlto investigate one child separately.
These are illustrative addresses. Replace the domain and path with your own. Entering a page such as /products/ requests that document as a sitemap; it does not start homepage discovery. An HTML page, login screen or error page at the submitted address is not XML sitemap content.
How to read the sitemap report
Check the file table and coverage first, then work through the findings:
- Green: no issues found in the inspected scope.
- Red: confirmed errors need attention, such as broken XML or missing URL locations.
- Yellow: review warnings, including duplicates, questionable dates or incomplete coverage.
- Gray: unavailable or unchecked data; it does not mean a successful check.
For an illustrative index with three child files, suppose two are fully parsed with 40 and 60 page entries, while the third cannot be fetched. The report can count 100 page entries from the two completed files. It cannot establish the site's full total. The parsed-file count also includes the successfully parsed index; index entries point to files, not pages.
URL entries and unique URLs are different measures. The same address listed twice creates two entries but one unique URL. Findings can overlap, so the issue count is not necessarily the number of affected pages. When shown, the bars compare entries in parsed child sitemaps; they are not a chart of indexed pages.
A run checks up to 20 files, 100,000 entries and 100 MiB of decoded content within 27 seconds, following one level of index children. Nested indexes, unreadable files or reached limits can leave coverage partial. Submit the relevant child directly to investigate the missing portion. Tool limits are separate from the per-file sitemap standard described below.
What valid sitemap XML looks like
A basic page sitemap uses UTF-8 XML, the Sitemap namespace, a urlset root and a loc value for each url entry. Each location must be a full URL, including the scheme and hostname. This minimal example lists one page:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/guides/</loc>
</url>
</urlset>
The Sitemap protocol allows up to 50,000 entries and 50 MiB (52,428,800 bytes) per uncompressed file. Gzip reduces transfer size, not that decoded limit. Split larger files and list them in an index.
XML escaping matters: a URL containing ?a=1&b=2 must write the ampersand as & inside loc. That preserves the URL; it does not make a parameter variant the preferred page. Screpy supports XML sitemaps, indexes and gzip XML. An unsupported format result does not establish that Google rejects that format, and extension schemas are not fully validated.
Check dates, duplicates and ownership
lastmod is optional. If included, use a real date such as 2025-09-12, or a valid date-time with a timezone. For a page entry, it represents the page's last significant modification, not the time the sitemap was regenerated. For an index entry, it describes the child sitemap file's modification. A future-date warning calls for checking the clock, timezone and source value.
Google's sitemap guidance says Google uses consistently accurate lastmod values and ignores priority and changefreq. Adding those optional fields does not create a ranking boost. The checker validates present values; it cannot verify when the page's content actually changed.
For duplicate entries, correct the generator's source list so the intended URL appears once. Check the examples before changing URLs: exact repeats are different from separate addresses that may represent the same content.
An ownership warning needs context. Cross-site submissions can be legitimate when configured appropriately, as Google's index guidance explains. This tool cannot verify ownership or submission settings; confirm them before treating another hostname or path scope as an error.
Fix the source, then check again
Repair the sitemap generator, CMS configuration or source data rather than editing a generated file that the next update will overwrite. Use the affected file and reported examples to locate the problem.
| Finding | What to change | What to verify afterward |
|---|---|---|
| Fetch failure or HTML instead of XML | Correct the public route, access restriction or server response. | The exact submitted address serves the sitemap without a login or challenge. |
Broken XML, namespace or missing loc |
Repair the template, escaping or incomplete entry. | The file parses and each entry has the intended absolute URL. |
| Duplicate URL or invalid date | Deduplicate source records; correct date values or omit optional dates you cannot maintain accurately. | The same finding is absent after regeneration. |
| Partial coverage or a file over standard limits | Inspect the named child separately; split oversized files and update the index. | The relevant files are fully checked and stay within per-file limits. |
Regenerate, publish the corrected file and rerun the same input. Download the JSON report if you need to retain the findings and checked scope for comparison.
A valid sitemap is not proof of indexing
The checker fetches sitemap documents, not every listed page. It does not establish page response codes, canonical tags, noindex directives or Google's indexing decisions. A well-formed entry can still point to a deleted page or a URL you do not want indexed.
Take a relevant listed URL and investigate the separate question: use the Robots.txt Tester for crawler access rules, the Canonical Tag Checker for its declared preferred URL, or the On-Page SEO Checker for page-level SEO signals. These checks also have their own scope; none guarantees indexing.
After correcting the sitemap, review its processing in Google Search Console. A successful status means Google fetched and read the file, not that every discovered page was indexed. Use the page's indexing information to investigate exclusions. The Sitemaps report documentation explains that distinction. Keep a remaining page-indexing problem separate from a sitemap syntax problem so you fix the right source.
To compare response codes and redirect chains across a list of pages, use the Bulk HTTP Status Checker.