“Blocked due to other 4xx issue” in Google Search Console
What the status means, whether it's a problem, and how to fix it, step by step.
Not indexed · Checked against Google's documentation on 2026-10-30
Short answerFix it
The server answered Googlebot with a 4xx code that isn't 401, 403 or 404. Search Console doesn't name it, so find the code first: use a URL checker, URL Inspection's live test and your server logs. Then fix the page, or the firewall rule blocking Google.
Google: “The server encountered a 4xx error not covered by any other issue type described here.” Page indexing report help
What the status means
The server answered Googlebot with a 4xx code that doesn't have its own line in the report. Google's help defines the status by exclusion: a 4xx error not covered by any other issue type.
404, 401 and 403 are reported separately. So when you see this one, the code is something less common, and the first job is to find out which.
What Google does with 4xx responses
From Google's documentation on HTTP status codes:
- Already indexed URLs that return a 4xx are removed from the index.
- All 4xx errors are treated the same, except 429.
- They don't affect crawl rate. That also makes them useless for slowing Google down.
- 429 is different: Google treats it as a server error, so it doesn't belong to this group.
A URL with this status won't get indexed however good its content is. Nothing else matters until the response changes.
Is it a problem?
| What's on the list | Verdict |
|---|---|
| Real pages you want in search | Fix it: they're invisible to Google, and may also fail for visitors |
| URLs with broken parameters, odd characters or very long strings | Usually harmless. Find the link that creates them |
| Bot-trap or old URLs nobody visits | Leave them, or return a plain 404 |
Find the actual code
Search Console doesn't tell you the number in the report, so check one of these:
- The checker below. Paste the URL to see the status code and every redirect on the way. Our checker isn't Google, so a rule aimed at Googlebot may not fire for it.
- URL Inspection → Test live URL. This is the request closest to what Google sees. If you get the error here and not in your browser, something treats Google differently.
- A request with Googlebot's user agent:
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/
A firewall can check the IP address as well, so a clean result here doesn't fully clear it.
- Server logs. Filter by
Googlebotand the URL. The logs show the exact code and the time.
Which code, and what to do
| Code | What it means | Usual cause | Fix |
|---|---|---|---|
| 400 | Bad request | A malformed URL, a broken redirect target, oversized headers or cookies | Correct the link or redirect that produces the URL. If real pages return it, look at the application or proxy limits |
| 405 | Method not allowed | The server or a framework route rejects GET or HEAD for this path | Allow GET on the route. Check API routes that were linked by mistake |
| 406 | Not acceptable | A security module such as ModSecurity rejects the request, or content negotiation fails | Check the firewall log and whitelist the rule causing it |
| 410 | Gone | The page was removed on purpose | If the removal was intended, you're done |
| 418 and other unusual codes | Usually a firewall, hosting or bot-protection response | A rule aimed at bots | Find the rule and exempt verified Googlebot traffic |
| 451 | Unavailable for legal reasons | A geographic or legal block | Googlebot mostly crawls from the US, so a block on US visitors can hit it |
How to fix it by platform
WordPress
- Security plugins and hosting firewalls are the first suspects. Check their logs for blocked Googlebot requests and allow it.
- Temporarily turn off the plugin that matches the time the errors began, then test the URL again.
Shopify, Wix and Squarespace
- You don't control the server, and these responses often come from an app, a redirect or a URL with bad parameters. Find what links to the URL. If a real page returns the error, contact support with the example.
Next.js and headless sites
- Check
middleware/proxylogic that returns custom statuses, such as auth or geo rules, and whether it runs on public pages. - Route handlers answer only the methods they export, so a page path that hits one with the wrong method gets a 405.
Cloudflare and other CDNs
- Open the WAF or security event log and filter by the URL. Look at custom rules, country blocks, and rate limits that answer with a 4xx.
- Google says not to use 401 and 403 to limit crawl rate. If you need less crawling, return 429 or 5xx for a short time.
After fixing
- Confirm the page returns 200 in URL Inspection's live test.
- Check redirects if the URL used to redirect: the final target should return 200 with no extra hops.
- Run Validate fix for the issue. Google says validation typically takes up to about two weeks, and in some cases much longer.
Fix what links to the URL as well, especially if it's in your sitemap. Google should only find URLs there that work. If the code turns out to be 500 or higher, you need the server errors guide instead.
Check a URL
Paste one of the URLs from the report. The checker follows redirects and tests the status code, robots.txt, noindex and canonical.
FAQ
No. Google's documentation says 4xx codes other than 429 have no effect on crawl rate. 429 is treated as a server error.
Yes, if it keeps returning the error. Google's documentation says indexed URLs that return a 4xx are removed from the index.
A firewall or bot-protection rule is the usual reason: it answers differently depending on the user agent, IP address or country. Check the security log for the URL and test it with URL Inspection.
Want us to look at your Search Console?
We go through the Pages report, crawl the site and tell you which statuses cost you traffic and which are harmless, with the fixes in priority order.