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:
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.
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.
That’s pretty snappy. If we look at the file requests we see that there are no redirects happening when the site is requested.
So what happens if we mess up that URL and run the test again?
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.
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.
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:
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.
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.
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.
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.
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.
Here is an example of redirects setup correctly. As you can see there is only one redirect happening.
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.
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:
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.
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.
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?
Send this to a friend