Dev.to WebDev 🛠 Dev 👁 0 📖 2 min read

The dead sitemap: how one July click kept a site invisible for three months

Search Console accepted my sitemap, listed it as Success, and told me nothing for three months. That combination is possible, and it cost me every new post I published from July to October. What "Success" actua

Search Console accepted my sitemap, listed it as Success, and told me nothing for three months. That combination is possible, and it cost me every new post I published from July to October.

What "Success" actually means

A submitted sitemap shows Success when Google has fetched the file. It says nothing about whether the URLs inside it were queued, crawled or indexed. Mine read Success with 0 discovered pages for weeks. I looked at the word Success and moved on.

The number that mattered was the discovered count next to it. Zero meant the file was fetched and then produced nothing usable.

The original mistake

In July I did something that seemed harmless: I edited the sitemap through a plugin's URL field and saved a value with a stray whitespace character at the end. The sitemap endpoint answered with a 200 and a body that was not valid XML.

Diagnosis in one command:

curl -s https://example.com/sitemap.xml | head -3

Valid output begins with <?xml. Mine began with a blank line before the declaration, which is fatal: XML declarations must be the very first bytes in the document. Browsers do not care. Parsers do.

Why the UI cannot tell you this

Search Console has no concept of "your sitemap is well-formed but semantically wrong". It fetched something, got a 200, and marked the row Success. The pages inside were never read because the document never parsed.

The read that finally surfaced it was the per-URL inspection: every new post showed "URL is unknown to Google", and the discovery column said sitemap. Unknown, from a sitemap listed as Success.

The fix, and the verification that matters

Remove whatever is generating the file and serve a real one, then verify the bytes rather than the dashboard:

curl -s https://example.com/sitemap.xml \
  | python3 -c "import sys,xml.dom.minidom as m; m.parseString(sys.stdin.read()); print('valid xml')"

Then count the URLs and compare against your post count:

curl -s https://example.com/sitemap.xml | grep -o '<loc>' | wc -l

If those two numbers disagree, the sitemap is not doing its job regardless of what the dashboard says.

What changed afterwards

After serving a valid file, the sitemap report moved from 0 discovered to 62 discovered pages within a day, and new posts started appearing in the per-URL inspection as "Discovered" rather than unknown.

It did not fix indexing on its own. Crawl stats still showed ~1 request per day, and pages sat in the queue. But it moved the problem from "Google cannot read my list" to "Google has my list and is choosing slowly", which is a solvable problem. Before that, nothing downstream could work.

The lesson I keep relearning

Dashboards report their own success criteria, not yours. Success on a sitemap row means "fetched". Success on a page row means "indexed". They are different claims and they are one click apart.

Verify the artefact, not the status. Especially the boring ones.

Originally published on my diary: The Dead Sitemap: How One July Click Kept My Site Invisible for Months

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.