WordPress Redirect – Best Practices For Faster Performance

There is a WordPress redirect functionality built into core which is designed to catch wrong URLS. When an incorrect URL is requested, WordPress tries to locate the correct URL and will redirect the visitor to the correct URL if it can find it. On hand one this is great, but let’s take a deeper look into some of the issues with this.

For example, a visitor to your site can either include or drop the www subdomain from your site’s URL and WordPress will redirect them to the proper URL. The same thing happens when the path that should appear before the page slug URL is dropped. So if you have a page that resides at http://www.example.com/parent/page. Try typing in http://example.com/page and see what happens. In most cases, WordPress is smart enough to locate the correct page and redirect you to it.

The situation gets more complex if you set up your website to resolve using HTTPS. If you do that, you’ll usually want to force all traffic to be redirected from HTTP to the HTTPS prefixed URL. That can make the redirection process really messy. Imagine this redirection mess:

Third, the visitor is redirected to the URL formulation that includes the parent page in the path.

Finally, the server begins to send the website files and resources to the visitor’s browser.

You might be thinking to yourself: “That’s great! I can butcher a link and the visitor will still end up where they’re supposed to end up.” In a sense, you’d be right to think that. WordPress is really good at figuring out where URLs are supposed to resolve, and that means that mistyped URLs will often resolve properly. However, all of this auto-redirection also has a downside.

The WordPress Redirect Lag

Once you realize how resilient WordPress is, it’s easy to be lulled into lackadaisical URL formulation. This is particularly dangerous if you manually type out the URLs in inline links and custom menus. It’s no big deal, right? Visitors still end up at the correct URL!

Well, yes, I guess that’s true. However, what you’re overlooking is the impact redirects have on page load speed. Here’s a Pingdom website page speed result for a WordPress site. This test is based on accessing a page using a properly-formulated URL to avoid any redirects.

Pingdom test result with properly formed url

That’s pretty snappy. If we look at the file requests we see that there are no redirects happening when the site is requested.

Whoa. That added more than half a second to the page load time — an increase of about 58%. Let’s take a look at the file requests to see what happened.

Pingdom bad URL file request

Now there are two redirects added to the front of the URL. Following the redirects, the page loads as normal. So we can attribute the slower page speed to the redirects happening when the incorrect URL is fed into the test. The bottom line is that redirects hurt web page load speed. The difference is significant and measurable.

To Redirect or Not to Redirect?

Redirects exist for a reason, and it’s a good one: they allow you to send visitors from outdated content and nonexistent URLs to updated content. We’ve already covered the nonexistent URLs angle to a degree. WordPress does some of that all on its own. However, WordPress won’t catch everything, and there are times that manual redirect rules are needed.

For example, let’s say you wrote an article titled What’s Brand New in WordPress back when WordPress 3.0 was released. It was a great post back in 2010, but Googlers looking for “what’s new in WordPress” today aren’t looking for that. You want to keep those readers happy. So you write a new post about the features that will be included in an upcoming planned version of WordPress.

In this scenario, a redirect from the old post to the new post is perfectly acceptable and appropriate. In addition, in this case, a redirect is good SEO practice since the link juice attributed to the old post would be passed to your new post giving it instant search engine cachet.

There are several scenarios where redirects are appropriate:

Just like in the example, you’ve posted updated content and want to redirect outdated content to the updated content.

You’ve overhauled a website’s permalink structure and need to redirect old URLs to their new structure.

You are updating a published page or post and want to temporarily redirect traffic to a different post or page while you work on the update.

As explained at the beginning of this article, WordPress works it’s magic and redirects users when URLs are close but not quite right.

When Not to Redirect

In all of the scenarios above, redirects are necessary to send visitors from outdated content and broken URLs to updated content, or as a temporary measure while a specific bit of content is updated.

You might argue that a WordPress redirect isn’t strictly necessary in the first scenario in the list above. However, the primary source of traffic for that outdated content is most likely search engine users using terms like “new WordPress features”. Clearly, the old article doesn’t fit those search terms, but the new content does, meaning a redirect is necessary if searchers are going to end up locating the content they are looking for.

So, when is it not appropriate to use a WordPress redirect? If you’re using a redirect when it isn’t necessary, then you should rethink your strategy.

For example, if you’ve built a custom menu using URLs that don’t include www, but your site URL does resolve with the www subdomain at the front of the URL, then you’re making a mistake that needs to be fixed. Using redirects in that scenario is not appropriate, and hurts the speed of your site.

How to Minimize Redirects in WordPress

If you’re sold on minimizing redirects in WordPress — and how could you not be? — there are two things you need to do to minimize the occurrence redirects.

Make sure your top-level domain resolves with no more than one redirection.

Never create unnecessary redirects intentionally.

Resolve Your Top-Level Domain with No More than One Redirect

Your goal is to make sure that your URL is reached with no more than one redirection no matter what combination of protocol prefix and subdomain a visitor throws in front of the top-level domain. Here’s what I mean. All of these URLs should resolve to the top-level domain with no more than one redirection, and one of these should resolve with no redirects.

http://example.com

http://www.example.com

https://example.com

https://www.example.com

If you aren’t sure how many redirections are required to resolve your site’s URL using those different combinations of protocol prefixes and subdomains, you can check using Patrick Sexton’s Redirect mapper.

Redirect mapper tool

Here is an example below of redirects that are not setup correctly which are easily spottable using the redirect mapper. You can see that there are duplicate redirects happening on both the www and non-www versions.

Struggling with downtime and WordPress problems?

Kinsta provides an all-in-one hosting solution designed to save you time! Let us handle the nitty-gritty stuff (caching, backups, etc.), and you focus on what you do best, which is growing your business.

Here is an example of redirects setup correctly. As you can see there is only one redirect happening.

Redirects setup correctly

If you do find that some of those combinations either fail to resolve (return a 404 server status code) or require more than one redirection to resolve, it’s time to get to work.

What you’ll need to do is add one or more redirection rules to the server to ensure visitors land at the proper formulation of your site’s URL as quickly as possible. If your site is hosted on a standard LAMP stack, you will need to add URL rewriting rules to your site’s .htaccess file.

However, if you’re using a more advanced hosting configuration, there’s a good change it’s powered by NGINX rather than Apache. In which case, things aren’t quite as simple, redirection configuration will vary from one host to the next, and you’ll be best served to get in touch with your host’s support group to fix the redirection issue.

If your site is hosted by Kinsta, then it is running on a NGINX server. Setting up redirects with Kinsta is really easy. You can add redirect rules through the MyKinsta dashboard but of course, you can always get in touch with support if you have any questions or need help.

The basic goal you’re trying to accomplish is to create redirect rules that target any URL formulations that require more than one redirection to force those URLs to resolve directly to the properly formulated URL. For example, if the URL http://example.com requires two redirects to get to https://www.example.com, create a manual redirection that makes that happen in one step rather than two.

You can also use their redirect rules feature to easily create 301 and 302 redirects from right within the MyKinsta dashboard. Using free WordPress plugins to implement redirects can sometimes cause performance issues as most of them utilize the wp_redirect function, which requires additional code execution and resources. Adding them in MyKinsta means the rules are implemented at the server level, which is a much more optimal way.

Add redirect rule

Use the Proper URL Structure When Creating URLs

Don’t intentionally create redirects when building internal links and menus. If you’ve gotten in the habit of typing URLs lazily, get out of that habit. When you type a URL make sure you:

Use the proper protocol prefix (HTTP or HTTPS)

Include or exclude the www subdomain as appropriate

Don’t use post and page ids in links

Include the entire path to the page or post

The redirection power built into WordPress is supposed to be a fallback in case you accidentally create a bad URL. Use it as a fallback and never intentionally to fix lazy URL writing.

Creating a WordPress Redirect With a Plugin

As we already covered, there are legitimate times to create a WordPress redirect. And if your host doesn’t have redirect rules feature, you might have to use a WordPress plugin. There are many redirection plugins available for free from the WordPress plugin directory.

WordPress Redirection plugin

Redirection is the most popular redirection plugin, by far. It’s very easy to use, and can be set up to create redirects using the WordPress core, .htaccess on an Apache server, or NGINX server redirects.

Simple 301 Redirects, another popular option, is designed to make redirection as simple as possible. It’s easy to use, offers no configuration options, and includes just enough information to make it easy to manually add 301 redirects.

Safe Redirect Manager is actually built by the awesome team over at 10up. It allows you to redirect locations to new URLs with the HTTP status codes of your choosing. The plugin uses the wp_safe_redirect function which only allows redirects to whitelisted hosts for security purposes.

Quick Page/Post Redirect Plugin is another popular plugin that will be preferred by users who prefer a shopping list of configuration options. With over 200,000 active installs it’s certainly been well-tested. It is easy to use, has a well-designed interface, and can be used to manually create 301 and 302 redirects. One particularly nice feature is a drop-down menu for selecting pages, posts, media pages, and archive pages as the redirection target, ensuring that manually-created redirection rules resolve without any redirection.

Practice Responsible Redirection

Plain and simple, WordPress redirects slow down your site. That’s why it’s worth taking the time to minimize the number of redirects visitors to your site experience. There are times that it’s appropriate to intentionally create and use redirection, but limit the use of redirection to necessary instances and make sure your visitors have the fastest experience possible when browsing your WordPress website.

What are your thoughts? Have you experienced performance issues due to too many redirects?

If you enjoyed this article, then you'll love Kinsta’s WordPress hosting platform. Turbocharge your website and get 24x7 support from our veteran WordPress team. Our Google Cloud powered infrastructure focuses on auto-scaling, performance, and security. Let us show you the Kinsta difference! Check out our plans

Hand-picked related articles

Comments

Comment policy: We love comments and appreciate the time that readers spend to share ideas and give feedback. However, all comments are manually moderated and those deemed to be spam or solely promotional will be deleted.

Leo
July 26, 2016 at 10:16 pm

Thanks Jon. Should ecommerce store owners do a redirect when their old products are phased out?

If you have an equivalent page that replaces the old one, then you should redirect it. But for example if you apply a 301 redirect to a category Google may consider this as a soft 404 (according to John Mueller of Google).

A small number of products disappearing and being redirected is no big deal. A bigger issue Tom is if you have hundreds or thousands of products disappearing or expiring directed to another category page. That looks like landing page spam to Google.

I agree with tomzur. If there’s a replacement or comparable product, 301 to that page.

SEO issues aside, a redirect to a category page might be confusing to the customer — not a feeling you want to create when trying to build trust with a potential paying customer. So, rather than redirect to a page that isn’t a direct replacement, I would add a note to the product description noting that it was no longer available and linking back to the most relevant category or product.

Great article! One remark and a question. At first the recommended tool Redirect Mapper isn’t very reliable. Its results differ with Chrome Devtools at times. Nice idea but I wouldn’t rely onto what it returns. :/ And about the question, you have recommend that top-level domains should resolve within one redirection max. But I’ve read up a bit and it turns out quite cumbersome to impossible. If you have your site at example.com and the visitor enters www. example.com you get two redirects. But with a single Apache rewrite rule that isn’t fixable reliably it looks like? so is it possible to accomplish a single redirect in that scenario at all? :/ cheers r.

Hi Jon – helpful article, thanks. We use Yoast Premium for our SEO, and it includes a redirect function which we’ve used for all our outdated links. I can’t tell from the article or Yoast documentation whether that approach gives us a performance overhead, so should be replaced by Kinsta redirects, or if it’s a good alternative (performance-wise). Would appreciate your views and other people’s experiences. Thanks

Hey Was,
Kinsta redirects will always be faster because they are done at the server-level, meaning it doesn’t ever hit WordPress. We always recommend using the Kinsta redirect tool if you can as this will give you the best performance.

I love Yoast WordPress SEO Premium (it does a lot of things perfectly) but like almost all redirect plug-ins even Yoast WordPress SEO Premium use the wp_redirect function, which requires additional code execution and resources. That is also autoloading data into the wp_options table.

Thanks for the article but I read it to the end expecting it would suggest how to write the code to put in the ACTUAL htaccess file for the example you described: non www, non http redirecting to a www https address which is the exact problem I’m having in trying to write this type of redirect code. What ever I try doesn’t work for my Wpress site and the page goes blank no matter what experts on stackexchange I read. #Beyondfrustrating

Hey Ian!
We’ll try to get those added. The reason we haven’t is that all of our clients at Kinsta are on Nginx. We don’t use Apache and our support team can easily add redirects for you or we also have a redirect tool right in our MyKinsta dashboard. These are done at the server-level for the best performance.

Follow us

A cookie is a piece of information that a website stores on a visitor’s computer. We use this for some functionality on our website to work properly, collecting analytics to understand and improve a visitor’s experience, and for personalized advertising. You can accept all cookies at once or fine-tune your preferences in the cookie settings.

Cookie settings

Accept cookies

Thanks, we've saved your settings, you can modify them any time on the cookie settings page

Cookie settings

Necessary cookies

Details

These cookies are needed for our website to function providing payment gateway security and other essentials. Therefore they are always on but they do not contain personally identifiable information (PII).

Name

Purpose

Cookie Settings

If you've set preferences (which cookies you accept and which you don't) we store your preferences here to make sure we don't load anything that you didn't agree to.

WordPress Cookies

WordPress sets a couple of cookies that track logged in users and store user preferences set in their WordPress user profile. These are set for members of the Kinsta website only - members of our staff.

Stripe

Stripe is our payment provider and they may set some cookies to help them with fraud prevention and other issues. This is required for our payments to work.

Affiliate cookie

This cookie contains information about the affiliate who refered a visitor. The cookie contains no information about the visitor whatsoever.

Google Analytics

Analytics help us deliver better content to our audience. We have made sure no personally identifiable information (PII) is sent by anonymizing IPs.

Newsletter Participation

If you sign up for our newsletter we'll remove the newsletter subscription box for you. This cookie has not personal data it just indicates if you have signed up.

Analytics cookies

Details

Analytics cookies allow us to gather data to help us better understand our visitors and offer them a better experience.

Select

Provider

Purpose

Google Optimize

Set and used by Google. It allows us to A/B test our content to make sure we're providing visitors with what they need most.

Marketing cookies

Details

Marketing cookies help us target our ads better. We mainly use them to target ads to users who have visited Kinsta.

Select

Provider

Purpose

Twitter

Set and used by Twitter, used for targeting advertisements and promoting content to users who have visited kinsta.com.

LinkedIn

Set and used by LinkedIn, used for targeting advertisements and promoting content to users who have visited kinsta.com.

Facebook

Set and used by Facebook, used for targeting advertisements and promoting content to users who have visited kinsta.com.

AdWords

Set and used by Google Ads for remarketing, personalization, and targeting advertisements to users who have visited kinsta.com. (Google Ads Settings)

Bing

Set and used by Bing Ads for remarketing, personalization, and targeting advertisements to users who have visited kinsta.com. (Bing Ads Settings)

Quora

Set and used by Quora, used for targeting advertisements to users who have visited kinsta.com.