Why can an unanchored MyKinsta redirect cause a loop?

Definition: An unanchored MyKinsta redirect is a redirect-from pattern without the ^ start anchor and, when an exact path is intended, without the $ end anchor. MyKinsta automatically treats redirect-from values as regular expressions, so a short pattern can match inside a longer path and send the request through the same rule again.

Key facts

• Kinsta says its redirect tool uses regular expressions automatically, so ^ should begin every from path unless matching beyond the beginning is intended (Kinsta redirect rules documentation).
• Kinsta gives /blogpost matching /category/blogpost as an example that could create a redirect loop (Kinsta redirect rules documentation).
• Kinsta documents ^ as matching the beginning of the line and $ as matching the end of the line (Kinsta redirect rules documentation).
• Kinsta fixes its /blog/about example by changing the from pattern to ^/blog/about$, so the suffix -me in the destination cannot satisfy the same rule (Kinsta redirect rules documentation).

Why does a short pattern match a longer path?

MyKinsta interprets the Redirect from field as a regular expression. A pattern such as /blogpost contains the path text but does not require that text to begin at the path boundary. Kinsta therefore warns that this pattern can also match /category/blogpost. If the destination still contains the original matching text, the next request can satisfy the same rule and continue the redirect chain.

The documented beginning anchor is ^. Kinsta says to add it at the beginning of every from path unless a match elsewhere in the path is wanted. This makes /blogpost mean a path beginning with that text, while /category/blogpost no longer matches that prefix.

Why is the end anchor needed?

The start anchor alone still allows additional characters after the target path. Kinsta’s example uses a rule from /blog/about to https://domain.com/blog/about-me. Because the destination begins with the same text as the from pattern, the remaining -me does not prevent another match. Kinsta describes that result as an infinite redirect loop.

For an exact path, use both documented anchors:

Redirect from: ^/blog/about$
Redirect to: https://domain.com/blog/about-me

Kinsta explains that $ makes the rule match only when the string ends there. The destination /blog/about-me therefore contains extra characters after /blog/about and fails the exact from pattern.

What do ^ and $ mean in a regular expression?

MDN’s input boundary assertion reference defines an input boundary as the start or end of a string. It states that ^ asserts the start of input and $ asserts the end of input, and that these assertions do not consume characters.

MDN also shows the general use of both assertions when a pattern must match an entire input instead of a substring:

/^[$_\p{ID_Start}][$_\p{ID_Continue}]*$/u

The same boundary idea explains the MyKinsta correction. ^ restricts where the match starts, while $ restricts where it ends. Kinsta’s redirect syntax uses the anchors in the path pattern, with the destination kept separate from the match.

How can you test the rule?

Kinsta recommends testing redirect changes with its HTTP status and redirect checker. The documentation says the tool can review response headers, client-side errors, and the redirect chain for a URL. Test the old path, a longer path containing the same text, and the destination path after adding the anchors.

Related terms

• Can MyKinsta redirects match a URL's query string?
• Does importing a redirect CSV replace existing MyKinsta rules?
• How can a MyKinsta redirect match uppercase and lowercase paths?

FAQ

Does ^ alone make a MyKinsta path exact?

No. Kinsta documents ^ for the beginning and $ for the end. Use both when the rule should match one complete path.

Why can /blog/about loop when it redirects to /blog/about-me?

The destination still starts with /blog/about, so the unanchored end of the from pattern can match it again. Kinsta’s documented fix is ^/blog/about$.

Can a rule accept both a path with and without a trailing slash?

Yes. Kinsta documents the optional ? quantifier and shows the pattern ^/oldpath/?$ in its bulk import examples. The slash before ? is optional, while the anchors keep the path bounded.

Sources

1. Kinsta, "Redirects", 18 February 2026
2. MDN Web Docs, "Input boundary assertion: ^, $", 27 August 2026

---

Check how a page reads to answer engines. Open the GEO score analyzer