Redirects look simple at first. Select the old URL and create a redirect to the new URL. But redirects are easy to get wrong. Small mistakes pile up and cost you SEO rankings, speed and users
Most of them stay hidden until rankings or traffic drop. Here are the ones we see most, and how to fix each
1. Using a 302 when the move is permanent
A 302 tells search engines the change is temporary, so Google keeps showing the source URL in search results and does not use the redirect as a signal that the new URL should be canonical. Use it for a genuinely permanent move and the old URL can stay indexed for weeks while the new one struggles to rank.
How to spot it:
Use a redirect checker to check the URL to see which status code it returns. A permanent move that shows "302 Found" instead of "301 Moved Permanently" is the red flag. The old URL still sitting in your Search Console index weeks after the move confirms it.
The fix:
Use a 301 for permanent moves. Reserve the 302 for cases where the original URL really will come back, such as a short promotion or a temporary maintenance page.
2. Redirecting every old page to the homepage
During a migration, it is tempting to point all your old domain URLs at the new homepage and call it done. The problem is that a homepage redirect throws away the specific ranking and relevance each specific page earned. Google says redirecting many old URLs to one irrelevant destination such as the home page can be treated as a soft 404, and a visitor who wanted a product page lands on a generic front door and leaves.
How to spot it:
Crawl your old URL list in Screaming Frog and check the redirect target column. If a large share of old URLs all resolve to the root domain, you have blanket homepage redirects. Rising soft 404 reports in Search Console back this up.
The fix:
Map old URLs one-to-one to their closest equivalent. A parent category is a reasonable fallback only when it genuinely serves the same intent as the old page. When nothing does, return a 404 or a 410 for content that is gone for good, rather than redirecting to the homepage.
3. Redirect chains
A chain happens when one redirect leads to another. The old URL points to B, B points to C and the visitor finally lands on C. Every hop adds latency for users and crawlers. Google states that permanent redirects do not cause a loss in PageRank, but Googlebot follows only about 10 hops in a chain and Google advises keeping chains to no more than three.
How to spot it:
Certain online tools that check redirects will show the entire path. You can easily see any chains in this view.
The fix:
Flatten chains so each starting URL points straight to the final destination. After any migration, re-check that yesterday's destinations have not since become redirects themselves.
4. Redirect loops
A loop is a chain that never ends. A points to B and B points back to A, so the browser gives up and shows an error. Loops usually come from rules that point in opposite directions, for example a www to non-www rule at your CDN and a non-www to www rule on the origin.
A forced HTTPS rule can also loop when a proxy terminates TLS and forwards the request to the origin over plain HTTP, so the origin redirects to HTTPS again on every pass.
How to spot it:
The most common way to spot redirect loops is the error your client returns once it hits its redirect limit, such as “ERR_TOO_MANY_REDIRECTS” in Chrome and Edge or “The page isn’t redirecting properly” in Firefox.
The fix:
Keep redirect rules in one place, order them deliberately and test the full path rather than a single rule in isolation.
5. Redirecting to loosely related content
When a page is gone, sending visitors to a vaguely similar page feels helpful. It rarely is. Users notice the mismatch and leave. Google may treat an irrelevant redirect as a soft 404, in which case it is not used as a signal that the destination should be canonical.
How to spot it:
This one is manual. Sample your redirects, click through and ask whether the destination is what the visitor actually wanted. High bounce rate or short time on redirected landing pages, plus soft 404 flags, point at mismatched destinations.
The fix:
Redirect only to a genuinely equivalent page. When nothing fits, return a clean 404 or a 410 for content that is gone for good. A clear error page beats a misleading redirect.
6. Leaving internal links pointing at old URLs
Redirects are a safety net for links you do not control, such as inbound links from other sites. They are not a reason to leave your own links outdated. Every internal link that still points at an old URL forces an extra hop and slows the page for no reason.
How to spot it:
Crawl your own site and look for internal links that return a 3xx instead of a 200. Those are your own links pointing at redirected URLs. Most crawlers list the internal redirect targets directly.
The fix:
Update internal links to point at the final URL directly. Treat redirects as backup for external links, not a permanent substitute for fixing your own.
7. Inconsistent HTTPS and www handling
If HTTP does not force to HTTPS, or both the www and non-www versions load, you have quietly split one site into several. Ranking signals scatter across duplicates and some visitors see security warnings.
How to spot it:
Test all four variants by hand, HTTP and HTTPS, www and non-www, and confirm each lands on the same canonical URL with a single 301. If any variant loads its own page or shows a certificate warning, the handling is inconsistent.
The fix:
Choose one canonical version, such as https://www.example.com, and 301 every other variant to it.
8. Using meta refresh or JavaScript redirects
A meta refresh or a JavaScript redirect runs in the browser after the page starts loading, which makes these client-side redirects slower and less reliable than a server response. Google reads an instant meta refresh or a JavaScript location redirect as a permanent redirect, but it only sees the JavaScript version if rendering of the page succeeds. It reads a delayed meta refresh as a temporary redirect, which keeps the old URL in search results. A meta refresh with a delay is also a poor experience for everyone.
How to spot it:
View the page source and search for http-equiv="refresh" or a window.location assignment. If the URL changes in the browser but curl -I on the original returns 200 rather than a 3xx, the redirect is happening client-side.
The fix:
Use server-side 301 or 302 responses wherever you can. Save client-side redirects like meta refresh and JavaScript redirects for the rare case where no server-side option exists.
9. Choosing the wrong status code for the request
Not every redirect is a simple GET. A 301 or 302 can cause a browser to convert a POST into a GET, which quietly breaks form submissions and API calls.
How to spot it:
Submit the form or call the endpoint with the Network tab open and watch whether a POST turns into a GET after the redirect. A 301 or 302 sitting on a POST route is the warning sign.
The fix:
Use a 308 when the request method must be preserved on a permanent move and a 307 when it must be preserved on a temporary one, and a 301 or 302 for standard page moves.
10. Ignoring trailing slashes and case
To a server, /Page, /page and /page/ can be three separate URLs. Handle only one and the others either break or create duplicate content that competes with itself.
How to spot it:
Request the variants directly. Load /page, /page/ and /Page and see whether they normalize to one URL or each returns its own 200. Duplicate same-content URLs in a crawl or in your indexing report confirm it.
The fix:
Decide on a canonical format for slashes and case, then normalize everything to it with redirects.
11. Dropping query strings and tracking parameters
A redirect that discards everything after the question mark can break features that depend on parameters and strip out UTM tags. Lose the UTM tags and the visitor will still arrive, but your analytics falls back to the referrer or records the session as direct. Campaigns will look like they are underperforming when they are not.
How to spot it:
Request an old URL with ?utm_source=test on the end and check whether the parameters survive to the final URL. Compare the Location header to what you sent. Missing UTM tags on redirected traffic in your analytics is the downstream tell.
The fix:
Decide deliberately whether each redirect should preserve or drop parameters, and preserve tracking parameters by default on marketing URLs.
12. Using masked or iframe redirects
A masked redirect is not a redirect. Instead of sending a 301 to the destination, the host returns a 200 response whose body is a frame or iframe pointing at the destination site, so the address bar keeps showing the old domain.
No redirect is ever sent; search engines see a thin framing page rather than a move, and the destination gets no SEO benefit. The option usually appears as a masking checkbox alongside the 301 and 302 choices in a forwarding tool.
How to spot it:
Load the old domain and watch the address bar. If it keeps showing the old domain while displaying the new site, it is masking. curl -I returning a 200 on the old URL, with no 301 at all, confirms it is not a true redirect.
The fix:
Turn masking off and select the permanent (301) option so the visitor lands on the visible destination URL. If your forwarding tool cannot do that cleanly, handle the redirect at a level that can.
13. Never auditing or cleaning up old rules
Redirect rules accumulate for years. Nobody remembers why half of them exist, a few contradict each other and the whole set adds weight to every request. Old rules are also where the chains and loops from earlier mistakes tend to come from.
How to spot it:
Export your full redirect list and count the rules. If you cannot explain what each one is for, or the list is far longer than your current URL count, it is overdue. Duplicate or conflicting source URLs in the export are red flags.
The fix:
Audit redirects on a schedule. Retire rules that no longer serve a page, collapse chains and document why the survivors exist.
14. Not testing after deployment
A rule that looks correct in a config file is not a rule that works. Typos, ordering conflicts and edge cases only show up against live traffic, and at the scale of a full migration, a small error can affect thousands of URLs at once.
How to spot it:
After any change, run your old URL list through a bulk status checker and confirm each returns the intended code and destination. Any 404s, 500s or unexpected targets mean the deploy did not do what the config implied.
The fix:
Test the live response codes and final destinations after every change. For migrations, test in bulk against a full list of old URLs rather than spot-checking a few.
15. Underestimating redirect speed at scale
Every redirect is an extra round trip before the real page loads. On slow or poorly located infrastructure, each hop can add meaningful delay, and that cost multiplies across chains and high traffic.
How to spot it:
Measure the redirect response, not just the final page. In the Network tab, look at the timing on the 3xx response itself or run the URL through WebPageTest and check the time spent before the destination starts loading. Hundreds of milliseconds per hop or extra rows in the waterfall are the signal.
The fix:
Serve redirects from fast infrastructure close to your users, keep chains flat and treat redirect performance as part of page speed rather than an afterthought.
Managing redirects without the mistakes
Most of these mistakes share a root cause. Redirects get created one at a time, in scattered places, by people who then move on. A lone .htaccess file or a pile of registrar forwards hides your chains. You cannot audit it easily and you get no data on how fast each redirect responds.
A dedicated redirect management platform like urllo fixes that. Everything lives in one place. You get traffic analytics, partial path matching and responses served from fast infrastructure.
If you are managing redirects at scale and several of the mistakes above feel familiar, that is usually a sign to check out a redirect tool like urllo.
Frequently asked questions about redirect mistakes
What is the most common redirect mistake?
Using a 302 for a permanent move. It looks correct and still sends users to the right place, so it goes unnoticed while the old URL stays indexed and rankings stall.
Do redirects hurt SEO?
A correct redirect protects SEO by passing ranking signals to the new URL. The damage comes from the mistakes above, such as chains, homepage-only migrations and irrelevant destinations.
How many redirects in a row is too many?
Aim for zero extra hops when possible. Each starting URL should reach its destination in a single redirect.
When should I use a 301 or a 302?
Use a 301 when the move is permanent and a 302 only when the original URL will return.
By Shannon Young
Customer Success Manager
Shannon is a seasoned professional in the customer success space. She has years of experience in a wide variety of customer-facing roles in various sectors.
Always ready to take on the next challenge, whether it be a new offensive cross stitch pattern or making her dogs sit still for another themed photo, she is prepared for anything.
