How to Add Redirect Rules for Your WordPress Sites
Updated on May 24, 2018
You can now add redirect rules from right within your MyKinsta dashboard! Redirect rules allow you to seamlessly direct traffic from one location to another. It is particularly useful for preventing 404 errors, ensuring proper SEO when you make changes, and routing visitors to the correct locations on your site.
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. Some of them also add autoloaded data to your wp_options table, which increases database bloat. Adding them in MyKinsta means the rules are implemented at the server level, which is a much more optimal way. Just follow the steps below on how to add them.
To add a redirect, click on your site in MyKinsta and go to “Redirects.” Then click on “Add Redirect Rule.”
You can then choose the type of redirect rule you want. Check out this article on redirection to learn more about which type of rule you should use. Our tool does use and support regex expressions.
301 redirect: Used for URLs and or content that is “moved permanently.” Typically this is the one you will want to use for SEO purposes.
302 redirect: Used for URLs and or content that is “found” or “moved temporarily.”
In this example below, we add a 301 redirect for a blog post URL that was changed and updated to something else. This ensures that all traffic, backlinks, and link juice from Google is now sent to the new URL. 301 redirects pass between 90-99% of link juice. You can select which domain prefix you want it to be added for. In this case, we want both www and non-www traffic to redirect.
Add 301 redirect
Note: This will automatically redirect UTM parameters or anything on the end of the URL. For example, if the old URL is shared on social media using a tool like Buffer, it might appear as the following:
This will automatically be directed to:
You will also notice we added ^ on the “Redirect From” URL above. This is because Kinsta’s redirect tool uses regex automatically. Therefore, you should add ^ at the beginning of every “from” path unless you want it to match at places other than the beginning of the path. For example, using simply /blogpost by itself could create a redirect loop on other URLs, such as /category/blogpost.
It is also important to check your current backlinks in a tool such as Ahrefs. For example, you might have backlinks on 3rd party sites that point to two different versions of your URL:
Notice the second one has a forward backslash on the end of it. If you don’t take this into consideration, it could break the redirect. Therefore, if you aren’t sure what version third party sites are linking to, you can always use a wildcard regex command (?) instead to ensure that both work. See example below:
In the above example, all links to both /blogpost and /blogpost/ (with the backslash) would get redirected to /newblogpost. You can then easily manage all of your redirect rules from the dashboard.
Manage redirect rules
A regular expression is a sequence of characters that define a search pattern. Below are some additional examples of that can be used with the MyKinsta redirect tool. The “Redirect from” field supports regular expressions and the “Redirect to” field allows capture group references and some variables (e.g. $host, $scheme). Here are a few important things to note:
Redirects are checked in the order you add them. Best practice is to have the more specific ones before the general redirects.
By default, our redirect tool is case sensitive (see below to use case-insensitive redirection).
Restricted characters: #, space, “, and linebreak characters.
You can’t redirect by arguments.
Here is a few common regex syntax:
^ – Match only if the following is at the beginning of the line
$ – Match only if the previous is at the end of the line
? – Match the previous 0 or 1 times (makes it optional)
. – Match any single character
* – Match the previous 0 or more times
\ – Escape special characters
(?i) – Case-insensitive
.* – Wildcard to match anything (any character any time which will match any string)
(.*) – Capturing group which contains a wildcard match for any string in the given place
Include your https://domain.com/store page
Include your https://domain.com/store page (with case-insensitive redirection)
Include a single file, such as https://domain.com/store.php:
Include all files of the same type, such as all of the PHP files.
Include everything that contains a certain phrase, such as https://domain.com/*store*
It is recommended to specify the redirection string “/” to decrease the chance of it redirecting something unwanted. Note: Since our tool automatically applies regex, .* are automatically applied and aren’t needed in this case.
/store or /store/
Include both of the following URLs: https://mydomain.com/fast-racing and https://mydomain.com/fast-car-racing
Here is another example from our article on Disabling Google AMP. We needed to redirect all blog posts containing /amp/ to their original non-AMP URL to ensure that they got re-indexed to their original URLs. In other words, we catch everything before /amp/ in the URI and append-only that in place of “$1”.
Redirect www traffic to non-www (and vice versa)
Add a 301 redirect for all www traffic to non-www.
If you set up your redirects incorrectly it’s possible for it to cause an infinite redirect loop, in which case you might see an error like ERR_TOO_MANY_REDIRECTS. If this is the case, you will want to go back through your redirect rules and double check them. This commonly happens when the location URL is included in both “Redirect From” and “Redirection To.”
For example, the following would cause a redirect loop:
Why? Because once the process reached ^/blog/about, the remaining part -me wouldn’t matter, and it would cause an infinite loop. You have to specify the end of the string and the starter point. Here is what you would do to fix it:
Perhaps you have a more complex setup or want to get rid of your 301 redirect plugin on your WordPress site. We also have the option for you to bulk import redirect rules from a CSV.
To add bulk import redirect rules click on your site in MyKinsta and go to “Redirects.” Then click on “Bulk Import.”
Paste the contents of a CSV file in the field. The CSV should contain information separated by commas in this order: status code, domain (all for all domains), redirect from path and redirect to URL. Each redirect rule should be placed on a new line. Then click on “Import Redirects.”
Bulk import redirect rules
Bulk deletion of redirect rules is also supported.
How to Export Redirects
We realize that some of you have hundreds or even thousands of redirects. Having the ability to export them allows for easier editing offline and re-importing, as well as the ability to easily transfer your redirects to another tool or service as needed. This is where the “Exports to CSV” option comes in handy.
Export redirects to CSV
Exporting Redirects from WordPress
If you are wanting to migrate your current redirects from a WordPress plugin to MyKinsta, many of them have export options available in their settings (export option example below from the EPS redirects plugin). Just ensure they are properly formatted before bulk importing.
For more complex redirects you might need to open up a support ticket. Since we don’t run Apache, you can’t use .htaccess. Instead, we run NGINX which has its own rewrite rule syntax; whatever you can do with .htaccess files you can “translate” to Nginx’s syntax and we’ll add them to your site’s NGINX config file.
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, and also to collect analytics to better understand our visitors and offer them a better experience. You can accept all cookies at once or fine-tune your preferences in the cookie settings.
Thanks, we've saved your settings, you can modify them any time on the cookie settings page
These cookies are needed for our website to function providing payment gateway security and ther essentials. Therefore they are always on but they do not contain personally identifiable information (PII).
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 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 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.
This cookie contains information about the affiliate who refered a visitor. The cookie contains no information about the visitor whatsoever.
Analytics help us deliver better content to our audience. We have made sure no personally identifiable information (PII) is sent by anonymizing IPs.
Analytics cookies allow us to gather data to help us better understand our visitors and offer them a better experience.
Set and used by Hotjar. We use Hotjar to analyze user behavior without identifying the user.
Marketing cookies help us target our ads better. We mainly use them to target ads to users who have visited Kinsta.
Set and used by Twitter, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by AdRoll for remarketing and targeting advertisements to users who have visited kinsta.com.
Set and used by Facebook, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by Quora, used for targeting advertisements to users who have visited kinsta.com.