Open the exact sitemap URL and inspect its response before resubmitting it. A successful status with an HTML fallback is different from a working XML sitemap. After confirming the file, check whether the listed URLs are the preferred public pages you actually want discovered.
Use the exact file path
Many sites use /sitemap.xml, but that is a convention, not a requirement. Some use a sitemap index, a platform-specific path or multiple files. Copy the URL from your CMS, robots file or Search Console submission. The checker tests common paths when you submit a page URL and accepts an exact .xml path for custom locations. A missed convention should not be treated as proof that the site has no sitemap.
Check the response before the contents
A server can return a generic homepage with status 200 for a missing XML URL. That is not a usable sitemap simply because the request succeeded. Look for a urlset or sitemapindex root, a closing element, the expected content and a sensible response type. A redirect can be intentional, but the destination must still be the sitemap. Server errors, bot blocks and login walls need separate fixes in the hosting or access configuration.
Review the URL selection
The file should help discovery of the preferred URLs, not preserve every historical variant. Review redirecting locations, staging hosts, nonpublic account paths and duplicate entries. A noindex page in the file sends an unhelpful mixed message about the page's purpose. For large sites, choose representative pages from each template and compare their final response, robots directives and canonical. A five-page sample is a starting point; it cannot certify thousands of entries.
Understand a sitemap index
An index lists child sitemap files rather than ordinary page URLs. NewSiteCheck samples up to two children and one level of page locations. That keeps a free check bounded, but it can miss another child file with errors. If one child is important, submit that exact XML URL separately. Record which files you inspected so a teammate can distinguish checked sections from assumptions about the rest of the site.
Fix generation at the source
If a CMS repeatedly exports incorrect locations, editing the XML by hand will only last until the next regeneration. Correct the canonical/base URL configuration, URL selection or plugin ownership instead. If two sitemap plugins are active, decide which one generates the file and references. After deployment, verify the response directly and check a small set of listed pages. Retain an example of an incorrect entry and its corrected result for the release record.
Resubmit and watch the right signal
A sitemap submission is a discovery aid, not a ranking action or an indexing guarantee. After fixing the file, inspect its processing information and priority page coverage in Search Console. Compare the submitted path with the one you tested. Avoid repeatedly resubmitting an unchanged file while overlooking page-level noindex or canonical problems. The useful outcome is a clean file plus eligible, useful linked pages, followed by evidence that the crawler can observe them.
A practical action checklist
- Copy the exact submitted sitemap URL.
- Verify HTTP response and basic XML structure.
- Remove duplicate, redirecting and unintended nonpublic entries.
- Inspect representative URLs from each child sitemap.
- Fix the generator, recheck and review Search Console processing.
NewSiteCheck workflow and examples. Review important production decisions against the applicable official documentation.