NewTry MagicWP now - first month free
WordPress troubleshooting

403 Forbidden on a WordPress site

The request was understood and refused. The refusal came from the web server, a firewall or a permissions rule — WordPress is rarely involved.

403 Forbidden — You don't have permission to access this resource.

Short answer

Note whether the whole site 403s or only some URLs, and whether it follows you or only affects one network. A site-wide 403 is nearly always file permissions or a rewrite rule; one that follows a single person is an IP block.

Diagnosis

What causes it, most likely first.

Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.

CauseHow to checkFix
File or directory permissions the web server cannot readThe error is site-wide and constant. Directories should be traversable and files readable by the web server user; anything more restrictive produces exactly this.Set directories to 755 and files to 644, owned by the user PHP runs as. A restore from a backup taken on a different host is the usual reason they drifted.
A security plugin has blocked your addressOther people can use the site normally and a different network works for you too. The plugin's log records the block with your address and a reason.Clear the block from the plugin's own list, then raise the threshold that triggered it. Repeated failed logins are the most common trigger.
A rewrite or access rule denies the pathOnly certain URLs fail — wp-login.php, wp-admin, xmlrpc.php — while the rest of the site is fine.Find the deny rule in the server configuration or .htaccess. Hardening snippets copied from a tutorial are the usual source, and they often restrict more than intended.
The index file is missing or not listedA directory URL 403s where a file URL in the same directory works. The server is refusing to list a directory that has nothing to serve as default.Restore the missing index file, or confirm the document root points where you think it does. A misdirected root looks exactly like a permissions problem.
Walkthrough

Fixing it, step by step.

Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.

  1. Establish the shape of the failure

    Site-wide or one path; everyone or only you. Those two answers remove most of the list before any command is run.

    curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
    curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/wp-login.php
  2. Read the server's own explanation

    A 403 is nearly always logged with a reason, and the reason names the layer that refused.

    tail -n 50 /var/log/nginx/error.log
  3. Reset ownership and permissions

    Directories traversable, files readable, both owned by the PHP user. Run from the site root.

    find . -type d -exec chmod 755 {} \;
    find . -type f -exec chmod 644 {} \;
  4. Take .htaccess out of the equation

    Rename it rather than editing it, so you can put it back unchanged. WordPress rewrites a fresh one on request.

    mv .htaccess .htaccess.bak
    wp rewrite flush --hard
  5. Confirm from a different network

    If the site answers from elsewhere while still refusing you, it is an address block and no amount of permission changing will help.

    curl -sS -o /dev/null -w '%{http_code}\n' --interface eth1 https://example.com/
On MagicWP

What the platform takes off the list.

File ownership is set to the site's own user at deploy and kept that way by the platform, so the permission drift that follows a manual restore does not happen here. Blocking is done at the edge rather than by a plugin inside WordPress, which means a blocked address never reaches PHP and, just as usefully, an administrator who locks themselves out can be let back in without database access.

FAQ

Questions, answered.

Why can everyone else use the site while I cannot?
Because the refusal is tied to your address rather than to the site. A security plugin or firewall added you to a block list, usually after repeated failed logins, and the block follows your network rather than your account.
Should I set permissions to 777 to test it?
No. It rarely fixes a genuine 403 and it makes every file writable by anything running on the machine, which converts a broken page into an exploitable one. 755 and 644 with correct ownership is the target.
The 403 only appears on wp-admin. What does that suggest?
A deliberate access rule rather than a fault. Somebody restricted the admin path by address or added authentication in front of it, and the restriction outlived whoever added it.
How is a 403 different from a 401?
A 401 asks for credentials and will accept them. A 403 has already decided, and sending credentials does not change the answer.
Related

If that was not it.

These fail in ways that look similar from the browser.