Daniel sent us this one — and it's a good one. He's been building websites since the late two-thousands, selling Wix sites to local businesses back in high school, and he's noticed something. He's never really paid much attention to them, and he suspects he probably should. The core question is straightforward: we all know 301 is the permanent redirect, but what do the other codes actually mean, and when should you use them? And then there's a deeper tactical question — if you're using Cloudflare, which a lot of us are, should your redirect logic live at the edge, at the Cloudflare layer, or should it happen when the traffic hits your actual server? And finally, when you do this right, what happens with search engines? How does the indexation actually work?
This is exactly the kind of thing where most people just cargo-cult the 301 and hope for the best. And honestly, for maybe eighty percent of cases, that works fine. But the other twenty percent is where you either leak SEO value, confuse browsers, or create debugging nightmares that surface at two in the morning. So let's unpack the status codes first, because the numbers aren't arbitrary — they map to specific browser and crawler behaviors.
Before you dive into the code zoo, I want to flag something Daniel mentioned that I think a lot of people feel but don't articulate. He said redirects are one of those things he's never really paid much attention to but probably should. That's the redirect experience in a nutshell. They're infrastructure plumbing. Nobody thinks about them until a migration goes sideways and suddenly half your URLs are serving 404s and your traffic falls off a cliff.
That's exactly why knowing the codes matters. So let's start with the family tree. Redirect status codes live in the three-hundred range, and they break into roughly two categories: permanent and temporary. The permanent ones are 301 and 308. The temporary ones are 302, 303, and 307. And then there's the weird cousin, 300 and 304, which aren't really redirects in the way most people mean.
The weird cousin who shows up at Thanksgiving and nobody's quite sure what they do.
So 301 — Moved Permanently. This is the one everyone knows. It tells the browser and search engines: this resource has permanently moved to a new location. Update your bookmarks. Pass the link equity. The key thing people miss is that a 301 can change the request method from POST to GET. That's a browser behavior quirk — most browsers will switch a POST request to a GET when following a 301, which can break things if you're not expecting it.
Wait, so if someone submits a form to an old endpoint and you've 301'd it to a new one, the form data just vanishes?
In most browsers, yes. The POST becomes a GET, the body gets dropped, and your form submission silently fails. That's where 308 comes in. 308 is Permanent Redirect, but it explicitly preserves the request method. POST stays POST. It was introduced in RFC 7538, which is relatively recent in web standards terms — 2015. Before that, if you needed a permanent redirect that preserved the method, you were out of luck.
308 is basically 301 with a seatbelt.
That's a perfect way to put it. And here's the thing — 308 adoption has been slow. A lot of frameworks and CMSes still don't expose it as an option. You'll see 301 everywhere, but 308 is genuinely underused for cases where it's the correct choice. API versioning is the classic example. If you're deprecating an old API endpoint and moving it permanently, you want a 308 so that POST, PUT, and PATCH requests are preserved intact.
That's the permanent side. What about the temporary ones? Because I feel like 302 gets thrown around without much thought.
302 is the original sin of redirects. It was defined in HTTP 1.0 as "Moved Temporarily," but the spec was vague about method preservation, so browsers handled it inconsistently. Some preserved POST, some switched to GET. It was a mess. That's why HTTP 1.1 introduced 303 and 307 to clean up the ambiguity. 303 says "See Other" and it always, unconditionally, switches the request to GET. This is the one you use after a form submission — the classic post-redirect-get pattern. User submits a form, you process it, and you 303 them to a confirmation page. The browser drops the POST, fetches the new URL with GET, and if they refresh, they don't resubmit the form.
Which is the thing that prevents you from accidentally ordering the same pizza twice.
Or donating to the same political campaign seventeen times, yes. And 307 is the mirror image — Temporary Redirect that preserves the method. POST stays POST. It was meant to replace the ambiguous 302 behavior. So to summarize: 301 and 302 are the old guard, widely supported but with method-switching quirks. 307 and 308 are their modern, method-preserving counterparts. And 303 is the specialized tool for form submissions.
The cheat sheet is: permanent and you don't care about method — 301. Permanent and you need POST to survive — 308. Temporary and you want the browser to switch to GET — 303. Temporary and you need the method preserved — 307. And 302 is legacy cruft you probably shouldn't use in new development.
And I'd go further — if you see 302 in a codebase written after, say, 2010, it's usually a sign that someone wasn't thinking carefully about redirect semantics. Now, there's also 300 Multiple Choices and 304 Not Modified. 300 is barely used — it's supposed to let the browser choose from multiple representations, but in practice nobody implements it. And 304 isn't really a redirect at all. It's the server saying "this resource hasn't changed since you last asked, use your cached copy." It's a performance mechanism, not a navigation tool.
I want to circle back to something you said about link equity and 301s. Daniel mentioned SEO value and backlinks — he's worried about preserving traffic when he migrates. What actually happens when Google hits a redirect?
This has evolved. The old understanding was that a 301 passed somewhere around ninety to ninety-nine percent of PageRank — there was always a little debate about the exact figure, and Google's John Mueller has been deliberately vague about it over the years. But the current guidance, as of roughly 2024 onward, is that 301s pass full link equity after Google processes the redirect and re-indexes the new URL. The key word there is "after." It's not instantaneous.
There's a processing lag where you're in limbo.
Yes, and that lag depends on how often Google crawls your site. For a news site that gets crawled constantly, the redirects might be processed within hours. For a small business site that gets crawled once a week, it could take days or weeks. During that window, your old URLs are still in the index, and the new ones haven't been discovered yet. That's why you never want to remove the old URLs or drop the redirects prematurely.
Daniel specifically asked about Google Search Console and whether the process is seamless.
It can be, if you do it right. The proper workflow is: you set up your redirects, you verify they're working, then you go into Search Console and use the URL Inspection tool on the old URLs. That tells Google "hey, this has moved, go crawl it." You can also submit a change of address if you're moving an entire domain. But here's the thing a lot of people miss — you should keep those redirects in place for at least a year. Some SEO practitioners say eighteen months. Google's official recommendation is to keep them "as long as possible," which is vague but directionally correct.
A year minimum. That's a commitment a lot of people don't plan for when they're excited about their shiny new site.
It's where the Cloudflare question gets really interesting. Because if your redirects live on your origin server, and a year later you migrate servers again or change your stack, you have to remember to carry those redirects forward. If they live at the Cloudflare layer, they're infrastructure-independent. Your origin can change completely and the redirects keep working.
Which is a perfect segue into the second part of the prompt. Daniel's asking: if you can do redirects at the Cloudflare edge or at the origin server, which should you choose? And he's specifically asking about a scenario with a few hundred redirects that follow a predictable pattern definable as regex.
Let's talk about the Cloudflare redirect architecture, because it's not just one thing. Cloudflare actually offers two distinct redirect products. There are Single Redirects, which are rule-based — you define a matching condition and a target, and you can use regex capture groups. And there are Bulk Redirects, which are designed for exactly the scenario described in the prompt: you have a list of specific URL mappings, potentially hundreds or thousands of them, and you want them processed at the edge with minimal latency.
What's the practical difference between the two?
Single Redirects are evaluated as part of Cloudflare's Ruleset Engine. They support complex matching expressions — you can redirect based on the URL path, query string, headers, cookies, the visitor's country, the request method, all sorts of things. And they support regex, including capture groups, so you can do pattern-based redirects elegantly. Bulk Redirects, by contrast, are essentially a lookup table. You upload a list of source URLs and target URLs, and Cloudflare matches against that list. They're simpler, faster for exact matches, and don't support regex — they're literal URL matching with some limited wildcard support.
For the scenario Daniel described — a few hundred redirects with a predictable path structure definable as regex — Single Redirects are the obvious choice. You write one rule instead of uploading a three-hundred-line CSV.
And that's the key decision point. If your redirects are pattern-based, use Single Redirects with regex. If they're a messy, one-off mapping with no consistent pattern — like a CMS migration where every slug changed arbitrarily — use Bulk Redirects and upload the mapping table. And both of these execute at the edge, meaning the redirect happens at the Cloudflare data center closest to the user, before the request ever touches your origin server.
What's the argument for doing it at the origin instead?
A few things. First, if you're not using Cloudflare — but Daniel is, so that's moot. Second, if your redirect logic depends on application state that only exists on your server. For example, if you need to check whether a user is logged in, or look up something in a database to determine where they should go, you can't do that at the edge. Cloudflare's redirect rules are stateless — they only have access to what's in the request itself.
That's the "can't check the database" problem. But for a news site with a predictable path structure, there's no database lookup needed. The old URL pattern maps deterministically to the new one.
The third argument for origin-side redirects is logging and analytics. If the redirect happens at Cloudflare, your origin server never sees the request. That means your server logs won't show the redirect traffic, and any analytics that depend on server-side processing won't capture it. Now, Cloudflare provides its own analytics, and you can see redirect metrics in the dashboard, but if you're feeding server logs into a custom analytics pipeline, edge redirects are invisible to it.
Daniel hinted at that — he said we could discuss analytics capture but we should leave it for another day. So let's flag it and move on. The analytics question is real, but for most people, the performance benefit of edge redirects outweighs the logging gap.
The performance benefit is substantial. An edge redirect at Cloudflare adds essentially zero latency — it's processed in the same data center that terminates the TLS connection. The user gets the redirect response before their request ever traverses the internet to your origin. If your origin server is in Virginia and your user is in Singapore, an origin-side redirect adds maybe two hundred milliseconds of round-trip time plus processing. An edge redirect adds single-digit milliseconds.
For a news site, where you might have readers all over the world, that two hundred milliseconds is the difference between someone waiting and someone bouncing.
There's another factor that doesn't get talked about enough: what happens when your origin is down? If your redirects live on your origin server, and that server goes offline, your redirects go offline too. Users hitting old URLs get connection errors instead of being smoothly redirected. If the redirects are at Cloudflare, they keep working even if your origin is completely unreachable. That's a resilience argument that becomes compelling once you've been through a few outages.
I've been through those outages. The redirects are the last thing you're thinking about during the incident, and the first thing you realize you should have thought about afterward.
Here's my rule of thumb, and I'm curious if you agree. If your redirects are purely URL-pattern-based with no application logic — which is the scenario described in the prompt — do them at Cloudflare. Use Single Redirects with regex. You get better performance, better resilience, and easier maintenance. The rules live independently of your application stack. If your redirects require application state, do them at the origin. And if you need full analytics visibility on redirect traffic, either do them at the origin or set up Cloudflare Logpush to capture redirect events.
I'd add one nuance. There's a middle ground where you do the simple pattern redirects at Cloudflare and the complex stateful ones at the origin. You don't have to pick one layer and put everything there. The Cloudflare rules let you set priorities, so you can have your edge rules run first, and anything that doesn't match falls through to your origin.
That's actually the best practice. Cloudflare's Ruleset Engine processes rules in phases, and redirect rules run early in the request lifecycle. If a redirect matches, it fires immediately. If not, the request proceeds to the next phase and eventually to your origin, where your application can handle anything the edge didn't catch. It's a layered defense.
Let me pull on a thread Daniel mentioned. He talked about web application firewalls and that intermediate layer, and said he often gets confused about what's the best place to do things. I think that confusion is widespread because Cloudflare has become this Swiss Army knife that does so many things — DNS, CDN, WAF, redirects, caching, workers — that it's not always obvious which feature should handle which problem.
The mental model that helps is to think about the request lifecycle. A request hits Cloudflare. First, DDoS protection filters it. Then the WAF inspects it for attack patterns. Then redirect rules run. Then cache lookup happens — if it's cached, serve from cache. If not, the request goes to your origin. Each layer has a specific job, and redirects belong early in that pipeline because there's no point in doing a cache lookup or hitting the origin for a URL that's just going to redirect anyway.
The redirect happens before the WAF?
After basic DDoS filtering, but before the full WAF inspection in most configurations. The logic is: if this request is going to be redirected anyway, don't waste WAF processing cycles on it. Redirect it and move on. But you can configure the rule ordering if you have a specific reason to do it differently.
I want to go back to the regex question, because Daniel specifically mentioned predictable path structures definable as regex. What does a good Cloudflare redirect rule actually look like for that scenario?
Let's take a concrete example. Say you're migrating a news site from an old WordPress structure to a new Astro site. Your old URLs looked like slash news slash twenty twenty-five slash zero five slash article-slug. Your new structure is slash articles slash article-slug. You've dropped the date hierarchy. A Single Redirect rule with regex would match the pattern — something like slash news slash asterisk slash asterisk slash asterisk — and use a capture group to extract the slug, then redirect to slash articles slash the captured slug. One rule handles every article.
The capture group is the magic there — you're pulling the slug out of the old URL and dropping it into the new one.
And Cloudflare's regex support includes capture groups in the target URL using backslash one, backslash two, and so on. You can also do transformations — convert to lowercase, remove trailing slashes, whatever you need. The key is to test thoroughly, because regex redirects are powerful but they're also a footgun. One badly written rule can redirect your entire site into a loop.
The stuff of nightmares.
They're surprisingly easy to create. You write a rule that matches slash old slash asterisk and redirects to slash new slash asterisk, but then another rule matches slash new slash asterisk and redirects back to slash old slash asterisk. Cloudflare has loop detection — it'll cap redirect chains at something like sixteen hops and then serve an error — but that's a safety net, not a design pattern.
Test in staging, ideally with a tool that can crawl your redirect map and verify every old URL lands where it should.
Keep your redirect map as a document, not just as configuration. I've seen teams where the redirect rules live in Cloudflare's dashboard and nowhere else, and six months later nobody remembers why a particular rule exists or whether it's still needed. Version control your redirect configuration. Cloudflare supports Terraform for this — you can define your redirect rules as infrastructure-as-code, commit them to a repo, and deploy them through a pipeline.
That's the kind of thing that sounds like overengineering until you're the person debugging a mystery redirect at eleven PM on a Friday.
Which brings me to another point about the Cloudflare versus origin decision. If your redirects are in Terraform and deployed to Cloudflare, they're auditable, reviewable, and revertible. If they're buried in your application code or, worse, in an htaccess file on a server that only one person has SSH access to, they're a liability.
The htaccess file. The fossil record of web development, where redirects go to be forgotten.
I've seen htaccess files with redirects from 2007 still active. Nobody knows if they're still needed. Nobody wants to touch them. They're the digital equivalent of that box of cables in your closet.
I feel personally attacked.
We all have that box.
Let's talk about the SEO follow-through, because Daniel asked specifically about what happens after a few days when search engines re-spider the site. He wanted to know if it's seamless.
The honest answer is: it's seamless if you've done everything right, and it's a slow-motion disaster if you haven't. When Googlebot hits a 301, it notes the redirect and schedules the new URL for crawling. Over subsequent crawls, it sees the redirect consistently, and it updates its index — the old URL is replaced by the new one. The link equity flows to the new URL. But this process is gradual. Google doesn't flip a switch. It updates its index incrementally, and during that window, both the old and new URLs might appear in search results.
You might temporarily see your traffic split across two URLs.
Yes, and that's normal. The important thing is not to panic and start changing things. Consistency is what Google's algorithms are looking for. If they see a 301 today, a 302 tomorrow, and a 404 next week, they get confused and the indexation process stalls. Set your redirects, verify them, submit the old URLs in Search Console, and then leave them alone.
There's also the sitemap question. When you migrate, you should submit a new sitemap with the new URLs, right?
Submit the new sitemap, but keep the old sitemap active for a while too. The old sitemap tells Google "these URLs still exist, but they redirect," which prompts Google to re-crawl them and discover the redirects. If you remove the old sitemap immediately, Google might not revisit those URLs for a while, and the indexation process slows down.
The old sitemap is like leaving a forwarding address at the post office. You don't cancel it the day you move.
And one more thing about Search Console — use the Change of Address tool if you're moving domains entirely. If it's just a path structure change on the same domain, you don't need that, but the URL Inspection tool on a sample of old URLs can speed things up. Google's official documentation says it can take "a few days to a few weeks" for redirects to be fully processed, but manual submission usually pushes it toward the faster end of that range.
I want to circle back to something we touched on earlier — the 302 versus 301 question in an SEO context. I've seen people use 302s for temporary content moves and then forget about them. What's the SEO impact of a 302 that's been sitting there for six months?
A 302 tells Google "this move is temporary, don't transfer link equity." So if you leave a 302 in place for months, you're essentially telling Google "don't bother indexing the new URL, and don't pass any authority to it." The old URL retains the ranking signals, but it's not serving content. The new URL is serving content, but it's not accumulating any SEO value. It's the worst of both worlds.
A forgotten 302 is an SEO black hole.
It really is. And I've seen cases where a site's traffic dropped thirty percent after a migration, and the culprit was a single 302 that should have been a 301. One misconfigured redirect rule, applied across thousands of URLs, silently bleeding link equity for months. The fix took five seconds once they found it. Finding it took weeks.
That's the redirect experience in a nutshell, isn't it? The consequences are invisible until they're catastrophic.
The tools for auditing redirects are not great. You can use Screaming Frog or Sitebulb to crawl your site and map redirect chains, but most people don't run those audits regularly. They set redirects during a migration and then never look at them again.
Let's talk about redirect chains, actually. Daniel didn't ask about them directly, but they're a common failure mode. Someone sets up a redirect from URL A to URL B, then later sets up a redirect from URL B to URL C. Now you've got a chain.
Every hop in the chain adds latency, dilutes link equity, and increases the chance of something breaking. Google's official guidance is to avoid redirect chains — they recommend redirecting directly from the old URL to the final destination. But in practice, chains accumulate over time, especially on sites that have been through multiple migrations or restructures.
This is where the Cloudflare layer actually helps, because you can see all your redirects in one place and spot chains. If your redirects are scattered across htaccess files, nginx configs, application middleware, and a CDN, good luck untangling that.
There's a specific Cloudflare feature worth mentioning here — you can use Cloudflare's Trace tool to see exactly how a request is processed through the ruleset pipeline. It shows you which rules fired, in what order, and what the final outcome was. It's invaluable for debugging redirect chains and unexpected interactions.
I didn't know about the Trace tool. That sounds like it would have saved me some late nights.
It's relatively new — added in the last couple of years as part of the Ruleset Engine overhaul. You give it a URL and it shows you the entire decision tree. Every rule that matched, every rule that didn't, every action taken. It's the kind of transparency that used to require tcpdump and prayer.
Prayer being the key ingredient in most redirect debugging.
I want to address one more thing from the prompt. Daniel mentioned that Cloudflare is great for many things, and he's been using it so long he can't remember the last time he didn't. I think that's true for a huge portion of the web at this point. Cloudflare's market share is something like twenty percent of all websites, and for good reason. But it also means that a lot of people are using Cloudflare features without fully understanding the architecture underneath. Redirects are a perfect example — the feature is there, it works, but the implications of where you put the redirect logic aren't always obvious.
That's the curse of good abstractions. When something works seamlessly, you don't feel the need to understand it. Until it breaks.
Redirects break in ways that are particularly hard to diagnose because the symptoms are indirect. Your traffic drops. Your rankings slip. Your conversion rate declines. None of those scream "redirect misconfiguration." They scream "something is wrong with the site," and you go looking at the new design, the new copy, the new hosting, when the actual problem is a three-line redirect rule that's been quietly sabotaging you.
If someone's listening to this and thinking about a migration, what's the checklist? Let's be concrete.
Step one: audit your existing URLs. Crawl your site, get a complete list of every URL that exists, and understand which ones have backlinks or organic traffic. Don't redirect what you don't need to, but don't miss anything important. Step two: design your redirect map. Old URL to new URL, one-to-one, no chains. Step three: decide where the redirects will live — Cloudflare edge for pattern-based, origin for stateful, or a mix. Step four: implement and test. Crawl every old URL and verify it lands at the correct new URL with the correct status code. Step five: submit old URLs in Search Console, update your sitemaps, and monitor. Step six: wait at least a year before removing any redirects.
Step zero, which is document everything in version control.
Step zero is the one that saves you when you're doing this again in three years and can't remember what you did.
I want to go back to the status codes one more time, because there's a subtlety we touched on but didn't fully unpack. The difference between 301 and 308 matters for APIs, but does it matter for regular web pages? If I'm migrating a news site, do I care whether the browser preserves the POST method?
For regular web pages, almost never. Normal page navigation is GET requests. The only time method preservation matters for a content site is if you have forms that POST to specific URLs, and those URLs are being redirected. And even then, the correct pattern is usually to update the form action to point to the new URL directly, not to rely on a redirect to forward the POST.
For the news site scenario Daniel described, 301 is fine. The method preservation nuance is an API concern.
And I'd go further — for a content site migration, 301 is not just fine, it's the correct choice. You want search engines to transfer link equity, and you want browsers to cache the redirect. 301s are cacheable by default. 302s and 307s are not. That cacheability matters at scale — if a returning visitor has the redirect cached, their browser goes straight to the new URL without even hitting your server or Cloudflare.
Which is another performance win that compounds over time.
The browser cache is the fastest redirect of all, because it's zero network requests.
Alright, I think we've covered the status code taxonomy, the Cloudflare versus origin decision, and the SEO indexation process. Let me try to synthesize this into a single coherent recommendation for someone in Daniel's position — running a news site, using Cloudflare, migrating to a new platform, dealing with a few hundred pattern-based redirects.
Use Cloudflare Single Redirects with regex rules to handle the pattern-based redirects at the edge. Use 301 status codes for all permanent content moves. Keep any stateful or application-dependent redirects at the origin. Submit old URLs in Search Console. Keep both old and new sitemaps active during the transition. Monitor for a few weeks. Leave the redirects in place for at least a year. And version control everything.
That's the playbook. The only thing I'd add is: if you have one-off redirects that don't fit a pattern, use Cloudflare Bulk Redirects rather than cluttering your Single Redirect rules with dozens of individual matches. Keep the pattern rules clean and the exceptions in a separate list.
If you're not on Cloudflare? If you're on some other setup?
The principles are the same. Do redirects as early in the request pipeline as possible. If you have a CDN, use its redirect capabilities. If you don't, do them at the web server level — nginx or Apache — rather than in application middleware. The closer to the edge, the better the performance and the simpler the architecture.
I feel like we should also mention the thing nobody wants to talk about, which is that sometimes you just can't recreate the old permalink structure and you have to accept some level of redirect complexity. Daniel mentioned that in the prompt — sometimes, for boring reasons, you can't or don't want to match the old structure.
That's where the regex approach really shines. You don't need to match the old structure exactly. You just need to extract enough information from the old URL to map it to the new one. Often that's just the slug or an ID. The date hierarchy, the category path, all the WordPress cruft — you can strip that out with a well-written regex and redirect to a clean new URL.
The regex is your universal adapter. It doesn't care how ugly the old URL was.
That's why I recommend Single Redirects over Bulk Redirects for pattern-based migrations. Bulk Redirects require you to enumerate every mapping. Single Redirects let you write one rule that handles thousands of URLs. It's the difference between writing a lookup table and writing a function.
Which is also the difference between something you can maintain and something that bit-rots the moment you stop paying attention.
Alright, I think we've given this topic a thorough going-over. Should we do the fun fact?
Let's do it. And now: Hilbert's daily fun fact.
Hilbert: The fermentation process for kava, traditionally attributed to Polynesian settlers arriving in Vanuatu around 1000 BC, was actually first documented in the late 1600s by French missionary Jean-Baptiste de la Fontaine, who incorrectly credited the technique to Filipino traders — a misattribution that persisted in European botanical literature until German ethnobotanist Augustin Krämer corrected it in 1902.
I don't know what to do with that information.
Jean-Baptiste de la Fontaine, ruining kava attribution since the 1600s.
This has been My Weird Prompts. Thanks to our producer, Hilbert Flumingtop. You can find every episode at myweirdprompts dot com or wherever you get your podcasts. If you enjoyed this, leave us a review — it helps other people find the show.
Until next time.
