Most redirect advice online collapses into one sentence: “always use a 301.” That advice is wrong often enough to cost you. Temporary redirects exist because sometimes the move genuinely is temporary, and telling search engines otherwise creates a mess you have to unwind later. A 302 or 307 says the resource lives somewhere else right now, but the original URL is still the canonical home and should stay indexed.
The practical question is never “which status code sounds safer.” It is “which URL do I want in Google’s index six months from now?” Answer that first, and the status code picks itself.
What a temporary redirect actually tells a search engine
A 301 is a signal that the original URL is dead and the destination inherits it — Google consolidates the ranking signals onto the target and eventually drops the old URL from the index. A 302 or 307 signals the opposite: keep the source URL indexed, serve the destination to users for now, and expect the source to come back.
In practice Google is more pragmatic than the specification. Its documentation describes redirects as strong or weak canonicalization signals rather than binding instructions. If a 302 stays in place for months and never reverts, Google will usually start treating it like a permanent move and consolidate onto the destination anyway. That is a fallback behavior, not a plan. Relying on it means handing the decision about which URL ranks to an algorithm instead of making it yourself.
302 vs 307: the difference that actually matters
Both are temporary. The distinction is about what happens to the HTTP request method, and it matters far more to developers than to SEOs.
- 302 Found — historically, browsers and clients would change a POST request into a GET when following it. The spec never said to do that; implementations did it anyway, and the behavior stuck.
- 307 Temporary Redirect — introduced to remove the ambiguity. The method and body are preserved, so a POST stays a POST.
- 308 Permanent Redirect — the permanent counterpart to 307, preserving the method where a 301 might not.
For a plain page-to-page redirect that only ever handles GET requests, 302 and 307 are interpreted identically by Google. Choose 307 when a form submission or API call passes through the redirect and you need the method preserved. Choose 302 when you want the broadest compatibility with old clients. Neither one ranks better than the other.
One special case trips people up: HSTS. When a site sends a Strict-Transport-Security header, the browser itself generates an internal 307 for subsequent HTTP requests before anything hits your server. That 307 appears in Chrome DevTools with no response headers and no server latency. It is not a redirect you configured and there is nothing to fix.
When a temporary redirect is the right choice
Reach for 302 or 307 when the source URL has a future. A few situations where that is genuinely true:
- Out-of-stock products you plan to restock. Redirect to the category page for now, keep the product URL indexed, restore it when inventory returns.
- Seasonal landing pages — a Black Friday hub pointed at the general deals page for ten months of the year.
- A/B tests where traffic is split between two versions and you intend to keep the original URL as the winner’s home.
- Maintenance windows on a specific section, though a 503 with a Retry-After header is the better signal for genuine downtime.
- Geolocation or language routing where a shared entry URL sends users to the version that fits them.
Notice the pattern. In every case, the original URL is still the address you want people to bookmark and search engines to rank. The redirect is a detour, not a relocation.
When you should use a 301 instead
If the source URL is never coming back, a temporary redirect is actively harmful. It keeps a dead URL in the index, splits signals across two addresses, and slows the consolidation you actually want. Site migrations, HTTP-to-HTTPS moves, www normalization, trailing-slash cleanup, retired blog posts folded into a newer guide, permanently discontinued products — all of these want a 301.
The most expensive version of this mistake is a migration executed entirely on 302s because a developer picked the framework default. Rankings do usually recover once the codes are corrected, but you burn weeks of crawl cycles and reporting confusion in the meantime. Check the status codes yourself before launch instead of assuming.
How long is “temporary” before it stops being temporary
There is no published threshold. What is observable is that Google re-crawls redirecting URLs on its own schedule, and a 302 that has not changed across many crawls starts behaving like a permanent one for canonicalization purposes. On a low-traffic page that might take months.
Treat every temporary redirect as something with an expiry date and an owner. A redirect you set up for a two-week promotion and forgot about in 2023 is not a temporary redirect anymore — it is technical debt. Keep a simple record: source URL, destination, reason, review date. Ten rows in a spreadsheet beats a perfect system nobody maintains.
Auditing temporary redirects across your site
Redirects rot quietly. The destination gets deleted, a second redirect gets stacked on top, or a rule written for one path starts matching a thousand. You will not notice from the browser because the page still loads.
Work through this sequence:
- Crawl the whole site with redirect following enabled and export every URL returning 3xx, grouped by status code.
- Flag every 302 and 307 and ask whether the source URL still has a future. If not, change it to a 301.
- Find chains and loops. Any hop count above one wastes crawl budget; above three, some crawlers stop following. Point every source directly at the final destination.
- Check internal links. Links inside your own site should point at final URLs, not at redirects. Redirects are for external links and old bookmarks you cannot edit.
- Confirm the destination is relevant. Bulk-redirecting hundreds of removed pages to the homepage is treated as a soft 404, and you get nothing for it.
- Re-check after every deployment. Server config, CDN rules, and plugin-level redirects all fire in a stack, and a change in one layer can shadow another.
Command-line spot checks are fast for individual URLs. curl -sIL https://example.com/old-page prints every hop with its status code, which is usually enough to confirm a single fix. For site-wide coverage you need a crawler, because the problems that hurt are the ones you were not looking for.
Mistakes that show up again and again
JavaScript-based redirects are the most common offender. A window.location assignment returns a 200 status with no redirect header at all, so search engines must render the page to discover the move. Google can handle it, but the signal is weaker and slower than a server-side response. Use HTTP status codes wherever you have server access.
Meta refresh tags have the same problem plus an accessibility cost. Redirecting to an irrelevant destination is another one — a discontinued blue widget should go to blue widgets or a close alternative, not to the homepage. And a redirect combined with a canonical tag pointing somewhere else sends contradictory instructions; pick one signal and make the whole site agree with it.
Making redirect hygiene routine
The reason redirect problems persist is not difficulty. It is that nobody looks. A full crawl surfaces every 3xx on the site with the actual source and destination URLs attached, which turns an abstract worry into a finite list you can work through in an afternoon.
That is the job SEO Rocket’s technical audits handle — a quick scan of roughly 25 pages when you want a fast read, or a deep full-site crawl that has been verified past 900 pages, with concrete evidence attached to each issue rather than a severity score you have to interpret. Run one, sort by status code, and decide which of your temporary redirects deserve to stay temporary.
