"URL is not available to Google" explained

“URL is not available to Google” looks like it belongs to the same family as the other Search Console messages about indexing. It does not, and that is the most useful thing to know about it.

This one comes from the live test. It is Google trying to fetch your page right now and failing.

The short answer

Google could not retrieve the URL at the moment you asked it to. Read the Availability section for the specific reason, because that is where the detail lives. It is a fetch problem rather than a quality or indexing judgment, which means it is usually mechanical and usually fixable today.

Why “URL is not available to Google” is different

Google’s own documentation puts this message alongside the Availability section, and labels that section “Availability (live test)”. That single word tells you which clock you are reading.

The other messages describe Google’s stored record: what it knows, when it last crawled, what it decided. This one describes right now. So two things follow that catch people out:

An indexed page can show this. Google indexed it last week, something broke since, and the live test is telling you before your traffic does. That is a good outcome caught early, not a contradiction.

A page that passes the live test can still be unindexed. Fetchable and worth keeping are separate judgments. Google says as much: a positive live result is no guarantee the page will appear, because the test does not check quality guidelines, manual actions or security issues.

The causes, in the order worth checking

Blocked by robots.txt. Cheapest to rule out and the most common. Open your robots.txt in a browser and read it rather than assuming. Disallow rules that were correct on staging have a habit of shipping to production.

404, or a soft 404. The URL does not exist any more, or it returns a page that says nothing is there while sending a 200 status. If you changed a slug and did not redirect, this is your answer.

Redirect error. A chain that loops, exceeds the hop limit, or lands somewhere broken. Follow it by hand and see where it actually ends.

401 or 403. The page is behind authentication or the server is refusing the request. Common on staging that was never opened up, and on production sites where a security plugin or WAF has decided Googlebot looks suspicious.

Server error, 5xx. Your server failed at that moment. Sometimes transient, sometimes a real capacity problem that also affects real visitors. Check whether the timestamp lines up with anything in your logs.

DNS or connection failure. Google could not reach the host at all.

N/A. Google’s documentation admits this is a generic failure with no further information available. Do not over-read it. Retry, and check your own logs for that timestamp.

When it is your site, not your page

If you see “Not available due to a site-wide issue”, stop looking at the individual URL. Google is telling you it could not run a live inspection against the property at all.

That points at DNS, at a server that is not responding, or at robots.txt itself returning a server error, which Google treats far more severely than a missing file. A robots.txt that 500s can stop crawling across the whole site, and it is the kind of failure that produces a lot of panic about individual pages when one fix resolves everything.

The trap: it works in your browser

The most common frustration with this message is that the page loads perfectly for you. It usually will, because Googlebot is not you. It arrives from a different network and a different country, with no cookies, no session, and a user agent some security products treat as hostile.

Things that produce exactly this pattern:

• A firewall, WAF or bot-protection rule challenging non-human traffic
• Rate limiting that trips when a crawler requests several URLs quickly
• Geo-blocking that excludes the region Googlebot is fetching from
• A CDN serving a challenge or interstitial rather than the page
• A login wall or paywall applied more broadly than intended
• Content that only appears after JavaScript your server did not render

Testing in a private window with JavaScript disabled gets you closer to Googlebot’s experience than a normal browser tab will. Your server or CDN logs are better still, because they show what was actually served to that request.

What to do, in order

1. Read the specific reason in the Availability section. Do not act on the headline alone.
2. If it says site-wide, fix the site-level cause and stop inspecting individual URLs.
3. Rule out robots.txt by opening it, and confirm it returns a page rather than an error.
4. Check the URL’s real status code yourself, following any redirects to the end.
5. Look at your server and CDN logs for Googlebot’s request at that timestamp. This is the step people skip and it is usually the one that answers it.
6. Re-run the live test once fixed, then request indexing. Here is what that button actually does.

Once it fetches, you may have a second problem

Fixing availability gets Google in the door. It does not commit Google to keeping the page.

If the URL becomes fetchable and then settles at crawled, currently not indexed, that is a different problem with a different cause, and the fix has nothing to do with servers. If it shows as unknown to Google instead, you have a discovery problem. And if the top line reads “URL is not on Google”, the real reason is in the section underneath it.

No submission tool helps with any of this, incidentally. A URL that cannot be fetched cannot be indexed by anything, whatever it costs. The full market comparison is here.

---

If the live test keeps failing and your logs are not telling you why, send me the URL. The diagnosis is free and you get the cause named rather than a list of things to try. Where there is real work, indexing work starts at $25 with a per-URL ledger. If it is affecting a set of pages rather than one, check the whole list at once, and this is what that looks like across location pages.