A 404 error is generated by your server when a requested URL is not found.
This post will help you decide if action needs to be taken and what action you should take.
When to redirect
Most people’s first instinct upon seeing a 404 error is to consider a redirect. Hold on!
Redirecting any and all 404 errors can actually be bad for your search engine results. Via Google Webmaster Tools:
Returning a code other than 404 or 410 for a non-existent page (or redirecting users to another page, such as the homepage, instead of returning a 404) can be problematic. Firstly, a page like this (called a “soft” 404) tells search engines that there’s a real page at that URL. As a result, that URL may be crawled and its content indexed. Because of the time Googlebot spends on non-existent pages, your unique URLs may not be discovered as quickly or visited as frequently and your site’s crawl coverage may be impacted (also, you probably don’t want your site to rank well for the search query [File not found]).
The first thing to ask yourself is: did this content ever exist?
If it did, and you have changed your domain or URL structure, you will want to implement redirect(s) to send users and search engines to the right place.
If it never existed, don’t sweat it. As mentioned above “Redirecting any and all 404 errors can actually be bad for your search engine results.”
Troubleshooting
WordPress sites can complicate the 404 troubleshooting process. Why? WordPress is a content management system that processes its own internal rewrite array as a part of its permalinks feature.
The first step to troubleshooting 404s is to figure out whether the 404 is being caused by the web server or by WordPress.
Static file
If your file is static (e.g. a jpg image) open your FTP client and verify that the file exists.
As an example, let’s say that the URL http://mydomain.com/wp-content/uploads/picture.jpg is producing a 404 error. You will want to:
- Open FTP Client and connect to your server (if you don’t know how to do so, read this.)
- Navigate to the file’s location
- Verify that the file exists
- If it is does not exist, you have found the source of your 404.
However, it it does exist, yet pulling the URL up in a browser results in a 404 error, continue on to find out whether the issue is web server-based or WordPress-based.
In FTP create two files at the root [/var/www/yourdomain.com/] for testing purposes.
First: Create an html file named test.html that has the words “It worked” in it. (Download this file here.)
After uploading it, head over to: http://yourdomain.com/test.html
If you see “It worked,” the server is processing static files correctly, so your issue is likely in WordPress.
Second: Create a PHP file named test.php (or download here) that includes the following:
<?php echo 'It works in PHP'; ?>
After uploading, head over to http://yourdomain.com/test.php. If it says “It works in PHP,” then PHP is functioning properly as well, so again your problem is likely in WordPress.
(Quick side note: make your mama proud by removing these files when you are done testing!)
Fixing 404s in WordPress
WordPress creates a rewrite array that is responsible for managing permalinks, or “pretty URLs.”
Improperly coded plugins, custom post types, and taxonomy alterations can break or corrupt the permalink array, thus causing 404s.
Quick fix: re-save permalinks
You can reset the permalink array by going to the permalinks tab in wp-admin and simply re-saving the permalink structure.
- Navigate to: WordPress Dashboard → Settings → Permalinks: Click “Save Changes”
Test your URL. If the 404 goes away, something caused an issue with your permalink structure and this fixed it.
Often the quick fix is enough to correct your 404 issues. However, should they come back, go on to the next troubleshooting step.
Find the cause
If the quick fix did not work or you are seeing 404s again, try disabling plugins that handle redirection or create customized permalinks. Did that solve it?
Next, 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: https://www.copyblogger.com/author/jerodmorris/feed/). 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: http://copyblogger.com/index.php?author_name=jerodmorris&feed=rss. 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.
***
And, of course, if you go through all of these steps are still unable to fix the issue, submit a Help Desk ticket.
If you have to submit a ticket, take note: it is very important that you let us know the exact URLs that are giving unwanted or unexpected 404 errors, and that you walk us through the troubleshooting steps you have already completed. Then we can add some next-level troubleshooting and insight to get your problem solved.