403 Forbidden Error: Diagnose and Fix Website Access Problems

By Rahul S., Founder and SEO Consultant at SearchCounselCo. Updated 8 October 2026.

Start with the symptom you actually see

What does 403 Forbidden mean?

RFC 9110: 403 Forbidden defines 403 as a request that was understood but refused. The refusal can come from a firewall, reverse proxy, web server or application. It can involve access rules, unreadable files, directory handling or application permissions. Credentials are not necessarily the reason.

Check the actual HTTP status as well as the visible message. A page saying “Forbidden” with status 200 is a different response from an HTTP 403. A recent migration, security update or rule change is a lead to investigate; timing alone does not confirm the cause.

On a narrow screen, scroll the table sideways.

An uploads directory can refuse listing while its individual public images load correctly. Decide the expected access for the exact URL. Enabling directory listing is not a general repair for a denied file or page.

Find the cause before changing settings

1. Capture the request that fails

A successful page load does not prove that its save, login or media request works. Use the browser’s Network panel to inspect the operation that actually fails. Chrome’s Network guide explains request and response inspection.

1. Preserve unsaved work. Open the browser’s developer tools, choose Network and keep recording enabled. Clear the existing request list; use Preserve log if the action navigates away.
2. Repeat the failing action once. For a page visit inspect the document; for a save inspect Fetch/XHR requests. Find the row whose Status is 403. A failed preflight OPTIONS request is a different request from the intended POST.
3. Select that row. Under Headers, record Request URL, Request Method, Status Code and the response request identifier, if present. Note the time and timezone.
4. Open Response. Record whether it is a WordPress JSON error, an AJAX response such as -1, a branded block page or a plain server error. A screenshot of the page alone will not reveal this distinction.
5. For an editor failure, record the endpoint and action from Payload without publishing its content, nonce or cookies. Use the response map below to choose the next check.
6. Keep the full record private. Before sharing screenshots or an exported HAR, remove credentials, tokens, personal information and confidential request data. Send the redacted record with the matching server or security event.

For a public GET on a site you manage, this command saves the first response without following redirects. Replace the example URL and use a private working directory.

curl --silent --show-error --connect-timeout 10 --max-time 20 \
  --dump-header response-headers.txt --output response-body.txt \
  --write-out "HTTP %{http_code}\n" \
  "https://example.com/affected-page/"

The curl reference documents these options. An HTTP 403 can still accompany curl exit code 0 because this command does not fail on HTTP error statuses. HTTP 000 means no HTTP response code was obtained. A HEAD request or logged-out GET is not an equivalent test of an authenticated POST. Use dummy content or staging for state-changing tests.

2. Match the response to the denying layer

• A matching firewall event can identify a security rule. Compare timestamp, host, path, method and visitor context.
• A server error log can distinguish an access-rule refusal from a directory-index or file-access problem.
• A WordPress JSON error can identify an application branch. Inspect its error code and the actual account context.
• An origin access-log entry with status 403 records the outcome; it may be reporting an upstream application response.

A Cloudflare header or Ray ID helps correlate a request that passed through Cloudflare. It does not establish that Cloudflare created the refusal. The Ray ID documentation also notes that these identifiers are not guaranteed to be unique. Use supporting request details.

3. Make one reviewable correction

Save the current rule or configuration and the rollback. Identify which legitimate request should pass and which protected request should remain denied. Change the confirmed cause in its actual scope, then retest before changing another setting. If the layer remains unknown, send the incident record below to the host.

How to fix 403 Forbidden as a website visitor

For a website you do not administer, check the address and whether the resource requires a legitimate account or permission. Sign in through the site’s normal process. If an individual page works but a directory URL does not, use the intended page address.

• Try a private window to compare browser state. It is logged out by default, so a different result may reflect authentication.
• If permitted, compare your normal connection with another connection. Record any VPN or network change when reporting the problem.
• Clear site-specific cookies only when session state is a plausible cause and you are prepared to sign in again.
• If access still fails, send the site owner the affected URL, time, action and request identifier.

These checks can identify a context difference. They cannot change a server policy. If your account lacks the required access, ask the owner for the appropriate permission.

How to fix a 403 Forbidden error in WordPress

A WordPress 403 can start in the host, firewall, web server or WordPress itself. First match the failed request to the component that refused it. If the host blocked it before PHP ran, changing plugins will not correct that denial.

If wp-admin or wp-login.php is forbidden

1. Compare the exact login/admin URL with one public page. Record whether the entire admin document fails or only a script or stylesheet. Use the intended account and normal access network.
2. Match the request with the hosting firewall, login-protection or security-plugin event. Check any intended IP restriction, role requirement or managed-host protection.
3. Save the relevant rule. Correct only a confirmed accidental restriction. If you cannot reach the dashboard, use the hosting support route with the request record; a public homepage test is insufficient.
4. Sign in again with the permitted account and perform the original admin action. Repeat a logged-out or lower-permission check to confirm that private access still requires authorization.

If a plugin is the confirmed lead

Prefer correcting its specific setting. For a temporary isolation test, use staging or an agreed maintenance window, record the original activation state and retain a rollback. Do not deactivate every security layer as a first step.

wp plugin list --fields=name,status,version --format=table

This plugin inventory is read-only. A successful isolation test narrows the investigation; it does not prove which setting was wrong. Finish with the intended plugin state, the legitimate action working and the protected control still denied.

Why WordPress or Elementor returns 403 when saving

The editor page and its save operation are separate requests. Inspect the actual POST and response body. Cookie-authenticated WordPress REST requests require the appropriate session, REST nonce and user capability. A missing nonce can make a request unauthenticated. An invalid nonce has a specific documented 403 error path. See REST authentication and the cookie error handler.

On a narrow screen, scroll the table sideways.

WordPress’s AJAX nonce-checking reference documents the default failed check. A nonce is not authorization by itself: the handler must also enforce the required capability. Plugin handlers can behave differently.

For an Elementor save failure, preserve a revision or copy of the work. Repeat a minimal, legitimate save with dummy content on staging when possible. Ask support for the matching POST and denial evidence. Do not make REST endpoints public or disable the entire firewall to solve one action. Success means the intended content was saved and can be reopened.

A complete editor-save retest

1. Copy the unsaved text or preserve the available revision. On staging, use a disposable draft and the same role, editor and endpoint as the failing action.
2. Capture the failing POST response. If it reports rest_cookie_invalid_nonce, preserve that evidence, sign in again through the normal login and reopen the editor so it obtains a current session and nonce.
3. Save one harmless change. Reopen the draft from a fresh page and confirm the exact change persisted. A green notice or status 200 alone does not establish that the right content was saved.
4. If the nonce error returns immediately, ask the developer to trace nonce generation and transmission, session changes and any caching of authenticated editor responses. Do not remove the nonce or capability check.
5. If the response instead names a permission failure, verify the required capability for that specific object and account. If a matching WAF event explains the refusal, correct that rule using the Cloudflare or host branch.
6. On the disposable draft, verify that a logged-out or unauthorized user still cannot perform the protected edit. Record both results and restore the draft/test state.

This is a documented test procedure, not an executed WordPress repair case. Elementor’s publishing guidance also identifies plugin and hosting-firewall conflicts as possible causes; the failed request determines which branch applies.

File permissions, .htaccess and asset-only failures

Confirm which server handles the request. Apache can apply .htaccess files when permitted by its configuration; Nginx does not interpret them. Preserve the original file and correct the rule selected by the evidence. Rebuilding permalink rules is appropriate when those rules are the identified fault. Deleting the entire file can remove unrelated redirects and protections.

For a file-access error, ask the host to confirm the resolved path, serving identity, owner, group and required access through parent directories. WordPress’s permissions guidance depends on hosting context. Directory mode 755 and file mode 644 are common starting points, not universal repairs. Wrong ownership or an inaccessible parent can still fail.

For an image, CSS or JavaScript refusal, inspect that asset’s exact URL and any hotlink, routing or access rule. Correct the identified path or policy, then confirm the actual asset loads. A refusal on the enclosing directory does not establish that every file needs a permission change. Avoid recursive 777 as a troubleshooting shortcut.

How to investigate a Cloudflare 403 error

Start with the response and the matching request evidence. Cloudflare’s 403 documentation covers origin denials and Cloudflare security responses. Branding is a clue, but early unstyled refusals can occur before zone configuration is loaded and may not be logged. A hostname/SNI mismatch is one documented case.

Find and interpret the matching security event

1. Open Security Events for the affected zone and narrow the time window.
2. Filter with the available request details, including Ray ID when present. Compare host, path, method, time and visitor context.
3. Expand the relevant event. Record the security product, rule ID and action. A request may trigger more than one event.
4. If the evidence confirms a false positive, inspect the rule’s scope and the correction supported by that security product.

Save the original rule and intended access policy. Change the identified condition or supported exception, rather than broadly exempting all admin traffic. Retest the original legitimate operation through the normal proxied hostname. Also check an unauthorized action and an unaffected public route. A public GET is not a substitute for the blocked editor POST.

When the event list does not explain the 403

Security Events can be sampled, so absence from a broad search is not decisive. Try a narrower window and inspect origin/hosting logs for the same request. Available history and dashboard features vary by plan.

An authorized comparison with the known origin can help when arranged by the host. Preserve hostname, TLS SNI, path, method and relevant authentication. Browsing a raw IP is not an equivalent test. An origin configured to accept only proxy traffic may deny direct access intentionally.

If the authorized origin request succeeds but the proxied request fails, investigate the edge path; that comparison alone does not name the rule. Keep the proxy protections in place while collecting the evidence.

Turn the event into a specific decision

Cloudflare guidance here describes a reproducible investigation; no account-specific Cloudflare repair or screenshot is claimed. Record the rule and before/after results only after your actual test.

How to fix 403 errors on Apache or Nginx

For managed hosting, request the exact error-log entry and active virtual-host configuration. For a server you administer, inspect the configuration actually serving that hostname and path. A file that is not loaded cannot explain the active request.

On a narrow screen, scroll the table sideways.

The first two Nginx patterns were observed in the isolated test below. The other rows are diagnostic branches, not additional executed tests. Plesk’s admin-asset case documents an Apache AH01630 example; its product-specific repair should not be copied to an unrelated stack.

Apache: check authorization and directory handling separately

Use the effective Require rules for the affected directory or location. For a directory request, compare DirectoryIndex with the deployed files. A missing index with listing disabled can refuse the directory while specific files remain readable. The .htaccess guide explains when per-directory configuration applies.

Nginx: check location, path and upstream behavior

Nginx allow and deny rules are checked in sequence until a match; inheritance depends on whether the current level defines its own rules. Check the actual location. Index processing may internally redirect into another location, and root and alias resolve file paths differently.

These diagnostic commands are for a server you administer. Use the actual binary, configuration path and required privileges. The file path is illustrative.

nginx -t
nginx -T
namei -l /var/www/site/public/index.html

Nginx -t checks syntax and referenced files; -T also prints configuration. Neither confirms the URL works. Keep configuration output private. namei -l shows path components and modes/owners; it does not validate application authorization or every ACL/SELinux condition.

If logs identify an additional security-policy denial, have the administrator correct that specific context or policy. Use the host’s supported activation process after a configuration check, then retest the request and protected controls.

Use this server check order

1. Match the log to the failed hostname, method, path and time. For managed hosting, request the relevant excerpt instead of guessing the server path.
2. Inspect the active virtual host and matched location/directory. On Nginx, -T prints the loaded configuration; on Apache, the host can inspect its active virtual-host and authorization configuration. Keep the output private.
3. For “access forbidden by rule,” identify the specific inherited or local access rule. Correct it only if the requested resource should be accessible to that visitor. Retest a private route too.
4. For “directory index … is forbidden,” compare the intended index file and mapped document root with the deployed files. Restore the index or correct the path when appropriate. A deliberately unlisted directory can correctly remain 403.
5. For a file-system “Permission denied,” inspect every parent component, the serving identity, owner/group, ACLs and any SELinux policy evidence. namei output is an inspection aid, not proof that the worker can access the file. Ask the administrator to correct the exact failing requirement.
6. Validate the changed configuration, activate it through the host’s supported process, and repeat the same request. A syntax check is necessary for a configuration change, but the expected response body and retained protections establish the repair result.

Recorded repair: restore a public file and preserve private access

This isolated Nginx 1.28.0 lab was executed on 7 October 2026. Static files were served on loopback with Host lab.invalid. An exact-location deny rule blocked the intended public file, while a separate rule protected a private file. The public request produced this actual denial record:

access forbidden by rule
request: "GET /public/guide.txt HTTP/1.1"
host: "lab.invalid"

Only deny all inside the exact public location was removed. This is the relevant lab excerpt, not a production configuration to paste into your server.

BEFORE
location = /public/guide.txt {
    deny all;
}

AFTER
location = /public/guide.txt {
}

UNCHANGED PRIVATE CONTROL
location /private/ {
    deny all;
}

Both configuration checks passed. After a controlled stop/start of the isolated server, the same five GET requests were repeated with the same path, host, source, User-Agent and Accept header.

On a narrow screen, scroll the table sideways.

The result demonstrates this scoped Nginx access-rule repair. The fixture used single-process mode under the current root UID, so it does not validate unprivileged worker ownership or Unix permission repairs. It was not a client incident and did not test WordPress, Cloudflare, Apache, TLS, PHP, SELinux or Google crawling.

Inspect the recorded evidence

The expandable records below are from the same 7 October lab. They let you compare the actual change, request log and response fingerprints. Ten responses were captured in one short local run; no sustained-load or recurrence window was tested.

--- before.conf
+++ after.conf
@@ -15,7 +15,6 @@
         root /tmp/scc-403-lab-8j5n5p3n/www;
         autoindex off;
         location = /public/guide.txt {
-            deny all;
         }
         location /private/ {
             deny all;

2026-10-07T17:28:54+08:00 "GET /public/guide.txt HTTP/1.1" 403
2026-10-07T17:28:54+08:00 "GET /private/record.txt HTTP/1.1" 403
2026-10-07T17:28:54+08:00 "GET /health.txt HTTP/1.1" 200
2026-10-07T17:28:54+08:00 "GET /empty/ HTTP/1.1" 403
2026-10-07T17:28:54+08:00 "GET /missing.txt HTTP/1.1" 404
2026-10-07T17:28:54+08:00 "GET /public/guide.txt HTTP/1.1" 200
2026-10-07T17:28:54+08:00 "GET /private/record.txt HTTP/1.1" 403
2026-10-07T17:28:54+08:00 "GET /health.txt HTTP/1.1" 200
2026-10-07T17:28:54+08:00 "GET /empty/ HTTP/1.1" 403
2026-10-07T17:28:54+08:00 "GET /missing.txt HTTP/1.1" 404

{
  "experiment": "One scoped Nginx access-rule correction",
  "run_date_utc": "2026-10-07",
  "platform": "Linux-6.18.44-x86_64-with-glibc2.39",
  "nginx_version_build": "nginx version: nginx/1.28.0\nbuilt by gcc 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04) \nconfigure arguments: --without-http_gzip_module\n",
  "listen": "127.0.0.1:43955",
  "worker_user": "Single-process mode using the current UID (root in this run)",
  "change": "Removed only deny all from the exact public /public/guide.txt location",
  "activation": "Configuration test followed by a controlled restart of the isolated single-process server",
  "request_context": "Same GET method, Host, User-Agent, Accept, source and route in each paired check; no redirects, TLS, authentication or CDN",
  "observations": [
    {
      "phase": "before",
      "method": "GET",
      "path": "/public/guide.txt",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 403,
      "body_sha256": "c48e78e4f96457c62566019c504ee700e63a2408cabe132662d4d08c64657ccc",
      "headers_file": "before-1-headers.json",
      "body_file": "before-1-body.txt",
      "captured_utc": "2026-10-07T09:28:54.782975+00:00"
    },
    {
      "phase": "before",
      "method": "GET",
      "path": "/private/record.txt",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 403,
      "body_sha256": "c48e78e4f96457c62566019c504ee700e63a2408cabe132662d4d08c64657ccc",
      "headers_file": "before-2-headers.json",
      "body_file": "before-2-body.txt",
      "captured_utc": "2026-10-07T09:28:54.785042+00:00"
    },
    {
      "phase": "before",
      "method": "GET",
      "path": "/health.txt",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 200,
      "body_sha256": "b3481939e70c2c1a1c101f5c86787b9832525fd890b4cb13088f49c885ec1c58",
      "headers_file": "before-3-headers.json",
      "body_file": "before-3-body.txt",
      "captured_utc": "2026-10-07T09:28:54.787688+00:00"
    },
    {
      "phase": "before",
      "method": "GET",
      "path": "/empty/",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 403,
      "body_sha256": "c48e78e4f96457c62566019c504ee700e63a2408cabe132662d4d08c64657ccc",
      "headers_file": "before-4-headers.json",
      "body_file": "before-4-body.txt",
      "captured_utc": "2026-10-07T09:28:54.788447+00:00"
    },
    {
      "phase": "before",
      "method": "GET",
      "path": "/missing.txt",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 404,
      "body_sha256": "c375e42b6328de1880de1424a93267d573a1afa2ed37f72a35d8218f6880dd58",
      "headers_file": "before-5-headers.json",
      "body_file": "before-5-body.txt",
      "captured_utc": "2026-10-07T09:28:54.789504+00:00"
    },
    {
      "phase": "after",
      "method": "GET",
      "path": "/public/guide.txt",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 200,
      "body_sha256": "0928bfb9c235528013342be3caa6de4675475d27824c78635e99f02dc4e97980",
      "headers_file": "after-1-headers.json",
      "body_file": "after-1-body.txt",
      "captured_utc": "2026-10-07T09:28:54.845559+00:00"
    },
    {
      "phase": "after",
      "method": "GET",
      "path": "/private/record.txt",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 403,
      "body_sha256": "c48e78e4f96457c62566019c504ee700e63a2408cabe132662d4d08c64657ccc",
      "headers_file": "after-2-headers.json",
      "body_file": "after-2-body.txt",
      "captured_utc": "2026-10-07T09:28:54.846411+00:00"
    },
    {
      "phase": "after",
      "method": "GET",
      "path": "/health.txt",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 200,
      "body_sha256": "b3481939e70c2c1a1c101f5c86787b9832525fd890b4cb13088f49c885ec1c58",
      "headers_file": "after-3-headers.json",
      "body_file": "after-3-body.txt",
      "captured_utc": "2026-10-07T09:28:54.848511+00:00"
    },
    {
      "phase": "after",
      "method": "GET",
      "path": "/empty/",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 403,
      "body_sha256": "c48e78e4f96457c62566019c504ee700e63a2408cabe132662d4d08c64657ccc",
      "headers_file": "after-4-headers.json",
      "body_file": "after-4-body.txt",
      "captured_utc": "2026-10-07T09:28:54.849656+00:00"
    },
    {
      "phase": "after",
      "method": "GET",
      "path": "/missing.txt",
      "host": "lab.invalid",
      "client": "127.0.0.1",
      "status": 404,
      "body_sha256": "c375e42b6328de1880de1424a93267d573a1afa2ed37f72a35d8218f6880dd58",
      "headers_file": "after-5-headers.json",
      "body_file": "after-5-body.txt",
      "captured_utc": "2026-10-07T09:28:54.850416+00:00"
    }
  ],
  "configuration_checks": [
    {
      "check": "before configuration test",
      "passed": true
    },
    {
      "check": "after configuration test",
      "passed": true
    }
  ],
  "scope_limit": "Local static-file access rules only. Not a client incident or a WordPress, Cloudflare, TLS, SELinux, ownership, PHP or Google crawl test.",
  "passed": true
}

For a reproduction, build a disposable loopback-only Nginx fixture with a public file, a separately denied private file, a healthy file, an unlisted directory and a missing path. Capture all five responses, remove only the public location’s accidental deny directive, validate/activate the isolated configuration and repeat the five requests. Record your environment and results as a new test; do not apply this lab’s root-user setup to production.

How to verify that the 403 fix actually worked

Define success for the original operation. A public page needs its intended content; an editor action needs the intended saved result. A 200 login screen or error page is not proof that the problem is fixed.

On a narrow screen, scroll the table sideways.

If the source is corrected but an old response persists, inspect the relevant browser, page or edge cache and its response headers. Clear the relevant cache when appropriate, then retest. Cache clearing cannot repair a rule that still refuses the request. Record the change and the actual result together.

Fix “Blocked due to access forbidden (403)” in Search Console

First decide whether the URL should be public. An account page may properly deny Google. A public article, product or category should be investigated when Google receives 403. The Page indexing report describes a recorded result, which may differ from the response served now.

For normal content URLs, Google’s HTTP-status documentation says that 4xx responses other than 429 are treated as unavailable content; previously indexed URLs returning them can be removed. Do not use 401 or 403 to throttle crawling. A restored 200 makes content available for processing; it does not guarantee indexing.

Verify the request before changing a bot rule

Correlate the affected URL and time with host/firewall logs. A Googlebot User-Agent string is not identity proof. Use Google’s verification methods for the relevant crawler or fetcher class, including the documented IP ranges or reverse-and-forward DNS checks. An exception for Google-InspectionTool does not establish ordinary Googlebot access.

Compare current access with recorded indexing evidence

After the confirmed repair, use URL Inspection in the verified property. Keep the live test and stored indexing result distinct. Inspect the returned content, not only a successful response.

On a narrow screen, scroll the table sideways.

Check affected rendering assets and sitemap requests separately. robots.txt has different fetch rules: Google treats a robots.txt 403 as though no valid robots file exists and assumes no crawl restrictions. This is different from a public content URL returning 403.

For a wider set of access failures, follow the crawl-error workflow. If intended access is restored but inclusion remains unresolved, move to indexing diagnosis. Access recovery, indexing and search performance are separate checks.

Copy this incident record for your host or developer

Complete one record for each failing request pattern. Remove cookies, authorization headers, tokens, personal data and confidential query values from shared copies. Retain full evidence only in the approved private incident system.

403 ACCESS INCIDENT
Time and timezone:
Hostname, path and HTTP method:
Action attempted and expected result:
Visitor role, login state and affected network:
Scope: public site / admin / save / asset / crawler:
Response status, error code and request or Ray ID:
Matching firewall/server/application evidence:
Recent relevant change:
Confirmed denying layer and reason:
Original rule/configuration and rollback:
One correction and activation time:
Original operation retest and expected result:
Unaffected public route result:
Private/unauthorized control result:
Cache/context checks and untested cases:
Owner and follow-up date:

Ask support to identify the layer and rule or path that refused this exact request, then propose the smallest correction that restores intended access. Include the time and request identifier so the relevant record can be located.

403 Forbidden FAQ

The one thing to do next

Capture one failing request and match it to the denial evidence before changing another setting. If public pages or verified Google requests remain blocked, bring the redacted incident record to SearchCounselCo’s technical SEO service so the access problem and affected search URLs can be assessed together.