Top Redirection Tips

Search bots and third party spiders are generally pretty stupid. They request files which don’t exist, get stuck in dead ends, don’t take into account site or platform-specific evidence
which might help them more effectively crawl, and generally prefer brute force (more crawling depth and resources) over crawl finesse. This behaviour clogs up your server logs with 404s and adds unnecessary server strain (you’re still using processing and bandwidth overhead to serve those 404s, and they generally aren’t cached), but also means that search engines and evaluative tools aren’t getting a good understanding of your website. More sophisticated bots are problematic in other ways – Google, for example, pro-actively manipulates URL strings and forms to pages and URLs which it otherwise miss; but in doing so, it too generates overhead and errors.

Bot-by-bot, this shouldn’t affect you greatly. However, it’s not unheard of for a relatively large website to get hit by many dozens of bots per minute, generating many thousands of
erroneous records (and causing SEO/social/user/technical issues) per day. If you’re an SEO perfectionist, or looking to squeeze out an extra drop of performance and visibility from your website, you’ll want to make sure that any time or resources which search engines are using to crawl your site is being used as effectively as possible. That means anticipating the kinds of mistakes they’ll make, and catching them before they happen.

The following is a list of ‘core redirects’ which I’ve compiled from my own experience – if you have other ‘must have’ redirects, let me know in the comments!

If you’re running WordPress, the Redirection plugin is perfect for setting up and managing your redirects and error management behaviour. Otherwise, your .htaccess file is a great place to start.

Lastly, bear in mind that, as ever, these are tailored for my sites, my needs. Implementing them as-is my cause redirect loops or errors. These are meant as learning material to inspire you to craft your own solutions, rather than as a copy-paste resource.

My Core Redirects

Redirects which tidy up erroneous filename requests (make sure that the correct/canonical version of the file exists, and/or adapt the rules to fit your own unique circumstances!):

  • Redirect erroneous requests for an IOS icon to the correct file.
  • Redirect erroneous requests for a favicon icon to the correct file
  • Requests to invalid/incorrect XML sitemap filenames (modify as appropriate to suit the correct version(s) for your site)

Redirects which clean up generally unfavourable behaviour

  • Requests to paginated children of, or date-based queries to the root URL (doesn’t make sense on non-blog websites – also bear in mind that this rule is intentionally quite greedy)
  • Requests for empty search strings (triggered by form submissions)
  • Breaking requests for images with malformed parameters (frequently used by Bing!)
  • Redirect all feed requests (if you don’t use feeds)

Utility redirects which solve specific problems caused by third party bots/networks

  • (Sometimes) breaking requests from Facebook containing post tracking parameters (do not use, or at least modify, if you rely on these strings for tracking/analysis or other functionality).

Things I haven’t covered

This is really just the tip of the ice-berg; at the moment, for Days Of The Year, for example, I’m running upwards of 600 redirect rules – however, it’s the rules I’ve outlined here which do most of the heavy lifting, and catch the majority of issues and problems.

Beyond these, there are definitely other areas you should think about; here are just a few places you’ll want to consider turning over some rocks:

  • Requests to your own, unique legacy/old/changed URLs and URL patterns (if you’re using Redirection’s, don’t rely on its auto redirect creation on changed post slugs; it’s a little flakey sometimes).
  • Pattern rules for when you change your image/thumbnail sizes, e.g,. -76[4-5]x382\.(jpg|png) –> -800-600.jpg
  • Pattern rules for when you update dependencies and libraries, e.g., jquery-1\.8\.js –> jquery-1.9.js
  • Pattern rules for security probes, such as for ‘backup.tar.gz’ type file sturctures – but these should typically be caught upstream (by something like iThemes Security for WordPress, and/or Cloudflare)
  • Fixing broken or malformed internal/inbound links, but this is already covered off superbly elsewhere
  • Rules for platform-level problems (or symptoms thereof) which can/should be solved elsewhere, like WordPress’ tendency to allow for empty archives, or page-zero concepts.

My WordPress ‘Cleanup’ Script

I include the following, or something similar, in most of my WordPress projects. It lightly standardises some awkward behaviours, removes some superfluous settings and capabilities which I rarely/never use, and enhances/improves some default functions and approaches.

Warning – do not simply copy and paste this into your theme/functions; it’ll need adapting to fit your use-case, and will likely cause as many problems as it solves if not tweaked and refined to fit your needs.

// Enable basics
	add_theme_support( 'post-thumbnails' );
// Remove Dashboard Widgets
	function remove_dashboard_widgets() {
	global $wp_meta_boxes;
	add_action('wp_dashboard_setup', 'remove_dashboard_widgets' );

// Remove WP crap

// Remove pings to self
	function no_self_ping( $links ) {
		$home = get_option( 'home' );
		foreach ( $links as $l => $link )
			if ( 0 === strpos( $link, $home ) )
	add_action( 'pre_ping', 'no_self_ping' );
	add_filter( 'xmlrpc_methods', 'Remove_Pingback_Method' );
	function Remove_Pingback_Method( $methods ) {
	   unset( $methods[''] );
	   unset( $methods['pingback.extensions.getPingbacks'] );
	   return $methods;
	add_filter( 'xmlrpc_enabled', '__return_false' );

// Remove Plugin Footprints
remove_action('login_form', 'll_credit_link');

// Disable admin bar
if ( ! current_user_can( 'manage_options' ) ) {
    show_admin_bar( false );
} else {
// Remove links menu
add_action( 'admin_menu', 'my_admin_menu' );
function my_admin_menu() {

	function cleaninit() {
		remove_action('wp_head', 'rsd_link');
		remove_action('wp_head', 'wlwmanifest_link');
		remove_action('wp_head', 'wp_generator');
		remove_action('wp_head', 'feed_links_extra', 3 );
		remove_action('wp_head', 'feed_links', 2 ); 
		remove_action('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 );
		remove_action('wp_head', 'rel_canonical');
		remove_action('wp_head', 'wp_shortlink_wp_head', 10, 0 );
		add_action('do_feed_rss2_comments', 'nullFeed', 1);
		add_action('do_feed_atom_comments', 'nullFeed', 1);
		remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
		remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
		remove_action( 'wp_print_styles', 'print_emoji_styles' );
		remove_action( 'admin_print_styles', 'print_emoji_styles' );	
		remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
		remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );	
		remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
		global $pagenow;
		if ( $pagenow != 'post.php' && $pagenow != 'post-new.php' ) { wp_deregister_script('heartbeat'); }
	add_action('init', 'cleaninit');

	// RSS	
	function nullFeed() {
		wp_redirect( DOMAIN, 301 );
	function custom_feed() {  
		load_template( TEMPLATEPATH . '/feed-rss2.php');  
	add_feed('rss2', 'custom_feed');	
	function deregister_styles() {
		if (!is_admin()) {
	add_action( 'wp_print_styles', 'deregister_styles');

	add_action( 'get_footer', 'dequeue_footer_styles');
	function dequeue_footer_styles() {

// Enable rich text editor for descriptions
remove_filter( 'pre_term_description', 'wp_filter_kses' );

// Better Excerpts
function improved_trim_excerpt($text) {
	global $post;
	if ( '' == $text ) {
		$text = get_the_content('');
		$text = preg_replace('@<script[^>]*?>.*?</script>@si', '', $text);
		$text = preg_replace('@<h2[^>]*?>.*?</h2>@si', '', $text);
		$text = preg_replace('@<h3[^>]*?>.*?</h3>@si', '', $text);
		$text = strip_tags($text, '');
		$excerpt_length = 80;
		$words = explode(' ', $text, $excerpt_length + 1);
		if (count($words)> $excerpt_length) {
			array_push($words, '&hellip;');
			$text = implode(' ', $words);
	return $text;
remove_filter('get_the_excerpt', 'wp_trim_excerpt');
add_filter('get_the_excerpt', 'improved_trim_excerpt');
/* Kill misc pages */
add_action('template_redirect', 'nerf_pages');
function nerf_pages() {
	global $wp_query, $post;
	if ( is_404() ) {
		header("HTTP/1.0 404 Not Found");

	if (is_day() || is_month() || is_year())
		header("HTTP/1.0 404 Not Found");
	if (is_attachment()) {
		header("HTTP/1.1 301 Moved Permanently"); 
		header("Location: ".get_permalink($post->post_parent)); 
	if ((is_archive()) && (!have_posts())) {
		header("HTTP/1.0 404 Not Found");

// If 's' request variable is set but empty
function SearchFilter($query) {
    if (isset($_GET['s']) && empty($_GET['s']) && $query->is_main_query()){
		header("HTTP/1.1 301 Moved Permanently"); 
		header("Location: ". DOMAIN); 
    return $query;

// Lowercase filenames
add_filter('sanitize_file_name', 'make_filename_lowercase', 10);
function make_filename_lowercase($filename) {
    $info = pathinfo($filename);
    $ext  = empty($info['extension']) ? '' : '.' . $info['extension'];
    $name = basename($filename, $ext);
    return strtolower($name) . $ext;

// Remove double spacing from content
add_filter( 'the_content', 'replace_double_space' );
function replace_double_space( $text ) {
	$sanitized_text = $text;
	$sanitized_text = preg_replace( '/[\p{Z}\s]{2,}/u', ' ', $text );
	return $sanitized_text;

// Enable uploads
add_action('post_edit_form_tag', 'add_post_enctype');
function add_post_enctype() {
    echo ' enctype="multipart/form-data"';

add_filter('gettext', 'ps_remove_comments_are_closed', 20, 3);
function ps_remove_comments_are_closed($translated_text, $untranslated_text, $domain) {
    if ( $untranslated_text == 'Comments are closed.' ) {
        return '';
    return $translated_text;

function remove_default_image_link() {
	$image_set = get_option( 'image_default_link_type' );
	if ($image_set !== 'none') {
		update_option('image_default_link_type', 'none');
add_action('admin_init', 'remove_default_image_link', 10);

Think you survived Mobilegeddon? Think again.

Think again.

Here’s the thing…

Your site is slow.

Thousands of visitors each month land on or reach error pages, ‘out of stock’ messages, empty URLs and dead ends.

Visitors frequently find the wrong products or services when they search, or content with incorrect or outdated information. They find pages targeted at the wrong country, currency or context.

Thousands of searchers don’t reach you at all, because you’re not speaking their language (literally, or metaphorically).

Everything you say, and every word on every page, is the bare minimum effort that you can put in to scaling the harrying of people into converting.

Your checkout process – or your hyper-aggressive sales messaging – confuses and irritates every single one of your customers, so big chunks of them shop elsewhere.

Your retargeting is aggressive, unsophisticated, and persists after purchase.

Your messaging, systems, products and brand aren’t consistent between territories – or between digital and the highstreet – and the experience is disjointed; disappointing.

You’re failing to understand how to support, educate, empower and amaze your audience – or failing to deliver upon that understanding.

But you didn’t get hit by mobilegeddon.

Even though your mobile experience is crap.

When getting it right is technically, conceptually simple.

When there are clear benefits to getting it right, and every blog and news outlet in the industry has spent months producing cookie-cutter business cases, best practice examples, and resources to help you to provide a great experience.

Here’s the thing…

None of these factors exist in isolation. ‘Mobilegeddon’ is part of a larger question around how well you serve your audience what they want or need, in a format which is suitable to their situation, in a way which builds a positive brand experience.

If you’re already getting that wrong in a thousand small ways, then maybe Google improving the way in which they measure one small part of it might not have a huge effect – not if you’re already scoring low across the board.

Not when you’re already providing a poor experience. When your competitors are providing a poor experience, too.

Imagine how much is on the table, in your space, for the first brands to win. To care. To surprise. To just get it right. To invest more than the minimum viable effort to survive the latest wave of algorithm updates.

So here’s the plan.
Sort your mobile experience out first. This week. Build a business case around the opportunity cost of bouncing visitors, checkout abandonments, and wasted media spend. Propose that all of your domains, pages and content is delivered responsively, reactively, or a hybrid of these as best fits your audience. Deliver the pitch whilst it’s topical, and whilst Mobilegeddon is all over the media which senior management are consuming. Strike while it’s topical, and while people are engaged.

Manage the implementation through, and measure the impact against the same metrics. Estimate the amount of money you’ve made. Be a hero.

Now go and fix everything else, or risk continuing to play Buckaroo with your brand.

Help! My developer won’t implement / wants to remove / objects to my redirects.

A client recently asked me to chip in on a debate they were having with an internal tech team about retiring old 301 redirects. Concerns had been raised about ageing and legacy CMS functionality which needed to be replaced, and as part of this process the IT folks pushed to remove (and not replace) the thousands of redirects which the system was powering. The only hint as to why they’d think this would be a good/necessary idea was a quote from the proponents stating that as Google had seen, visited and clearly indexed the destination URLs for some time, the redirects were no longer necessary, and their removal shouldn’t cause any harm. At best, they’d concede that the SEO guys needed to maintain a smaller list of redirects which were specifically set up ‘for SEO purposes’ (such as forcing http/s and lowercase, and a handful of specific page-level redirects), but that otherwise they’d need to ‘trim the fat’.

Of course, this instantly set alarms bells ringing – the business dominates their market, largely because of the performance of the destination URLs for the redirects in question, and so any negative impact whatsoever on the equity flowing to those pages could have huge real-world, commercial implications.

This is a type of scenario which I see frequently. There’s always huge reluctance from the IT/developer community to implement, support or maintain ‘bulky’ redirect lists either on a day-to-day basis or as part of website launches or significant overhauls, and it’s invariably a painful experience fighting to justify why “let’s just redirect the top 100 most visited URLs on the website” isn’t a viable option. Because it’s hard to quantify the tangible opportunity cost of failing to implement redirects, it’s an incredibly challenging argument to have, and often resorts to pleading for people to take leaps of faith.

Given how many times I’ve fought this corner in my own experience, I thought I’d go all out, and attempt to constructive a comprehensive argument which weighed indisputably in favour of maintaining legacy redirects. Here’s the (slightly edited to preserve anonymity) transcript.

Don’t ever remove redirects. There’s no reason to, and no benefit in doing so. The performance gloom and doom your developers preach is nonsense.

Don’t ever remove redirects. URLs still gets hit/crawled/found/requested years after it’s gone. This impacts equity flow and crawl quotas.

Don’t ever remove redirects. It gives a bad user experience, which impacts the bottom line.

There are a few core considerations from my perspective (from my agency experience, technical SEO knowledge, and Linkdex experience):

  • Tech teams are always highly skeptical of redirects, as I’m sure you’re well-aware. They’re often hesitant to implement even foundational numbers of global redirects (such as case-forcing, http/s, etc) due to either:
    • A lack of understanding/consideration of the user experience and/or the way in which Google discovers, crawls and indexes (and the way in which equity flows in this process)
    • Concern over server performance resulting from high levels of redirect lookups on each request
    • A desire to ‘trim the fat’ as a part of general housekeeping because it’s good practice to do that kind of thing in other scenarios and dev processes
  • In each of these cases, I’ve found that focusing on the user experience component is a good solution, where setting an expectation that any scenario in which a user hits a 404 error page has a negative commercial impact on the business removes a lot of the ‘SEO politics’ from the equation. You can even go so far as to quantify this through surveying (e.g., “would seeing an error page on our site affect how much you trust the brand?”) and ascribe a £loss value to each resultant 404 per hit, based on estimated impact on conversion rates, average order values, etc. This gives you lots of ammunition to justify the continued existence of the redirects in a context which they can understand and buy into.
  • This also goes some way to resolving the performance concerns; any small investment made into optimising the impact of large volumes of redirects (which is always marginal at most, and vastly less than they anticipate). I should note that I’ve personally handled and argued for implementing/retaining large redirect sets on a number of huge site launches/relaunches, and in each case experienced these kinds of reactions; I’ve never once seen any actual performance impact following the successful deployment of redirects numbering in the low to mid thousands (formed of mixes of static and pattern matching / regex rules). London Stock Exchange were particularly hesitant to implement ~1k redirects as part of a large site relaunch, but were surprised to see no measurable performance impact following their implementation.
  • If performance concerns are still a barrier, I typically resort to identifying equivalent performance opportunities, load speed improvements and technical optimisations which can offset the perceived cost; and there’s never any shortage of opportunities for simple things like improved resource caching, client-side rendering efficiencies, etc. If it’s helpful, I can assist/support on reeling off some suggestions in this arena, from hardcore back-end stuff to softer front-end stuff. If they can quantify the ‘damage’, it’s easy enough to offset.
  • It’s also worth considering that almost all of the major CMS platforms operate by looking up the requested URL against a database to find a pattern matched result; as such, depending on the approach to implementation, having a large list of redirects to check against needn’t necessarily represent an extra lookup, process, or performance hit. If your team are particularly sophisticated, emulating the load-balancer style approach with layers of high-level caching can further mitigate performance concerns.

In an ideal scenario, you’d have a solution in place which monitors how many times a redirect has been hit, and the last time/date at which this occurred; I use a system like this on a number of my own sites, and periodically review for and retire redirects which have been stale for over 6 months, and have a low overall hit count [I use the Redirection plugin for WordPress, it’s one of my favourite tools].
What I’ve found interesting from running this system for a number of years over multiple sites is that:

  • Any URLs which used to have any real levels of equity, links and/or performance keep getting hit for years.
  • Redirects which have been removed and return a 404 keep getting hit by search engines, indefinitely
  • I run ~4k redirects on one of my own sites at present, with no measurable performance hit for turning them all on/off
  • Removing redirects in these scenarios has a definite impact on SEO, even if this is only indirect, due to the impact being on the reduced discovery, crawlability, and crawl equity distribution resulting from a bot entering the site at a dead URL
  • People still link to dead content; much of the web is stale. We also know that urls which used to be linked to still maintain some degree of equity, so removal of any of these is liable to negatively impact the destination page’s equity.
  • Any marginal performance overhead for running this kind of system (the performance fears resurface here in the context of maintaining these kinds of logs) is vastly offset by the value retention and improved user experience

I think that crawl quota is a particularly relevant point for you guys; with a site of your size and scale, any activity which is likely to result in Google allocating lower crawl resource is liable to have enormous consequences to indexation levels and speed, which is obviously to be avoided at all costs.

I’d expect a site of your scale to want to maintain as many of these legacy redirects as possible, for as long as possible, until the impact of them is measurably and demonstrably detrimental and this cannot be offset elsewhere. Upwards of 6,000 sounds a lot, but I think that it’s a reasonable and realistic volume given your site, legacy, etc. Having said that, I’d definitely want to be putting processes in place in the future to minimise the likelihood of URL structures expiring, and planning for more future-proof’d patterning (obviously easier said than done!). Good practice suggests that no URL should ever change or die, which is a card you might be able to play, but I suspect that may lead to blame games around who-chose/designed-which-legacy-URL-structure, which may cause more harm than good at this stage!

If there’s continued pressure to ‘trim the fat’, I’d personally want to investigate, query and quantify every single rule which is proposed for deletion to understand whether there’s still anything linking to it, whether the URL has/had any social shares, and whether server-logs indicate that it’s been hit recently. This is something Linkdex could definitely help with, however, it’s likely to be a resource-intensive process and may not provide any value – even if the vast majority of URLs turn out to be ‘duds’, all of the above rationale around user experience and equity management still apply.

I wonder – as part of the migration process, is there any opportunity to combine any of the redirects into pattern matching rules? E.g., if there are 100 URLs with a shared folder root, it may be prudent to craft a single rule based on matching that pattern. This should reduce quantities significantly.

From a completely alternate perspective, if deletion is to proceed, I’d potentially consider returning a 410 rather than 404 status on the URLs in question. This may help in sending a stronger signal that, rather than a large section of your website having broken/vanished (and the negative connotations associated with this), that a deliberate decision has been made to remove those pages. I’m not convinced that this would make any realistic difference, but it feels like a low risk/effort which may help out.

In summary…
Hopefully some of this can help bolster your arguments.
As a predominantly technical person, I’ve often argued in favour of redirects from an equity-preservation perspective; it’s only in writing the email that I realised that the two biggest points here are the tangible impact on user experience, and the expected (and somewhat measurable) impact on crawl quotas. I think that next time I run into this scenario, I might not talk about ‘link juice’ or the difference between different HTTP status codes at all, and just focus on these elements. Who’d have thought?

Turbo-charging your WordPress website

Some of the key resources, tasks, tools and code referenced in my SearchLove talk. Let me know if there’s anything missing!

Skilling up at up hosting & server config

  • Get some ‘proper hosting’ (at minimum a Linux VPS, or something more advanced, or an Amazon EC2 T2 small instance).
  • Buy a domain (often easier to configure if/when it’s with the company you host with)
  • Point your domain at your hosting (configure nameservers & DNS)
  • Familiarise yourself with cPanel (demo) for managing your site(s), & phpMyAdmin (demo) for managing your database(s).
  • Install WordPress from scratch
  • Familiarise yourself with WHM (demo) for managing your server. Build your own Apache config via ‘EasyApache’, and tweak some key server settings via ‘Tweak Settings’

WordPress core

Must-have Plugins

Other recommended plugins

Resources for monitoring & measuring performance

  • Google PageSpeed Insights – don’t forget that a high score doesn’t mean a fast site. It’s just looking at whether you’ve jumped through hoops.
  • ySlow – Useful as a second opinion on score-based speed analysis.
  • Google Analytics – don’t forget to change your sampling settings to avoid slow mobile devices skewing the average!
  • Pingdom – on demand site speed testing based on request monitoring, and subscription uptime & speed monitoring packages
  • WebPageTest – more hardcore, technical site speed testing
  • iPerceptions – user experience feedback via sophisticated on-page surveying
  • NewRelic – server-level performance monitoring, error tracking, user satisfaction indexing (a bit tricky to install but worth the learning curve)

General front-end

  • Configure a CDN (either a third party, or your own subdomains)
  • Use subdomains to parallelise connections
  • Minimise the number of requests each page makes
  • Use CSS sprites
  • Minimise reflow and repaint

Expert stuff

  • Reduce reliance on ad-hoc calls to WP functions like the_title(); store commonly used variables instead
  • Manage erroneous requests which show up in GWMT and Redirection’s logs
  • Serve large, static resources from a CDN
  • Clean up plugin overheads
  • Optimise your media; file types, sizes, behaviours
  • Kill unnecessary templates
  • Tailor your site’s behaviour using custom post types and custom fields
  • Fix errors and notices by exploring your error_log file

Upgrading to SSL

Visualising the performance stack

  1. Hosting Type
  2. Server spec & config
  3. Theme / CMS
  4. Domain(s) config
  5. Media / Assets
  6. HTML & DOM (and CSS + JS)
  7. Reflow, repaint and FPS

Common 404/error hits you can catch with Redirection

  1. apple-touch-icon.png (and variants)
  2. favicon.ico (and variants)
  3. browserconfig.xml
  4. feeds which don’t / shouldn’t exist
  5. invalid page/date ranges
  6. broken internal links (and missing http links)
  7. alternate sitemap and meta data urls
  8. pages & images with weird, breaking parameters
  9. security probes