How to Fix the WordPress 403 Forbidden Error (Complete Guide 2026)

TL;DR: The WordPress 403 Forbidden error means the server understands your request but is actively refusing to fulfill it, most often because of incorrect file permissions, a corrupted .htaccess file, or an overzealous security plugin. Fix it by resetting file permissions to 755 (directories) and 644 (files), regenerating your .htaccess file, and temporarily deactivating security plugins to isolate the cause.

Last Updated: July 2026. Tested on WordPress 6.7 running PHP 8.3.

Few errors stop a WordPress site owner cold like the 403 Forbidden error. One moment your site is live. The next, anyone who visits gets a stark “403 Forbidden” message and your content is completely inaccessible. With 8,200 searches per month, this is one of the most common WordPress errors people run into, and it is fixable in most cases without touching a single line of custom code.

This guide walks through every root cause of the WordPress 403 Forbidden error and provides tested, step-by-step fixes for shared hosting environments (cPanel), managed WordPress hosting, and everything in between. You will also learn how the right hosting setup prevents this class of error from ever appearing in the first place.

What Is a 403 Forbidden Error?

Try GigaPress AI Free →

The HTTP 403 status code is defined in RFC 7231 as a response the server sends when it understands the request but refuses to authorize it. Unlike a 404 error where the resource simply does not exist, a 403 means the resource is there but access is blocked.

In a WordPress context, you might see any of these variations:

• 403 Forbidden
• HTTP Error 403
• Error 403 – Forbidden
• 403 Forbidden – nginx
• Access Denied
• You don’t have permission to access / on this server

The error can appear on the entire front end of your site, on the WordPress admin (/wp-admin/), on specific pages or post types, or even only on image and media URLs. Where it appears is an important diagnostic clue for narrowing down the cause.

Common Causes of the WordPress 403 Forbidden Error in 2026

Before reaching for a fix, it helps to understand the root causes. The most common triggers are:

Cause	Where It Shows Up	Likelihood
Incorrect file or folder permissions	Entire site or /wp-admin/	Very common
Corrupted or invalid .htaccess file	Entire site (Apache servers)	Very common
Security plugin blocking a request	Specific URLs, admin, or REST API	Common
Hotlink protection misconfiguration	Images and media files only	Moderate
CDN or Cloudflare firewall rule	Entire site or specific pages	Moderate
Incorrect index file or missing DirectoryIndex	Homepage or specific directories	Less common
Malware-injected .htaccess rules	Entire site or specific paths	Less common

Fix 1: Reset WordPress File and Folder Permissions

Incorrect file permissions are the most frequent cause of the WordPress 403 Forbidden error. The correct permission values for WordPress 6.7 are:

• Directories: 755 (rwxr-xr-x)
• Files: 644 (rw-r–r–)
• wp-config.php: 440 or 400 (read-only for security)

Using cPanel File Manager

If you are on shared hosting with cPanel access, follow these steps:

1. Log in to cPanel and open File Manager.
2. Navigate to your WordPress root directory (typically public_html).
3. Select all files and folders, then right-click and choose Change Permissions.
4. For directories: check the Owner, Group, and World execute boxes, set to 755, and apply recursively to directories only.
5. For files: uncheck the execute boxes, set to 644, and apply recursively to files only.

Using SFTP or SSH

Connect via SFTP using a client such as FileZilla, or SSH into your server and run these two commands from your WordPress root directory:

find /var/www/html -type d -exec chmod 755 {} ;
find /var/www/html -type f -exec chmod 644 {} ;

Replace /var/www/html with your actual document root path. After running these commands, reload your site to confirm the 403 error is resolved.

Fix 2: Regenerate the WordPress .htaccess File

The .htaccess file controls how Apache processes URLs and requests. A corrupted or manually edited .htaccess is a very common source of 403 errors on Apache-based shared hosting. On Nginx-based servers (including many managed WordPress hosts), .htaccess is not used, but equivalent server block configuration issues can cause the same problem.

To regenerate a clean .htaccess file:

1. Connect via SFTP or cPanel File Manager and navigate to your WordPress root.
2. Rename the existing .htaccess file to .htaccess.bak (this creates a backup without deleting it).
3. Log in to your WordPress dashboard and go to Settings > Permalinks.
4. Without changing anything, click Save Changes. WordPress will write a fresh .htaccess file automatically.

If you cannot access the dashboard because the 403 error is affecting the entire site, create a new .htaccess file manually via cPanel File Manager with the following content for a standard WordPress installation:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

This is the standard WordPress .htaccess content as documented at WordPress.org. Once access is restored, log in and resave your Permalinks to let WordPress rewrite the file properly.

Fix 3: Deactivate Security Plugins

Security plugins such as Wordfence, Sucuri Security, and iThemes Security (now Solid Security) include firewall features that can incorrectly flag legitimate requests and return a 403 response. This is particularly common after a plugin update or after changing your site’s URL structure.

To test whether a security plugin is responsible:

1. Rename the plugins folder via SFTP: navigate to wp-content/ and rename plugins to plugins-disabled. This deactivates all plugins at once.
2. Attempt to load the URL that was returning the 403 error.
3. If the error is gone, rename the folder back to plugins, then reactivate plugins one at a time to isolate the offending plugin.
4. Once identified, check that plugin’s firewall settings or whitelist rules, or temporarily deactivate it and contact the plugin developer.

For the 403 error affecting the WordPress REST API specifically, see our WordPress REST API Troubleshooting Guide 2026 for additional plugin-level fixes.

Fix 4: Check and Fix Hotlink Protection Settings

If the 403 error only affects images and media files but not the rest of your site, hotlink protection is almost certainly the cause. Hotlink protection prevents other websites from embedding your images directly, saving your bandwidth. When misconfigured, it blocks your own site from accessing its own media files.

Disabling Hotlink Protection in cPanel

1. Log in to cPanel and navigate to Security > Hotlink Protection.
2. Click Disable if hotlink protection is currently enabled, then test your media URLs.
3. If that resolves the issue, re-enable hotlink protection but add your own domain (including www and non-www variants) to the URLs allowed list before saving.

You may also find hotlink protection rules written directly into your .htaccess file. Look for lines containing RewriteCond %{HTTP_REFERER} and either remove them or ensure your domain is listed as an exception.

Fix 5: Review CDN and Cloudflare Firewall Rules

If your WordPress site is behind Cloudflare or another CDN, a firewall rule or WAF (Web Application Firewall) policy may be returning the 403 before the request ever reaches your server. Cloudflare’s Free plan includes a basic WAF that can trigger on WordPress login pages, XML-RPC endpoints, and REST API calls.

1. Log in to your Cloudflare dashboard and navigate to Security > Events (formerly Firewall Events).
2. Filter by “Block” actions and look for events matching the URL that returns 403.
3. If a rule is triggering, either edit the rule to exclude your domain or create a bypass rule for the specific path.
4. As a temporary diagnostic step, switch Cloudflare from “Proxied” (orange cloud) to “DNS only” (grey cloud) in the DNS settings to route traffic directly to your server and confirm whether Cloudflare is the source.

Fix 6: Correct the DirectoryIndex and Check for Missing Index Files

When Apache cannot find a default index file (index.php, index.html) in a directory and directory browsing is disabled, it returns a 403 Forbidden response rather than showing a directory listing. This can happen if the WordPress index.php file was accidentally deleted or if a deployment process failed to copy it.

1. Check your WordPress root via cPanel File Manager or SFTP and confirm index.php is present.
2. If index.php is missing, download a fresh copy from WordPress.org and upload just the root index.php file.
3. Also verify that the DirectoryIndex directive in your .htaccess or server configuration lists index.php before index.html.

Shared Hosting vs. Managed Hosting: Why the Environment Matters in 2026

The troubleshooting steps above cover the most common fixes, but the environment you are hosted on significantly changes how 403 errors occur and how they are resolved.

Factor	Shared Hosting (cPanel)	Managed WordPress Hosting
File permission control	Manual via cPanel or SFTP	Managed by host, often locked down
.htaccess access	Full access to edit	May be abstracted or replaced by Nginx
Security plugin conflicts	Common, self-managed	Less common, host WAF handles firewall
403 from server config	Possible, user-editable	Support ticket required
Hotlink protection	cPanel toggle available	CDN-level configuration
Best fix approach	Self-service fixes above	Contact support + check WAF dashboard

On shared hosting, you have more direct access to the files and settings that cause 403 errors, but you are also more exposed to configuration drift. On managed WordPress hosting, the hosting provider’s infrastructure handles many of these layers, which means 403 errors are less common but harder to self-diagnose when they do occur. For issues touching the 503 error space, see our guide on what the 503 Service Unavailable error means and how to fix it.

Fix 7: Check for Malware in .htaccess

Malware frequently targets the .htaccess file to redirect visitors or block access to the site owner. If you have ruled out the other causes and the 403 error appeared suddenly without any configuration changes on your part, inspect the .htaccess file for unfamiliar rules.

1. Open your .htaccess file in cPanel File Manager or via SFTP.
2. Compare it against the standard WordPress .htaccess content shown in Fix 2 above.
3. Any rules you did not add yourself should be treated with suspicion. Remove unfamiliar RewriteRule or RewriteCond blocks carefully.
4. After cleaning the file, run a full malware scan using a plugin such as Wordfence Security or MalCare.

For a thorough walkthrough of securing your site after a malware incident, see our guide on how to fix WordPress security vulnerabilities using AI tools in 2026. You can also review how common WordPress errors connect in our 50+ common WordPress errors reference and our guide on the 405 Method Not Allowed error, which sometimes accompanies 403 issues when REST API requests are blocked.

Diagnosing 403 Errors on Specific WordPress Paths

The path where the 403 appears tells you a great deal about the cause.

• /wp-admin/ returns 403: Check file permissions on the wp-admin directory specifically, check for IP-based blocking rules in .htaccess, and check whether a security plugin has blocked your IP address.
• Homepage returns 403, inner pages load fine: This is often a DirectoryIndex problem or a missing root index.php file.
• All pages return 403: Focus on .htaccess first, then file permissions across the entire root directory.
• Only media/uploads return 403: Hotlink protection is almost always responsible.
• 403 only on wp-login.php: Your host or a security plugin is blocking access to the login page from certain IP addresses. This is often intentional brute-force protection; whitelist your IP in the plugin settings.
• REST API endpoints return 403: A security plugin’s REST API blocking feature is engaged. Check Wordfence or Solid Security settings, or refer to the REST API troubleshooting guide.

How GigaPress Managed Hosting Prevents 403 Errors

Many 403 Forbidden errors on WordPress sites come down to configuration management: file permissions drift after an update, a security plugin overfires, or a cPanel setting gets misconfigured. GigaPress managed WordPress hosting addresses these root causes at the infrastructure level:

• File permissions on managed WordPress hosting are locked to the correct values (755/644) and do not drift after updates or deployments.
• Nginx-based server architecture means there is no .htaccess file to corrupt. Server configuration is managed by the hosting team, not editable by individual plugins.
• The server-level WAF is tuned specifically for WordPress, reducing false-positive 403 responses from overly aggressive firewall rules.
• One-click staging environments let you test security plugin configurations before pushing changes to production, catching misconfigurations before they affect live visitors.

Sites hosted on GigaPress AI Builder launch on this managed infrastructure by default, meaning the file permission and .htaccess error classes covered in this guide are handled at the platform level rather than left to the site owner to manage.

Want a Pro WordPress Site in Minutes?

GigaPress AI builds you a full WordPress site in about 15 minutes — AI handles layout, styling, content, and images. Free to design, only pay when you’re ready to go live. Sites launch on managed infrastructure where file permissions, .htaccess, and server firewall settings are pre-configured correctly, so you never have to debug a 403 error from a misconfigured server environment.

Frequently Asked Questions

Why does my WordPress site show a 403 error only for logged-out users?

If logged-in users see the site normally but logged-out visitors get a 403, a security plugin or server-level rule is likely restricting public access to the site. This can happen when a plugin like Wordfence or Solid Security has a “Learning Mode” or IP reputation rule that blocks certain visitor profiles. Check the firewall logs in your security plugin and look for blocked requests matching the visitor IP ranges. Also verify that no .htaccess rule is restricting access based on authentication headers.

Can a WordPress update cause a 403 Forbidden error?

Yes. A WordPress core update, plugin update, or theme update can occasionally write new files with incorrect permissions, especially on shared hosting where the file ownership model may not match the web server user. Updates can also modify the .htaccess file in unexpected ways. If a 403 error appeared immediately after an update, start by resetting file permissions (Fix 1) and regenerating .htaccess (Fix 2).

My hosting provider says my .htaccess file is fine but I still get a 403. What else should I check?

If the .htaccess file is confirmed clean, move to these less obvious sources: (1) Check whether mod_security on your shared host is blocking the request. Ask your host to check the mod_security logs for your domain. (2) Verify the web server user has read access to the parent directories above your WordPress root, not just the root itself. (3) Check whether a php.ini or .user.ini file in the WordPress root contains a restrictive open_basedir setting that is blocking PHP from accessing its own files. (4) If you use a CDN, check the CDN’s security dashboard for blocked requests as described in Fix 5.

How do I fix a 403 error on WordPress wp-admin without FTP access?

If you cannot access wp-admin and you do not have FTP or SSH, use your hosting control panel. In cPanel, the File Manager tool lets you navigate to your WordPress root, edit the .htaccess file, and change file permissions without needing a separate FTP client. Most shared hosts also provide phpMyAdmin access, which lets you deactivate plugins by renaming their entries in the wp_options table (specifically the active_plugins option) without needing dashboard access.

Does the 403 Forbidden error affect SEO?

Yes, and this is one reason to fix it quickly. When Googlebot encounters a 403 on a URL it previously indexed, Google Search Console will eventually report it as a crawl error. Repeated 403 responses on important URLs signal to Google that the content is unavailable and can lead to pages being deindexed. A 403 on critical pages like your homepage or main landing pages can cause significant ranking drops within days. Fix the error promptly and use Google Search Console to request re-indexing of affected URLs once the problem is resolved.