A 403 means "the server understood your request and is refusing it" — not because you need to log in (that's 401) but because permission won't be granted regardless. Common causes: wrong file permissions, firewall blocking your IP, .htaccess deny rules,…
HTTP 403 Forbidden means the server understood what you asked for and is deliberately refusing to serve it. This is fundamentally about authorisation, not authentication: it isn't saying "log in" (that's 401), it's saying "even if you did log in, you wouldn't get this." 403 covers a wide range of refusal scenarios — your IP is blocked, the file has the wrong permissions, the directory has indexing disabled, a hotlink protection rule fired, or a geo-restriction policy applied to your region. Unlike 451 (which specifically signals legal blocking), 403 doesn't tell you why — that's a deliberate design choice to avoid leaking information about server configuration.
Pages returning 403 are not indexed by Google. If a previously-indexed page starts returning 403, Google removes it from search results within days to weeks. A sitewide 403 (often from a hosting suspension or firewall misconfig) deindexes the entire site fast. Google does not distinguish between "intentionally locked" and "accidentally locked" — both look like a content disappearance, which damages rankings. If you need to block access to staging or admin pages, use authentication (401) or robots.txt instead of 403 to avoid this signal.
LemWatch alerts the moment a previously-public page starts returning 403 — almost always the sign of a firewall rule change, plugin update, or accidental .htaccess edit. We also distinguish between consistent 403s (deliberate) and sudden new 403s (likely a mistake).
HTTP 403 was defined in the original HTTP/1.0 spec (RFC 1945, 1996) as the "I refuse to tell you why" status code. The deliberate vagueness was intentional: the spec authors wanted servers to be able to refuse access without leaking whether the resource exists, whether the user's credentials would work elsewhere, or what policy triggered the block. This makes 403 a security-by-obscurity tool — sometimes useful, sometimes a debugging nightmare.
HTTP 403 Forbidden means the server understood the request but is refusing to serve it. The refusal is not about authentication (which would be 401) — providing valid credentials will not help. Common causes: file permissions, firewall blocks, .htaccess rules, hotlink protection, or geo-restriction.
Check the server's error log first — it will show the specific rule that fired. Then verify (1) file and directory permissions (chmod 644/755), (2) .htaccess or nginx deny rules, (3) firewall and WAF rules blocking your IP, (4) hotlink protection misconfiguration. Most 403s are caused by recent config changes or plugin updates.
401 Unauthorized means "you need to authenticate" — log in and you'll get access. 403 Forbidden means "you are not allowed, regardless of authentication." 401 is about identity; 403 is about permission.
Almost always one of: file permissions are wrong (the web server can't read the file), .htaccess contains a deny rule, your IP got added to a firewall block, a WordPress security plugin locked the area, or a hotlink protection rule blocked the request. Start with the server's error log — it names the rule.
Pages returning 403 are not indexed. Previously-indexed pages that start returning 403 get removed from search results. A sitewide 403 (often from a hosting suspension or firewall misconfig) can deindex the entire site within days. For private pages, use authentication or robots.txt — not 403 — to avoid the SEO damage.
403 is a generic permission refusal — could be any reason. 451 Unavailable For Legal Reasons specifically signals that a legal demand (court order, takedown, government block) is causing the refusal. Use 451 when censorship or legal blocking is the actual cause; use 403 for everything else.
Yes — Cloudflare returns 403 when a WAF rule, IP access rule, country block, or Bot Fight Mode triggers. The Cloudflare dashboard's Security → Events log shows exactly which rule fired. A common false-positive pattern: aggressive WAF rules blocking legitimate API traffic from server-to-server integrations.
It's a security-conscious default: if the bucket policy doesn't grant ListBucket permission, S3 returns 403 for both "object exists, no permission" and "object doesn't exist" — preventing attackers from enumerating bucket contents by probing for known filenames.