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.
How to Add a Redirect Rule
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.
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
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.
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.
www.mydomain.com - ^(.*)$ - https://mydomain.com$1
Too Many Redirects
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:
^/blog/about Redirect To:
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:
^/blog/about$ Redirect To:
The $ character will tell Nginx to stop and match the request only if the string is there exactly, but nothing after it.
Further Regex Reading
Here are some helpful links for further reading about what you can do with Regex, and understanding the basics:
How to Bulk Import Redirect Rules
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 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.
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.
If you are using the Simple 301 Redirects plugin you can use this Export Simple 301 Redirects to CSV plugin.
Our team is happy to help set up simple redirections. However, 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. If your site’s .htaccess file includes a lot of complex rules, you will need to work with a developer to convert these into Nginx format and then supply the converted rules to our team.