WordPress speed tip PSA! Don’t use the Redirection plugin if you don’t have to!
I’ve seen it for like the 200th time now this year. New client comes over for speed optimization or webhosting and I see the Redirection plugin. Some of them have redirects in there. Some are just there to log 404’s. UGHHHH…*SHAKING MY HEAD*. Don’t do it like that!
What is the Redirection plugin?
What’s it do and why do people use it so much?
The Redirection plugin is a handy tool that does the following:
- Lets you set up redirects using a graphical interface with handy dropdown selections.
- Reports your 404 page requests (when visitors access unavailable url’s).
So what’s the problem with Redirection plugin?
The “problem” is that way too many people use it when they don’t have to. And that the Redirection plugin redirects users via slow PHP rather than from the server. Install redirection plugins are like putting a [slow] bouncer in front of your webpage checking everyone’s destination URL before you let them in.
- If you need it for redirects, please use htaccess (if you have access to it). Not only redirected visits but ALL website visits will be faster that way.
- If you need it for logging 404’s, please don’t do that. That’s a waste of server resources and website speed. You can check your website 404’s in Google Search Console.
- The Redirection plugin slows down ALL pages on your website, not only the ones getting redirected.
So why do so many people use the Redirection plugin if it’s “bad”?
- Because it’s so easy/simple AND they don’t know how to write redirects in htaccess – Please search Google for the right “htaccess generator” for your needs).
- Because they want to track their 404’s – again, please use Google Search Console. Or if you want, track it for a month if you have many 404’s, then disable after making corrections.
- Because they see everyone else using it – this is faulty logic that leads to horrendous plugins (like Jetpack) ruining WordPress sites everywhere.
- Because they don’t have to htaccess or server-configs (webhost using NGINX) – this is the only valid reason and unfortunate drawback of using NGINX.
What if you STILL want to use a redirect plugin?
- Please listen to me! Try without for a week and see if you really really need it.
- Decide if you really want BOTH the redirect and 404 logging feature. If all you need is the redirect functionality, use Safe Redirect Manager instead. It’s coded by one of the best development teams out there and much leaner IMO than the bloated/consumer-grade ones like Redirection.
What’s the speed savings?
- As much as half a second to one whole second speed gain on slow servers. On faster servers, not much but still noticeable. Try it and see. Just disable your plugin for a moment. If the gain isn’t big enough for you, then ok fine. But do know that having more redirects and 404 logs built up over time will probably slow things down in the future.
Hi Johnney,
This is seriously good stuff. This post and your other posts I went to after reading this! Many thanks.
Yes, I am one of those using Redirection plugin out of habit and thinking all was well but with redirects having bloated over time to over 160 I was looking into how to remove them. Then found your site.
Redirection does have a useful .htaccess export so quite an easy job to replace, but not 164 redirects. Which leads me to ask:
Q1: With very old redirects still getting hits, why is this happening? Many posts are so old it does not seem credible that browsers out there are still using the old post links.
Q2: I have already deleted redirects over a year old, and will need to monitor 404s as you suggest. Is there a better way to prune redirects?
Q3: I see from your Swift Performance setup post that .htaccess lines can be put into the plugin. Would you recommend this as ok rather than use “Safe Redirect Manager”? I intend to replace SG optimizer with Swift based on your work too!! SG Optimizer has caused so much trouble for so long and very happy to have found your analysis.
Thanks again for your superlative help. Very much appreciated.
Hi Richard,
Thanks for stopping by. It should be “easy” to export all redirects you have in Redirection plugin and paste right into the bottom of your .htaccess file.
Q1 – old links are usually visited either by A) internal pages on your site that haven’t been updated, or B) other websites that are linking to your site through outdated links.
Q2 – as long as you’re monitoring your 404’s carefully, you can probably just delete them all. A smart idea would be to back them up to a file and quickly restore the ones you see in your 404 reports.
Q3 – I don’t recommend you use Swift htaccess function for that. Please put them directly into your htaccess file. Otherwise if you ever change or get rid of Swift later, you lose your redirects. Safe Redirect Manager, I only recommend if you absolutely must have a plugin and/or you’re on NGINX (which doesn’t have htaccess) with no access to the config file.
Hey Johnny. Great article again, thanks !
I have question to know what you think :
I set up e-commerce for clients who usually have a lot of products with a big turnover (when some products are gone, they are gone for good).
So I usually instal the Redirection plugin or use Rank Math built-in redirection feature* and write a little user guide for them to set up 301 redirects when a product is out of stock and won’t be available anymore (and if there is another page / product that makes sense to have the 301 pointing to).
Of course no one wants to have non-tech savvy clients messing around with their .htaccess file so I feel using a plugin for this specific case is the only solution but maybe I’m wrong ?
What would you recommend for this specific case (which I’m sure this case is pretty common) ?
*If you’ve had the change to test it, is it ok to use the Rank Math redirection feature or would you still recommend to use .htaccess redirections instead ?
Thanks again for the great content !
You should do what you like best. My guide is only my opinion for my specific use cases. If yours is different, then it would make sense to operate differently.
Alright thanks ! Still a rookie in the WP world so I’m always trying to improve my processes and ways to work 🙂
Thanks for the post, I will be looking at alternatives. I suppose there’s no plugin that directly writes redirects to .htaccess ? Seems like that would be a security risk…
One thing worth mentioning, there is absolutely a place for 404 error logging at the site/server level rather than using Google Search Console. GSC records 404’s encountered by Googlebot. That will typically not include all 404’s. Especially after a domain migration where lots of redirects are put in place it’s really helpful to, over a few months, check 404 error logs like the redirection plugin provides. We’ve often discovered 404’s from referral traffic going to certain URLs which GSC never identifies. You don’t have to use the redirection plugin for this, there are other options, but I would warn webmasters against putting all their eggs in one basket with GSC. Remember that Googlebot is a crawler. It will not know about browser bookmakers, links in emails, links in non-indexable web or social media content, links in software or apps, and the list goes on.
does cPanel redirection work as well vs the htaccess method? or does this run into the same issues as the plugin?
CPanel redirection is simply a GUI for htaccess. It’s the same as htaccess. Just that end users don’t have to learn/remember Apache directives.
Hi Johnny,
The Wp Engine host have deprecate htcaccess since PHP 7.4 https://wpengine.co.uk/support/htaccess-deprecation/
With hundreds of redirects to manage, is the redirection plugin the best way to go?
If you don’t have a way to use server redirects (htaccess for Apache/LiteSpeed, nginx_config for NGINX), then you’ll have to use a plugin.
Is this still the case? I just did a bunch of tasting with a redirection plugin that has over 20000 redirects set up. To really amplify the differences I have turned off caching and CF APO. The difference is non existent. Identical TTFB on non-redirected page (along with all the other metrics).
Redirected page has the same TTFB too. The redirection adds around 400ms according to GT metrix, but the target page is much leaner so it loads below 1s anyway.
Does using redis/memcache + Cloudflare APO impacts the redirection plugins’ performance?
Our use case doesn’t allow us for other solutions because redirects are often added and edited by VAs.
Are you on NGINX?