Sanjeev Sabhlok's notes on technology, hardware, gardening

Fix 404 errors in WordPress > WordPress dashboard pages giving 404 error


404 Not Found
The server did not find a visitor’s requested file. This error commonly occurs when a visitor mistypes a URL. [Source]

Also frequent 500 errors, and this one:

503 Service Temporarily Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.



Switch to PHP7. This seems to work best. PHP7 seems to take significantly less RAM.


1) Admin > Settings > Permalinks

2) Revert permalinks again to default.


If your .htaccess file were writable, we could do this automatically, but it isn’t so these are the mod_rewrite rules you should have in your .htaccess file. Click in the field and press CTRL + a to select all.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

In such a case go to the .htaccess file and fix it. BUT IDEALLY, SET .HTACCESS TO 666 THAN RESET TO 644  [see also this]

3) If it works, swith it to desired permalink option and check it again. [USE MONTH/DATE/NAME]



Go to bulletproof security htaccess Core and REDO all htaccess files.


This website says that deleting wp-admin’s htaccess can help. [Source] – DID NOT HELP IN ANY WAY.


disable one plugin at a time, each time trying to reproduce the problem before you disable another plugin. Start with the plugins that have anything to do with the administration of WP, then move down to regular theme plugins, widgets and such. Inspect the “Not Found” page that you are served better (browse with Opera and open the Info panel which will show you the headers, alternatively browse with Firefox and have Firebug with the “Net” panel enabled) and do a search through all of your plugins to see if they might be serving it directly. If not, take a look at the log of the web server to find out what exact resource it’s unable to serve; a plugin might be doing some fancy redirecting or rewriting so it’s not necessarily the URL you see in your browser that’s causing the 404. [sOURCE]


use a debugger to view the rewrite array and confirm that the rewrite rule responsible for processing your URL is not in place. To do this, install the plugin Debug This, which makes it easy to view what is actually in the WordPress rewrite array.

Once this plugin is installed and activated, go to your site. Then navigate to:

Homepage → Admin Bar → Debug This → Query → Rewrites.
You should end up on a screen that contains rewrite rules on the left hand side and the actual PHP string being rewritten on the right hand side. So what do you do with this information?

Let’s say we have a broken author feed (example: To troubleshoot the broken feed, look for the word “author.” Eventually this rule is found: author/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$

If you don’t find the rule, this is the source of your issue. WordPress will not process the request unless it knows what it is doing.

The actual PHP URL string that WordPress uses for this author feed is: If this long PHP URL does not work, you have another problem with your site.

You will now want to start by deactivating plugins one by one to see if you can find the conflicting PHP responsible for the issue.



See this: and


just finished chatting with a dreamhost tech support person who told me that a user account i have with them was hitting process memory resource limits (all processes) and that was what was causing strange, seemingly htaccess-related problems. i was getting intermittent 404 errors from an htaccess file that should not have been called at all! it was dreamhost with a haunted house server.

apparently, the process killing robot that dreamhost uses will kill a web process in the middle and then for some reason, the (now zombie) apache actually tries to finish its job (doing its best to exit cleanly out of the unglamorous end to a subrequest is my best guess). it throws a 500 error into the main http log, but after doing so, it actually fires off the rewrite condition and rule that should never have been fired (using the standard file -f and directory -d htaccess file above) – and it doesn’t write a new log entry! a new (invisible man) request then triggers the index file in the last line of the htaccess file

beware the resource limits in dreamhost basic accounts! if you go over their limits, and you have htacess with mod_rewrite lines you will see strange things


The major problem with DreamHost’s setup is that, in the eternal fight to keep memory consumption at a minimum, it means getting rid of as many features as possible — namely, all that will reduce bandwidth (good for the visitors!) or CPU (good for the server, but DreamHost doesn’t control CPU consumption as aggressively as they control RAM). For instance, this means getting rid of gzip’ed HTML + CSS (which will consume CPU + RAM) or any of the several Minify plugins (which will consume RAM as well). The more sophisticated the cache (I’m fond of using W3 Total Cache, or at least WP Super Cache), the more RAM will be consumed as well.

Similarly, many plugins which limit the number of MySQL queries to improve performance will instead consume RAM. So finding a trade-off where you can still keep your site replying with good performance while avoiding to consume precious RAM is a hard task!

So far, my best results on busy sites is to uncheck Page Speed Optimization and Extra Web Security which will apparently consume a lot of RAM, and rely instead on a combination with W3 Total Cache and Cloudflare (free reverse proxy service). Cloudflare will effectively do the same thing as the “Extra Web Security” module, but since it runs outside DreamHost, it’s fine. W3 Total Cache consumes a lot of memory but once the pages are statically stored locally, Cloudflare will very efficiently cache them — so you might get 404/500 while editing posts, at least your visitors will not experience them (Cloudflare also can serve static pages even if DreamHost gives a 404 or a 500).

Also, thanks to this article, I have found out that FastCGI uses more RAM than ‘normal’ CGI. And since PHP 5.3 is better at managing RAM (more aggressive garbage collection, less memory leaks), I’ve experimentally switched to PHP 5.3 CGI (not FastCGI) without Page Speed Optimization nor Extra Web Security, relying on W3 Total Cache + Cloudflare to accelerate the site. Now the backoffice is slower (more CPU consumption!) but at least I don’t see 404/500 (so far!).

I’m still unhappy with the combination, so I’ll certainly continue to tweak DreamHost’s settings hoping to reduce RAM consuption even more and still get adequate performance. Like @dgw said, I also use a lot of plugins — because I require their functionality. Not everybody hosting WP with DreamHost has simple, blogging needs; the more complex the site, the more functionality it will require… and that’s the beauty of WordPress, you just need to use the plugins you really need, and keep the core WP install simple if you’re happy with few needs. Plugins, however, aren’t necessarily “bad” or that heavy on the site; but it’s true that some may consume a lot of RAM…

SOLUTION: I’ve moved to managed SQL on dreamhost and all issues with 400 adn 500 errors have disappeared. Cost $15 per month PLUS cost of the general server. But it is worthwhile, since I’m at least able to DO something.

MySQL VPS    An additional service similar to a webserver VPS that only runs the MySQL server and no other services.



View more posts from this author

Leave a Reply

Your email address will not be published. Required fields are marked *