Blocked Due to Other 4xx Issue: What Google Means and When to Fix It

Blocked due to other 4xx issue: what it means

Google defines it in one line. Its Page indexing help, re-read on October 18, 2026, says this label covers any code in the 400s that has no reason of its own in the report. A code in the 400s is a refusal: the site got the visit and declined to hand over a page.

Google's URL Inspection API reference draws the line more tightly, listing this reason as "Blocked due to other 4xx issue (not 403, 404)". So it is never the same as Not found (404), which has a guide of its own, and the 401 and 403 reasons are covered at the end of this page.

What it changes is narrow. Google's documentation on status codes says that "Google doesn't index URLs that return a 4xx status code", and also that these codes, apart from 429, "have no effect on crawl rate." The rest of the site carries on as before. The only question is whether each listed address is one you want on Google.

Older forum threads use the label Submitted URL blocked due to other 4xx issue, from an earlier version of the report; it is the same reason. If Google's email brought you here, the guide to Google's indexing emails reads the whole email, and this page takes the one reason in depth.

Is it a problem? Sort each address in a minute

Every address under this reason gets the same two questions, drawn below. The first does most of the work: is this a page you want customers to find on Google?

Plenty of addresses on a website were never meant to be pages. A contact form hands its message to one, a plugin talks to the server through another, and a store platform runs its own out of sight. Open one in a browser and it answers with a refusal, because it expects a request from the site's own code, not a visitor. Google can still find such an address in a page's code and try it. When a listed address is one of these, the refusal is the correct answer and there is nothing to change.

The second question is for real pages only. Open the address in a private browser window, which visits the way a stranger would. If the page loads for you, run Test live URL in Search Console. If Page fetch says Successful, the refusal has cleared. If the live test still shows it, send your host the message below; the section on why it opens for you and not for Google explains the usual cause. If it does not load for you either, put the page back or correct the link that points to it.

The pages worth checking first

Start with the pages that bring in work: contact, quote, booking and the main service pages. A refusal on one of those keeps it out of Google until it is sorted, and these are the pages a customer most needs to reach.

The pictures below show the contact page of Brindlewater Commercial Plumbing, a commercial plumbing site built by Theo, with a form for property managers to request a building walkthrough. A page like that has to open for Google's smartphone visitor every time, because Google reads sites mainly as a phone would.

Where to find the addresses in Search Console

Google's email names reasons, never addresses, so the next step is always the report. In the email, the reason reads word for word as it does in the report, and the Open indexing report button lands on the same screen as these steps.

1. Sign in to Search Console with the Google account the email went to, and pick the site.
2. In the left menu, click Indexing, then Pages, and scroll to the table headed Why pages aren't indexed.
3. Click the row named Blocked due to other 4xx issue. Its Source should read Website, meaning the refusal came from your site.
4. Read the examples. Google lists up to 1,000 addresses with the date of its last visit, and its help adds that the list "isn't guaranteed to show all URLs in a given status".
5. Open the menu at the top that reads All known pages and choose All submitted pages. What remains are addresses your sitemap lists, which deserve a look first, because the sitemap tells Google you want them found.
6. Click any address for the option to inspect it. That opens URL Inspection for the one address, which the next section uses.

Find the exact code

Search Console never names the code, and the live test keeps it hidden too. The extra detail behind View tested page includes the HTTP headers, but Google's URL Inspection help says: "Additional response data is available in the live test only when the test status is URL is available to Google or URL is available to Google, but has issues." A refused page never gets that far. These four steps get the code another way.

1. Open it yourself. Paste the address into a private browser window. If the site refuses you too, many servers print the code and its name on the page they send back, such as 405 Not Allowed. Others send a near-blank page, like the single 0 that WordPress shows at its admin-ajax.php address.
2. Run the live test. In URL Inspection, paste the address and click Test live URL. If the page loaded for you but Page fetch reads Failed: Blocked due to other 4xx issue, the refusal is aimed at Google's visits. Crawl allowed will read Yes, which rules out robots.txt.
3. Ask for a test under Google's name. Google's everyday crawler calls itself Googlebot, and its live tester calls itself Google-InspectionTool. Your host or web person can request the address under each name, which takes one line in a terminal. A rule that turns visitors away by name refuses that request too, and the reply shows the code. In the July 2026 family-tree case described further down, a request named Google-InspectionTool got back 406 Not Acceptable, with the words Not acceptable: bad-ua. A firewall that judges visits by the network they come from lets this test through, because the request does not come from Google's own addresses. So if both requests get the page, go on to the log.
4. Ask for the log line. Your host or web person can look up Google's real visits to that address in the server or firewall log, around the date the report shows, searching for both names. Each line records the code the site sent back.

What each 4xx code means and who handles it

Google treats every 400s code except 429 the same way, as its status code documentation explains. So the table below is about who handles each one, not how much it weighs with Google. The verdicts assume a typical small business site.

Three codes in the 400s are missing on purpose, because each has a reason of its own: 401 and 403, covered at the end of this page, and 404, in the Not found (404) guide. A fourth is 429 Too Many Requests. Google handles a 429 like the 500s codes, so the Server error (5xx) section of the email guide covers it. A 410 (Gone) works like a 404 for Google; the Not found (404) guide covers it.

It opens fine for me. Why does Google get a refusal?

Because something in front of the site treats Google's visits differently from yours. Hosts run firewalls, a WordPress site may add a security plugin, and some software keeps a list of bots to turn away. Each one judges a visit by who is asking and how often. Googlebot visits far more often than a person does, from Google's own addresses and under its own name, and a strict rule can mistake that for unwanted traffic.

Two public cases show the pattern. In January 2022, on Google's own Search Central Community forum, a site owner reported pages that loaded in a browser but failed Google's live test, and other site owners joined with the same symptom, some about their contact pages. That owner's host traced it to ModSecurity, a firewall that screens each visit against a list of patterns, and switched off the rules that were catching Google for that site; a second owner's host did the same. In July 2026, the owner of a site running an open-source family-tree program found that the program's bad-bot list named Google-InspectionTool, so every live test got 406 Not Acceptable.

The fix is narrow. The host lets verified Google visitors through and keeps every other protection in place. Verified matters, because anyone can type Googlebot as a name. Google's guide to verifying its crawlers tells hosts to look up the visiting address and confirm it belongs to googlebot.com, google.com or googleusercontent.com.

What shows up on Shopify, WordPress, Wix, Squarespace and GoDaddy

Of the 6,861 small business sites whose owners ran Theo's free audit between August 2 and September 30, 2026, 24 percent were on Shopify and 14 percent on WordPress, with Wix, Squarespace and GoDaddy Website Builder at 6 percent or less each (the research), so the table runs in that order. Not sure which one your site uses? The website platform checker tells you in a few seconds.

The background addresses in the drawing below were opened on October 18, 2026, and their codes are that day's answers. In a December 2022 thread on Shopify's own forum, several store owners reported a Shopify background address under this reason. It answered 405 then, and 503 on five live stores on October 18, 2026, so advice tied to one code there is out of date.

After the fix: test again, then tell Google

When the host or web person says the change is made, check it the way Google will. In URL Inspection, run Test live URL on the same address until Page fetch reads Successful. Then click Request indexing for that page. Google's help says "Indexing typically takes only a day or so, but can take much longer in some cases", and there is a daily limit on requests, so save them for pages that matter. The post on getting Google to index a page covers Request indexing step by step.

Then go back to the reason's row and click Validate fix, once, but only if every address still listed is one you fixed. If background addresses you chose to leave are still there, skip it: Google's help marks validation Failed when "a certain threshold of pages still contain this issue", and Google rechecks the list on its normal visits anyway. The Validate fix timeline is on the guide to Google's indexing emails.

What you may have read that is not right

A few claims about this reason travel from page to page. Here is each one beside what Google's own pages say, all re-read on October 18, 2026.

Its two siblings: Blocked due to unauthorized request (401) and Blocked due to access forbidden (403)

Search Console files these two codes under reasons of their own. Both come down to the same first question as above: is it a page you want customers to find?

Frequently asked questions