DEV Community

ricco020
ricco020

Posted on

Google said it had never heard of my URL. The URL was fine, my probe was not.

#seo #webdev #googlecloud #debugging

Last night I ran Google's URL Inspection API against a site I run and got this back:

coverageState : 'Google ne reconnait pas cette URL'
lastCrawl     : JAMAIS
Enter fullscreen mode Exit fullscreen mode

"Google has never heard of this URL." On a page that had been in the sitemap for weeks.

I was about to open a very large investigation. The page was fine. My probe was not. Here are the three ways that API lied to me in one sitting, and the one number that finally told me something true.

Trap 1: www and non-www are different URLs to this API

I passed https://save-my-disk.com/fr/blog/carte-sd-non-detectee. The sitemap declares https://www.save-my-disk.com/.... Same site to a human. Two different URLs to the API.

The result is not an error. It is not a 404. It is a confident, well-formed answer to a question I did not mean to ask:

without www :  'Google ne reconnait pas cette URL'   lastCrawl JAMAIS
with www    :  'Envoyee et indexee'                  lastCrawl 2026-07-18
Enter fullscreen mode Exit fullscreen mode

The same page. Indexed the whole time.

The rule I now follow: never compose the URL you inspect. Read it out of the sitemap you actually serve. I fetch sitemap.xml, grep the slug, and inspect that exact string.

Trap 2: the indexed field on sitemaps is zero for everyone

The Sitemaps endpoint returns a contents block that looks like it answers the only question you care about:

{"type": "web", "submitted": 3258, "indexed": 0}
Enter fullscreen mode Exit fullscreen mode

That indexed: 0 is not a measurement. I have a site doing 1677 impressions a month reporting indexed: 0. Every property I own reports indexed: 0. If you build a dashboard on that field you will build an alarm that fires forever.

Use errors and warnings from the same block. Those are real. Ignore indexed and inspect URLs individually if you want indexing state.

Trap 3: two states that read alike and mean opposite things

This is the one that matters, and it is the reason the whole exercise was worth it.

  • "Discovered - currently not indexed" means Googlebot knows the URL exists and has never fetched it. lastCrawl is empty.
  • "Crawled - currently not indexed" means Googlebot fetched the page, read it, and declined to index it. lastCrawl has a date.

They sit next to each other in the same report. They call for opposite work. The first is a crawl budget and discovery problem: more internal links, sitemap pings, authority. The second is a quality or duplication judgment: the page was seen and found wanting, and adding more pages like it makes things worse.

The number

I sampled 14 article URLs at random from a 590-page corpus on a data recovery site I run, and inspected each one. I validated the probe on a known-healthy control page first, which came back "Submitted and indexed" as expected.

 4/14   Submitted and indexed                      29 %
 4/14   Google does not recognise this URL     |
 4/14   Discovered - currently not indexed     |   8/14 with lastCrawl = never
 2/14   Crawled - currently not indexed            fetched, then declined
Enter fullscreen mode Exit fullscreen mode

Eight of fourteen pages had never been fetched at all. Only two had been read and rejected.

I had spent the previous hour preparing to write another article for that site. The measurement says that would have produced a 657th URL that Googlebot has never visited. The bottleneck is not the writing. It is that two thirds of what already exists has never been looked at.

That reframes the work entirely: internal linking, sitemap hygiene and off-site authority, instead of publishing volume. Not a conclusion I wanted, which is usually a sign it is the real one.

What I would tell past me

  1. Read the URL out of the artifact you serve. Do not build it from a folder name or a slug you remember.
  2. Run any new probe against a page you already know is healthy, before you trust it on the page you are worried about.
  3. When a check returns zero on everything it looks at, suspect the check first.

The API is not wrong in any of these cases. It answers precisely the question you asked. The gap between that question and the one you meant is where the hour goes.

Top comments (0)