What Is Error 400 (Bad Request)?

Code 400 belongs to the 4xx family, reserved for errors that originate on the client side. Under the current specification, RFC 9110, the server responds with 400 when a request has "malformed syntax, invalid framing, or deceptive routing." In practice that covers everything from a URL with unencoded characters to a form submitting broken JSON, or a cookie that exceeds the size the server accepts.

There is rarely a single cause. An internal link generated from a broken template, a search parameter with unescaped quotes, or a corrupted language header can all trigger the same code. That is why 400 errors rarely show up alone. They tend to arrive in batches, tied to a recent change in URL generation, a plugin, or a third-party integration.

The most common mistake is treating 400 as a cousin of 404, though the resemblance is only superficial. A 404 means the server understood the request, looked for the resource, and did not find it. A 400 means the request never reached that stage: it was discarded earlier.

400 shares a family with codes that get mixed up easily. The table below shows where each failure originates and what typically triggers it.

For SEO, the distinction that matters most is against 404: 400 and 500 report a failure while processing the request, while 404 confirms the process finished and the resource simply is not there.

When a browser or a crawler sends a request, the server processes it in stages. It first validates the syntax: the URL, the headers, the cookies, the body if there is one. Only once that validation passes does the request move into the routing stage, where the server decides which resource it refers to. 400 is generated in that first stage. The server detects something it cannot interpret and stops before it even attempts to locate a resource.

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Date: Sat, 08 Aug 2026 10:15:32 GMT

That difference from 404 (which does reach the routing stage) and from 500 (which fails later, inside the application logic) has practical consequences. A 400 almost never gets fixed by creating a page or a redirect, because no page is involved yet. What needs fixing is how the request is being built.

On a website, the most frequent causes are technical and easy to miss: a migration that changes the character encoding of internal URLs, an e-commerce filter system that generates parameters with unencoded spaces, or an analytics integration that adds an oversized header. A CDN or reverse proxy in front of the site can also enforce its own header or URL-length limits, stricter than the application behind it. Googlebot and every other crawler receive the same 400 a user would, and log it the same way: as a request failure, not a content problem.

A single 400 barely moves rankings. The problem appears when it repeats across a URL pattern, because crawling then spreads less efficiently. Google does not process the content of a URL returning 400: its systems tell the next stage that the content does not exist, the same treatment applied to every 4xx error except 429. If that URL was indexed before, it drops out of the index over time.

The added difficulty is that Search Console does not break 400 out as its own category. In the Crawl Stats report, a pure 400 lands inside the catch-all "Other client error (4xx)" bucket, alongside codes that have nothing to do with it, such as 406 or 411. Anyone reading only that report can miss how many of those URLs are actually 400 until they cross-check with server logs.

That is the decision this code drives: if 400 volume climbs after a technical change, it is worth investigating before crawling pulls back on those routes and drags down internal links that were carrying real value.

• Filter server logs for code 400 specifically, since Search Console groups it under "Other client error (4xx)" without separating it out.
• Validate the character encoding of dynamically generated URLs (filters, internal search, campaign parameters) before publishing them as internal links.
• Test forms and endpoints with edge cases: empty fields, special characters, oversized payloads, to see whether the server answers with 400 instead of a proper validation message.
• Check header and cookie size limits after installing new analytics or marketing tools, a common and easy-to-miss cause.
• Audit redirect chains after a migration, since a badly encoded parameter in an intermediate hop can turn a valid redirect into a 400.
• Keep a real 400 (malformed request) separate from a 404 (resource not found) in application code; treating them the same makes every later diagnosis harder.

• Confusing 400 with 404 in application code and returning the same status for two different problems.
• Ignoring the "Other client error (4xx)" bucket in Search Console because it looks minor, when it can hide hundreds of URLs with broken parameters.
• Leaving URL encoding broken after a migration, assuming it only affects a handful of pages.
• Relying only on Search Console's sample instead of the full server logs, which show the actual volume.
• Configuring header or cookie validation so strictly that it ends up blocking legitimate requests from crawlers or real users.