Redirect rules are a surprisingly powerful tool for managing how users and search engines interact with your website, and you can configure them entirely at the CDN level, completely bypassing your application code. This means you can implement changes like permanent URL redirects (301s) or temporary ones (302s) without needing to deploy new code, restart servers, or even touch your development team.

Let’s see this in action. Imagine you’ve rebranded from "OldBrand" to "NewBrand" and want all traffic hitting oldbrand.com to seamlessly land on newbrand.com. Here’s how you’d configure that at the CDN (using a hypothetical CDN syntax, but the principles apply to AWS CloudFront, Cloudflare, Akamai, etc.):

{
  "rules": [
    {
      "name": "Redirect OldBrand to NewBrand",
      "condition": {
        "host": "oldbrand.com"
      },
      "action": {
        "type": "redirect",
        "status_code": 301,
        "target": "https://newbrand.com$path"
      }
    }
  ]
}

In this configuration:

  • name: A descriptive label for the rule.
  • condition: This specifies when the rule should apply. Here, it’s when the incoming request’s host header matches oldbrand.com. You can use more complex conditions, like matching specific URL paths (/old-page) or even query parameters.
  • action: This defines what happens when the condition is met.
    • type: "redirect": Clearly indicates a redirect action.
    • status_code: 301: This is crucial. A 301 Permanent Redirect tells browsers and search engines that the page has permanently moved. This is vital for SEO, as it transfers link equity. A 302 Temporary Redirect would be used if the move was short-lived.
    • target: "https://newbrand.com$path": This is the destination. $path is a placeholder that injects the original request’s path (e.g., /products/widgets) into the new URL, so https://oldbrand.com/products/widgets redirects to https://newbrand.com/products/widgets.

The mental model here is that your CDN acts as a highly efficient, global proxy. Before a request even hits your origin servers (where your application lives), the CDN inspects it based on a set of predefined rules. If a rule matches, the CDN executes the specified action – in this case, sending a redirect response back to the client. This offloads a significant amount of traffic management from your application and infrastructure.

You can use these rules for a variety of scenarios beyond simple domain changes:

  • Consolidating HTTP to HTTPS: Redirect all http://example.com/* to https://example.com/*.
  • Canonicalizing URLs: Ensure all requests for example.com/page (without a trailing slash) redirect to example.com/page/ (with a trailing slash), or vice-versa, to prevent duplicate content issues for SEO.
  • Path-based routing: Directing traffic for /api/* to one origin and /images/* to another, all without application logic.
  • Geo-targeting: Redirecting users from specific countries to localized versions of your site.
  • A/B testing: Sending a percentage of traffic to a different version of a page or feature.

The underlying mechanism is essentially a sophisticated, distributed if-then-else statement executed at the edge. When a request arrives at a CDN edge server, it’s evaluated against the rule set. The first rule whose condition evaluates to true triggers its action. This evaluation happens before the request is forwarded to your origin, meaning your origin server never sees the original request for oldbrand.com in our example.

When configuring these rules, especially for SEO-critical redirects like 301s, it’s important to understand the difference between $path and $uri. While often interchangeable, $uri typically includes the query string, whereas $path usually does not. If you need to preserve query parameters, you’d often use something like https://newbrand.com$uri or construct the target URL explicitly if your CDN offers advanced query string manipulation. For instance, redirecting example.com/search?q=widgets to newbrand.com/search?q=widgets requires preserving the query string.

The power of CDN redirect rules lies in their ability to decouple presentation and routing logic from your core application. This makes your application more portable, easier to scale, and allows for rapid iteration on user-facing URL structures without code deployments.

If you’re setting up redirects for an e-commerce site, you’ll often find yourself needing to redirect old product URLs to new ones after a redesign or product update. The complexity arises when you have thousands of these, and you need to ensure the mapping is correct and that you’re using the appropriate HTTP status code for SEO. The CDN’s ability to handle these bulk redirects efficiently at the edge is a significant operational advantage.

Once you’ve mastered basic redirects, the next logical step is to explore advanced conditional logic, such as combining host, path, and header conditions, or implementing dynamic redirects based on user attributes.

Want structured learning?

Take the full Cdn course →