Edge Redirects

TL;DR — An edge redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. is a normal 301 or 302 redirectA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore., but instead of living in your website’s code or server config, it lives on your CDN — the network (like Cloudflare) that sits in front of your site. The redirect fires at the CDN before the request ever reaches your real server, so you can ship it in minutes with no code deploy, and it keeps working even while you’re moving to a new server. For Google’s purposes, the redirect itself works like any other server-side redirect — same status code, same Location header. That doesn’t mean everything about it is identical to an origin redirect (cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., security rules, and how fast it reaches every visitor can all differ), but the part Google reads is the same. The one thing to watch: don’t leave an old redirect running on your server and add a new one at the edge for the same URL — you’ll accidentally chain them.

What an edge redirect is

An edge redirect is still an HTTP redirect; “edge” describes where the response is generated. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection Google evaluates the returned redirect response and target rather than awarding a special benefit for CDN execution. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Redirects and Search

Most websites sit behind a CDN (content delivery network) — a global network of servers that sits between your real server (the “origin”) and the outside world, and serves your site quickly from a location near each visitor. Cloudflare is the best-known one; Akamai, Fastly, Vercel, and Netlify are others.

An edge redirect puts your redirect on that CDN instead of on your website. When someone (or GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.) requests an old URL, the CDN answers first — it returns the redirect straight from the edge and sends the visitor to the new URL, before the request ever touches your real server.

You can set up a normal redirect in a few different places:

• In your app or CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. — a WordPress redirect plugin, a rule in your framework, or a line in an .htaccess file on the server.
• At the edge — a rule in your Cloudflare, Fastly, or Vercel dashboard.
• In JavaScript — the page loads, then a script sends the browser somewhere else. (That’s a different animal with its own tradeoffs — see the JavaScript redirectsA JavaScript redirect is a client-side redirect that uses code like window.location.replace() to send a visitor (and crawler) to a different URL. Because it only fires after the page is downloaded and rendered, Google prefers server-side and meta refresh redirects above it. article for that side.)

This article is about the middle one: doing it at the edge.

Why people do it at the edge

Three big reasons:

• It’s fast to ship. No developer, no deploy, no release cycle — you add a rule in a dashboard (or upload a spreadsheet of them) and it’s live in minutes.
• It survives a migration. If you’re moving to a new site and shutting down the old server, edge redirectsAn edge redirect is a 301/302 (or 307/308) redirect executed at the CDN layer — Cloudflare, Akamai, Fastly, Vercel, Netlify, or Lambda@Edge — before the request reaches your origin server, so it works even during a migration when the old origin is being decommissioned, across platforms that don't support server-side redirects, and without a code deploy. keep working because they don’t depend on that old server being alive.
• It works when you can’t touch the server. On locked-down platforms (like some ecommerce systems) you may have no way to add a server-side redirect at all — the CDN is the only place you can.

Does Google care that it’s at the edge?

Not for the part it actually reads. Google sees a status code (like 301) and a Location header telling it where to go — it has no idea whether that came from your CDN or your real server, so a 301 is a 301 either way for redirect interpretation. So an edge redirect is a proper server-side redirect as far as SEO is concerned.

That equivalence is specifically about the response — the status code and the destination URL. It doesn’t mean an edge redirect and an origin redirect are identical in every other respect: caching behavior, which security rules run first, how fast the change reaches every visitor worldwide, and what shows up in your logs can all differ between the two layers. And moving an otherwise-identical redirect from your origin to the edge isn’t a ranking booster on its own — there’s no evidence it improves rankings or crawl budgetThe number of URLs an engine will crawl in a timeframe. by itself. What matters for SEO is that the redirect resolves correctly and stays that way, not which layer served it.

The one beginner mistake to avoid

Don’t stack redirects. If your old server already redirects /old → /new, and then you also add an edge redirect for /old, you can end up with two redirects in a row (a “chain”) instead of one clean hop — or, in the worst case, a loop where the two keep bouncing the request back and forth. The rule of thumb: when you move a redirect to the edge, remove the old one. Replace it; don’t pile on top of it.

Want the platform-by-platform version, the exact status codes, how the chain/loop trap actually happens, and how to test a redirect straight from the edge? Switch to the Advanced tab.

TL;DR — An edge redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. is a 3xx served at the CDN layer before the request reaches the origin. For Google’s redirect interpretation, a 301 from Cloudflare can carry the same status and Location as one from your origin — that bounded equivalence doesn’t extend to identical cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., security, latency, routing, or logs, and it isn’t a ranking booster on its own. Teams move redirects to the edge for rollout speed (no deploy), migration resilience (works when the old origin is gone), multi-origin consolidations, and locked-down platforms. Status-code rules don’t change at the edge: 301/308 permanent, 302/307 temporary; 308/307 only matter for non-GET requests, and query/path/fragment preservation is a product setting you have to check, not a universal default. The edge-specific risk is stacking: an edge rule plus a surviving origin rule for the same URL builds an invisible chain — and a CDN security rule can run before the redirect phase and eat the redirect entirely (verify your own deployed phase order; it’s vendor- and product-specific, not a universal Cloudflare-wide rule). One source of truth, replace not stack, and verify with real GET/non-GET requests, curl -I, DevTools, and GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. — a HEAD request alone isn’t conclusive.

What “at the edge” actually means

CDN workers can generate redirects before a request reaches the origin, but the client receives standard HTTP semantics. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection Migration and canonical outcomes remain subject to Google’s redirect guidance. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Redirects and Search

Every redirect is the same HTTP response — a 3xx status code plus a Location header. What changes with an edge redirect is where in the request path it’s generated. It’s returned by the CDN’s point of presence nearest the visitor or crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index., before the request is proxied to your origin. Three layers, in order of who sees the request first:

1. Edge / infrastructure layer — the CDN (Cloudflare, Akamai, Fastly, Vercel, Netlify, Lambda@Edge). Sees the request first.
2. Origin / application layer — your server config, .htaccess, or CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms./app code. Only runs if the edge passes the request through.
3. Client / renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. layer — a JavaScript redirectA JavaScript redirect is a client-side redirect that uses code like window.location.replace() to send a visitor (and crawler) to a different URL. Because it only fires after the page is downloaded and rendered, Google prefers server-side and meta refresh redirects above it. that fires after the browser loads and renders the page. This is the counterpart topic covered in the JavaScript redirectsA JavaScript redirect is a client-side redirect that uses code like window.location.replace() to send a visitor (and crawler) to a different URL. Because it only fires after the page is downloaded and rendered, Google prefers server-side and meta refresh redirects above it. article — I won’t re-cover window.location, meta refreshA meta refresh redirect is a client-side redirect written as an HTML <meta http-equiv=\"refresh\"> tag (or an equivalent HTTP Refresh header) — not an HTTP status code. The server returns a normal 200, then the browser navigates after the page loads. An instant (0-second) one is read by Google as permanent; a delayed one as temporary., or the render-queue timing here; the short version is that an edge redirect is seen at crawl time as a clean HTTP hop, whereas a JS redirect isn’t visible until a later, uncertain renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. pass.

To a search engine, only the response matters, not the layer that produced it. Google’s guidance is to “Set up server-side redirects whenever possible” — and an edge redirect qualifies, because GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. receives an HTTP 3xx regardless of whether it came from the origin or the CDN.

Be precise about what’s actually equivalent, though: for Google’s redirect interpretation, an edge-generated response can supply the same relevant status code and Location header as an origin-generated one. That’s a bounded equivalence — it covers what Google reads to follow the redirect, not caching, latency, security-rule behavior, routing, observability, or failure modes, which can all differ between the two layers. It’s also not a ranking mechanism: no reviewed evidence shows that moving an otherwise identical redirect from origin to edge automatically improves rankings, PageRankPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems. transfer, or crawl budgetThe number of URLs an engine will crawl in a timeframe. on its own. The edge can reduce origin round-trip work, but it isn’t universally faster either — DNS, TLS negotiation, edge-function execution, cache/match behavior, and any extra hops in the chain can dominate a given request just as easily as an origin round trip would.

Why teams move redirects to the edge

Four structured reasons, not just “it’s faster”:

• No deploy required. You ship a rule through a dashboard or a bulk CSV upload, live in minutes — no code release, no dev queue. This is the same “beat the dev-backlog” motivation that drives edge SEOEdge SEO (serverless SEO) is the practice of making technical SEO changes — redirects, meta tags, canonicals, hreflang, robots.txt, structured data — at the CDN/edge worker layer before the response reaches the user or crawler, instead of editing the origin server or CMS. generally; the edge SEO hub covers the broader governance and platform-lock context.
• Migration resilience. Because the redirect resolves at the CDN before hitting the origin, it keeps working even after the old origin server is fully decommissioned — as long as DNS/CDN routing for the old domain still flows through the CDN. Bing makes this exact architectural argument in its migration guidance: it recommends standing up “a new separate minimal server or load balancer with the redirect rules” on something like Azure and pointing the old domain’s DNS at it, “to handle all redirects of the old domain going forward without it impacting the server of the new hostname.” That’s the edge-redirect pattern in all but name: keep the redirect-serving infrastructure separate from (and lighter than) your production origin.
• Multi-origin consolidations. During a brand rollup or platform migration you may be redirecting across several different origins at once. The edge sits above all of them, so one rule set can span origins that individually can’t redirect to each other.
• Locked-down platforms. On SaaS/enterprise platforms that don’t expose server-side redirect config, the CDN is often the only place you can implement a redirect at all. Cloudflare frames its own tooling exactly this way — letting teams “implement URL redirects in the cloud without the need to have administrator access to the origin.”

Fastly puts the “why edge” case bluntly: “Ensuring URLs never die is one of the most important aspects of a good SEO strategy, and the edge is the best place for redirects, so that they can be served as fast as possible.” Its own redirects tutorial adds the operational motivation — servers often handle millions of requests for old and non-canonical URLs, which degrades origin performance and clutters logging if you keep that at the origin.

None of this changes the redirect fundamentals (map 1:1, don’t bulk-redirect everything to the homepage, keep redirects live far longer than a year) — the site migrationsA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once. article covers those and I’m treating them as assumed background here.

Choosing the right status code at the edge

The status-code rules are identical to redirects anywhere — the edge doesn’t invent new ones:

The 301-vs-308 and 302-vs-307 split only matters for non-GET requests — forms and API endpoints where the HTTP method and body must be preserved on the hop. For ordinary page-to-page SEO redirects (all GET), 301 remains the conventional, SEO-safe default. Google is explicit that all permanent methods land the same: all permanent redirection methods have the same effect on Google Search, though “the time it takes for us to notice the different redirect methods may differ.”

Platform defaults differ, and that trips people up. Cloudflare’s Bulk Redirects and Single Redirects lean toward 301/302; Vercel explicitly recommends 307/308 to avoid the method-switching ambiguity that 301/302 carry (its docs are built around API routes as much as pages); Fastly’s own redirect tutorial example defaults to 308. The takeaway: pick your code from permanence and method-preservation need, not from whatever the platform’s example happens to use. For a permanent content move you almost always want 301.

The chain/loop risk unique to edge + origin stacking

This is the failure mode this article exists to warn about, because it’s specific to the edge and under-explained everywhere else.

The stacking pattern

The two dangerous layers — edge and origin — are configured in different systems, by different people, with no shared visibility. That’s the whole problem. A concrete sequence:

1. Marketing adds an edge Bulk Redirect A → B during a rebrand.
2. Six months later, engineering ships an app-level redirect B → C during a replatform — and never touches (or never sees) the edge rule.
3. Now a request for A hits the edge (A → B), gets proxied to the origin for B (B → C), and resolves as A → B → C: an invisible two-layer chain neither admin can fully see from their own dashboard.

Point the two rules at each other instead and you get a loop — the request bounces forever. Google can follow a chain up to a point, but the guidance is unambiguous: “Avoid chaining redirects. While GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. can follow up to 10 hops in a ‘chain’ of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly.” The 10-hop ceiling is a technical limit, not a budget to spend — a fast edge redirect that’s part of a two-layer chain is still a chain.

The general mechanics of chains and loops (the 10-hop limit, the per-crawl behavior, diagnosing them) live in the redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency. and redirect loopsA redirect loop is a chain of redirects that circles back on itself instead of ever reaching a live page — URL A redirects to B and B redirects back to A (or a longer cycle). No page ever returns a 200, so browsers show ERR_TOO_MANY_REDIRECTS and crawlers can't index anything. write-ups; I’m focused here on the edge-specific cause.

WAF-before-redirect: your security rules can eat the redirect

There’s a second, sneakier edge trap. In Cloudflare’s currently documented pipeline (Cloudflare Ruleset Engine phases reference, checked 2026-07-16), Bulk Redirects specifically run in the http_request_redirect phase, which executes after the WAF managed-rules phase (http_request_firewall_managed). So if a security rule — or bot-fight mode — blocks or challenges the request first, the Bulk Redirect never fires at all. Googlebot can be silently blocked before your carefully configured redirect rule ever runs. This is the redirect-specific version of the “your CDN can accidentally block Googlebot” risk the edge SEO hub documents for edge SEO broadly.

Treat that ordering as an example, not a universal law. Redirect, rewrite, WAF, origin, header-transform, and cache phases are vendor-, product-, version-, plan-, and configuration-specific — the Bulk Redirects order above doesn’t automatically apply to Cloudflare’s Single Redirects or Workers, and it says nothing about Akamai, Fastly, Vercel, Netlify, or Lambda@Edge. Check your own deployed phase graph or rule-trace tool for the platform and product you’re actually using instead of assuming this exact order carries over.

The classic edge-specific loop: SSL mode vs. origin HTTPS redirect

The single most common edge-specific loop in the wild is a TLS mismatch: a CDN’s SSL/TLS setting (Cloudflare’s “Flexible” mode is the usual culprit) conflicts with an origin-level HTTP→HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' redirect. The edge talks HTTP to the origin, the origin redirects to HTTPS, the edge re-requests, the origin redirects again — forever. The redirect loops write-up flags this HTTPS/SSL-mode mismatch as a common loop cause; it’s worth knowing it by name because it’s almost always the answer when a “working” HTTPS redirect loops behind a CDN.

The fix: one source of truth, replace don’t stack

Maintain a single source of truth for redirect rules — ideally the edge, since it’s the first layer to see the request — and actively retire the equivalent origin-level rule rather than letting both run. Don’t stack; replace. When auditing an existing site, compile every redirect from every source (CMS, CDN, .htaccess/server config, Search Console’s “Page with redirectA Google Search Console Page Indexing status for a URL that redirects elsewhere. It's not indexed by design because it's a redirect — the destination is a separate question, and Google says the target may or may not end up indexed — usually expected, not an error (unlike the separate \"Redirect error\").” report, analytics) before you add anything new — miss one source and you manufacture the exact chain you’re trying to avoid.

TIP Catch an edge-origin loop in the final response path

A dashboard rule can look valid in isolation while another layer sends the destination back to the source. Test the compiled chain from outside the stack.

Trace the live redirect with my free Redirect Checker Free

1. Test representative sources through the public hostname after edge and origin rules are active.
2. Find the layer that revisits a prior URL and replace stacked rules with one owner.
3. Point each source directly to its final destination and rerun the trace.

Tap to enlarge

The result labels the chain broken and fix now. It shows 301 from URL A to URL B, 302 from B back toward A, then 301 to A, with no final URL. It also warns about three redirects and a temporary redirect inside a permanent chain.

Platform-by-platform mechanics

The short version of where each platform’s redirect tooling sits. (The edge SEO hub has the broader Snippets-vs-Workers and platform-capability comparison; this is the redirect-specific slice.)

• Cloudflare. Bulk Redirects (CSV/list-based, account-level, no regex) for large migration maps; Single Redirects / Redirect Rules (regex, wildcards, dynamic expressions) for per-rule logic; Workers for anything needing a KV-backed lookup table beyond Bulk Redirects’ scale, or custom logic. Cloudflare’s own framing for why the category exists: URL redirects ensure visitors keep reaching the right content, and without them, links in emails, blogs, and brochures fail — “potentially costing the business revenue in lost sales and brand damage.”
• Akamai. Edge Redirector Cloudlet (a no-code UI for match/redirect rules) for straightforward cases; EdgeWorkers (JavaScript) with EdgeKV for large or logic-driven redirect tables. Enterprise-oriented — typically more provisioning than Cloudflare’s self-serve dashboard.
• Fastly. No no-code redirect UI for most setups — redirects are implemented in VCL (a vcl_recv/vcl_error pattern using a synthetic response with obj.status and obj.http.Location) or the newer Compute platform. Developer-oriented; best fit for teams already running custom VCL.
• Vercel. vercel.json config redirects for pattern/wildcard/geolocation rules; a dedicated Bulk Redirects feature (CSV/JSON/JSONL) for large lists; Edge Config + Middleware for redirects that need to update without a redeploy. Note the 307/308 default recommendation above.
• Netlify. The _redirects file or netlify.toml [[redirects]] blocks; supports 301/302, 200 (rewrite), and 404; a force flag (!) overrides file-shadowing; splats and placeholders handle pattern matching; edge-level geoGenerative Engine Optimization — visibility inside AI answer engines./language redirects are built in.
• Lambda@Edge (AWS/CloudFront). A full Node.js runtime at the edge — the most flexible option, but the highest latency and cold-start overhead here. Best when the redirect logic needs more than pattern matching (custom business logic, external lookups) and the team is already CloudFront-native.

A useful mental sort: no-code tools (Cloudflare Bulk/Redirect Rules, Netlify _redirects, Vercel vercel.json) handle simple 1:1 and wildcard redirects with no code; compute options (Workers, EdgeWorkers, Compute, Lambda@Edge) are for conditional redirects, large dynamic lookups, or geolocation branching that the no-code tools can’t express. You don’t need a Worker to do a simple redirect.

Conditional redirects: cache keys, forwarded headers, and open-redirect risk

Not every edge redirect is a static 1:1 mapping. Once a rule branches on geo, device, language, authentication state, a cookie, or a forwarded header, a few edge-specific failure modes show up that a simple redirect never hits:

• Decision inputs need matching field availability. A rule can only branch on a signal the platform actually exposes at the phase it runs in. On CloudFront, for example, viewer-request logic runs before the cache lookup on every matching request, while origin-request logic only runs when CloudFront forwards to the origin after a cache miss — so the same conditional logic sees different fields, executes at a different frequency, and has different cost and observability depending on which phase you put it in. Confirm which phase your platform’s conditional-redirect feature actually runs in before assuming a field (geo, cookie, header) is available.
• Cache-key alignment is not automatic. If the redirect destination depends on geo, device, language, auth state, or a cookie, the cache key has to vary by those same inputs — otherwise the edge can serve one visitor’s cohort-specific redirect to a different cohort, or the redirect function may not even see the input it needs to decide correctly. This is the single most common cause of “it works for me but not for [other users]” bug reports on conditional edge redirectsAn edge redirect is a 301/302 (or 307/308) redirect executed at the CDN layer — Cloudflare, Akamai, Fastly, Vercel, Netlify, or Lambda@Edge — before the request reaches your origin server, so it works even during a migration when the old origin is being decommissioned, across platforms that don't support server-side redirects, and without a code deploy..
• Credential and privacy boundaries. Don’t let an authenticated or cookie-scoped redirect response get cached and served to a different, unauthenticated visitor — keep credential-dependent redirects out of the shared cache or key them explicitly by the credential/session dimension that decided the destination.
• Bot and locale consistency. A conditional rule that redirects search crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. to a different destination than regular visitors based on geo/locale/bot detection can read as cloaking if the two paths diverge in substance, not just presentation — keep crawler and visitor behavior aligned unless you have a documented, policy-compliant reason to differ (see the edge SEO hub’s cloaking guidance).
• Fallback behavior. Define what happens when the deciding signal is missing or ambiguous (no geo match, no cookie, unrecognized locale) — an unhandled fallback can silently 404, redirect to the wrong default, or skip the redirect entirely.
• Open-redirect guard. Any redirect that carries a destination from user input — a login redirect with a ?return= parameter is the classic case — needs an allowlist, safe URL parsing and encoding, and loop prevention. Copying an untrusted destination parameter straight into the Location header is an open-redirect vulnerability, not just an SEO risk.
• First-match shadowing. A terminating edge redirect can prevent later redirect, rewrite, or origin logic from ever running. If you have overlapping or duplicate conditional rules, test precedence against the exact request shape (method, headers, query) rather than assuming the dashboard’s rule order matches execution order.

Testing and verifying edge redirects

Don’t trust the dashboard UI, and don’t trust a single HEAD request either — verify the response the edge actually returns for the request types that matter.

• A HEAD request isn’t conclusive. curl -I defaults to a lightweight probe, but method, body, headers, cookies, cache state, geo, and bot/security decisions can all make a real GET, POST, or authenticated request behave differently than a bare HEAD. Trace the request types that actually matter for the URL — typically a real GET, plus any non-GET methods (form submits, API calls) if the redirect covers those routes — without letting the client auto-follow, so you can read the first hop’s status and Location in isolation.
• curl -I is still the fastest first check. curl -I https://example.com/old-url shows the raw status code and Location header straight from the edge, with no browser cache or JS interference. Follow the whole chain with curl -sIL to count hops, but also test the query, path-suffix, and fragment cases that matter for the URL: does an appended path suffix survive, do query strings pass through unchanged (empty, present, repeated, and conflicting query cases can all behave differently), and remember fragments (#section) are never sent to the server at all — a redirect can’t preserve or transform a fragment it never receives, so any fragment on the destination has to come from configured output or client-side behavior.
• Browser DevTools → Network tab. Confirm the redirect fires with the expected status in the Status column and the right Location. Then check cache-related headers (cf-cache-status on Cloudflare, x-vercel-cache on Vercel, x-nf-request-id on Netlify, x-cache on Fastly/CloudFront) to see whether the redirect itself is being cached — a cached redirect can delay a fix from propagating.
• GSC URL Inspection is the authoritative check on what Googlebot actually received, independent of what curl or DevTools show from your network location. If curl says 301 but GSC shows something else, believe GSC.
• Test from multiple regions and cohorts, and check both edge and origin logs. Edge rules can propagate at different speeds across a CDN’s global network right after a change — a dashboard “success” state doesn’t prove every point of presence is serving the new rule yet, so don’t assume instant, universal propagation. Test from more than one geographic point and, for conditional rules, from more than one cohort (the geo/device/auth states the rule branches on). Record the response status, Location, cache/security headers, and a request ID where the platform provides one, and check edge and origin logs where available — logs are often the only place that shows whether the WAF or a security rule intercepted a request before the redirect phase.
• Roll out with a canary and a tested rollback. For redirects that affect meaningful traffic, ship to a subset first and confirm the response matrix above before a full rollout. Test the rollback path too, and make sure rolling back doesn’t silently restore a conflicting old layer (the origin or app-level rule you were replacing) — that’s exactly the stacking failure this article’s chain/loop section warns about, just triggered by an incident response instead of a deploy.

Common myths

• “Google handles edge and application redirects differently.” No — Google sees a status code and a Location header and has no visibility into the layer that produced them. Same PageRank/signal treatment.
• “Moving a redirect to the edge fixes a chain.” Only if you also remove the old origin rule. Adding an edge rule on top of a surviving origin rule doesn’t replace anything — it adds a hop.
• “Edge redirects are automatically better for SEO because they’re faster.” Partly overstated. They cut origin load and can shave latency, but avoiding chains and using the correct status code matter far more to crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. than raw speed. A fast redirect inside a two-layer chain is still a chain.
• “CDN security features can’t interfere with redirect rules.” They can — the WAF phase runs before the redirect phase on Cloudflare, so a blocked/challenged request never reaches the redirect.
• “You need a Worker/Compute script for any edge redirect.” No — for simple 1:1 and wildcard redirects the no-code tools are enough; compute is for custom logic.

If you’re looking for the client-side counterpart — window.location, meta refresh, and the render-queue timing that makes JS redirects riskier for SEO — that’s the JavaScript redirects topic, not this one.

AI summary

A condensed take on the Advanced version:

• An edge redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. is a 3xx served at the CDN layer (Cloudflare, Akamai, Fastly, Vercel, Netlify, Lambda@Edge) before the request reaches the origin. For Google’s redirect interpretation, an edge 301 can carry the same status and Location as an origin 301 — a bounded equivalence that covers what Google reads, not identical cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., security, latency, routing, propagation speed, or logs, and it isn’t a ranking booster on its own.
• Why teams do it: ships in minutes with no deploy; survives a migration when the old origin is being decommissioned (as long as DNS/CDN routing for the old domain keeps working); spans multiple origins during a consolidation; and works on locked-down platforms where server-side config isn’t exposed. Bing makes the same “separate minimal server/load balancer for redirects” argument in its migration guidance.
• Status codes don’t change at the edge: 301/308 permanent, 302/307 temporary; the 308/307 variants only matter for non-GET (forms/APIs). Platform defaults differ (Cloudflare 301/302, Vercel 307/308, Fastly 308) — choose by permanence + method need, not the platform default. Query-string, path-suffix, and fragment preservation are explicit product settings, not universal defaults — test empty/present/repeated/ conflicting query cases and remember fragments are never sent to the server at all.
• The edge-specific risk is stacking: an edge rule A→B plus a surviving origin rule B→C = an invisible two-layer chain neither admin sees from their own dashboard; point them at each other and it’s a loop. Google follows up to 10 hops but says avoid chaining entirely.
• CDN security can eat the redirect: in Cloudflare’s currently documented pipeline, Bulk Redirects specifically run after the WAF managed-rules phase, so a blocked or challenged request never reaches that redirect rule — but phase order is vendor-, product-, and configuration-specific, so verify your own deployed phase graph rather than assume the same order elsewhere.
• Classic edge loop: CDN SSL “Flexible” mode conflicting with an origin HTTP→HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' redirect.
• Conditional redirects (geoGenerative Engine Optimization (GEO) is the practice of optimizing content and brand presence so AI-powered search engines and assistants — Google AI Overviews, ChatGPT, Perplexity — cite, recommend, or mention you when generating answers. Google's position is that it's still SEO./device/auth/cookie-based) need cache keys that vary by the same inputs the rule decides on, a defined fallback when the signal is missing, and an open-redirect guard — never copy an untrusted destination parameter straight into Location.
• Verify with more than a HEAD request: trace real GET and relevant non-GET requests, curl -I/curl -sIL, DevTools cache headers, and GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. — not just the dashboard. Test from multiple regions/cohorts, since propagation isn’t instant or universal, and canary + test rollback before high-traffic changes.
• Fix for stacking: one source of truth, replace the old layer (don’t stack).

Official documentation

Primary-source documentation from the search engines and the CDN platforms.

Google

• Redirects and Google Search — the preference for server-side redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. and how permanent methods are treated.
• Site moves and migrations with URL changes — the redirect-chain guidance and the 10-hop limit.
• Crawling December: CDNs and crawling (2024) — why Google treats CDN-fronted sites differently, and how a CDN’s own security layer can block a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. before your rules run.

Bing / Microsoft

• Website Migration with Bing (Dec 2020) — the “separate minimal server/load balancer for redirects” pattern and redirect-duration guidance.

CDN / platform docs (implementation reference, not search-engine authority)

• Cloudflare — Bulk Redirects — the CSV/list-based bulk redirect tool.
• Cloudflare — Ruleset Engine phases list — confirms http_request_redirect runs after http_request_firewall_managed (WAF managed rules).
• Fastly — Redirects tutorial — the VCL synthetic-response pattern and origin-load rationale.
• Vercel — Redirects — vercel.json redirects, status-code guidance, and the 307/308 recommendation.
• Netlify — Redirect options — the _redirects/netlify.toml syntax, status codes, force flag, and splats.

Quotes from the source

On-the-record statements. Each link is a deep link that jumps to the quoted passage on the source page.

Google — server-side redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. and chains

• “All permanent redirection methods (HTTP 301, HTTP 308) have the same effect on Google Search, but the time it takes for us to notice the different redirect methods may differ.” — Google Search Central, Redirects and Google Search. (The same page recommends: “Set up server-side redirects whenever possible.”) Jump to quote
• “a server side redirect has the highest chance of being interpreted correctly by Google.” — Google Search Central, Redirects and Google Search. Jump to quote
• “Avoid chaining redirects. While GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. can follow up to 10 hops in a ‘chain’ of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly.” — Google Search Central, Site moves and migrations with URL changes. Jump to quote

Bing — do redirects on separate/edge-adjacent infrastructure

• “To improve server resources for example.ai, a new separate minimal server or load balancer with the redirect rules can be set up and configured, e.g. on Azure, and point the DNS of www.example.com to this instance to handle all redirects of the old domain going forward without it impacting the server of the new hostname.” — Bing WebmasterMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. Blog, Website MigrationA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once. with Bing. Jump to quote
• “the redirects on the old domain need to remain live for at least 1 to 2 years, preferably longer.” — Bing Webmaster Blog, Website Migration with Bing. Jump to quote
• “CrawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. the new website thereafter will reveal any unexpected errors, such as unnecessary redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency. or error pages.” — Bing Webmaster Blog, Website Migration with Bing. Jump to quote

Fastly — why the edge is the right place for redirects

• “Ensuring URLs never die is one of the most important aspects of a good SEO strategy, and the edge is the best place for redirects, so that they can be served as fast as possible.” — Fastly, 3 ways the edge simplifies SEO. Source

Cloudflare — why edge redirect tooling exists

• “URL redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. ensure visitors continue to see the correct content. Without these URL redirects, hyperlinks in emails, blogs, marketing brochures, etc. would fail to load, potentially costing the business revenue in lost sales and brand damage.” — Cloudflare Blog, Maximum redirects, minimum effort: Announcing Bulk Redirects. Cloudflare positions the feature as letting teams “implement URL redirects in the cloud without the need to have administrator access to the origin.” Source

Should you do this redirect at the edge?

Whatever you pick, the non-negotiable is one source of truth per URL: if the edge is handling the redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., remove the equivalent origin rule so you don’t build a chain or a loop.

Edge-redirect deployment checklist

Before and after you ship an edge redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't.:

• Confirmed no existing origin/app/.htaccess rule already redirects this URL — or retired it so you’re not stacking two layers.
• Checked Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s “Page with redirectA Google Search Console Page Indexing status for a URL that redirects elsewhere. It's not indexed by design because it's a redirect — the destination is a separate question, and Google says the target may or may not end up indexed — usually expected, not an error (unlike the separate \"Redirect error\").” report and any CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms./CDN redirect exports for the same URL (compile every source before adding).
• Chose the correct status code from permanence + method need: 301 (permanent GET), 308 (permanent non-GET), 302/307 (temporary) — not the platform default out of habit.
• Confirmed the redirect points straight to the final destination, not to another URL that itself redirects (no chain).
• Verified the CDN’s WAF / botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.-fight rules aren’t blocking or challenging the request before the redirect phase runs (GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. must reach the redirect).
• For HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' redirects: checked the CDN SSL/TLS mode isn’t “Flexible” against an origin HTTP→HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' redirect (the classic edge loop).
• Tested with curl -I (and curl -sIL to count hops) from the command line — not as the only check: also traced a real GET, and any non-GET methods the URL actually serves, since a HEAD probe alone isn’t conclusive.
• Checked query-string and path-suffix behavior (empty, present, repeated, and conflicting query cases) and confirmed the final Location, not just the first hop.
• For conditional rules (geoGenerative Engine Optimization (GEO) is the practice of optimizing content and brand presence so AI-powered search engines and assistants — Google AI Overviews, ChatGPT, Perplexity — cite, recommend, or mention you when generating answers. Google's position is that it's still SEO./device/auth/cookie-based): confirmed the cache key varies by the same inputs the rule decides on, and that no untrusted destination parameter is copied straight into Location.
• Checked the Network tab for the status, Location, and cache-status headers.
• Confirmed with GSC URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. actually received.
• Tested from more than one region/PoP and, for conditional rules, more than one cohort — don’t assume the change is live everywhere just because the dashboard shows success.
• For high-traffic redirects: rolled out via canary first, and tested that rollback doesn’t silently restore a conflicting old origin/app-level rule.
• Documented the rule in your single source of truth so the next person doesn’t add a conflicting one.

Edge redirect cheat sheet

Status codes

Platform → redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. tooling

Platform default status codes (don’t inherit blindly)

• Cloudflare: 301/302 · Vercel: recommends 307/308 · Fastly tutorial: 308

Cache-status headers to check in DevTools

• Cloudflare cf-cache-status · Vercel x-vercel-cache · Netlify x-nf-request-id · Fastly/CloudFront x-cache

The three verification tools

• curl -I (raw status + Location, no cache) → DevTools Network (cache headers) → GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. (what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. saw).

The one rule

• One source of truth per URL. Replace the old layer; never stack on it.

Verify an edge redirect from the command line

curl -I is the fastest way to see the raw status code and Location header straight from the edge — no browser cache, no JavaScript.

macOS / Linux

# Single request: status line + headers only
curl -I https://example.com/old-url
# → HTTP/2 301
# → location: https://example.com/new-url
# → cf-cache-status: DYNAMIC        (Cloudflare cache header, platform-specific)

# Follow the WHOLE chain and count hops — you want ONE hop, not three
curl -sIL https://example.com/old-url | grep -Ei "^HTTP|^location"

# Pretend to be Googlebot to check for bot-specific blocking at the edge (WAF/bot-fight)
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/old-url

Windows (PowerShell)

# -MaximumRedirection 0 stops it from silently following the redirect,
# so you see the 3xx and the Location header instead of the final 200
$r = Invoke-WebRequest -Method Head -MaximumRedirection 0 `
     -Uri "https://example.com/old-url" -SkipHttpErrorCheck
$r.StatusCode
$r.Headers["Location"]

Browser DevTools console — quick redirect check

Paste in the console (DevTools → Console). fetch with redirect: "manual" returns an opaque response but a non-followed status, so it’s a fast “is there a redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. here?” probe; the Network tab is still where you read the exact status and cache headers.

// Does this URL redirect at the edge, and does the fetch get blocked first?
fetch("https://example.com/old-url", { method: "HEAD", redirect: "manual" })
  .then(r => console.log("type:", r.type, "status:", r.status || "(opaque redirect)"))
  .catch(e => console.log("blocked or network error:", e.message));

Bookmarklet — inspect the current page’s redirect trail

Save as a bookmark; click it on any page to log the redirect chainA → B → C instead of A → C. Each hop loses link equity and adds latency. the browser followed to get there (each entry is one hop — more than one means a chain to flatten).

javascript:(function(){performance.getEntriesByType("navigation").forEach(function(n){console.log("redirects:",n.redirectCount,"| redirect time(ms):",Math.round(n.redirectEnd-n.redirectStart),"| final URL:",location.href);});})();

A redirectCount above 1 on a page you thought had a single clean redirect is your signal that an edge rule and an origin rule are stacking.

Tools for building and checking edge redirects

• Redirect Map Builder — review the map, keep unmatched/410 decisions explicit, and export a deployable Netlify _redirects file or standalone Cloudflare WorkerA serverless function that runs at Cloudflare's global edge, close to every user. JavaScript. It also exports a WordPress Redirection import CSV plus a separate human-review evidence CSV when the CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. plugin, rather than the edge, owns the write route.
• curl — the ground-truth CLI check for status code, Location, and hop count (curl -I, curl -sIL). Nothing else is faster or more trustworthy.
• Browser DevTools → Network tab — see each hop’s status, Location, and the platform cache-status header (cf-cache-status, x-vercel-cache, etc.) to tell whether a redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. is being cached.
• Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. — the authoritative view of what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. actually received from your edge, independent of your own network location.
• Cloudflare dashboard — Bulk Redirects (CSV upload), Redirect Rules, and the Rules → Trace tool to see which phase acts on a request (confirming WAF isn’t eating the redirect).
• Screaming Frog SEO SpiderA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. / Ahrefs Site Audit — crawl the site to surface redirect chains and loops across the whole URL set, including ones created by edge+origin stacking.
• httpstatus.io / redirect-checker tools — quick multi-hop redirect-chain visualizers for spot checks and sharing with non-technical stakeholders.
• The platform config files themselves — vercel.json (Vercel), _redirects / netlify.toml (Netlify), VCL (Fastly) — keep these in version control as your single source of truth.

Playbook: an edge redirect chains, loops, or never fires

1. Capture the public behavior before editing. Run curl -I without following and curl -sIL for the trail; repeat with the verified crawler user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. and, if relevant, another region. If the first response is a challenge or block instead of a 3xx, go to step 2; if it redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. and then fails, go to step 3.
2. Check phases before redirect logic. Inspect WAF, botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.-management, and security events for the request. If a rule blocks/challenges before the redirect phase, correct the narrowly scoped security condition and re-test; do not rewrite the redirect rule to compensate for a request that never reaches it.
3. Compile every rule layer for the failing URLs. Export CDN/edge redirectsAn edge redirect is a 301/302 (or 307/308) redirect executed at the CDN layer — Cloudflare, Akamai, Fastly, Vercel, Netlify, or Lambda@Edge — before the request reaches your origin server, so it works even during a migration when the old origin is being decommissioned, across platforms that don't support server-side redirects, and without a code deploy., origin/server rules, CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms./application rules, and relevant platform configuration. Trace the exact A→B→C path. If two layers own the same source or destination cohort, choose the intended source of truth before changing either.
4. Check TLS mode when the loop is HTTP/HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'. Compare the CDN-to-origin SSL mode with the origin’s HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' redirect. If the edge contacts the origin over HTTP while the origin forces HTTPS, correct the encryption mode or remove the conflicting layer, then test again.
5. Flatten to the final destination. Replace A→B→C with A→C and retire the superseded origin/app rule rather than stacking another edge rule. Preserve the intended permanence and method behavior.
6. Purge only the affected cached redirect state. If the corrected config is live but an old 3xx persists, invalidate the relevant edge cache/key according to the platform’s process. If uncached requests are still wrong, return to the rule inventory instead of waiting.
7. Verify all request classes and document ownership. Confirm one expected hop, correct Location, no challenge, correct destination response, and the same intended behavior in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.. Record the surviving rule in the single source of truth.

Edge redirect mistakes that survive a dashboard review

Add an edge rule on top of an origin rule

Moving a redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. to the edge fixes a chain only when the old layer is retired. Otherwise it adds a hop or creates a loop. Compile every layer and replace ownership; do not stack it.

Treat edge speed as the SEO win

Lower origin latency is useful, but a fast redirect with the wrong status, a generic destination, or multiple hops is still broken. Optimize correctness and direct mapping before milliseconds.

Assume security rules cannot intercept redirects

On platforms where WAF/botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. phases execute first, a block or challenge prevents the redirect from firing. Test crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. request classes and inspect phase/security events, not only the redirect dashboard.

Inherit the platform’s example status code

Vendors demonstrate different defaults. Choose 301/308 for permanent moves and 302/307 for temporary ones based on method-preservation needs, not copied sample code.

Redirect missing URLs to the homepage

A broad homepage dump destroys relevance and may be treated as a soft 404A soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing.. Map to the closest legitimate replacement or return a real not-foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. response when no equivalent exists.

Use compute for every simple rule

Workers and edge functions add code, deployment, cache, and debugging surface. Use the platform’s declarative/bulk redirect tool for straightforward one-to-one and wildcard mappings; reserve compute for real conditional logic or dynamic lookups.

Audit a compiled redirect inventory

Audit this combined redirect inventory from CDN/edge, origin/server, CMS/application,
and framework config. Normalize source and destination URLs, then report:
1. Multiple layers claiming the same source
2. Chains with the complete hop path
3. Loops and the rules that close them
4. HTTP/HTTPS behavior that can conflict with CDN-to-origin TLS mode
5. Permanent versus temporary status mismatches
6. Redirects to homepages, generic categories, errors, or another redirect
7. Sources with no unique final destination
8. A proposed single-source-of-truth map pointing directly to final destinations

Preserve query/path behavior only when the supplied requirements say to. Do not invent
replacement URLs. Put unmapped sources in manual review instead of sending them to the
homepage.

Inventories and platform execution order:
[PASTE CSV/CONFIG]

Review one edge redirect incident

Trace this curl -I / curl -sIL output together with the CDN rule, origin rule, WAF event,
cache headers, and SSL mode. Identify the first layer that changes or blocks the request,
the minimal correction, what rule must be retired, and the exact commands/requests to
prove a clean single hop afterward. Separate confirmed evidence from assumptions.

Incident evidence:
[PASTE OUTPUT]

Resources worth your time

My related writing

• Redirects for SEO: A Complete Guide — redirect typesA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., status codes, and when to use each (the fundamentals this article assumes).
• 301 vs. 302 Redirects: Which Should You Use? — the permanent-vs-temporary decision.
• Are Permanent Redirects Permanent? — how long 301s actually stick, and what that means for retiring old rules.
• The Beginner’s Guide to Technical SEO — where redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. sit in the bigger technical picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and serving, which is the pipeline an edge redirect intercepts. (Standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Cloudflare — Bulk Redirects docs — the authoritative implementation reference for large redirect maps on Cloudflare.
• Cloudflare — Ruleset Engine phases list — proof that WAF managed rules run before the redirect phase (the “security rule eats the redirect” trap).
• Cloudflare Blog — Maximum redirects, minimum effort: Announcing Bulk Redirects — why the bulk-redirect category exists and the “no admin access to origin” motivation.
• Fastly — Redirects tutorial — the VCL synthetic-response pattern and the origin-load argument for moving redirects to the edge.
• Vercel — Redirects docs — vercel.json redirects, status codes, and the 307/308 recommendation.
• Netlify — Redirect options — _redirects/netlify.toml syntax, status codes, force flag, and splats.
• Oncrawl — Creating & Managing Redirects on The Edge — the closest existing write-up framing redirects-on-the-edge as its own topic.

Test yourself: Edge Redirects

Five quick questions on implementing and verifying redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. at the CDN layer. Pick an answer for each, then check.

Edge Redirects

An edge redirect is a 301/302 (or 307/308) redirect executed at the CDN layer — Cloudflare, Akamai, Fastly, Vercel, Netlify, or Lambda@Edge — before the request reaches your origin server, so it works even during a migration when the old origin is being decommissioned, across platforms that don't support server-side redirects, and without a code deploy.

Related: Edge SEO, Redirect, Redirect chain, Redirect loop, 301 redirect, JavaScript Redirect

Edge Redirects

Edge redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. are 301/302 (and 307/308) redirects implemented at the CDN or edge-compute layer — Cloudflare Bulk Redirects, Redirect Rules, or Workers; Akamai Edge Redirector or EdgeWorkers; Fastly VCL or Compute; the Vercel Edge Network; Netlify Edge; or Lambda@Edge on CloudFront — instead of in application code, a CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. plugin, or .htaccess on the origin server. The request is redirected before it ever reaches the origin: the CDN’s point of presence closest to the visitor (or crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.) returns the 3xx response directly.

That placement is what makes them useful. Because the redirect resolves at the edge, it keeps working even when the old origin is offline, decommissioned, or mid-migration, and across multiple origins during a platform consolidation — and it ships in minutes through a dashboard or bulk upload with no code deploy or CMS release cycle.

From a search engine’s point of view an edge redirect is a server-side redirect. Google sees an HTTP status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. and a Location header; it has no visibility into whether that response came from a CDN edge node or the origin, so a 301 from the edge can carry the same redirect signal as a 301 from the origin. That equivalence is bounded to what Google reads to interpret the redirect — it doesn’t mean the two are identical in cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., security, latency, routing, or logs, and moving an otherwise-equivalent redirect to the edge isn’t a ranking booster on its own.

Edge redirects are the infrastructure layer of redirect implementation, distinct from the origin/application layer (server config, CMS) and from the client/renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. layer (JavaScript redirectsA JavaScript redirect is a client-side redirect that uses code like window.location.replace() to send a visitor (and crawler) to a different URL. Because it only fires after the page is downloaded and rendered, Google prefers server-side and meta refresh redirects above it.). The edge-specific risk is stacking: an edge rule and a surviving origin rule for the same URL can create an invisible chain or loop, because the two layers are configured in different systems with no shared visibility.

Related: Edge SEO, Redirect, Redirect chain, Redirect loop, 301 redirect, JavaScript Redirect

Changelog