403 Forbidden error: What does access denied mean, why does it happen, and how do you fix it?

What should you do if you see a 403 error as a visitor?

What visitors can do is limited; 403 is the server’s decision and only the site owner can apply a lasting solution. Nevertheless, a few simple checks can show whether the block is specific to the person.

The first check is the address itself: if a directory address lacks a filename at the end or the address was copied incorrectly, the server may refuse access to that folder. Then open the page in a private window; an old session cookie may cause confusion on pages requiring login. If using a VPN, proxy, or corporate network, disable it and try mobile data. If a shared IP address was previously abused, the security layer may block everyone coming from that address.

If the problem persists, send the site owner the full address, time, and screenshot; include any reference number displayed on the error page.

Diagnosis for site owners: How do you find the source of a 403?

A 403 Forbidden error is diagnosed by progressively narrowing down whom, which address, and which layer the block affects. When a 403 report arrives in our maintenance process, we follow this sequence:

1. Scope: Is the entire site, only wp-admin, a single file or folder, or only images affected?
2. Who is affected: Everyone, a particular country or network, only logged-in users, or only bots? Test from a different network and a private window.
3. Timing: On what day did the error begin; was there a plugin update, site migration, SSL or CDN change, or a new security setting that day?
4. The appearance of the error page: Is it a server, CDN, or WordPress page? This determines the layer to investigate.
5. Server logs: Look for lines returning 403 in the access log and, where available, the ModSecurity rule ID in the error log.
6. Security and CDN records: Check the security plugin’s blocked request list and the CDN’s event logs.
7. Testing while bypassing the CDN: Temporarily pause the CDN; if the error disappears, a CDN rule is the source; if not, examine the server side.

If 403 appears only on the login screen, the Unable to log in to the WordPress admin panel guide’s steps are also applied alongside these checks.

How do you fix a WordPress 403 Forbidden error?

WordPress 403 Forbidden problems are usually resolved in four areas: file permissions, .htaccess rules, security plugin settings, and directory structure. Back up files and the database before every intervention; make changes individually so you know which one produces a result.

Correcting file and folder permissions

WordPress’s File permissions documentation recommends 755 or 750 for folders and 644 or 640 for files. According to the same documentation, wp-config.php should be 440 or 400 to prevent other server users from reading it. It also explains that files should generally belong to the site’s FTP account; if ownership changed to another user after migration, 403 may persist even when permission values look correct. After changes, separately verify that the website and uploads work.

Regenerating the .htaccess file

Back up .htaccess in the root directory and temporarily rename it, for example .htaccess-eski. If the site opens, the problem is in this file; then click “Save Changes” under Settings › Permalinks. WordPress’s Permalinks documentation states that WordPress writes its own rules if the file is writable; otherwise, it displays rules that must be added manually. Review redirect and security lines in the old file individually and restore those needed.

Servers using Nginx do not read .htaccess; access rules are in the server configuration.

Checking the security plugin and WAF rule

For security-layer blocks, the aim is to find the rule generating the false alarm rather than disable protection. The checking sequence is as follows:

• If the panel is accessible, examine the plugin’s blocked request log and allowlist the administrator’s own IP if needed.
• If the panel is inaccessible, temporarily rename the security plugin folder under wp-content/plugins; if the site opens, review settings individually and restore the folder name.
• For a ModSecurity block, identify the rule ID in the error log and define an exception only for that rule.
• On the CDN side, temporarily disable recently added bot, country, and rate-limit rules and test them individually.

Checking the index file and upload directory

If index.php is missing from the root directory or site files were uploaded into a subfolder instead of the main folder, the homepage may return 403. After a new installation or migration, check that files are in the correct directory.

What happens to SEO if a firewall blocks Googlebot with 403?

Googlebot does not use the content of a page returning 403; if the page was already indexed, it may be removed from the index. This effect also applies when the block affects only bots, and because the site owner sees everything working normally in a browser, the problem may remain unnoticed for weeks.

Google’s HTTP status codes and network errors documentation states that content from URLs returning 4xx is not used and previously indexed URLs are removed from the index. The same documentation asks that 401 and 403 not be used to limit crawling; 4xx codes other than 429 do not affect crawl rate. Trying to slow bots with 403 is both ineffective and risks removing pages from the index.

Google’s Page indexing report documentation defines a separate row for 403. It explains that 403 means credentials were provided but access was denied, while Googlebot never sends credentials and the server is returning this error incorrectly. Typical scenarios in which Googlebot receives 403 are as follows:

• Country blocking: Google’s locale-adaptive pages documentation states that Googlebot’s default IP addresses appear US-based; a site open only to Turkey may also exclude Googlebot.
• Aggressive bot protection: A CDN or plugin setting blocking every nonbrowser client also covers search-engine bots.
• User-agent-based blocking: A rule written to stop bad bots may also catch legitimate bots whose names contain a similar expression.
• Rate-limit rule: If a limit triggered during intensive crawling returns 403, the search engine reads it as access denied.

The same logic applies to bots from AI search tools: if the security layer stops them with 403, they cannot access the website’s content. Other reasons for a website never appearing in search in the Website not appearing on Google article are explained separately.

How do you check a 403 block with Search Console?

Three places in Search Console show a 403 block: the live test in URL Inspection, the Page indexing report, and the Crawl Stats report.

According to Google’s URL Inspection documentation, the live test fetches and examines the URL in real time and shows whether Google can retrieve the page from the server. If the page opens in a browser but cannot be fetched in the live test, the block is most likely bot-specific. Perform checks in this sequence:

1. Enter the problematic address in URL Inspection and run the live test; record the page fetch status and response information.
2. Open the 403-related row in the Page indexing report and examine example affected URLs.
3. In Crawl Stats under Settings, examine the distribution by response type; a sudden rise in 4xx indicates the date the block began.
4. Repeat the live test after correction; if successful, request indexing for important pages.

Crawl Stats documentation states that this report is available only for root-level properties, meaning a domain property or a root URL-prefix property.

How do you verify genuine Googlebot and AI bots?

Because the user-agent line is easily spoofed, a request is verified as genuinely coming from Googlebot through its IP address. Google’s Verify Googlebot documentation defines two methods: manual verification with reverse DNS and automatic matching against IP ranges published by Google.

The manual verification sequence described in the documentation is broadly as follows: perform a reverse DNS lookup for the IP address in the log and check that the returned domain ends with googlebot.com, google.com, or googleusercontent.com. Then perform a forward DNS lookup for that domain; if the result matches the IP in the log, the request belongs to Google. If not, it is another client impersonating Googlebot.

For the automated method, Google publishes its crawlers’ IP ranges as JSON files in CIDR format; common crawlers such as Googlebot, special-case crawlers, and user-triggered tools are listed in separate files. Firewall allow rules should rely on these lists or the security service’s verified bot feature, rather than the bot name alone. A similar arrangement exists for AI; OpenAI’s bot documentation publishes IP addresses for crawlers such as GPTBot, OAI-SearchBot, and ChatGPT-User as JSON files. The general logic of CDN bot settings in the What is Cloudflare article is explained.

Common mistakes with 403 errors and the correct method

The most common mistake is disabling all security to remove a 403 Forbidden error; the correct approach is to identify the single rule producing the block and fix only that rule. The differences between common quick fixes and our approach are as follows:

If a 403 error appears alongside unfamiliar .htaccess lines, unknown server files, or new administrator accounts, the problem may be a security breach rather than configuration. In that case, scan the website before adjusting permissions; possible precautions in the WordPress security guide is explained.

When should you consult a specialist for a 403 Forbidden error?

Specialist support saves time if a 403 Forbidden error does not disappear within half an hour of permission, .htaccess, and plugin checks, or if Search Console shows 403-related blocks. Intervention must be systematic if server logs are inaccessible, the block affects only particular countries or bots, or an e-commerce checkout or cart step returns 403.

For one-time failures, the WordPress troubleshooting service identifies and resolves the source of the block. Our working process takes a backup first and then diagnoses layer by layer; instead of disabling rules, rule-specific exceptions are defined and every change is noted. For regular security, update, and bot-access checks, WordPress maintenance costs 500–2,000 TL per month depending on the site’s size and scope.

Because Search Console warnings and security logs are periodically reviewed in the maintenance arrangement, a rule blocking Googlebot can be noticed before pages drop out of the index.