WordPress 403 error on a public path: find the blocking rule

Confirm that the path really should be public

The homepage works, but a page, image or download returns 403 Forbidden. This status means the request was understood and refused. By itself it does not prove a file is missing, a password is wrong or an attacker was detected. The denial may come from the application, server or a protection layer in front of it.

Start by naming the resource that should be accessible and to whom. A published visitor-facing page is not handled like a private export or technical-files directory. A directory may deliberately refuse listing while its public files remain readable. Eliminating every 403 is therefore not a sufficient goal.

This guide targets a path whose public access has been confirmed by the owner. It offers three routes without a new plugin: check application access, repair the path’s serving configuration or correct a specific security rule. If denial affects only an administrative action after login, continue with the permissions guide rather than opening that path to the public.

Prepare a record and rollback suited to the intervention

Keep a private copy of the exact address, message and time with its time zone. Remove tokens and personal data from the support version. Record the last known change: migration, new rule, access change or file transfer. Also choose a nearby working public path for comparison.

Reading a page does not require a full backup beforehand. Before changing a rule or permission, record its value and retain the affected file outside the public directory. If broader restoration may become necessary, verify that the backup covers files and database and how recent data will be preserved.

The procedures below distinguish access requirements: an authorized editor for a page, hosting account for a file, security administrator for the firewall. Do not perform a route for which you lack the intended access. You can still make browser observations and send a targeted request.

Read the denied request in the browser

Required access: a browser with developer tools, without a technical account. The goal is the URL actually receiving 403. A correctly displayed page may contain a denied image or API call; correcting the main page would then be pointless. Do not repeat an order or payment to obtain this evidence: observe the request already recorded.

If reading succeeds in private browsing but fails in your session, keep that difference for diagnosis. Do not delete all cookies at this stage. This route is read-only: close the tools to return to your usual display.

1. Open the affected page, then developer tools through the browser menu or F12 depending on your device.
2. Select Network, clear only the displayed request list if needed, then reload the read-only page once.
3. Find the row with status 403. Open it and record Request URL, Request Method and Status Code from the headers.
4. Record any redirect destination and displayed request ID. Do not copy Cookie or Authorization.
5. Open the reference path, then compare the same denied path in a private window. Keep both results.

Check a read with curl if you have a terminal

This optional check suits readers who already have curl. It requires neither SSH nor a plugin installation. On an authorized copy, replace the fictional address with the public test path’s URL, then run only the line matching your system. The command performs a GET read, displays headers and discards the body; it does not modify site files.

The expected result is a first line showing HTTP status. If you get 301 or 302, inspect Location before separately testing that known destination. Not automatically following redirects helps retain the first denial. Protections may treat curl and a browser differently: a discrepancy is evidence to share, not proof that the firewall should be disabled.

This command does not reproduce a POST form, logged-in session or JavaScript validation. Do not add a password or copied cookie. Keep headers private, particularly Set-Cookie. No rollback is needed; if curl is unavailable, use the previous section’s browser procedure.

The --disable option must remain the first argument to curl or curl.exe. It ignores the personal curlrc file to retain the first response, even if that file normally enables redirect following. Explicitly supply the network and certificate parameters required by your environment.

# macOS ou Linux : une seule lecture publique
curl --disable -sS -D - -o /dev/null "https://site.example.test/guide-public/"
# Windows PowerShell : choisir cette ligne à la place
curl.exe --disable -sS -D - -o NUL "https://site.example.test/guide-public/"

Choose one of the three routes according to the evidence

The first route examines the application when denial depends on content, public status or a route declared by a component. It is particularly suitable when an administrator can view the resource but visitors cannot. Confirm the expected setting before touching a server rule.

The second examines the server when logs report a missing index, file permission, incorrect owner or access rule. It must target the precise path and configuration actually in use. A working homepage does not rule out an inherited restriction in a subfolder.

The third addresses a security event correlated with the legitimate request. It requires identifying the rule and reducing only its incorrect scope. Attribution to a rule requires evidence beyond status 403 alone. If evidence conflicts, keep the observation record and have the cause clarified before combining all three types of change.

Approach 1: restore a page’s authorized visibility

Choose this route if a specific page is intended for everyone but remains restricted to some users. Required access: permission to edit and publish this content. The expected result is the correct page visible without login, with a normal response; private or protected states do not always return 403, hence the importance of confirming the real setting.

If the page is already publicly published and still denied, do not change its slug or date. Move to the component or layer identified in logs. Rollback: restore the status and protection recorded before testing, then save. Publication must concern only content whose public opening is actually authorized.

1. Open Pages, then All Pages, search for the title and click Edit. For a post, use Posts.
2. In the block editor, open Settings at the top right, then the Page or Post tab rather than Block.
3. Record the current status. Open Status; depending on the version, this group may be called Status & Visibility. Choose the intended published and public state, removing only an incorrect protection.
4. Click Save, Update or Publish depending on the initial state and confirm if asked. In the classic editor, the setting is in the Publish box beside Visibility.
5. Copy the published link and open it in a private window. Compare status and content with the initial record.

If a component protects the page, correct its rule rather than the entire API

A public page may remain blocked by a membership, download or security rule added by a component. Required access: its settings or an administrable test copy. Under Plugins, then Installed Plugins, identify the tool actually providing the path; use its Settings link and look for the page or content assignment. Record the rule before changing only that assignment.

The expected result is access to the chosen public content while restricted content stays protected. If the tool cannot cleanly limit this change, reproduce it on a copy and use its current documentation rather than disabling all production plugins. Restore the original assignment if denial persists.

For a REST route, give the maintainer the recorded URL and method. They must correct the client or that route’s permission check; a public page may call an operation requiring an identity. Replacing every check with general authorization would expose other actions without properly resolving the cause.

Approach 2: find the folder and repair the intended entry point

This route applies when a log indicates a missing index or unexpected folder. Required access: the domain panel and its file manager. A folder without an index may refuse listing while correctly serving public files. The goal is to serve the intended page without enabling display of every file.

Expected result: the homepage or page URL reaches its real entry point. If the folder belongs to another application, do not replace it: have the domain association corrected or replacement prepared. Rollback: restore the destination path or only the restored file from its private copy.

1. In the hosting panel, open the exact domain and record its root folder. Do not infer this folder from the site’s public name.
2. Open that folder in the manager and look for the intended index file, generally index.php for a standard WordPress installation.
3. If the index disappeared after an identified intervention, restore that file alone from a reliable backup of the same installation. For a standard installation, an official archive matching the installed version may supply the original; preserve any current file before replacement.
4. If core is separate in a subfolder, use its specific procedure: the root index must load that core. Do not copy a standard index without adapting its path.
5. Reopen the path in the browser. If only the technical directory remains forbidden while public files work, retain that protection.

Correct a public file’s permissions in cPanel

Required access: cPanel and File Manager, for files you are authorized to manage. Choose this route if the log confirms a permission problem after a transfer. It fixes neither a WAF rule nor an incorrect owner. On a site deployed through Git or an automated system, correct the artifact or deployment procedure rather than its output manually.

Limited example: a public image is set to 0600 while this hosting policy expects 0644 for that file type with the correct owner. Expected values must be established before changes; 0644 is not a prescription for every file or folder. Expected result: the image becomes readable by the server. If this fails, restore the old value and examine ownership or the access rule.

1. In cPanel, open Files, then File Manager. Go to the folder containing the file whose URL receives 403.
2. Select only that file, then Permissions in the toolbar. Record the displayed value.
3. Enter the value expected by the configuration, for example 0644 in the limited case described, then click Change Permissions.
4. Reload the image’s exact URL and check its status. Do not rely solely on the manager preview.
5. Apply neither 777 nor a recursive operation. To undo the test, select the same file and restore its recorded value.

Check which server rule protects the path

If the Apache log indicates a restriction for the public PDF, ask the authorized maintainer to locate the rule actually applied to its folder and filename. The .htaccess file is one possible source. A server setting or deployment tool may also cause the denial. Compare the resolved disk path with the requested URL. Record the configuration file or deployment source and rule context without republishing a copy that may contain secrets.

The team must confirm the PDF is intended for the public and determine why the rule classifies it as restricted. On a copy, they can correct that classification in the authoritative configuration while keeping a dated version of the initial state. Check that the requested document becomes readable again and that a neighboring document requiring restricted access retains its control. If the result differs, have the configuration returned to its starting version before another test.

Approach 3: identify the Cloudflare rule that blocked the read

Required access: viewing the domain’s security events in Cloudflare. Use this route if the site actually passes through that service. Expected result: a rule and action associated with your precise test. The status or logo alone is insufficient. Some early denials may also be absent from this view; retain origin logs to supplement it.

This consultation is read-only and requires no configuration rollback. If nothing matches, check the period, domain and filters: some logs are sampled and events do not represent every request. Attribution remains unconfirmed without a visible row.

1. Select the affected domain in Cloudflare. Open Analytics, then the Events tab according to the current interface.
2. Set the period around the recorded time. Use Add filter to narrow by path, host or available ID, then Apply.
3. Open the matching event and record the action, product, ruleset and rule ID.
4. Confirm that path, method and context match the legitimate read. Another request at the same time is not evidence.
5. Send the record to the team authorized to change the rule. They can confirm its scope before preparing a correction on a copy.

Have the authorized team correct the overly broad rule

Prepare a ticket with the public URL, read method, time with time zone and request ID. Add the correlated event, issuing product, observed action and rule ID when available. State who confirmed the resource is public. Provide a working reference path and one whose protection must remain active. If the log cannot link the 403 to the rule, first ask the team to confirm attribution.

Ask the configuration owner to verify the rule’s intent and scope. For a custom rule, the team can correct the criterion wrongly including a public resource. For a managed rule, pass the evidence to the protection owner or publisher to classify the false positive and choose a supported correction. Have the change checked on a copy before any application decision. The check must cover the intended public path and resources remaining restricted.

Agree on the results to review with the team: a normal response on the public path, expected content, retained control on the restricted path and consistent logs. Keep the previous configuration in the change process. If a reference fails, the team restores the last validated version and resumes attribution. This route repairs the rule at its responsible layer.

Check the current response before purging caches

After correction, distinguish a new response from an old display. Reload in an appropriate session, inspect status and destination, then ask the provider whether it finds the new request and its result. A browser retaining an old page provides different evidence from a denial still produced by the server.

Do not automatically attribute 403 to Cloudflare cache: this status is not among responses cached by default. Custom rules or other layers may nevertheless change behavior. Examine the effective policy, headers and caches present before deciding a purge is useful.

If an old response really is retained, purge the affected path or layer, then repeat the same read. Repeated global purges do not repair a permission or rule still denying the request. If only a logged-in session works, revisit context differences and access rules rather than considering the repair complete. Document the level where the result changed.

On WordPress.com or a network, use available settings

On WordPress.com, an administrator can open Settings, then Reading and Site Visibility. Record Public, Private or Coming Soon status. If public launch has been authorized and the state is wrong, choose Public, then Save Changes. Check in a private window afterward. To roll back, restore the recorded state; do not open a confidential site solely to remove a message.

This global setting does not necessarily repair an isolated public file. If only that file receives 403, send its request to managed-environment support. Apache or Cloudflare rules are editable only if you actually manage those layers.

In Multisite, tell the super administrator which site and path are affected. A network rule may exceed your scope. A user able to edit their page retains that local operation; a shared-rule change must be performed in the intended network context.

Validate the correction and undo only the faulty change

Reuse the URL, method and context recorded at the start. Success means obtaining the right content for the intended audience; a general redirect to the homepage does not replace that content. For a form, use a planned test case that does not trigger an unintended real payment or send.

If the check fails or opens access too broadly, restore the original WordPress status, permission or file, or ask the owner to restore the previous configuration according to the route taken. Do not chain further changes before this rollback.

1. Open the resource as a logged-out visitor and check its status in Network.
2. Open the public reference path and a resource required by the page; confirm they work.
3. With the owner, check a prepared case that must stay protected without trying to display real private data.
4. After correcting a rule, find the new request in available logs and confirm expected behavior.
5. Keep the time, changed setting and results. A global database restoration requires a separate plan preserving new orders and registrations.

When access is missing, send an actionable request

Give the owner the available domain, path, method, time and request ID. Add the working reference path and observed difference between visitor and logged-in account. Request a targeted check: file owner and permission, folder entry point or triggered rule ID.

This escalation is useful after accessible actions, or when required logs and settings are unavailable to you. It does not replace reading Network, checking visibility or correcting a file you can actually manage. Send only sanitized excerpts through the appropriate private channel.

Then retain the confirmed reason and correction. If a rule or permission returns after every deployment, correct its source in that deployment. Repeating the same manual adjustment without examining what recreates it leaves the failure ready to return.

Reconstruct a denial from two fictional logs

On a copy, prepare three paths with known roles. In the test, /guide-public/ must be readable, /aide/ is the public reference and /guide-public/interne/ must stay restricted. Record the first HTTP status of each read, then look for the matching event in the producing layer’s log. Here, response reference REC-001 links the first 403 to fictional rule REGLE-LECTURE-042. The restricted path also returns 403 with a different application event. The two denials therefore require two different decisions.

In your authorized logs, start with the available ID, then confirm time, host, method and path. If the protection log has the event but the request is absent from the origin log, it may have been blocked before reaching the server. Also check log coverage before concluding. A status, logo or row from the same minute does not alone identify the responsible rule. On the live site, start with requests already observed and existing records.

Confirm the correction and retained control on a copy

On the copy, have the public path’s classification corrected, then verify a normal response and expected content. The public reference must keep working and the restricted path must remain denied for the same application reason. Restore the test configuration to confirm return of the first denial. This protocol requires no changes to a real protection service.

Agree on these checks before the change. Success must include the expected legitimate response and content, along with the control that must remain. If the page opens but the restricted reference becomes visible, stop the test and request restoration of the retained configuration. If logs do not agree after modification, keep the new IDs and resume attribution with the responsible team.

If only a file embedded in another page receives 403

When an image opens directly but fails when embedded, also investigate protection against media use from other sites. A hotlink protection rule may consider the referrer and produce a denial different from a file-permission issue. Record the embedding page, resource address and failure context; do not fabricate a header to bypass the rule.

The owner checks whether the page’s domain, its www variant or the test domain belongs to authorized uses. On the copy, they correct only this scope when wrong, then compare legitimate embedding with a reference that must remain denied. Keep the previous value for undo. A successful direct opening does not justify disabling protection globally, and WordPress administrator access does not automatically grant control over that server or CDN rule.