Netlify’s redirect rules accept a number of options to customize how the paths are matched and redirected. The examples on this page use the
_redirects file syntax, but all of these options are available in the Netlify configuration file syntax as well.
# HTTP status codes
HTTP status codes are sent in server responses to the client or browser. The code gives information about the type of response.
You can specify the HTTP status code for any redirect rule. If left unspecified, the default is
Here are some examples of status codes you might use:
301(default): Permanent redirect. Tells the client that the address for this resource has permanently changed, and any indexes using the old address should start using the new one. The URL in the browser address bar will display the new address.
302: Temporary redirect. Tells the client that the current address change is temporary. The URL in the browser address bar will display the new address.
404: Not found. You can use this status code to present custom 404 pages when visitors access paths on your site that don’t exist. With this status code, the page content will change, but the URL in the browser address bar will not.
200: OK. Redirects with this status code will change the server response without changing the URL in the browser address bar. This is used for rewrites and proxying.
Here are some example redirect rules with status codes:
# Redirect with a 301 /home / 301 # Redirect with a 302 /my-redirect / 302 # Show a custom 404 for this path /ecommerce /store-closed 404 # Rewrite a path /pass-through /index.html 200
# Custom 404 page handling
You can set up a custom 404 page for all paths that don’t resolve to a static file. This doesn’t require any redirect rules. If you add a
404.html page to your site, it will be picked up and displayed automatically for any failed paths.
You can also use this in combination with other features of our redirects by creating explicit entries for different paths:
/en/* /en/404.html 404 /de/* /de/404.html 404
Due to the shadowing behavior in our redirects system, the 404 pages will only be returned for nonexistent assets under the above paths.
An asterisk indicates a splat that will match anything that follows it.
You can use the splat in your rewrites or redirects like this:
This would redirect paths like
The redirect engine processes the first matching rule it finds, so more specific rules should be listed before more general ones:
# This will redirect /jobs/customer-ninja-rockstar /jobs/customer-ninja-rockstar /careers/support-engineer # This will redirect all paths under /jobs except the path above /jobs/* /careers/:splat # This will never trigger, because the rule above will trigger first /jobs/outdated-job-link /careers/position-filled
You can use placeholders in the origin and target paths:
This would redirect a URL like
/blog/2004/02/12/my-story. A placeholder either matches a path segment from one
/ to the next
/ or matches a final path segment including a file extension but excluding a query string.
# Query parameters
You can also use query parameters to more finely control your URL matches.
While our service automatically passes on all query string parameters to destination paths for redirects with
302 HTTP status, you can also choose to define a redirect path based on a specific parameter or combination of parameters.
The following match redirects a URL like:
/blog/my-blog-post with a
301 redirect. This affects request URLs with an
id query parameter only.
/store id=:id /blog/:id 301
Note that this rule matches only URLs that have only the
id parameter and no others. If the URL contains other parameters in addition to or instead of
id, the request doesn't match that rule.
To match more than one query parameter, add separate key/value pairs separated by space:
/articles id=:id tag=:tag /posts/:tag/:id 301
If you have multiple parameters, some of which are optional, this is the pattern to follow to ensure that we are prepared to handle all possibilities. Note that the most general redirect is after the more specific ones:
# Both values - ordering from the browser doesn’t matter; this will cover either. /path/* param1=:value1 param2=:value2 /otherpath/:value1/:value2/:splat 301 # One value or the other. Must match exactly. /path/* param1=:value1 /otherpath/:value1/:splat 301 /path/* param2=:value2 /otherpath/:value2/:splat 301 # Base case, when no params are passed. # Our system forwards all query params to the /otherpath URL if this is the only rule. # Otherwise it matches all requests not matched in a prior rule for the same path such as the ones above. /path/* /otherpath/:splat 301
Query parameter changes
Query parameters are now passed by default to the destination path even if they aren't specified in a redirect rule. Visit our community forum to learn more about this change to redirects with query string parameters.
# Trailing slash
Our CDN edge nodes do URL normalization before the redirect rules kick in. This happens to make sure we can guarantee the highest possible cache hit rate and the absolute best performance for your site.
What this means for your redirect rules is that Netlify will match paths to rules regardless of whether or not they contain a trailing slash.
# These rules are effectively the same: # either rule alone would trigger on both paths /blog/title-with-a-typo /blog/typo-free-title /blog/title-with-a-typo/ /blog/typo-free-title # This rule will cause an infinite redirect # because the paths are effectively the same /blog/remove-my-slashes/ /blog/remove-my-slashes 301!
You cannot use a redirect rule to add or remove a trailing slash. However, you can enable Netlify’s Pretty URLs feature in Site settings > Build & deploy > Post processing > Asset optimization.
In addition to forwarding paths like
/about/ (a common practice in static sites and single-page apps), it will also rewrite paths like
# Domain-level redirects
All of the examples so far assume configuration for all domains assigned to the site, using the specified paths. If instead you need to do something special for a specific domain alias or protocol (HTTP vs HTTPS), you’ll want a pattern more like this one:
# http and https need separate rules if you don’t force_ssl! http://blog.yoursite.com/* https://www.yoursite.com/blog/:splat 301! https://blog.yoursite.com/* https://www.yoursite.com/blog/:splat 301! # other URLS might proxy or redirect offsite https://frontend.yoursite.com/login/* https://backend.yoursite.com/:splat 200
Refer to the note on shadowing for the reasoning behind the
! — it is presumably the case that you have a
/blog/index.html that you’d rather serve than your site’s main
index.html in this case!
Domains must be assigned to the site
# Redirect by country or language
For large multi-regional or multi-lingual sites, you may want to send site visitors to different content based on their location (by country GeoIP data) or their browser’s language configuration.
Netlify can handle these requests with GeoIP- and language-based redirects directly from our CDN nodes.
Both the language and the country can be specified in a cookie as well (
When you add these redirect rules, Netlify automatically creates alternate headers to enable the redirection in our CDN nodes. This removes the need for a round trip to our origin servers and ensures that normal pages, besides country or language based redirects, are cached on the CDN nodes.
Here are some examples:
# Redirect users in Australia or New Zealand to /anz. # There CANNOT be spaces in the last parameter: Country=x,y,z or Language=xx,yy / /anz 302 Country=au,nz # Redirect users in israel to /israel / /israel 302 Country=il # Redirect users with Hebrew language preference from /israel to /israel/he /israel/* /israel/he/:splat 302 Language=he
The system is smart enough to flatten chains of redirect. So in the above case, if a user in Israel with Hebrew language preference visits
/, they’ll get redirected directly to
/israel/he in one step. Our cache server will cache this redirect for any other users that would match the same country and language rules.
Country attribute accepts ISO 3166 country codes.
Language attribute accepts standard browser language identification codes.
General and regional language codes
General language codes will match all regional variations. For example,
en will match
zh will match
# Redirect by role
Role-based redirects let you restrict access to certain paths of your application to logged-in visitors with certain roles, as authorized by Netlify Identity or any authentication provider that supports JSON Web Tokens (JWT). (Role-based redirects using external authentication providers may not be available on all plans.)
This access control is implemented at our CDN edge, removing the need for a round trip to our origin servers.
For more information, visit the page on Role-based access control.
# Edge Handlers
Did you find this doc useful?
Your feedback helps us improve our docs.