Path Redirects

(For full domain redirects, check out the Project Settings > Domains page)

You can configure path level redirects via the Servd dashboard ranging from simple, full string matches to complex regex-based rewrites.

Path redirects are configured on a per-environment basis, allowing you to test specific configurations in Staging before copying those same settings over to production.

You can configure path redirects from the [Environment] > Redirects page in the dashboard.

Redirects are evaluated before any other logic within your project. If a redirect matches the incoming request a response will immediately be sent back to the client without PHP or Servd's caching layer coming into play.

Redirects are evaluated in order. The first one in the list which matches the incoming URL pattern will be used and no further redirects will be checked.

Incorrectly formed redirects can take your entire project offline. We have put several safeguards in place to try to prevent this from happening, but you should always test new redirects in staging before applying them to production.

All redirects are formed from three elements:

  1. From: a pattern which is checked against the incoming URL path (the part after the domain, excluding query params). If this pattern matches the redirect takes effect.
  2. To: the resulting location of the redirect. This can optionally contain capture groups collected in the From pattern.
  3. Permanent: whether the redirect should return a 301 or 302 status code.

The From pattern is evaluated as regex. The full scope of regex is too large to discuss here, but you can learn more here and try some examples here.

Examples #

Here are some common patterns which you might find useful:

Exact match redirect to another URL

From: ^/the-old-path$
To: /the-new-path

Exact match redirect to another website

From: ^/the-old-path$

Remove a section from the path for multiple URLs using a capture group

From: ^/news/category/(.*)$
To: /news/$1

Capture multiple segments of a URL

From: ^/blog/([^/]+)/[0-9]{4}/([^/]+)$
To: /$1/$2

The above pattern would match the path /blog/category/2020/blog-post-name and return a redirect to /category/blog-post-name.

Common Problems

Redirect Loops

It is important to consider what will happen once your redirect has taken place and the subsequent request is sent to the server. Will it be matched by the same redirect again? If so it could result in an infinite redirect loop.

A common example is adding a From value of /:

From: /
To: /admin

Because we use regex to match the From string, the value of / will match every possible path (they all begin with a /) resulting in an infinite redirect loop. For this reason we explicitly block a From value of / being used. Instead we recommend using ^/$ which will only match the path / exactly, and nothing else.

Similarly, consider the following redirect to add a portion to the URL:

From: ^/news/(.*)$
To: /news/archive/$1

The path /news/an-article will match the From pattern and return a redirect to /news/archive/an-article which is exactly what we want, but the end-user's browser will then send another request to the server with this new path.

The new path also matches the From pattern, so the server will respond with another redirect to /news/archive/archive/an-article and this will loop until the end-user's browser gives up trying.

The regex required to avoid these situations can be complex. In this particular circumstance we can use a negative lookahead:

From: ^(?!.*/archive/)/news/(.*)$
To: /news/archive/$1

We'll leave it to you to figure out exactly why that works 🙂