Answer First
Definition: A 301 redirect (“Moved Permanently”) tells browsers, search engines, and CDNs that the entry’s destination has permanently changed and that the entry URL should be retired in favor of the new one. A 302 redirect (“Found”) tells them the current destination is temporary, so the entry URL stays the canonical address and nothing should be remembered long-term.
Why: The decision isn’t about where the entry points today — it’s about how confident you are that the destination is final. 301 responses are cacheable by default, so browsers and CDNs keep serving the old destination for hours or days after you edit it, which reads to visitors as “the link is broken.” 302 responses are not cached unless a server explicitly opts in, so a destination edit takes effect on the very next click. For a campaign entry still being tuned, that’s the difference between a five-minute fix and a multi-day propagation wait.
Example: You point go.example.com/summer-sale at a pre-launch placeholder using a 301. Two hours later the real landing page ships, and you update the destination in the Console. Visitors who already loaded the 301 keep landing on the placeholder — some for days — because their browser cached the redirect. With a 302, the first click after your edit hits the new page.
Key Facts
- Per RFC 9110, 301 responses are heuristically cacheable by default; 302 responses are cacheable only when explicitly allowed via
Cache-ControlorExpires. - A destination edit behind a 301 can take days to reach every visitor; behind a 302 it propagates immediately.
- Every click on a 302 passes through the entry, so access statistics stay accurate. A cached 301 can bypass the entry entirely and undercount repeat clicks.
- Both statuses forward the full URI — including
utm_*campaign parameters — to the destination, so campaign attribution survives either choice. - Search engines treat 301 as a permanent move and consolidate ranking signals on the new URL; a 302 keeps those signals on the entry URL.
- The choice is per entry, not per account: a tunable campaign entry can sit on 302 while a permanent brand URL sits on 301.
Expert Explanation
What the codes actually say. RFC 9110 defines 301 as the signal that “the target resource has been assigned a new permanent URI” and 302 as the signal that the target “resides temporarily under a different URI.” Both tell the client to follow the URL in the Location header — the difference is the semantics attached to permanence, and those semantics license different caching behavior. That one sentence in the spec is where nearly all practical problems come from.
Why a 301 can look broken for days. 301 responses are heuristically cacheable: unless the server sends explicit cache-control headers, any cache — a browser, a corporate proxy, a CDN — may store the redirect and reuse it without re-asking the origin. Browsers commonly keep a heuristic-cached 301 for hours up to “until cache is cleared.” So after an edit, the entry’s true destination is new, but many visitors’ machines never ask again; they keep replaying the old answer. This is the TTL/propagation effect in practice: the redirect’s effective lifetime is whatever each cache decides — typically not seconds, and often days for repeat visitors. A 302, by contrast, is only cacheable with explicit opt-in, so nearly every click re-queries the entry and returns the current destination.
Why 302 keeps an entry flexible. Campaigns change: the approved ad goes live, then the landing page gets A/B-tested, the offer shifts, the promo ends. With 302, edits are effective immediately and you can iterate without scheduling around cache expiry. It also keeps your data honest — every click reaches the entry, so logs and access statistics reflect what actually happened, which matters when ad clicks aren’t converting and you’re checking the entry before rewriting the ads.
What each choice does to analytics. There are two analytics layers to keep separate. Entry-level: your access statistics come from requests the entry actually receives. Every 302 click hits the entry; cached 301s don’t, so repeat-click volume undercounts with a 301. Destination-level: analytics platforms read campaign parameters from the URL the browser ends up on, and because a redirect forwards the query string, utm_source, utm_medium, and friends survive both 301 and 302. In short: 302 keeps entry-level counts complete; either status keeps destination-level attribution intact.
SEO signal transfer — and when it doesn’t matter. For indexable URLs, 301 is the standard way to signal a permanent move and consolidate ranking signals on the new destination; Google documents treating 301 and 308 as permanent and 302 and 307 as temporary. But many campaign subdomains are excluded from indexing precisely because they’re ephemeral — for those, SEO is a non-factor and the decision reduces to caching and statistics. One caveat: a 302 that stays in place for months can eventually be treated as permanent by crawlers, so a “temporary” redirect that never changes becomes de facto permanent — with worse caching semantics than a 301 would have given you.
When a 301 is the right lock. Long-lived public URLs deserve a 301: a permanent brand shortcut, an evergreen download page, or a path consolidated after an acquisition. If the URL will outlive the campaign and the destination is final, 301 is the correct choice — it signals permanence, transfers signals, and trims repeated redirect overhead. That’s why a post-acquisition subdomain consolidation playbook leans on permanent redirects. The discipline is timing: only lock in a 301 when you’re confident you won’t edit the destination later.
Decision Framework
| Scenario | Status | Why |
|---|---|---|
| Live campaign, destination may still change | 302 | Edits apply on the next click; entry stats stay complete |
| Landing page changed after the ad was approved | 302 | The fix must reach visitors immediately, not after cache expiry |
| Entry-level click statistics drive ad decisions | 302 | Every click passes through the entry and gets counted |
| Permanent brand URL (downloads, evergreen, shortcuts) | 301 | Signals permanence and consolidates SEO signals |
| Post-acquisition consolidation of old domains | 301 | Standard for permanent moves to a single home |
| URL must outlive the campaign unchanged | 301 | Lock it once the destination is stable and final |
Practical limits to plan around. Heuristic caching means “days” is a planning assumption, not a promise: a browser may keep a 301 for hours or until the user clears the cache, and CDNs add a second cache layer on top. There is no way to force-flush every client, so treat every 301 as committed for at least as long as caches live. If you need speed later, flip the entry to 302 first, make your edits, then return to 301 once stable. And note that editing a 301’s destination is not an error — the change simply propagates slowly.
Checklist before locking a 301:
- This URL is the final home of the content — not a campaign landing page that might change.
- The destination has been reviewed by whoever owns edits.
- You can tolerate stale redirects for days if the destination changes later.
- You don’t need per-click entry statistics (a cached 301 can undercount repeat clicks).
- If the URL is indexable, this is a genuine permanent move; if it’s noindexed, SEO isn’t the deciding factor.
- The change history still needs to stand up to an audit — both statuses log traceable edits, so compliance requirements don’t force either choice.
Key Takeaways
- Treat the redirect status as a per-entry decision with a sensible default: 302 while live and tunable, 301 only when final.
- The real cost of a premature 301 is invisible: cached redirects keep sending visitors to an old destination for days.
- 302 keeps edits instant and entry-level statistics complete — the two things a live campaign needs.
- 301 is the right lock for long-lived public URLs and permanent consolidations, where signal transfer and clean semantics matter.
- Both statuses preserve UTM parameters; neither choice breaks campaign attribution.
- When in doubt, start with 302 — and lock in a 301 only when the entry is stable and meant to last.
FAQ
Q: Do 301 or 302 redirects strip my UTM campaign parameters?
A: Neither, as long as the redirect forwards the full URI. The Location header carries the query string, so utm_source, utm_medium, and friends reach the destination, and analytics platforms reading the final URL still attribute the click to the campaign. What differs is what your entry sees: with a 302, every click passes through the entry; with a cached 301, repeat clicks may bypass it entirely, so entry-level statistics can undercount.
Q: I already published a 301 and now need to change the destination. Is the entry broken? A: No — the entry is working as configured; the change just propagates slowly because browsers and CDNs cached the old 301. Edit the destination as usual, but expect some visitors to keep reaching the old page until caches expire, which can take days. If you’re mid-campaign and expect more edits, switch the entry to 302 so future changes apply on the next click.
Q: Does a 302 hurt my search rankings? A: For an indexable URL, 301 is the standard way to tell search engines the move is permanent and to consolidate ranking signals; a 302 keeps those signals on the entry URL, which is correct while the entry is temporary. Many campaign subdomains are excluded from indexing anyway — in that case SEO signal transfer is a non-factor and the decision comes down to caching and statistics, not rankings.
Q: Should I use 303 or 308 instead? A: Those codes exist for specific cases: 303 tells clients to switch to GET after a form submission, and 308 is a method-preserving permanent redirect. For managed entry destinations — a GET request forwarded to a new URL — 301 and 302 are the practical choices, and 308 follows the same caching logic as 301. The decision framework above applies unchanged.
Sources
- RFC 9110 — HTTP Semantics, Sections 15.4.2 and 15.4.3: defines the 301 and 302 status codes and their default caching rules.
- MDN Web Docs — HTTP Redirections: explains how 301 and 302 behave, when each is used, and the caching implications.
- Google Search Central — Redirects and Google Search: how Google treats permanent versus temporary redirects for crawling and indexing.
- Google Analytics Help — Custom campaigns: how campaign parameters like
utm_sourceare read from landing URLs.