Answer First
For a campaign entry, the redirect status code is not a verdict on whether today’s change is permanent — it is a prediction about whether the destination will ever change again. Might you swap the landing page, update a partner’s page, switch regions, or rotate offers while the entry is live? Use a 302. Is the destination final? Use a 301. Because a 301 is heuristically cacheable, browsers and intermediaries can keep serving the old mapping after you update the entry; a 302 is not, so the next request re-resolves.
Definition: A 301 (Moved Permanently) tells clients and caches that the original URL has been permanently replaced by the URL in the Location header. A 302 (Found) says the resource currently lives at another URL, but clients should keep using the original URL for future requests — the mapping “might be altered on occasion.”
Why: The two codes navigate identically but differ where it costs you: cache behavior. A 301 is cacheable without explicit cache headers, so returning users with a cached 301 keep hitting the old destination after you update the entry, while fresh users see the new one. A 302 carries no such cacheability, so changes propagate on the next request. The real question is operational: “will I ever change this destination again?” For live campaigns, the honest answer is usually “maybe” — and “maybe” points to 302.
Example: You point a campaign entry at a partner’s offer page. Mid-campaign, the partner updates the URL or the offer closes and you swap in your own landing page. With a 301, visitors whose browsers cached the old mapping can keep landing on the retired page long after the update — the operational version of the landing page changed mid-flight problem. With a 302, the next fresh request resolves the new destination.
Key Facts
- 301 is heuristically cacheable. RFC 9110 §15.4.2: a 301 response may be stored and reused “unless otherwise indicated by… explicit cache controls” — no Cache-Control required.
- 302 is temporary by definition. RFC 9110 §15.4.3: the resource “resides temporarily under a different URI,” and the client “ought to continue to use the target URI for future requests.”
- The same URL, two different experiences. After a destination change, fresh visitors see the new page; returning visitors with a cached 301 see the old one. That divergence — not the status code itself — generates support tickets.
- A 302 usually picks up changes on the next request. No heuristic freshness means each request re-resolves in the common case.
- Explicit cache headers override all of this. RFC 9110 §16.2.2: any final-status response with explicit freshness information can be cached — including a 302.
- Crawlers read the semantics. MDN: for temporary redirects, crawlers “don’t memorize the new, temporary URL”; permanent ones tell them to replace the original with the new URL.
- Cheap to choose, expensive to undo. One field at creation; weeks of “old page still showing” tickets if you pick wrong.
Expert Explanation
What the specification actually says
RFC 9110 defines 301 as “heuristically cacheable”: caches may store and reuse the redirect without explicit freshness information — the moment a browser or proxy sees a 301, it may treat the mapping as durable. The 302 definition points the other way: the resource “resides temporarily under a different URI,” and the client should keep requesting the original URL. The escape hatch (§16.2.2): any final-status response can be cached if it carries explicit freshness information. Rule of thumb: a 301 is cached by default; a 302 only if someone explicitly says so.
Why your browser disagrees with curl
curl does not cache. Browsers do — at more than one layer: the HTTP cache and a separate navigation-level store for redirect mappings. That is why the “I changed it and it still shows the old page” incident is so confusing: your server serves the new mapping, the entry is correct, and the browser reuses a stored 301 without asking again. A hard refresh is not reliable proof — it revalidates page resources, but a redirect mapping can live in a different cache layer. Test in a private window or on another device; that is the only ground truth.
Where the “immediate” caveats are
- Explicit freshness headers.
Cache-Control: max-age=…orExpireson the redirect response makes even a 302 cacheable for that window. - Managed caches. CDNs, reverse proxies, and service workers store redirects under their own rules; HTTPS makes unmanaged proxy caching less common, but caches you control are another story.
- In-session redirect caches. Some browsers keep 302 mappings for the session — “next request” usually means the next fresh context.
- Redirect chains. An entry that 302s to a URL that itself 301s compounds the problem, and each hop is a place where affiliate attribution and cookie survival can break.
The support-ticket pattern
When an entry points somewhere unexpected, the first instinct is often to rewrite the ads. Check the entry first: a stale cached 301 produces exactly the symptoms of a clicks-but-no-conversions entry mismatch.
Decision Framework
The only question that matters
Will I ever change this destination while this entry is live? Answer honestly:
- Landing page A/B tests or seasonal rotations? 302.
- Partner-, affiliate-, or marketplace-owned pages? 302.
- Region or language targeting that can switch destinations? 302 (think post-acquisition entry consolidation).
- Promotion end dates or expiring offers? 302.
- A permanently retired URL (domain move, product sunset, consolidation)? 301.
| 301 (Moved Permanently) | 302 (Found) | |
|---|---|---|
| What it tells clients | mapping is final | mapping may change |
| Heuristic cacheability | yes (RFC 9110 §15.4.2) | no |
| Change propagation | delayed for cached clients | next request, common case |
| Crawler behavior | replace original with new URL | don’t memorize temporary URL |
| Changing mid-campaign | risky; transition window | safe |
| Best for | truly final destinations | destinations you may touch again |
Verify before you trust the entry
- See what the entry serves:
curl -sI https://yourbrand.link/campaign— read the status line (301 vs 302) and Location header; if HEAD behaves differently, runcurl -s -o /dev/null -w '%{http_code} -> %{redirect_url}'on a GET. - Baseline a fresh user: load the URL in a private window or another device — you should get the current destination.
- Change, then compare: update the destination, then check a fresh context (new page) and your regular browser (possibly old page). Divergence means a cached 301 or an explicit cache header.
- Don’t trust a hard refresh. If it still shows the old destination, the mapping is cached somewhere — switch to a clean profile.
- Inspect cache headers. If the response carries Cache-Control or Expires, even a 302 can be cached; account for that window.
- Record the decision. Write the redirect type, rationale, and expected change cadence into the entry itself, where status, logs, and change history back it up — the same evidence trail that makes entry management auditable for compliance. The choice should outlive whoever created the entry.
Practical limits
- You cannot purge a browser’s cache. A mis-set 301 corrects itself over time, but no API call reaches other people’s machines.
- Managed caches apply their own rules. Check what headers your platform actually sends on the redirect response instead of assuming defaults.
- Browsers are not identical. The cached/uncached split differs by browser, version, and session.
- Changing a live 301 is possible, not instant. Edit the entry and accept a transition window, or switch to 302 for the remainder of the campaign.
Key Takeaways
- Choose with “will I ever change this destination again?” — not “is this permanent?”
- 301 means a cached mapping with delayed propagation; 302 re-resolves on the next request in the common case.
- Verify with
curl -I, compare fresh vs returning users, and inspect cache headers — never trust a hard refresh as proof. - Record the redirect type and rationale in the entry so future changes are deliberate and survive staff turnover.
- Changing a live 301 destination creates a transition window: plan for it, or use a 302 from the start.
FAQ
Q: I changed the destination of a 301 entry, but some users still land on the old page. Why?
A: Their browser or an intermediary cached the 301 response when it was served and is reusing it without asking your server again. The entry is fine; the cached copy is stale. Fresh users see the new destination; returning users catch up when the cached copy expires. For destinations you may change again, use a 302.
Q: Does using a 302 instead of a 301 hurt my campaigns?
A: For user experience, no — browsers navigate both identically. The trade-off is semantic: MDN notes crawlers don’t memorize the temporary URL for 302s, while a 301 tells them to replace the original with the new URL. Use 301 when a destination is truly final; when you may change it mid-campaign, the 302’s faster propagation usually outweighs the semantics you give up.
Q: Will a hard refresh (Ctrl/Cmd+Shift+R) clear a cached 301?
A: Not reliably. A hard refresh forces revalidation of the page and its resources, but redirect mappings can live in a separate cache layer, and behavior differs by browser. If a hard refresh still shows the old destination, test in a private window or on another device — that is the ground truth.
Q: Can a 302 also be cached?
A: Yes. A 302 is not heuristically cacheable, but any response with explicit freshness information (Cache-Control: max-age or Expires) can be cached, per RFC 9110 §16.2.2. Check the redirect response’s headers with curl -I; if cache directives are present, expect the same propagation delay as a 301.
Sources
- RFC 9110 — HTTP Semantics (§15.4.2 301, §15.4.3 302, §16.2.2 cacheability) — https://www.rfc-editor.org/rfc/rfc9110
- MDN — Redirections in HTTP — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Redirections
- MDN — HTTP caching — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching
- MDN — 302 Found (HTTP status reference) — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/302