Of all the technical mistakes websites carry around, badly set up redirects are some of the most common and least noticeable at first glance. The page loads, the visitor ends up where they should, everything looks fine. The problem is that Google doesn't just judge whether the visitor arrived correctly: it also reads which status code that redirect used, and that technical detail decides whether the authority and ranking of the old URL fully transfer to the new one or get stuck halfway.
What each code actually means, without the jargon
A 301 says "this has moved for good, forget the old URL and treat the new one as the original." A 302 says "this is here temporarily, keep an eye on the old URL because it's coming back." More precise variants exist (307, 308) that preserve the request method, but for the day-to-day of a normal website, the decision that matters is between those two: permanent or temporary.
The most expensive mistake: using a 302 for a permanent change
It's common to find 302s set by default by a plugin, a CMS, or a developer who didn't stop to think about it, on changes that are actually definitive: a category renamed for good, a domain replaced, a page merged into another with no way back. When Google sees a 302, it's more conservative about transferring the ranking signal to the new URL, precisely because it assumes the old one might return. The result, weeks later, is a traffic drop nobody connects to "that redirect we set up a while back."
Redirect chains: every hop costs something
It's easy to end up with a URL that redirects to another one, which in turn redirects to a third, usually because changes have piled up without cleaning up the previous ones. Every hop adds loading time, and in long chains part of the ranking signal gets diluted along the way. The fix isn't complicated: once you spot a chain, point the original redirect straight at the final destination, skipping the intermediate stops.
Where these problems usually show up in practice
The most common trouble spots are domain or system migrations (WordPress to a custom website, for example, or the other way around), HTTP-to-HTTPS switches that weren't closed off properly, ecommerce plugins that auto-create redirects when a product name changes, and URL structure changes made without a full before-and-after mapping.
How to check your own
You don't need to be a developer to run a first check. Tools like Screaming Frog (its free version already covers small sites) show at a glance which code each URL returns and whether there are chains. A browser extension that displays HTTP headers works for checking specific cases without installing anything. And Search Console's page report flags it when it finds a redirect where it expected an indexable page.
Frequently asked questions
Can I just always use a 301 to be safe?
Not a good idea: if the change really is temporary (a promotion, a page under maintenance) and you use a 301, you're telling Google to treat that change as permanent, and it may be slow to reverse it once the original URL is active again.
How long does Google take to process a freshly set 301?
There's no fixed timeframe: it can range from days to several weeks, depending on how often Google crawls that part of your site. The more authority the domain has, the faster it usually reacts.
Do redirects affect the loading speed my visitors experience?
Yes, each hop adds an extra request to the server before reaching the final content, which is especially noticeable on mobile and slow connections. It's one more reason not to leave redirect chains uncleaned.