In short. Use (?i) at the start of a MyKinsta redirect pattern when the path should match letters in either case.
Definition: MyKinsta's Redirects tool is case-sensitive by default. To let a regular-expression path match letters in either case, prepend the documented inline modifier
(?i)to the from pattern, as in(?i)^/store.
Key facts
- Kinsta's redirect rules documentation was last updated on 18 February 2026 and says the Redirects tool is case-sensitive by default.
- The
Redirect fromfield supports regular expressions. Kinsta'sRedirect tofield separately supports capture group references and variables such as$hostand$scheme. - Kinsta lists
(?i)as the regex syntax for case-insensitive matching and gives(?i)^/storeas the example for the/storepage. - Redirect rules are checked in the order they are added, with Kinsta recommending more specific rules before general ones.
- The PCRE2 pattern reference explains that
(?i)makes letters match independently of case within the pattern.
What is the default MyKinsta behavior?
Kinsta's documentation places redirect creation at Sites > sitename > Redirects, followed by Add redirect rule. The same page says that the tool uses regular expressions and that the Redirect from field accepts them. Its default is case-sensitive, so the letter case written in the pattern matters unless the pattern enables the documented modifier.
The rule is a path pattern. Kinsta lists ^ as matching only when the following text is at the beginning of the line, and $ as matching when the previous text is at the end. Those anchors remain available when the pattern also uses (?i).
How do you write the case-insensitive pattern?
Place (?i) at the start of the pattern, before the beginning anchor and path text:
^/store
(?i)^/store
The first line is a case-sensitive pattern. The second is Kinsta's documented case-insensitive form. The inline modifier changes how letters in the pattern are compared, while ^ still marks the beginning of the path. The PCRE2 pattern reference, updated 25 October 2025, describes (?i) as an option setting inside a pattern and says that caseless matching makes letters match independently of case.
For a path containing store, this lets the same rule handle path spellings whose letters use different uppercase and lowercase forms. The source page documents the modifier and pattern, while the PCRE2 reference explains the matching meaning of the syntax.
What else should you check in the rule?
Kinsta says that redirects are checked in the order they are added and recommends placing specific rules before general rules. A case-insensitive general pattern can therefore be considered alongside the ordering of other rules. The page also lists #, spaces, quotation marks, and line breaks as restricted characters, and says that redirects cannot be made by arguments.
After adding or removing a rule, Kinsta recommends clearing the cache. Its documentation also points to an HTTP status and redirect checker that reviews response headers, client-side errors, and redirect chains. Test the path with the letter cases you expect, then inspect the response and its destination.
Related terms
- Why can an unanchored MyKinsta redirect cause a loop?
- Can MyKinsta redirects match a URL's query string?
- HTTP redirects
FAQ
What should I enter for a case-insensitive /store path?
Enter (?i)^/store in the MyKinsta Redirect from field. Kinsta gives this exact pattern as its case-insensitive example.
Does (?i) belong in the destination field?
Kinsta documents (?i) in the regular-expression syntax for the Redirect from pattern. The Redirect to field is documented separately for capture group references and variables.
Will this make a query argument part of the match?
No. Kinsta says that redirects cannot be made by arguments and that MyKinsta Redirects cannot redirect query strings. The modifier changes letter matching in the path pattern.
Sources
Check how a page reads to answer engines. Open the GEO score analyzer