How do I check if my sitemap is working?

`curl -sI https://example.com/sitemap.xml` should return 200 with an XML content type. A sitemap served as `text/html` is read by some consumers and refused by others.

Fetch the body and confirm it parses. A single unescaped ampersand in a URL makes the whole document invalid, and the failure is silent to anyone reading it in a browser.

Check the root element: `<urlset>` for a list of pages, `<sitemapindex>` for a file listing other sitemaps. Mixing the two in one file is invalid.

Confirm the size and count are within the protocol limits of 50 000 URLs and 50 MB uncompressed. Past either, the file has to be split and listed in an index.

Every URL should return 200. Redirects and errors in a sitemap waste crawl requests and are reported as errors.

Every URL should be canonical to itself. Listing a URL whose canonical tag points elsewhere is two contradictory statements about the same page.

No URL should carry `noindex`. Advertising a page for indexing while instructing against it is the contradiction Search Console reports most often.

Every URL should be on the same host as the sitemap, and should use the canonical host and scheme rather than a variant that redirects.

Spot-check a sample rather than reading the whole file. Ten URLs chosen from different sections will find a structural problem if one exists.

`<lastmod>` should reflect the date the content meaningfully changed, not the date the file was regenerated.

A sitemap where every URL carries today's date on every build is not informative, and Google has said it ignores the field when it is not consistently accurate.

Used honestly it lets a crawler prioritise what actually changed, which is where the value is on a large site.

The dates in the sitemap and the `Last-Modified` header on the page itself should agree.

`<changefreq>` and `<priority>` are part of the protocol and are ignored by Google. Setting them is harmless and achieves nothing.

The sitemap report shows the status of the last read, the date it happened, and the number of URLs discovered.

Compare discovered against the number in your file. A large shortfall means the file failed to parse partway, or the URLs were rejected for being off-host or malformed.

A status of "Couldn't fetch" points at reachability: a 404, a redirect chain, a robots.txt rule blocking the sitemap path, or a bot filter.

Submission is not required for the sitemap to be used — the `Sitemap:` line in robots.txt is read by every major crawler — but submitting it is what produces this report.

The counts lag by days, so a fix shipped this morning will not appear this afternoon.

It does not cause indexing. Google's documentation is explicit that inclusion is a hint about discovery, not an instruction to index.

It does not improve ranking, and a larger sitemap does not help.

It does not compensate for a page that is linked from nowhere. Such a page is discoverable and still low priority.

It does not override a `noindex`, a robots.txt block, or a canonical tag pointing elsewhere. Every one of those wins.

Its real value is highest on large sites, on sites with weak internal linking, and for content that changes often enough that discovery speed matters.

VeriFixScan's `seo.sitemap` check reports whether a sitemap was found, whether it was reachable, and whether it parsed.

Cross-checking the sitemap against the crawl is where the useful findings are: URLs listed but not reachable, and URLs reachable but absent from the file.

`seo.noindex` and `seo.canonical` on the crawled pages surface the two contradictions that make a technically valid sitemap useless.

A scan reads the file the way a crawler does. What Google did with it is only visible in Search Console.