When the sitemap and the site claim different things

Search Console reports errors on the submitted sitemap; in the browser the same page looks flawless. Or the generator keeps serving http addresses after the switch to https because nobody reconfigured it. Both are the same contradiction. It does not cost rankings straight away, but it costs trust in the file: Google counts redirecting and non-indexable entries in Search Console as a defect of the submitted sitemap, and once a list is classified as unreliable, new pages are found via links again and nothing else.

How to go about it in JMX

1. Check the live file. In the Sitemap check tab (the Apply section) enter the URL or a file path under Sitemap A and click Check. A sitemap index is loaded with all its parts, gzip is unpacked transparently. The report groups into five sections — Fetch & file, Structure & protocol, The URLs, Metadata, hreflang — including the protocol limits: 50,000 entries, 50 MB per file, 2,048 characters per URL.
2. Collect the actual inventory. Enter the address at the top, Start. Under Settings → Crawl leave “Read sitemaps” switched on, otherwise JMX has nothing to hold the file against.
3. Look at the contradictions. The Issues tab carries eight rules in the Sitemaps category for this: “sitemap contains a non-indexable URL”, “… a redirecting URL”, “… a broken URL”, “sitemap URL never reached in the crawl”, “indexable page missing from the sitemap”, “sitemap lists URLs of a foreign host”, “sitemap violates the sitemap protocol” and “no XML sitemap found”.
4. Generate a clean version. In the Results, next to Export, sits the Generate sitemap button. Everything internal, indexable and HTML with status 200 goes in, regardless of the view’s filters; the preview counts what it will be before writing.
5. Hold the two against each other. Back in the sitemap check: the generated file into Sitemap A, the live URL into Sitemap B. Above the individual reports the comparison appears, with “Only in sitemap A — missing from B”, “Only in sitemap B — missing from A” and the third, inconspicuous list: “In both, but written differently” — http next to https, with and without www., with and without a trailing slash.
6. Make the case repeatable. The same without a window, for the deploy script: jmx-cli --check-sitemap /var/www/sitemap-new.xml --compare-sitemap https://example.com/sitemap.xml --fail-on Warning. Return code 2 stops the run before the file goes live.

What to watch out for

“Only in A” is a question, not an error. The generated file contains indexable pages with status 200 and nothing else; the live sitemap may well list pages the crawl never saw — behind a login, under an exclusion pattern, or on a host the run did not include. That is also why JMX reports “indexable page missing from the sitemap” as a notice and not as an error.

The sitemap check does not crawl. It checks what is in the files — whether the listed addresses also answer and are indexable is what the eight sitemap rules of a crawl answer, and only both together are the complete check. One of those rules stays quiet on purpose: “sitemap URL never reached in the crawl” reports nothing if the run was cancelled or hit its URL limit, because a crawl stopped at 5,000 addresses would otherwise produce thousands of findings about its own limits. Without a license the comparison lists stop at 25 rows; the counters above them stay complete.

One special case concerns lastmod. JMX writes none onto the generated entries, because the crawl knows the time of retrieval and not the time of change. In the comparison that has a consequence worth knowing: if the live file carries a lastmod everywhere and the generated one carries none, every shared URL counts as a metadata difference. Up to 100 examples per field appear in the list, the counter beside it names the full number. That is expected behaviour and not a statement about your site.

A sitemap is a claim about your own inventory, and it will be checked in any case — either beforehand by you or afterwards by Google.