You can add redirect rules from right within MyKinsta! Redirect rules allow you to seamlessly direct traffic from one location to another. This 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.
Prefer to watch the video version?
How to Add a Redirect Rule
To add a redirect, click on your site in MyKinsta and go to Redirects. Then click the Add redirect rule button.
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 regular expressions (regex).
- 301 redirect: Used for URLs and or content that is “moved permanently.” Typically this is the one you’ll want to use for SEO purposes.
- 302 redirect: Used for URLs and or content that is “found” or “moved temporarily.”
In the 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’ll also notice we added
^ to the beginning of the Redirect from path 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
/blogpost by itself could create a redirect loop on other URLs, such as
It’s also important to check your current backlinks in a tool such as Ahrefs. You may have backlinks on 3rd party sites that point to two different versions of your URL:
Note that the second one has a forward slash on the end of it. If you don’t take this into consideration, it could break the redirect. If you aren’t sure which version third-party sites may link to, you can use the single character wildcard regex quantifier
? instead to ensure that both work:
In the above example, all links to both
/blogpost/ (with the forward-slash) would get redirected to /newblogpost.
After adding redirects in MyKinsta, you can then manage all of your redirect rules there.
Using Regular Expressions (regex)
A regular expression is a sequence of characters that define a search pattern. Below are some additional examples 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.
$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’s some 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|
|.*||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 redirecting something unwanted.
Note: Since our tool automatically applies regex, the
.* wildcard to match anything is automatically applied and isn’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 post on Disabling Google AMP. We needed to redirect all blog posts containing
/amp/ to their original non-AMP URL to ensure they got re-indexed to their original URLs. In other words, we catch everything before
/amp/ in the URI and append that in place of “$1”.
Add a 301 redirect to redirect all www traffic to non-www.
Too Many Redirects
If you set up your redirects incorrectly, it may cause an infinite redirect loop, in which case you might see an error like ERR_TOO_MANY_REDIRECTS. If this happens, you’ll want to go back through your redirect rules and double-check them. This commonly happens when the location URL is included in both the Redirect from and Redirect to fields.
For example, the following would cause a redirect loop:
Why? Because once the process reaches
^/blog/about, the remaining part
-me won’t matter, and it will 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:
$ 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:
Check out our video to learn the WordPress Redirect Best Practices to Maximize SEO and Page Speed:
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 file.
To add bulk import redirect rules, click on your site in MyKinsta, go to Redirects, and click on the Bulk import button.
Paste the contents of your CSV file in the field provided. 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. Place each redirect rule on a new line. Click the Import redirect rules button.
Bulk deletion of redirect rules is also supported by selecting the checkbox next to each rule. Once you select one or more rules, a Delete redirect rules button appears near the upper right corner.
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 and the ability to easily transfer your redirects to another tool or service as needed. This is where the Export to CSV option comes in handy.
Exporting Redirects from WordPress
If you want 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’re using the Simple 301 Redirects plugin, you can use this Export Simple 301 Redirects to CSV plugin to export your redirects.
Our team is happy to help set up simple redirects. 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.