A 302 redirect leaves the old URL ranking and the new one ignored
Summary
Google's Gary Illyes said only a permanent redirect transfers an old page's ranking signals, because a 302 keeps the old URL in search results and ignores the new one.
Check the status codes on your last migration's redirects and move anything permanent off 302 or 307.
Google’s Gary Illyes said a 301 redirect hands all of the old page’s ranking signals to the new URL, while a 302 passes nothing: Google “assumes you are going back eventually, keeps the old URL in the search results, and basically ignores the new URL.” Illyes and Cherry Prommawin, both on Google’s Search Relations team, were explaining how redirect codes feed canonicalization, in a discussion covered by Search Engine Journal.
Both codes do the same first job. Google groups pages with similar main content into a cluster, and per Prommawin, a permanent and a temporary redirect both put the old and the new URL in the same cluster. They split at the step after that. Canonicalization picks one URL out of the cluster to represent it in search, and only the permanent redirect influences the pick. Illyes put the 301 case in one line: “Google takes all the ranking signals of the old page and hands them to the new page.”
A migration left on temporary redirects is not a slower version of one on permanent redirects. The old URL stays the URL Google ranks, and the new URL, the one carrying the site’s internal links, gets ignored. The failure is quiet: positions hold, because the old URL is still the ranked URL and still forwards visitors to the new page. The gap shows only when someone checks which URL is actually ranking.
Prommawin opened with reassurance. “Relax,” she said, because whichever redirect you choose one of your pages stays in search, and “getting it wrong is not the end of the world.” That is true about indexing and easy to misread. On a move meant to be permanent, which URL shows up is the whole question. The practical consequence is that a site on 302s has to keep its old URLs answering indefinitely, because the day they stop, nothing was ever passed on.
Where 307 and 308 fit
307 and 308 carry the same temporary and permanent meanings as the older pair. Illyes said the only major difference is how they handle POST data, meaning what a browser sends when someone submits a form.
| Code | Meaning | Forwards POST data |
|---|---|---|
| 301 | Permanent | No |
| 308 | Permanent | Yes |
| 302 | Temporary | No |
| 307 | Temporary | Yes |
Illyes’s example was a shopper submitting a checkout form on Black Friday when the main payment server is overloaded and the site fails over to a backup. A 302 to the backup loses the submitted data. A 307 tells the browser to keep the request as a POST and forward the same data, so the transaction goes through behind a brief loading wheel.
Google also recommends server-side redirects over meta refresh and JavaScript redirects. The reason Illyes gave is work at the browser: an HTTP redirect is “a clean, instant instruction,” while the alternatives make the browser download the page, parse the code, wait for the script to run, and only then send the user somewhere else.
What to do
- Pull the status code for the redirects from your last migration. Anything meant to be permanent that answers 302 or 307 should answer 301 or 308:
curl -sI https://example.com/old-url | head -n 1. - Confirm which URL ranks for the moved pages, not just the position they hold.
- Leave the old URLs answering after you switch the code. Google only sees the new code when it recrawls the old URL.
- Keep 307 for the case it was built for, a POST that has to survive a failover, and not as a general-purpose redirect.
- Take an index-count baseline before the next migration. A daily count caught a 77,000-URL redirect on day one, which is faster than waiting for traffic to tell you.