Severity: Major · Fix time: 5–15 min · Skill level: Intermediate

403 Forbidden is an HTTP status code returned by a web server when a request is understood but deliberately refused. Unlike a 404 error, where the page simply doesn’t exist, a 403 means the resource is there — the server just won’t allow access to it. The visitor, search engine bot, or script making the request lacks the required permissions to view or interact with that resource, and credentials alone won’t fix it.

For WordPress site owners, a 403 error almost always signals a configuration problem rather than a content problem. It can appear site-wide, on specific pages, or only in certain areas like the WordPress admin. Because access denials block legitimate users and search engine crawlers alike, catching and fixing the underlying configuration is part of keeping a WordPress site healthy and properly indexed.

Need a quick map of every WordPress error? See our 70+ WordPress Errors Guide → for a categorized reference of every common WordPress issue.

[Image: Browser screenshot showing a 403 Forbidden error message, with an HTTP status code indicator]

How a 403 Forbidden Error Works

Web servers enforce access control through file permissions, server configuration rules, and security software. When a request arrives, the server checks whether the requesting party has the right to access the resource. If the check fails, it returns a 403 status code instead of delivering the page.

On WordPress sites, this check happens at several layers simultaneously:

  • File system permissions — Every file and directory on the server has permission settings assigned to the file owner, the server group, and the public. Standard WordPress directories should be set to 755 for folders and 644 for files. Permissions set to 000 block all access; permissions set to 777 create a security risk that some server configurations will automatically deny.
  • The .htaccess file — This Apache configuration file controls how the server handles requests. A corrupted, missing, or misconfigured .htaccess file is one of the most common causes of 403 errors on WordPress sites.
  • Security plugins and web application firewalls — Plugins like Wordfence or Sucuri include firewall rules that can block requests they identify as suspicious. Legitimate requests sometimes get caught in these rules, especially after a ruleset update.
  • Hosting-level rules — Many hosting providers add server-level security layers that can return a 403 for requests that trigger rate limits, IP blocklists, or geographic restrictions.
  • Index file missing — If the web server can’t find an index file (like index.php) in a directory and directory browsing is disabled, it returns a 403 rather than listing the directory contents.

Check This First — 2-Minute Diagnostic

  1. Identify the scope — Does the 403 affect every page, specific directories (like /wp-admin/), or just one URL? Scope determines where to look first.
  2. Check for recent changes — Was a security plugin updated, a migration performed, or a new firewall rule added? Changes immediately before a 403 appears are almost always the cause.
  3. Try the URL from a different device or network — If the 403 only affects one IP or network, your IP may be blocked by a security plugin or hosting-level firewall rule.
  4. Rename .htaccess temporarily — Connect via SFTP and rename .htaccess to .htaccess_old. If the site loads, the .htaccess was the cause. Regenerate it via Settings → Permalinks → Save Changes.
  5. Check file permissions via SFTP — Verify that /wp-content/, /wp-content/plugins/, and /wp-content/themes/ are set to 755. Individual files should be 644.

Purpose & Benefits

1. Protecting Sensitive Resources Legitimately

The 403 response is a legitimate and useful security mechanism. Server administrators use it intentionally to block public access to directories, admin areas, configuration files, and other resources that should never be publicly accessible. On WordPress sites, rules that deny access to wp-config.php, the /wp-admin/ directory from unauthorized IPs, or PHP files in the uploads directory are correct and intentional uses of 403 — part of a solid WordPress hardening strategy.

2. Signaling Configuration Problems Early

When a 403 appears unexpectedly on a page that should be publicly accessible, it’s an early warning that something in your hosting configuration has changed or broken. Catching and resolving it quickly prevents legitimate visitors from hitting dead ends, and prevents caching layers and CDNs from storing error responses that get served to future visitors even after the underlying issue is fixed.

3. Protecting Search Rankings from Access Denials

Google’s crawler is treated like any other visitor. If Googlebot requests a page and receives a 403, it interprets this as a deliberate permission denial. Repeatedly receiving 403 responses for pages that should be indexed will cause those pages to be dropped from search results over time. Monitoring Google Search Console’s Coverage report for 403 errors on public pages is an important part of on-page SEO maintenance.

Examples

1. Incorrect File Permissions After a Server Migration

A business migrates their WordPress site to a new hosting provider. During the transfer, file permissions reset — directories that should be 755 end up at 700, blocking the web server user from reading them. Every page returns a 403. Fix: connect via SFTP and correct permissions using the hosting file manager or SFTP client:

# Fix WordPress file permissions from the site root
# Set all directories to 755
find . -type d -exec chmod 755 {} \;

# Set all files to 644
find . -type f -exec chmod 644 {} \;

# Tighten wp-config.php specifically
chmod 640 wp-config.php

After running these commands, reload any affected pages to confirm access is restored.

2. Corrupted .htaccess After a Permalink Change

A developer updates the permalink structure in WordPress settings. The auto-generated .htaccess file gets saved with a syntax error — a line break in the wrong place or a conflicting rule from a plugin. The server can’t parse the rules and returns a 403 for all incoming requests. Resolution: rename the current .htaccess to .htaccess_old via SFTP, then navigate to Settings → Permalinks and click Save Changes without changing anything — WordPress regenerates a clean .htaccess file automatically.

3. Security Plugin Blocking an IP Range

A company’s office IP range gets flagged by a security plugin’s threat intelligence feed after an unrelated organization in the same IP block was associated with malicious activity. Every employee logging in from the office network hits a 403. The fix: access the security plugin settings through a network that isn’t blocked (mobile hotspot or VPN), and add the office IP range to the plugin’s whitelist. This restores access without weakening the site’s overall protection for other IP ranges.

Common Mistakes to Avoid

  • Setting file permissions to 777 — This grants full read/write/execute access to everyone on the server. Some guides suggest 777 as a quick fix for permission errors, but it creates a serious security vulnerability on shared hosting where other sites on the same server can write to your files. Use 755 for directories and 644 for files.
  • Deleting .htaccess instead of renaming it — If the .htaccess file is causing the 403, rename it rather than deleting it outright. Renaming preserves your custom rules (redirects, security rules, cache headers) while allowing you to test whether the file was causing the error. Deletion makes those rules unrecoverable.
  • Ignoring 403 errors in Google Search Console — A 403 on a page that should be publicly indexed will eventually cause that page to be dropped from search results. Monitor Search Console’s Coverage report regularly for 403 crawl errors, not just 404s.
  • Assuming the error is always the visitor’s fault — Unlike some 4xx errors, a 403 is almost always a server-side configuration issue, not a user error. Don’t dismiss visitor complaints about 403 errors before investigating your hosting environment.
  • Not testing after security plugin updates — Security plugins update their rulesets frequently. New rules occasionally block legitimate traffic from real users or crawlers. After any security plugin update, check whether public pages are still accessible from a logged-out browser session.

Best Practices

1. Audit File Permissions After Every Migration or Major Change

After any server migration, major plugin update, or hosting configuration change, verify that your WordPress file and directory permissions match recommended settings. Run the permission check commands from an SFTP connection or hosting terminal, and include wp-config.php in your check — it should be 640 or 644, never 777.

# Check current permissions on key WordPress directories
# Run from your WordPress root via SFTP terminal or SSH
ls -la wp-config.php
ls -la wp-content/
ls -la wp-content/plugins/
ls -la wp-content/uploads/
# Look for anything that isn't 644 (files) or 755 (directories)

2. Keep .htaccess Clean, Documented, and Backed Up

The .htaccess file is small but critical. Include it in your regular backup routine, and document any custom rules you add to it. If a 403 appears after modifying this file, comparing it to a known-good backup is the fastest way to identify the problem. Keep a plaintext copy of your intended .htaccess rules in a password manager or documentation system so you can restore them quickly after a regeneration.

3. Review Security Plugin Settings After Each Update

Security plugins update their rulesets frequently, and new rules occasionally block legitimate traffic. After any security plugin update, check whether your site’s public behavior has changed — load pages while logged out, attempt login from different IP addresses, and check Google Search Console for new crawl errors. Pay particular attention to rules governing /wp-admin/ and the login page, which receive aggressive protection that can sometimes block legitimate administrative access.

4. Use IP Whitelisting for Admin Area Access

For high-security sites, restricting /wp-admin/ access to specific IP addresses via .htaccess is a legitimate hardening technique. If you implement this, document the whitelisted IPs and maintain a process for updating the whitelist when team members’ IPs change. An improperly maintained IP whitelist is one of the most common causes of self-inflicted 403 lockouts.

# Restrict wp-admin access to specific IP addresses
# Add to .htaccess inside the wp-admin directory
<Files "*.php">
  Order Deny,Allow
  Deny from all
  Allow from 203.0.113.0/24
  Allow from 198.51.100.50
</Files>

5. Implement a Malware Scanning Schedule

Malware infections frequently modify .htaccess and file permissions as part of their payload. A site that experiences recurring, unexplained 403 errors — particularly after cleaning up a previous incident — should be scanned for malware as part of the diagnostic process. A clean .htaccess that keeps getting modified points to an active infection, not a configuration error.

Frequently Asked Questions

What causes a 403 Forbidden error most often in WordPress?

The most common causes are incorrect file permissions (directories set to something other than 755, files other than 644), a corrupted or misconfigured .htaccess file, and security plugin firewall rules that block legitimate requests. After these three, the next most common cause is an IP block — either from a security plugin or a hosting-level firewall — affecting a specific user or network.

How do I fix a 403 Forbidden when locked out of wp-admin?

Connect to your site via SFTP or your hosting file manager. First, check whether an .htaccess file exists in the /wp-admin/ directory — some security guides place one there to restrict access. If it contains an IP whitelist that doesn’t include your current IP, add your IP or remove the restriction. Next, check file permissions on /wp-admin/ — it should be 755. If permissions are correct and no .htaccess restriction is present, deactivate plugins by renaming /wp-content/plugins/.

Can a 403 Forbidden error hurt my SEO?

Yes, if it affects pages that should be publicly accessible. A 403 tells search engine crawlers that the resource exists but access is denied. Repeated 403 responses on indexable pages will eventually cause Google to stop attempting to crawl those URLs and remove them from search results. For pages that are intentionally protected (admin areas, member-only content), 403 is correct and has no negative SEO impact.

What is the difference between a 403 Forbidden and a 404 Not Found?

A 404 error means the server can’t find the resource — the page doesn’t exist at that URL. A 403 means the resource exists but access is denied. For SEO, they behave differently: a 404 signals a missing page, while a 403 tells crawlers the page is there but off-limits. A 403 on a public page is more problematic for SEO than a 404 because the crawler knows something is there but can’t access it.

Will a 403 error go away on its own?

Rarely. Unlike a 503 Service Unavailable that may resolve once a server recovers from overload, a 403 is almost always the result of a deliberate configuration — either intentional (and correct) or unintentional (and broken). It won’t resolve without an intervention: fixing file permissions, updating .htaccess, adjusting security plugin rules, or removing an IP block.

Related Glossary Terms

How CyberOptik Can Help

Still broken? Our team fixes WordPress errors like this in under 30 minutes for maintenance clients. Unexpected 403 errors point to hosting or configuration issues that affect both visitors and search engine crawlers — and diagnosing them requires understanding how file permissions, .htaccess rules, and security plugin configurations interact. Our WordPress maintenance plans include server configuration reviews, security plugin audits, and rapid troubleshooting for access errors like this. Contact us to discuss your site or learn about our WordPress maintenance services.