Why is my website saying 403 Forbidden? How to find and fix the cause

What a 403 Forbidden actually means

Every HTTP response carries a three-digit status code. A 403 Forbidden is a client error, but on your own site the word client is misleading: the server found, or could have found, the thing you asked for and has refused to hand it over. That is different from a 404 Not Found, where the server says nothing exists at that address, and from a 401 Unauthorized, where the server asks you to log in and will try again if you send credentials.

A 403 is the server saying no without offering a way in. The refusal comes from one of three layers, and knowing which layer answered is most of the fix:

• The operating system. The web server process asked to read a file or enter a folder and the system said permission denied. The server turns that into a 403.
• The web server configuration. A rule in nginx, Apache, .htaccess or the Plesk panel says this path, this IP address or this kind of request is not allowed.
• A security layer in front of or inside the site. Cloudflare, another CDN, ModSecurity, a hosting firewall or a WordPress security plugin decided the request looked dangerous.

The page that comes with the code often gives the layer away: a plain page with nginx or Apache underneath came from the web server, and a branded page with a Ray ID came from Cloudflare.

The common causes and what each one looks like

Most 403s on small business sites come from a short list. The table pairs each cause with the clue that usually points to it, so you can start with the most likely one.

If the 403 only affects some visitors, the cause is almost never file permissions. Permissions apply to every request equally. A 403 that depends on who is asking, from where or with which tool points at a rule or a firewall.

How to diagnose it before changing anything

Start by reproducing the 403 with a tool that shows the raw response. curl works on every system and shows the headers the browser hides:

curl -sI https://www.example.com/about/
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://www.example.com/about/

Compare the two. If the normal request returns 200 and the Googlebot one returns 403, something is filtering on the user agent. Look at the server header too: cloudflare means the answer may have come from the edge, and a cf-mitigated: challenge header means Cloudflare served a challenge page, which also carries a 403 status.

Read the error log

The error log almost always names the reason. On a typical Linux server the logs live in /var/log/nginx/error.log or /var/log/apache2/error.log. On Plesk each domain has its own under /var/www/vhosts/system/example.com/logs/, with error_log for Apache and proxy_error_log for the nginx layer in front of it.

sudo tail -n 50 /var/log/nginx/error.log
sudo grep -i "forbidden\|denied" /var/www/vhosts/system/example.com/logs/error_log | tail -n 20

Check permissions along the whole path

The web server needs execute permission on every folder from the root down, and read permission on the file. One closed folder blocks everything beneath it, so check the full chain rather than the file alone:

ls -l /var/www/example.com/public/
namei -l /var/www/example.com/public/about/index.html

namei -l prints the owner and mode of each component, which makes a drwx------ folder halfway up the path easy to spot. If the error log stays silent while visitors see a 403, the request never reached your server, and the firewall in front of it is the place to look. Our guide to 403 errors in audits covers the case where only an audit tool or crawler is blocked.

The server changes that fix it

Permissions and ownership

The safe default for a normal PHP or static site is 644 for files and 755 for folders, owned by the account the site runs as. Set them in two passes so folders and files get the right modes:

sudo chown -R siteuser:siteuser /var/www/example.com/public
sudo find /var/www/example.com/public -type d -exec chmod 755 {} \;
sudo find /var/www/example.com/public -type f -exec chmod 644 {} \;

Keep stricter modes on files that hold secrets, such as wp-config.php, which many hosts set to 600 or 640 when PHP runs as the site user. Never fix a 403 with 777. It hides the real problem and lets any process on the server change your files.

nginx

Check that root points at the folder that holds the site, that an index line lists the files you use, and that no broad deny catches public paths:

server {
    server_name example.com www.example.com;
    root /var/www/example.com/public;
    index index.html index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # Blocks hidden files such as .git and .env, but not the /.well-known/ folder
    location ~ /\.(?!well-known) {
        deny all;
    }
}

A rule written as location ~ /\. { deny all; } without that exception also blocks /.well-known/, which breaks certificate renewals and some verification files. After any edit, run sudo nginx -t before sudo systemctl reload nginx.

Apache and .htaccess

On Apache 2.4 the access rules are Require lines; older Order, Allow and Deny lines still appear in old files. A leftover block like this denies everything in its folder:

<IfModule mod_authz_core.c>
    Require all denied
</IfModule>

Rename .htaccess to .htaccess-off for a minute and reload the page. If the 403 disappears, put the file back and comment out blocks with # one at a time until you find the culprit. A missing DirectoryIndex index.php index.html line, or Options -Indexes on a folder with no index file, causes the folder-only 403. For redirect rules in the same file, see fixing redirects on Apache.

Cloudflare, ModSecurity and security plugins

If the origin log shows nothing, the 403 was decided before the request reached you. In Cloudflare, open the security events log for the domain (under Security, then Events, in most dashboard layouts) and filter by the path or your IP address. Each event names the service that acted, such as a custom rule, a managed rule, Bot Fight Mode, rate limiting or an IP access rule, along with the action taken.

• Custom rules and IP access rules. Country blocks and broad user agent blocks are the usual offenders. Narrow them to the paths that need protecting, such as a login page.
• Managed rules. A false positive on a form or a long query string can be handled with an exception for that one rule and path rather than switching the rule set off.
• Bot Fight Mode. It challenges traffic that looks automated, including monitoring services and some legitimate tools. On the free plan it cannot be bypassed per path, so turn it off if it is catching traffic you need.
• Search engines. Cloudflare treats verified crawlers such as Googlebot as known bots. A custom rule that skips or allows requests where cf.client.bot is true keeps them out of your own blocks.

On the server, ModSecurity writes the rule ID into the error log; in Plesk you can switch a single rule off under Web Application Firewall rather than disabling protection. WordPress plugins such as Wordfence or iThemes Security keep their own block lists and live traffic views, and a plugin lockout often names itself on the 403 page. For crawlers specifically, the AI crawler access guide shows how to let the bots you want through while still blocking the rest.

A worked example

A small agency moves a client's brochure site to a new VPS, uploads the files with a new FTP client while logged in as root, and the whole site starts returning 403. The home page, the CSS and the images all fail, and the page shows a plain 403 Forbidden with nginx underneath, so the firewall is ruled out straight away.

$ sudo tail -n 3 /var/log/nginx/error.log
... open() "/var/www/client/public/index.html" failed (13: Permission denied)
$ ls -l /var/www/client/public | head -n 4
-rw------- 1 root root  8412 Oct 17 09:12 index.html
drwx------ 2 root root  4096 Oct 17 09:12 images

The files are owned by root with mode 600, and the folders are 700, so the www-data user nginx runs as cannot read or enter anything. Running the chown and two find commands from the section above restores normal ownership and modes. The next request returns 200, and a fresh URL Inspection live test in Search Console confirms Google can fetch the home page again. The agency also sets the FTP client to upload as the site user, so the problem does not come back with the next upload.

The fix, step by step

Edge cases worth knowing

• SELinux. On Red Hat style servers, files can have perfect permissions and still be denied because their security context is wrong, often after moving them from a home folder. ls -Z shows the context, and restorecon -R on the web folder resets it.
• Only POST requests fail. Contact forms or checkouts returning 403 while pages load fine usually point at a WAF rule or a security plugin reacting to the submitted content, or a failed security token in the application.
• Only one country fails. Check country rules in Cloudflare and in the hosting firewall. Remember that Googlebot mostly crawls from the United States, so blocking that country blocks most of Google's crawling.
• Admin area only. Plesk password-protected directories, an .htpasswd rule or a plugin that limits /wp-admin/ to certain IPs will refuse anyone outside the list, including you on mobile data.
• Behind a CDN, a 403 from the origin can be cached. Purge the CDN cache after fixing the origin, or the edge may keep serving the old refusal.

Keeping it fixed

Most 403s come back for the same reasons they appeared: files uploaded as the wrong user, a copied server block, or a new firewall rule. A few habits stop that:

• Deploy as the site user, not root.
• Test new firewall and WAF rules in log or simulate mode before switching them to block, where the service offers that option.
• After any server move or configuration change, request the home page, one inner page, a CSS file and an image with curl -I, both normally and with a crawler user agent.
• Watch the Page indexing report in Search Console for Blocked due to access forbidden (403), which lists the URLs Google was refused.
• Run a regular crawl so that new 403s show up before visitors find them. The HTTP error audit guide explains how to read the results, and HTTP errors on Plesk covers that panel in detail.