{"id":4377,"date":"2012-09-19T12:00:04","date_gmt":"2012-09-19T11:00:04","guid":{"rendered":"http:\/\/www.markwilson.co.uk\/blog\/?p=4377"},"modified":"2012-09-19T00:33:48","modified_gmt":"2012-09-18T23:33:48","slug":"reducing-website-errors-http-301-redirects","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2012\/09\/reducing-website-errors-http-301-redirects.htm","title":{"rendered":"Reducing website errors with HTTP 301 redirects"},"content":{"rendered":"

A couple of weeks ago, I wrote about a WordPress plugin called Redirection<\/a>. I mentioned that I’ve been using this to highlight HTTP 404 errors on my site but I’ve also been using the crawl errors logged by Google’s Webmaster Tools to track down a number of issues resulting from the various changes that have been made to the site over the \u00a0years, then creating HTTP 301 redirects to patch them.<\/p>\n

Redirections as a result of other people’s mistakes<\/h3>\n

One thing that struck me was how other people’s content can affect my site – for example, many forums seem to abbreviate long URLs with … in the middle. That’s fine until the HTML anchor gets lost (e.g. in a cut\/paste operation) and so I was seeing 404 errors from incomplete URLs like https:\/\/www.markwilson.co.uk\/blog\/2008\/12\/netboo…-file-systems.htm. These were relatively easy for me to track down and create a redirect to the correct target.<\/p>\n

Unfortunately, there is still one inbound link that includes an errant apostrophe that I’ve not been able to trap – even using %27<\/a> in the redirect rule seems to fail. I guess that one will just have to remain.<\/p>\n

Locating Post IDs<\/h3>\n

Some 404s needed a little more detective work – for example\u00a0https:\/\/www.markwilson.co.uk\/blog\/2012\/05\/3899.htm is a post where I forgot to add a title before publishing and, even though I updated the WordPress slug afterwards, someone is linking to the old URL. \u00a0I used PHPMyAdmin to search for post ID 3899 in the wp_content table of the database, from which I could identify the post and \u00a0create a redirect.<\/p>\n

Pattern matching with regular expressions<\/h3>\n

Many of the 404s were being generated based on old URL structures from either the Blogger version of this site (which I left behind several years ago<\/a>) or changes in the WordPress configuration (mostly after last year’s website crash<\/a>). For these I needed to do some pattern matching, which meant an encounter with regular expressions, which I find immensely powerful, fascinating and intimidating all at once.<\/p>\n

Many of my tags were invalid as, at some point I obviously changed the tags from \/blog\/tags\/tagname to \/blog\/tag\/tagname\u00a0but I also had a hierarchy of tags in the past (possibly when I was still mis-using categories) which was creating some invalid URLs (like https:\/\/www.markwilson.co.uk\/blog\/tag\/apple\/ipad). \u00a0The hierachy had to be dealt with on a case by case basis, but the RegEx for dealing with the change in URL for the tags was fairly simple:<\/p>\n