302 redirect

What a 302 actually signals

A 302 is a routing instruction with a lifespan attached to it. The server tells the client that the resource is answering from another address right now, and that the client should keep asking at the original URL next time. Everything that matters in SEO derives from that single semantic difference, not from a mythical share of PageRank lost in transit.

Google Search Central states the distinction plainly in its redirect documentation: Googlebot follows 301, 302, 303, 307 and 308 alike, but only permanent redirects, 301 and 308, are used by the indexing pipeline as a signal that the destination should become the canonical URL. With 302, 303 and 307, the redirect itself is not treated as a canonicalization signal, and the source URL may remain indexed. That is the operational definition worth memorising, because it is the one that produces measurable consequences.

The consultant folklore about a temporary redirect leaking a fixed percentage of link equity has never been pinned to a Google statement or a patent. Google has said for years that PageRank flows through 30x redirects. What a 302 withholds is not authority, it is the instruction to replace one address with another in the index. Treating those two things as the same failure is how audits end up recommending a mass 301 rewrite that fixes nothing and breaks a legitimate temporary routing rule.

The practical rule follows directly from the documentation: use 302 when the change is genuinely temporary, meaning stock outage, A/B test, seasonal campaign landing, maintenance window. Use 301 or 308 when the URL has moved for good and you want the destination to replace the source in search results. Anything else is you guessing, and the guess costs you weeks of ambiguous indexing.

The 2026 mechanics: canonicalization, not equity loss

When Googlebot meets a 302, it fetches the destination, processes it, and then has to decide which of the two URLs deserves to be the indexed one. The redirect gives it no vote. Everything else does: internal links, the canonical annotation declared in the head, the sitemap entry, hreflang clusters, and the external link graph. In practice, a 302 left in place for months produces one of three outcomes, and you cannot pick which one.

Either Google keeps the source indexed as intended, which is exactly what the header asked for. Or Google decides on its own that the destination is the better canonical, because every other signal points that way, and consolidates there anyway. Or it oscillates, which is the expensive case: the URL shown in the SERP flips between the two, your rank tracking looks noisy, and your reporting turns into a debate. None of that is a penalty. It is ambiguity, and ambiguity is the thing you are paid to remove.

Worth saying clearly for anyone writing a post-mortem: no confirmed Google update in the past year changed 302 handling. The December 2025 core update ran from 11 to 29 December, roughly eighteen days. The March 2026 core update started on 27 March and completed on 8 April according to Search Engine Land. The May 2026 core update rolled from 21 May to 2 June. All broad ranking updates, none of them documented as touching redirect semantics. If a site lost visibility after a migration in that window, the redirect configuration is the first suspect, not the update that happened to overlap it.

Measurement deserves the same discipline. In September 2025 Google disabled the num=100 search results parameter, and industry reporting attributed the subsequent drop in reported impressions for lower-ranking results to that change rather than to any ranking movement. Anyone reading a post-September 2025 impression curve as evidence that a redirect destination lost authority is reading an instrumentation artefact. Compare clicks, indexed source versus destination URLs, Googlebot hits in server logs, the final HTTP status, the canonical Google actually selected, and the referring domain counts on each side. Impressions alone will lie to you.

Where a 302 costs you in a netlinking operation

Here is the scenario that turns a technical footnote into a budget problem. You buy a contextual placement. The publisher links to /offer-summer. Six weeks later the campaign ends and the client puts a 302 from /offer-summer to /services. The link is still live, the equity still moves, but the URL Google keeps in its index is the dead campaign page. The money page you actually sell from accumulates nothing that a rank tracker can attribute to it, and the client concludes that link building does not work.

This is why redirect status belongs in the acquisition checklist, not in a separate technical audit run six months later. Before ordering a placement, resolve the destination and confirm it answers 200 directly. When you work through a catalogue where you pick the host media and the target URL yourself, that check takes ten seconds and removes the single most common reason a campaign underperforms without anyone noticing.

The cost angle is blunt. A contextual link on a real editorial site is not free, and the whole point of knowing what each placement costs before you commit is to make sure the authority lands where it converts. Pointing a paid link at a URL that will be 302ed away in a quarter is the netlinking equivalent of paying for a billboard on a road that closes next month. On the French editorial media we operate in-house at Nautilinks, the destination URL supplied by the client is checked at order time for exactly this reason: a link placed on a redirecting target is a link the client paid for twice.

The same logic governs how authority consolidates across a domain during rebrands. Links acquired over successive migrations pile up hops. Ahrefs Site Audit guidance, updated 31 October 2025, classifies a path such as 301 then 301 then 200 as a redirect chain even though it resolves correctly, on the grounds that chains slow loading and complicate crawler handling. The recommendation is to replace internal links to redirecting URLs with direct links, flatten to a single hop where possible, and stay under five redirects where a chain cannot be avoided. A 302 discovered inside such a chain is the finding to chase first, because it almost always marks something nobody intended to leave running.

What we see go wrong in audits

The default server behaviour catches more teams than any deliberate choice. Several frameworks and load balancers emit 302 unless told otherwise, and a developer who writes a redirect rule without specifying the status code ships a temporary redirect for a permanent move. The migration looks fine in a browser, the pages resolve, and six weeks later half the old URLs are still indexed while the new ones fight for the same queries.

The second recurring pattern is the geo or device routing layer applied at the root. A visitor from Germany gets 302ed from the canonical page to a country variant, Googlebot crawling mostly from US infrastructure sees something else, and the permanent redirect logic used elsewhere on the site contradicts it. Country routing should be an in-page choice or a proper hreflang cluster, not a redirect that fires before the crawler can see the content it was sent to evaluate.

Third, the redirect used as a content management shortcut. A page is retired, someone 302s it to the category listing to avoid a 404, and the redirect is never revisited. Two years later the site has a hundred of them, none reversible in any meaningful sense, and the index is full of URLs that serve nothing. If a page is gone for good, 301 to the closest genuine equivalent or return a clean 410 and let it drop. If it is thin rather than gone, an explicit noindex directive is a more honest instrument than a redirect that lies about being temporary.

Fourth, the audit that reports every 302 as an error. Some are correct. A checkout step, a login gate, a genuine maintenance window, a short campaign: those should stay temporary. An audit that flags them all without triage produces a ticket list the dev team learns to ignore, which is worse than no audit.

The working playbook

Crawl before and after every migration and diff the status codes, not just the final destinations. Screaming Frog SEO Spider handles this at the low end of the budget: the free version crawls up to 500 URLs and already surfaces redirects, chains and loops, and unlimited crawling with list upload for migration audits runs at 199 pounds per licence per year, with volume tiers down to 169 pounds at twenty licences or more. For a one-off migration check on a small site, the free tier is genuinely enough.

Build the redirect map before the migration goes live, with the final destination in the right-hand column rather than the intermediate URL, so no chain gets created on day one. Update internal links, the XML sitemap you submit to Search Console and any campaign URLs to the final address, then keep the old rules in place for the crawlers that will still hit them for months.

Set a review date on every 302 you create. A temporary redirect with no expiry is a permanent redirect wearing the wrong header, and it will outlive the person who wrote it. In log analysis, watch for Googlebot repeatedly hitting the source of a long-lived 302: that repetition is the crawler doing exactly what the header instructed, and it is crawl budget spent on a decision you never made.

When the outreach or acquisition side of the operation is involved, close the loop by re-resolving every acquired link destination quarterly. Links rot, targets move, and a placement that pointed at a 200 in January can point at a 302 by June without anyone touching the host page. That quarterly resolve is fifteen minutes of scripting and it protects the entire spend.