"Blocked due to other 4xx issue" in Search Console: what it means on WordPress and what to do
Google asked for the address and got a status code in the 400s other than 401, 403 or 404. On WordPress's own files, such as admin-ajax.php and xmlrpc.php, that is normal and needs nothing. For a real page, find the code, then what sent it, which is often a rule or a firewall.
- By
- WP Ministry
- Published
- Tested on
- WordPress 7.1.3, PHP 8.3.35
In short
- The report does not name the code. The status covers every answer in the 400s except 401, 403 and 404, which have reasons of their own.
- A fresh WordPress answers 400 or 405 at several addresses of its own, admin-ajax.php and xmlrpc.php among them. Listed for those, the status is right and needs nothing.
- A real page is listed when something refused Google, such as a rule in .htaccess, a firewall, a rate limit or a link with a broken address.
- A page that loads in your browser can still answer Google with a 4xx. The Crawl Stats report and the server's access log show what Google was sent.
- The live test in Search Console asks as Google-InspectionTool, not as Googlebot. A rule that goes by the name Googlebot lets the test through.
- Google removes an indexed address that answers 4xx. A 429 is the exception. Google counts it as a server error and slows its crawl.
"Blocked due to other 4xx issue" is a reason Search Console's Page indexing report gives for a page that is not indexed. Google asked for the address and was answered with a status code in the 400s other than 401, 403 or 404. The report does not say which code. Whether anything is wrong depends on the address.
Read the list of addresses first. If they are WordPress's own working files, such as /wp-admin/admin-ajax.php, /xmlrpc.php and /wp-comments-post.php, or addresses under /wp-json/, the status is correct and there is nothing to do. A fresh WordPress answers 400 or 405 there, and none of them is a page. If a page you want found is on the list, something refused Google when it asked. Find out which code was sent, then what sent it. If the whole site is missing from Google, start with WordPress site not showing up on Google.
What Google means by it
Google's help for the report defines the status in one sentence: the server met "a 4xx error not covered by any other issue type described here". It then points to the URL Inspection tool for debugging. The help's own heading is "URL blocked due to other 4xx issue". The report prints "Blocked due to other 4xx issue", read there on October 8, 2026, with "Website" under Source. The help says a reason with that source is, in general, one the site's owner can fix.
Three codes in the 400s have a reason of their own, named in the help as follows. This page is about the fourth row.
| The site answered | Reason in the help | Where to read on |
|---|---|---|
| 401 | Blocked due to unauthorized request (401) | A password in front of the site, as on a staging copy |
| 403 | Blocked due to access forbidden (403) | The 403 Forbidden error |
| 404 | Not found (404) | Not found (404) in Search Console |
| Any other code in the 400s | URL blocked due to other 4xx issue | Here |
Google's page on status codes says what follows from such an answer. Google does not use the content of an address that answers 4xx and does not index it. An address already in the index is removed, and Google asks for it less and less often. Every 4xx code is treated the same way but one. A 429, which means too many requests in a given amount of time, is read as a sign of an overloaded server and counted as a server error, and Google slows its crawl of the site. Neither page says which reason the report files a 429 under, so do not assume it is this one.
Each list in the report is an example list of up to 1,000 addresses, and the help says it may not show every address with the status.
What causes it
The address is one of WordPress's own files, not a page
CommonWordPress answers 400 or 405 when its Ajax, comment, XML-RPC and REST API addresses are asked for the way a crawler asks. They are not pages, and the answer is the right one.
Fix: Find out which code Google was sent, or Leave WordPress's own addresses as they are
A firewall, a CDN or a security plugin refuses Google's crawler
CommonProtection in front of a site answers by who is asking, going by the name, the IP address or the number of requests. Visitors get the page and the crawler gets a refusal.
Fix: Find out which code Google was sent, or Change the firewall or rate limit that refuses Googlebot, or Test the live page, then ask Google to validate
A rate limit counts Googlebot as too many requests
SometimesA crawler asks for more pages than a person does. A limit set for people can turn it away, and a limit that answers with a 4xx code other than 429 is not read by Google as a request to slow down.
Fix: Find out which code Google was sent, or Change the firewall or rate limit that refuses Googlebot, or Test the live page, then ask Google to validate
A rule in .htaccess answers crawlers differently from visitors
SometimesA few lines that test the user agent can refuse every request that carries a crawler's name while every browser is served.
Fix: Find out which code Google was sent, or Remove a rule in .htaccess that refuses crawlers by name, or Test the live page, then ask Google to validate
A rule answers 410 Gone for a page you still want
RareA line left in .htaccess from a page that was once retired answers 410 for its address, and for every address that begins the same way.
Fix: Find out which code Google was sent, or Remove a rule that answers 410 for a page you still want, or Test the live page, then ask Google to validate
A link points at an address the server cannot read
SometimesAn address with a percent sign that is not followed by two hexadecimal digits is refused by the web server with a 400 before WordPress runs.
Fix: Find out which code Google was sent, or Correct a link whose address the server cannot read, or Test the live page, then ask Google to validate
How to fix it
Find out which code Google was sent
- Easy
- No risk
- About 15 minutes
- Steps tested on WordPress 7.1.3
A site can answer Google differently from how it answers you, so one request from your own computer settles little. Compare these.
Step 1: Read Google's own record of the request
The Crawl Stats report, under the property's settings, groups Google's requests by the response they got. The row "Other client error (4XX)" opens a list of example addresses, and the help says that clicking one shows that request's details, the response code among them. The report exists only for a property at the root of a domain.
In the Page indexing report, the inspect icon beside a listed address opens the URL Inspection tool. It shows the last crawl's time, the page that may have led Google to the address ("Referring page"), and whether the fetch failed.
Step 2: Test the live address
"Test live URL" fetches the address now. Two limits apply. By the help, the response's HTTP headers are shown only when the test succeeds. For a fetch that failed, it gives a reason from the report's own list, and this one names no code. And the test asks under the name
Google-InspectionTool, which Google documents as a separate user agent fromGooglebot. A pass does not show that the crawler is let through.Step 3: Ask for the page yourself
Replace the address with one from the report.
The first line printed is the status. The headers under it often say who answered, as the page on 429 describes.
bashcurl -s -o /dev/null -D - https://example.com/your-page/Step 4: Ask again under Googlebot's name
A different first line means something on the site goes by the name. The same line proves less: the command copies the name and not Google's IP addresses, and protection that goes by address will treat it as an ordinary visitor or as an impostor.
bashcurl -s -o /dev/null -D - -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' https://example.com/your-page/Step 5: Read what the server logged
The access log is the server's record of what it answered. In the combined format, the address is the seventh item on a line and the status the ninth. This prints a count, a status and an address for each 4xx answer to a request that carried Googlebot's name.
If Search Console records a refusal at a time when the log shows none, the answer came from something in front of the server. AI bots slowing down your website shows where hosts keep the log.
bashgrep -i 'Googlebot' /path/to/access.log | awk '$9 ~ /^4/ { print $9, $7 }' | sort | uniq -c | sort -rn | head -n 20
The page indexing check and the redirect checker show what an address answers a third party. Both ask from our server under our own name, never under Google's.
Leave WordPress's own addresses as they are
- Easy
- No risk
- About 5 minutes
- Steps tested on WordPress 7.1.3
On a fresh WordPress with Post name permalinks, on Apache, these answered with a code this status covers:
| Address | Answer | Why |
|---|---|---|
/wp-admin/admin-ajax.php | 400 | It needs an action and has none. It answers with the single character 0 and a noindex header |
/wp-comments-post.php | 405 | It accepts a comment sent with POST. The code means the method is not supported by the address |
/xmlrpc.php | 405 | "XML-RPC server accepts POST requests only." |
/wp-json/oembed/1.0/embed | 400 | The REST API was asked without the url it requires |
/wp-json/wp/v2/posts?page=99 | 400 | The REST API was asked for a page of results past the last one |
| An address over about 8,190 bytes | 414 | Apache's default limit on a request line. The code means the address is longer than the server will interpret |
WordPress points at some of these itself. Its robots.txt carries Allow: /wp-admin/admin-ajax.php, and a post that takes comments names /wp-comments-post.php in its form.
Step 1: Ask your own site
It prints
400,405,405,400and400, each beside its address.bashfor path in /wp-admin/admin-ajax.php /wp-comments-post.php /xmlrpc.php /wp-json/oembed/1.0/embed '/wp-json/wp/v2/posts?page=99'; do curl -s -o /dev/null -w "%{http_code} $path\n" "https://example.com$path" doneStep 2: Compare with the report
Addresses of these kinds need nothing. A 4xx is the true answer to a request that was not made the way they expect, and the help says pages under "Not indexed" are not necessarily there because of an error.
Other addresses of WordPress's own answer with codes the report files elsewhere. On the same site, a log-out link without its nonce and /wp-mail.php answered 403, /wp-trackback.php and a REST route asked with the wrong method answered 404, and /wp-json/wp/v2/settings answered 401.
Remove a rule in .htaccess that refuses crawlers by name
- Takes care
- Back up first
- About 15 minutes
- Steps tested on WordPress 7.1.3
This applies to Apache and LiteSpeed. Such a rule looks like this one.
# An example of a rule that refuses a crawler by name.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} Googlebot [NC]
RewriteCond %{THE_REQUEST} !\s/robots\.txt[\s?]
RewriteRule ^ - [R=406,L]
</IfModule>On the test site, a page answered 406 under Googlebot's name. Asked for plainly, and under the name Google-InspectionTool, the same page answered 200. The number after R= is the status, and Apache's documentation says any valid status code may be given there, not only a redirect. With R=429 the rule answered 429. [F] answers 403, which the report lists under its 403 reason.
Step 1: Download a copy of .htaccess
It sits in the site's main folder, beside
wp-config.php.Step 2: Search it for rules that test the user agent or answer a 4xx
Each line printed starts with its line number. WordPress's own section, between
# BEGIN WordPressand# END WordPress, has no such line, and on a file that holds only that section the command prints nothing.bashgrep -n -i -E 'USER_AGENT|User-Agent|R=4[0-9]{2}|[[,]G[],]|Redirect(Match)? +(gone|4[0-9]{2})' .htaccessStep 3: Remove the rule, or take Google's names out of it
Delete the condition, its
RewriteRuleand the lines that enclose them. If they sit between markers that name a plugin, change that plugin's setting instead, since it may write them again.Step 4: Ask again under Googlebot's name
The second command of the first fix now prints the same status as the first.
To undo it: Put your copy of the old .htaccess back.
Change the firewall or rate limit that refuses Googlebot
- Advanced
- Low risk
- About 30 minutes
Google's help for the report, in its part on server errors, says protection systems are often set to block unusually high numbers of requests, and that Googlebot, which asks for more than a person does, can set them off. It adds that the firewall may be the host's, so the host may have to change it.
Step 1: Name what answered
The headers and the words of the refusal, from the first fix, often carry a product's name. The 403 page covers switching a security plugin off to test it.
Step 2: Let Google's crawler through by address, not by name
Anyone can send Googlebot's name. Google documents two checks of a request's IP address. For Googlebot, a reverse DNS lookup gives a name ending in
googlebot.com, and a forward lookup of that name gives the same address back. Or the address is in the lists of ranges Google publishes. Look in the product for a setting that exempts verified search engine crawlers, or ask its support how to allow Googlebot by those lists.Step 3: If the aim is to slow Googlebot, answer with the right code
Google's page on crawl rate says not to use 401 or 403 for this, and its page on status codes says 4xx codes other than 429 have no effect on crawl rate. To slow the crawler in an emergency, Google says to answer 500, 503 or 429 for a couple of hours or a day or two. It warns against longer: an address that answers that way for several days may be dropped from the index.
Step 4: If the rule is the host's, send them the evidence
Give the address, the crawl time from Search Console and the code. Ask which rule answered.
If nobody can name what refused the request, a WordPress SEO audit from WP Ministry is a one-time, written audit of what stands between a WordPress or WooCommerce site and a search engine. What each address answers with is part of it.
Remove a rule that answers 410 for a page you still want
- Takes care
- Back up first
- About 10 minutes
- Steps tested on WordPress 7.1.3
A 410 means the page is gone and likely to stay gone. The help's "Not found" reason speaks of a 404 only, so by its definition a 410 belongs under this status. Apache sends one from either of these lines.
Redirect gone /summer-offer
RewriteRule ^summer-offer/?$ - [G]Redirect gone matches the path it names and everything under it. On the test site, such a line for one page answered 410 with and without the closing slash, and for an address below the page, while the rest of the site loaded.
Step 1: Find the line
The search command in the fix for crawler rules prints both forms.
Step 2: Check that the page is meant to exist
If it was retired on purpose, leave the line. Google treats a 410 as it treats a 404.
Step 3: Delete the line and ask for the page
The first command of the first fix now prints a 200 status.
To undo it: Put your copy of the old .htaccess back.
Correct a link whose address the server cannot read
- Takes care
- Back up first
- About 15 minutes
- Steps tested on WordPress 7.1.3
In an address, a percent sign has to be followed by two hexadecimal digits. On the test site Apache answered 400, a request it would not process, for /50%-off/ before WordPress ran. WordPress had given the page titled "50% off" the address /50-off/.
Step 1: Find where the address is written
The URL Inspection tool's "Referring page" may name the page. To search the site's own content, with the address from the report in place of this one:
It prints the table and column, then the ID of each row that holds the text.
bashwp db search '/50%-off/'Step 2: Replace it with the page's real address
Take a database backup, then see what would change.
It prints the number of replacements. Run it again without
--dry-runto make them.bashwp search-replace '/50%-off/' '/50-off/' --include-columns=post_content --dry-runStep 3: Ask for the corrected address
The first command of the first fix prints a 200 status for it.
If the link is on someone else's site, nothing on yours is broken. The address is not a page, and the status is correct.
To undo it: Restore the database backup you took before the change.
Test the live page, then ask Google to validate
- Easy
- No risk
- About 10 minutes
Step 1: Run the live test on a few of the listed pages
The help recommends this after a fix. A pass means the inspection tool could fetch the page at that moment. The help is plain that it is not a statement that the page will be indexed.
Step 2: Click "Validate fix" on the reason's page
By the help, this tells Google the issue is fixed. Search Console checks a few pages at once and stops if any still fails. Otherwise it works through the addresses it knows with the issue. The help says validation typically takes up to about two weeks and can take much longer.
Step 3: Wait for it to end
The help says not to click again until validation has succeeded or failed.
Validation is a request, not a switch. The help says Google updates the count whenever it crawls a page with a known issue, whether or not validation was asked for.
When to get help
Get help when real pages are listed and you cannot reproduce the code yourself. The page answers 200 to you, under Googlebot's name and in the live test, and the access log shows no refusal. That usually means something between the site and Google is answering, at the host or at a CDN, and finding it takes access to those accounts.
Common questions
Which status code is "other 4xx"?
Any code in the 400s except 401, 403 and 404. The Page indexing report does not say which. The Crawl Stats report and the server's access log do. On the test site, a fresh WordPress sent 400 and 405 from its own files.
The page loads fine for me. Why did Google get an error?
A site can answer by who is asking. A rule or a firewall may go by the user agent, the IP address or how many requests arrived in a short time, and Google's crawler differs from your browser in all three. The first fix compares them.
Should I block admin-ajax.php or xmlrpc.php in robots.txt to clear the list?
There is nothing to clear. They are not pages, and the reason describes them correctly. A rule in robots.txt would stop Google asking, and the report has a reason for that too. See Blocked by robots.txt.
Does this status affect the rest of the site?
Google's page on status codes speaks of the address itself: it is not indexed, and it is asked for less often. A 4xx code other than 429 has no effect on crawl rate. A 429 or a 5xx slows crawling of the whole host name.
Is a maintenance or coming soon page the cause?
Not WordPress's own maintenance mode. It answers 503, which the report lists as a server error. A holding page that answers 200 is an ordinary page to Google. WordPress coming soon pages and SEO shows how to read what yours answers.
- ResourceWordPress SEO audit checklist: what to check, in order, and how to check each item
- GuideWordPress SEO without a plugin: what WordPress already does and what it leaves out
- GuideWordPress site not showing up on Google: what to check, in order
- Guidewp-sitemap.xml: the sitemap WordPress makes, why it answers 404, and which one to submit
- Guidewww vs non-www for a WordPress site: which to choose, and how to make every other form redirect to it
- GuideBing Webmaster Tools for WordPress: setup, IndexNow, and what it means for ChatGPT and Copilot

