451 Unavailable For Legal Reasons

What HTTP 451 means, how Google treats legally blocked content vs. geo-restricted content, how it appears in Search Console, and when to use 451 vs. other status codes for geoblocking.

First published: Jun 27, 2026 · Last updated: Jul 17, 2026 · Advanced
demand #14 in HTTP Errors#30 in HTTP Status Codes#285 in Technical SEO#381 on the site

A 451 Unavailable For Legal Reasons means a resource is being withheld because of a legal demand — a court order, government censorship, a DMCA takedown, sanctions, or a regulation — not because it's missing (404) or access-forbidden (403). It's the only HTTP code designed for legal transparency: RFC 7725 asks the server to explain who's demanding the block and under what authority, and to add a Link: rel="blocked-by" header. For SEO, don't expect special treatment — Google doesn't document 451 among its "top 20" codes, and Search Console has no dedicated 451 label, so it lands in the catch-all "URL blocked due to other 4xx issue" and behaves like any generic 4xx: not indexed, or dropped from the index. Serving 451 globally by mistake deindexes just like an accidental 403/404. And using 451 for GDPR geo-blocking is genuinely contested, not settled fact.

TL;DR — 451 is the only HTTP status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. designed around legal transparency rather than technical or access state. RFC 7725 defines it for “resource access denied as a consequence of legal demands,” and asks (SHOULD) servers to explain the demand in the body plus add a Link: rel="blocked-by" header. For SEO there’s no bespoke handling: Google doesn’t document 451 among its “top 20” codes, Search Console has no dedicated 451 label (it lands in “URL blocked due to other 4xx issue”), and the outcome is generic-4xx — not indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., or removed if it was. A 451 served globally by mistake deindexes just like an accidental 403/404. And using 451 for GDPR geoGenerative Engine Optimization (GEO) is the practice of optimizing content and brand presence so AI-powered search engines and assistants — Google AI Overviews, ChatGPT, Perplexity — cite, recommend, or mention you when generating answers. Google's position is that it's still SEO.-blocking is genuinely contested, not settled — I’ll cover both sides.

What 451 is — and why it exists at all

451 has an unusual origin for a status code. It began as informal proposals (Chris Applegate in 2008, Terence Eden in 2012), was written up by Tim Bray in 2013, and was approved by the IETF on December 18, 2015 as RFC 7725. The number is a deliberate literary reference to Ray Bradbury’s Fahrenheit 451.

More importantly, it exists for a reason no other status code covers. RFC 7725’s own framing: “This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.” That’s a fundamentally different design goal than 403 (permissions) or 404 (existence). Evidence for this claim HTTP 451 reports that access to a resource was denied because of a legal demand. Scope: RFC 7725 defines the status code and its legal-demand scope; it does not establish whether a particular restriction is legally required. Confidence: high · Verified: IETF: RFC 7725 — An HTTP Status Code to Report Legal Obstacles A 451 says: access is being denied because of a legal authority — not the operator’s choice, not a bug. RFC 7725 is explicit that the response itself implies neither that the resource exists nor that it doesn’t; removing the legal demand wouldn’t guarantee a later request succeeds.

451 vs. 403 vs. 404 — what’s actually different

  • 404 Not Found404 Not Found is the HTTP client-error status code a server returns when it can't find the requested URL — RFC 9110 defines it as no current representation, or unwillingness to disclose one. A \"hard 404\" actually returns the 404 status; a \"soft 404\" returns a success code (like 200) for a page that's really gone. 404s are normal and expected: the fact that some URLs 404 doesn't affect your site's other, successful pages, and Google de-indexes 404'd URLs over time (probably retrying for some period, less and less often). — the resource doesn’t exist.
  • 403 ForbiddenAn HTTP 403 client-error status code meaning the server understood the request but refuses to fulfill it — access is denied, whether or not credentials are involved. For SEO, a 403 served to Googlebot on a page meant to be public and indexable usually points to a misconfigured rule; a persistent 403 keeps a page out of the index either way. — the resource exists, but access is refused (a login wall, an IP block, a WAF rule). The server is refusing.
  • 451 Unavailable For Legal ReasonsAn HTTP 451 client-error status code that tells a browser or crawler a resource can't be served because of a legal demand — a court order, government censorship, DMCA takedown, or regulatory requirement — rather than a technical failure (404) or an access-permissions problem (403). It's the only status code built specifically for legal transparency, and RFC 7725 asks servers to explain who is demanding the block and under what authority. — access is refused because of a legal demand, and the refusal originates with a third party — a court, a government, a rights-holder — rather than the operator’s own access rule. Unlike 404 and 403, RFC 7725 deliberately doesn’t say whether the resource exists or would otherwise be servable; that ambiguity is intentional, not an oversight.

For an auditor, that last distinction is the whole value of 451: it tells you why a page won’t load for certain visitors — a genuine legal/compliance requirement — rather than leaving you guessing whether it’s a misconfigured access rule. Mixing 451 and 403 up in an audit can mask that difference.

How Google treats 451 — no special handling, and you should assume the worst

This is the single most important expectation to set, because it runs against intuition: Google does not document 451 specially, and you shouldn’t expect it to distinguish “we legally can’t show this” from “this is broken.”

Google’s own page on how status codes affect its crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. is explicit that it only covers the codes it commonly encounters: “This guide describes how Google Search treats the top 20 status codes that Google encounters on the web… More exotic status codes, such as 418 (I’m a teapot), aren’t covered.” 451 isn’t in that top-20 list — I confirmed it doesn’t appear anywhere on that page. So there’s no bespoke Google 451 policy to lean on.

What does govern it is Google’s generic 4xx rule: “Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” And: “All 4xx errorsThe 4xx (client error) and 5xx (server error) HTTP status codes a server returns instead of a successful 2xx — and how Google treats each class very differently., except 429429 Too Many Requests is an HTTP client-error status code that means a client sent too many requests in a given time window — a mechanism called rate limiting. Unlike other 4xx codes, Google treats 429 as a server-overload signal and slows crawling instead of removing content., are treated the same: Google crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. inform the next processing system that the content doesn’t exist.” Evidence for this claim Google does not index URLs returning 4xx responses and removes already-indexed 4xx URLs over time; 429 is the exception to uniform 4xx handling. Scope: Google's generic 4xx crawler documentation supports the indexing outcome applied here to 451; it does not document special 451 behavior. Confidence: high · Verified: Google: How HTTP status codes affect Google's crawlers

So functionally, a persistent 451 behaves like any other non-indexable 4xx: the page won’t enter the index, and if it’s already there, it falls out. The safest, most defensible SEO claim about 451 is “Google treats it as a generic 4xx” — not “Google has special handling for legal blocks.”

How 451 shows up in Search Console (short answer: it doesn’t, specifically)

Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.’s Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. has no dedicated 451 reason. The report’s labeled reasons include “Not found (404),” “Blocked due to unauthorized request (401),” “Blocked due to access forbidden (403),” and a catch-all: “URL blocked due to other 4xx issue.” Google’s help page doesn’t name 451 specifically, so mapping it into that catch-all is my best current-evidence inference, not something the documentation states outright — confirm it for a specific URL with the URL Inspection tool rather than assuming the bucket.

The practical consequence is real: a site owner deliberately serving 451 to specific geographies will see those URLs lumped in with every other non-401/403/404 4xx code, with no way inside GSC to tell “legally blocked” apart from “misconfigured.” If you’re intentionally serving 451, you can’t rely on Search Console to confirm it’s doing what you meant — you’ll need server logs or live-URL testing from the affected geography to verify.

The indexing consequence — and the “don’t do this by accident” warning

Because 451 behaves like a generic 4xx, the risk is asymmetric. Scope it correctly (by geography/IP) and only blocked visitors ever see it. Scope it wrong — return 451 globally instead of geoGenerative Engine Optimization — visibility inside AI answer engines.-scoped — and you hand every crawler a 4xx for a page you wanted indexed, deindexingDeindexing means getting a URL to stop appearing in Google's search results. There's no single delete button — the right method depends on whether you own the page, whether removal is temporary or permanent, and whether the content should still exist. it the same way an accidental 403 or 404 would.

One more technical wrinkle from RFC 7725: 451 responses are cacheable by default. That has practical implications if a CDN edge caches a 451 that was only meant to apply to specific IP ranges or geographies — a cached legal-block response can leak to requesters (and crawlers) it was never intended for. Set cache behavior deliberately.

How Bing treats 451

Bing’s public documentation doesn’t specifically address 451, so I’ll scope this honestly rather than pad it. Bing runs its own EU delisting process — a form to block Bing search results in Europe tied to the 2014 CJEU “right to be forgotten” ruling — but that’s a search-index mechanism, not anything to do with server-level HTTP status codesAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index.. The reasonable working assumption (an inference, not an official Bing statement) is that Bing treats an undocumented 4xx like 451 the way it treats other client errors: deprioritize/remove from the index, consistent with general crawler behavior. As with 403, “fix Google” isn’t automatically “fix Bing” — check both engines’ tools after any geo/legal-block change. Neither Google nor Bing publishes a fixed recrawl or re-indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. SLA once a legal block is lifted — don’t promise a client a recovery timeline; expect the normal crawl-budget-dependent pace, confirmed with live inspection, not a guaranteed turnaround.

Implementing 451 the right way — the RFC 7725 checklist most sites skip

Almost every real-world 451 (and every competing explainer I found) ignores what the spec actually asks for. RFC 7725 says: “Responses using this status code SHOULD include an explanation, in the response body, of the details of the legal demand: the party making it, the applicable legislation or regulation, and what classes of person and resource it applies to.” On top of that, the spec defines a Link HTTP header with rel="blocked-by" identifying the entity that demanded the block.

A defensible 451 implementation therefore:

  1. Explains the legal demand in the response body — who’s demanding it, which law/regulation, and to whom it applies. (This is also just good UX and transparency for a blocked visitor or a researcher.)
  2. Adds the Link: rel="blocked-by" header naming the entity implementing the block — not necessarily the authority that demanded it. That distinction matters: the header identifies who’s carrying out the block, while the party mandating it belongs in the response body.
  3. Scopes the block correctly — by geography or IP, so you don’t 451 requesters (and crawlers) outside the affected region.
  4. Controls caching deliberately — since 451 is cacheable by default, make sure a CDN edge isn’t caching a geo-scoped block for everyone.

None of this makes the underlying block lawful, correctly scoped, or sufficient for compliance — the checklist buys you protocol transparency, not a legal conclusion. Whether a restriction actually needs to exist, and whether it’s been drawn correctly, is a legal determination for whoever owns that decision, not something the HTTP response can settle.

One more precision worth getting right: 451 doesn’t have to originate at the origin server. RFC 7725 explicitly allows an ISP, CDN, DNS provider, or search engine to implement the block on someone else’s behalf. Cloudflare, for example, documents that it may pass an origin’s 451 straight through — but pass-through behavior only proves the response travelled through that layer, not that Cloudflare (or any other intermediary) received the legal demand or generated the response itself. If you’re auditing a 451 behind a CDN, check where it actually originates before you assume who implemented it.

Is 451 the right code for GDPR geo-blocking? (it’s contested)

This is where I want to be careful, because a lot of glossary pages state “451 is for GDPR geo-blocking” as settled fact. It isn’t settled.

Terence Eden — one of the original informal proposers of the code — argued the case in Is HTTP 451 suitable for GDPR blocking?: “If the only way to access a resource would involve serving content which breaks the law, then 451 is appropriate.” His reasoning is that RFC 7725 only requires a “legal demand,” not a court order or active censorship — and EU law itself can constitute that demand.

But even Eden’s post makes the counter-argument that belongs in any honest treatment: the better fix is to comply with the law, not to block. Critics — and GDPR’s own text — hold that the regulation requires compliant data handling (proper consent and data practices), not denial of access. On that reading, EU news sites that threw up a 451 wall for European visitors after 2018 were choosing a workaround, not satisfying a legal requirement to block. Both framings are legitimate; the article you should walk away with is that 451-for-GDPR is a defensible-but-debated choice, not a mandated one.

Worth remembering too: you don’t need a 451 to satisfy a DMCA order or court takedown. Plenty of sites comply with 404s, 403s, or plain content removal and never adopt 451. Its added value is transparency — telling visitors and researchers why — not a technical-legal requirement to use that specific code.

To be clear, none of this is legal advice. Whether a specific GDPR-related regional block, copyright notice, sanctions rule, or court order actually requires or permits a 451 — or requires compliance instead — is a legal and factual question for your counsel to answer. The RFC’s semantics and how other sites have implemented 451 don’t settle that question for your situation; they just tell you what the code does and doesn’t communicate once you’ve decided.

Real-world 451 in the wild

  • Automattic (WordPress.com) was one of the earliest and most-cited adopters. In its 2016 transparency post it said the code “will be returned to visitors from those countries where we have been forced to block websites for legal reasons” — while stressing it’s “strongly opposed to Internet censorship.” A useful reminder that serving 451 makes a block transparent; it doesn’t mean the operator endorses it.
  • US news sites post-GDPR (2018+) blocking EU traffic rather than achieving compliance — the most visible everyday 451 most people encounter.
  • Sanctions-driven inaccessibility — the BBC has reported on Sudan sanctions cutting off Western services, the kind of scenario 451 was designed to make legible.
  • DMCA-driven repository blocks are widely cited industry-wide (GitHub is the usual example); if you’re going to cite a specific current implementation, verify it live first rather than trusting reputation.

For the broader family — how 4xx vs 5xx differ, and where 451 sits among them — see my HTTP Status Codes & Their SEO Impact guide, and the sibling 403 ForbiddenAn HTTP 403 client-error status code meaning the server understood the request but refuses to fulfill it — access is denied, whether or not credentials are involved. For SEO, a 403 served to Googlebot on a page meant to be public and indexable usually points to a misconfigured rule; a persistent 403 keeps a page out of the index either way. and 404 Not Found404 Not Found is the HTTP client-error status code a server returns when it can't find the requested URL — RFC 9110 defines it as no current representation, or unwillingness to disclose one. A \"hard 404\" actually returns the 404 status; a \"soft 404\" returns a success code (like 200) for a page that's really gone. 404s are normal and expected: the fact that some URLs 404 doesn't affect your site's other, successful pages, and Google de-indexes 404'd URLs over time (probably retrying for some period, less and less often). deep dives in this cluster.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.