How to Fix 403 Forbidden Error in WordPress and .htaccess (2026)
In April 2007, while travelling between cities, I checked my site and found a 403 forbidden error on every page. My hourly statistics showed the site had been down for 15 hours. My host, Dreamhost, had emailed to say Googlebot was overloading the server and they had blocked it in .htaccess, but the rule took down the whole site. Here’s how I fixed it then, and a full checklist for fixing 403 errors in 2026.
Quick answer: A 403 Forbidden error means the server understood the request but refuses access. On WordPress the usual causes are a bad .htaccess rule, wrong file permissions (folders should be 755, files 644), a security plugin or firewall blocking your IP, or a CDN rule. Rename .htaccess to test, reset permissions, and check your security and CDN settings.
Table of Contents
How I fixed my .htaccess 403 error in 2007
With the site and WordPress admin both down, I downloaded FileZilla on the computer I was using away from home and connected to my hosting. The .htaccess file didn’t show at first because it’s hidden, so I enabled showing hidden files. Inside were deny rules, including one blocking the 66.249 IP range Googlebot uses, and the misconfiguration was blocking every visitor. I had never edited .htaccess myself, so I cleared those lines, uploaded the file and the site came back instantly. Dreamhost later apologised for the error.
How to fix a 403 forbidden error
1. Test your .htaccess file
- Connect via your host’s File Manager or FTP and enable hidden files.
- Rename .htaccess to .htaccess-old and reload your site.
- If it works, go to Settings > Permalinks in WordPress and click Save to create a fresh .htaccess, then re-add any custom rules one by one.
2. Fix file permissions
Folders should normally be 755 and files 644; wp-config.php can be 440 or 600. Your host’s File Manager or support can reset them.
3. Check security plugins
Wordfence, Solid Security and similar plugins can block your IP or country. Temporarily disable them by renaming their folder in wp-content/plugins.
4. Check your firewall or CDN
Cloudflare, Sucuri or your host’s firewall may block your IP, country or user agent. Review firewall events and allow your IP.
5. Missing index file
If directory browsing is off and a folder has no index.php or index.html, the server returns 403.
6. Ask your host
Server-level rules (ModSecurity, bot blocks) are often set by the host. As I found in 2007, sometimes the fix is on their side.
403 vs other errors
- 401: authentication required (wrong password on a protected folder; see password protecting a directory with .htaccess).
- 404: page not found. 410: page gone permanently.
- 500: internal server error, often a broken .htaccess too. Here’s how I fixed internal server errors.
Note: this is based on my experience; if you’re unsure about editing server files, ask your host’s support.
FAQ
Can a 403 error hurt SEO?
Short outages are fine, but if Googlebot gets 403 errors for days, pages can drop from search results.
Why do I get 403 only in WordPress admin?
Usually a security plugin, ModSecurity rule or IP restriction on wp-admin.
Does clearing the cache fix 403 errors?
Sometimes, if a cached error page is being served. Clear your browser, plugin and CDN caches.
You will probably want to create an error document for codes 404 and 500, at the least 404 since this would give you a chance to handle requests for pages not found. 500 would help you out with internal server errors in any scripts you have running. You may also want to consider ErrorDocuments for 401 – Authorization Required (as in when somebody tries to enter a protected area of your site without the proper credentials), 403 – Forbidden (as in when a file with permissions not allowing it to be accessed by the user is requested) and 400 – Bad Request, which is one of those generic kind of errors that people get to by doing some weird stuff with your URL or scripts.
Hello friend,
You can visible hidden files (.htaccess) in FileZilla 3 as follows:
— You go under the menu item “Server” and activate “list hidden files force”
— The following dialog close simply by klick OK. Done.
Greeting
I had a similar problem. I was doing some testing and have installed PHP 5 on a development server. I had a site installed on the server that was working correctly, complete with quite an elaborate .htaccess file handling many redirects and rules. However, after installing PHP5 it turns out any php file I tried to view just returned a 403 Forbidden error. I began to scratch my head. Searching on Google didn’t immediately bring up a solution either. However, I eventually narrowed it down to the fact that I needed to add Options +FollowSymLinks to my .htaccess file. That solved it all.
In my experience with Dreamhost, they do mean well, and usually fix it right the first time – but this shows that yes, they are human. They can make mistakes, However, they will tell you when they do something, they don’t beat around the bush, and if something requires action from you (that they can’t just control themselves from the support center), they will give you step-by-step direction on the matter, whether it is upgrading your webapps (a clear-cut case of “staying on top of things”) or telling Google that they don’t need to make 50,000 hits every hour (a clear-cut case of “our servers can handle it…. can yours?”).
Granted, Google pretty much IS the internets these days, but even they can be blocked with very little effort. :P
Thanks for posting this. It helped me figure out why our forums page rank went to 0. It killed our ad revenues and search results.
I’m really xx that Dreamhost would do this without contacting me. They have a fine contact/support system, yet when they decided to make huge changes like this, they don’t let me know?
Really, really annoying.
Blocking Googlebot goes too far. For people who make a living from search engines it is unacceptable.
I use Dreamhost as well. They disabled two of my sites at different times because they said I configured my .htaccess file incorrectly, causing it to hit the server over and over again. In actuality, it was googlebot spidering my site of 20,000 pages. Seriously, they can’t handle googlebot? To solve the problem I went into Google Webmaster Tools and slowed down the crawl rate for spidering my site.
You have this site on a shared hosting plan over DreamHost?
I am a client of them as well, but I only host smaller sites there. Not reliable at all from my past experiences.
but I can’t remember to close my html tags apparently… hehe
Another alternative would have been to SSH into your dreamhost server and edit the htaccess directly on the server. I always keep a copy of putty on my thumbdrive for such occasions.