Getting the 403 Forbidden Error in WordPress? Here’s How to Fix It

Posted on April 26, 2016 by in Tips & Tricks | 24 comments

Getting the 403 Forbidden Error in WordPress? Here’s How to Fix It

Everyone who spends time online has come across an HTTP status error at one point or another. Few of them, however, are as frustrating as getting a 403 Forbidden error on your own WordPress website. Considering you pay for a hosting service and probably set up that WordPress install on your own, it’s pretty obnoxious when you’re denied access.

Fortunately, this error is not a byproduct of your servers suddenly becoming sentient and deciding to take over your website (at least, not to the best of our knowledge). It’s just a matter of it refusing a request due to a lack of necessary permissions, most often due to something minor breaking down in your WordPress installation. In fact, you’ll probably spend more time figuring exactly where the error lies than actually fixing it.

Now that your fears have been assuaged, let’s review the potential causes (and fixes) for this error.

First: Backup!

Before we jump into the meat of the article, let us take up a brief moment of your time in order to spread the gospel of performing regular backups. In case you haven’t taken the time to set up a backup solution for your WordPress website, you definitely should. Even though the 403 Forbidden error can be pretty simple to fix, having a recent backup can (and probably will) save you a giant headache at some point when you do run into a site breaking error.

If you’re sure where to start, we’ve got you covered. We’ve written extensively about multiple backup solutions in the past, and all of that advice remains relevant, so take a moment to check out the following articles:

Now that you’ve successfully converted to the Church of Backups (t-shirts and other merchandise pending), let’s move on to the most common causes of the 403 Forbidden error.

Step 1: Check Your File Permissions

As we mentioned at the beginning of this article, the 403 Forbidden error is the consequence of a server refusing a request due to a lack of proper permissions. Therefore, it makes sense to start your troubleshooting by checking whether your WordPress files have the correct permissions.

First of all, in order to check this out, you’ll need to use an FTP manager. For the purposes of this guide, we’ll be working with FileZilla, and if you need any help setting it up or learning the basics, take a look at this recent article where we covered everything you need to know.

Once you’re set on that front, you’ll want to access your FTP server using your login credentials, then go over to your WordPress installation folder. If you haven’t done this before, they’re located inside the public_html folder – all you have to do is double-click on it:

Screenshot of the public_html folder as seen in FileZilla.

Inside public_html, you’ll find a lot of folders and files that represent the backbone of your WordPress website. Each of these will have its own permission settings, with a numeric value that tells you exactly which interactions are enabled for which group of users. For example, every WordPress folder should have a setting of 755 by default, which can be easily seen on FileZilla:

Screenshot of the file permission settings of several WordPress folders as seen in FileZilla.

The permission column should appear to you by default, but if for some reason it doesn’t, all you have to do is right-click on the titles of the columns in order to activate it. Additionally, you can simply right-click each file or folder and choose the File Permissions option. You’ll then be able to modify the numerical value of the permissions or manually change the settings for each group of users, which will automatically update the permission value.

Warning: This isn’t the kind of thing that you want to tweak just for kicks. Setting the wrong permissions could easily cripple your site and lead to a 403 Forbidden error situation.

Now, if for some reason the default permission values of your WordPress installation have been changed, you’ll have to restore them manually in order to make the 403 Forbidden error go away. Bear in mind that changing your permission settings won’t necessarily cause this specific error or any error in particular, but it still could leave your site vulnerable from a security standpoint. Once we’ve gone through the process of restoring the default permission values, we’ll talk a bit about why those specific values are desirable.

Now, let’s look at your WordPress folders. For efficiency’s sake, we recommend that you select all of them at once in order to change their permissions in a single stroke. Once you’ve selected them, right-click and pick the File Permissions option.

Once inside, if the numerical value of their permissions is anything other than 755, change it to that value and click on OK.

It’s as simple as that! Now let’s repeat the same process for the individual files lying around public_html, which should all be set to 644. Select them all, go to File Permissions, and if the value isn’t already set at 644, correct that.

Pretty simple, but we’re not done yet. Now you have to check whether the files inside the folders whose permissions you fixed all have their values set properly. We recommend that you pay extra special attention to your wp-admin, themes, and plugin folders, since they contain some of the most crucial WordPress files.

Now, you might be wondering exactly why these two specific values, 755 and 644, are chosen by default. To make a long story short, these are codes representing which group has which permissions, as you may have surmised while tinkering with FileZilla’s File Permissions tab. The 755 code enables every user to read and execute the files included therein, but only the file’s owner retains writing privileges.

Now, as far as permissions go, when we say that all users have execution privileges, we’re only using the official lingo in order to indicate that these folders can actually be accessed by the server. As long as all users don’t have writing privileges (which would be a 777 code – a big no-no), your site should be alright. When it comes to individual files and 644, this code means that files are readable by all users, but can only be modified or written by their owners.

Now that we’ve successfully restored the correct file and folder permissions, it’s time to check whether the 403 Forbidden error has disappeared. If that isn’t the case, it’s time to try a couple other things.

Step 2: Check Your .htaccess File

It is possible for your .htaccess file to become corrupted, which in turn can cause a 403 Forbidden access error to appear on your WordPress site. The good news is that fixing a corrupted .htaccess file will only take you a couple of minutes with the aid of your trusty FTP manager.

If you’re following our guide step-by-step, your FTP manager should still be open – otherwise, get it started again and go to your WordPress root folder. Therein you’ll find the .htaccess file we’re looking for, and we’ll proceed to make a backup of it just to play it safe. Right-click on the file and choose the Download option. It will then be downloaded to the folder that’s set in your Local File directory:

Screenshot of the .htaccess file as seen in FileZilla.

Once you have a copy stored securely on your computer, proceed to delete the .htaccess file on your WordPress installation. Don’t worry, we will be restoring it shortly, and you should still be able to access your dashboard.

When you have successfully deleted the file, try to access your site again in order to see if the error persists. If it does, we can discard the .htaccess file as the source of the problem – in which case simply proceed to re-upload the copy you made to your WordPress root directory via FTP.

However, if deleting the file does solve your issue, it was most likely corrupted – in which case we’ll have to generate a new copy. To do so, access your dashboard, jump to Settings, and select the Permalinks option.

Inside, you may proceed to update your settings if there is anything you wish to change. As an aside, it’s important to note that updating your permalink structure can sometimes result in a 403 Forbidden error, since the rules you set are inserted into the .htaccess file.

Once you’re satisfied, simply click on Save Changes, and this will automatically generate a brand new .htaccess file:

Screenshot of the Permalinks page in the Settings tab.

Step 3: Check Your Plugins

We already covered this in detail in a previous guide, but let’s do a quick recap in case you missed it. It’s quite easy to find out whether the 403 Forbidden error is being caused by a faulty plugin without having to deactivate each one individually.

All you have to do is deactivate them all at once, and if the error disappears, you can proceed to go through the boring task of pinpointing exactly which plugin was causing the error in the first place.

In order to achieve this feat, all you need to do is relocate to your plugin directory via FTP, and change its name to something different as in the example below.

Screenshot of the modified plugins folder as seen in FileZilla.

This will render WordPress unable to find your plugins, and therefore result in their deactivation. Once that’s done, proceed to check once more whether the error is gone – if that’s the case, restore the folder’s name, then change the name of each individual folder inside in order to deactivate them until you find the culprit.


As you can see, the 403 Forbidden error is really more of a nuisance than something to be scared of. Chances are that if you ever run across this issue, you’ll be able to fix it in a matter of minutes with a little tinkering – and the help of our guide.

Let’s run through a quick recap. If your server does rise up against you and you’re faced with a 403 Forbidden error on your WordPress site, all you need to do is follow these steps:

  1. Check your user privileges.
  2. Check your .htaccess file.
  3. Check your plugins.

Have you ever run into the 403 Forbidden error in one of your sites, and what did it take to fix it in your case? Share your story with us and subscribe to the comments section below!

Article thumbnail image by johavel /


  1. NGINX is also known to initially only display index page on WordPress powered sites and not subsequent pages (permalinks). In addition NGINX bypasses .htaccess rewrite rules, so is of no use. In that case, You need to tell nginx how to process php files. Add this to your server block:
    try_files $uri $uri/ /index.php?$args;

    • Tom Ewer

      Thanks for the advice and code, Joe!

  2. Love this article. Changing permissions can be risky and it’s not something I normally think about when debugging. My steps have always been backwards. Check plugins first, check theme, check htaccess and then check permissions. 🙂

    • Tom Ewer

      Hello Heather! At least you have the right order – just in reverse!

  3. I monitor all sites I manage through Webmaster Tools. This lists crawl errors encountered by Google. Over many years of using WordPress, my experience is that the plugin most likely to cause 403 Errors is W3 Total Cache.

    The strange thing is, it only seems to impact Google’s crawlers – a human visitor does not receive the 403 error. It usually happens at random – 1 site out of 15 on the same server, or different sites on different hosting company servers in different countries. It happens without warning, rhyme or apparent reason.

    I have seen sites completely de-indexed by Google as a consequence of this insidious issue. If you don’t use Webmaster Tools to monitor your site, you might never even be aware that it is occurring.

    Deactivating the W3 Total Cache plugin immediately fixes the problem. On reactivation, the problem does not immediately return, but invariably reappears within a week.

    This is frustrating because W3 TC is a better plugin than the other (free) caching plugins.

    My solution was WP Rocket Cache which I now run on the 50+ WordPress sites I manage for clients. It is not free, but has proven to be reliable and delivers outstanding results – and no 403 errors!

  4. Since many of us use more user-friendly FTP client software than yours, you should *also* translate *every* octal file-permissions number into “rwx” format, e.g.,:
    – 777 (user:rwx, group: rwx, other:rwx)
    – 755 (user:rwx, group:r-x, other:r-x)

  5. Great article, thank you!

    Just one quick observation. As the article mentions – once you rename the plugins folder, it will deactivate all plugins in one fell swoop – which is a great technique to find out whether a plugin is causing the problem. However – once you rename the plugin folder back to ‘plugins’ – the individual plugins remain deactivated – so you can use the admin to reactivate them one at a time, rather than having to go through the trouble of renaming them each individually.

  6. Also, mod_security can be the issue for 403 errors. Also, WordFence firewall false positive can sometimes make 403 to admin-ajax.php

    Nice article though

    • Tom Ewer

      Thanks for the extra info!

  7. I have recently been getting a 403 forbidden page when visiting urls on my site. This only occurs from any computer on the office network.

    The thing is that it first happened when I was updating my site to wp-core 4.5 and the latest version of my premium theme. So I thought it was to do with that. I went through methodically checking my .htaccess both root and admin (which actually had not changed anyway), checked file permissions, checked my hosts (to see if our range of IPs were blacklisted), deactivated all plugins, swapped theme to default 2016 but the 403 was still happening. In desperation I reloaded a backup of the site both database and files.

    When I went back on in the morning the site was fine. I could edit, view, etc. Ahh I thought that must have been the reason (I didn’t think about the overnight change of IP!). So carried on with the older version. About half way through the day the 403 error pages were back! Arrgghh. I did notice that when this happened one computer on the network had just been booted up. This could be the problem I thought. I disconnected the computer and then restarted the router (for new IP) and I was back in. I then updated the wp-core to 4.5 and it was OK for a bit, but then the dreaded 403 came back. So it wasn’t that one computer. This time I just went and reset the router and I was back in.

    So I’m confused, it doesn’t seem to be the IP range as I am now happily connected and using, it doesn’t seem to be the wp-core or theme update as it happened again with the old versions installed, it’s not the .htaccess and it doesn’t seem to be any of the plugins.

    Someone has mentioned that it could be stemming from an FTP client. I use filezilla and the times of it’s use could well match the 403 error. Has anyone heard of the program causing this?

    • Tom Ewer

      Oliver, I haven’t heard of this particular issue. I would suggest heading over to Filezilla’s support page ( ) and telling them your issue. If there is an incompatibility issue, the people there will know!

      Good luck, and thanks for your comment!

  8. Its informative i like it. It’s a good article. Its more attractive and effective for people.

  9. This article has solved my issue related to 403 Forbidden error. Thanks alot

  10. tom ever ! kindly help me how I can shift my Blogger site to WordPress ?
    as i dont know how to fix this issue on blogger blogspot site ! 🙁 🙁

  11. Thanks bro! Deleting the .htaccess worked for me.

    • Tom Ewer

      Good stuff, Emmy! Glad to have been of service 🙂

  12. Thanks for share this

500,591 Customers Are Already Building Amazing Websites With Divi. Join The Most Empowered WordPress Community On The Web

We offer a 30 Day Money Back Guarantee, so joining is Risk-Free!

Sign Up Today

Pin It on Pinterest