SEO Redirect

I start every redirect project with an audit. On a recent client site with 500 blog posts, I found 120 old URLs that still carried backlinks after a CMS migration. I pulled that list from Search Console, Google Analytics, and a backlink tool. Every URL with organic traffic, rankings, or external links went into a spreadsheet. The columns: old URL, redirect type, destination URL, and a note on whether the destination still existed or needed to be created.

Once I have the map, I decide on the right type. For permanent moves — which covers almost every scenario I encounter — I use a 301 redirect. That passes the majority of link equity to the new URL. For temporary moves, such as a seasonal landing page that will return, I use a 302. The distinction matters because Google will treat a 301 as a signal to transfer ranking signals and update its index, while a 302 keeps the old URL in play.

I implement at the server layer — either .htaccess on Apache or a redirect rule in nginx — because that avoids conflicts with CMS plugins. I have seen a site where a WordPress plugin and a server rule both fired, creating a chain that doubled the redirect latency. Pick one layer and stick to it. If the site is on a CDN like Cloudflare, you can set redirects there, but test that the CDN does not override your origin config.

After implementation, I test every redirect. I use curl to check the HTTP status code and the final URL. For the blog migration example, I tested 120 URLs in about 30 minutes. I caught two chains where an old URL redirected to an intermediate that then redirected again. I consolidated those so the old URL went directly to the final destination. That saves crawl budget and avoids latency.

Finally, I resubmit the [sitemap](/sitemap/) in Search Console and monitor the crawl stats for the next two weeks. If I see a spike in 404s or a drop in indexed pages, I cross-check against the redirect map. On that migration, we preserved 87% of organic traffic to the redirected URLs within one month. The rest were pages where the destination was a poor topical match — something I now avoid by mapping to the most specific available page, even if that means creating a new archive page.

The most common mistake I see is using a 302 for a permanent move. A 302 does not pass link equity. Google treats it as a temporary signal, so the old URL remains the canonical source. I once used a 302 for a permanent URL change on an ecommerce product page. Three months later, the old URL still appeared in search results with zero traffic because Google had not transferred the ranking signals. Switch to a 301 if the move is permanent.

Another mistake is redirecting everything to the homepage. I see this often when someone migrates a site and does not want to map each old URL. The result is a loss of relevance. In the blog migration I mentioned earlier, the client initially wanted to send all old blog posts to the homepage. I showed them that traffic would drop by an estimated 40% based on the backlink profile. Instead, we mapped each old URL to a similar post or created a new archive page for orphaned topics.

Redirect chains waste crawl efficiency. I once audited an ecommerce site that had a chain of four redirects: old product URL → category page → new product URL → HTTPS version of new product. Google crawled eight URLs to reach two pages. Consolidate chains so the old URL points directly to the final destination. Use a tool like Screaming Frog to detect chains during a [technical SEO](/technical-seo/) audit.

Redirect loops are even worse. A loop between old and new breaks resolution entirely. Search engines give up and fail to index either page. I always test for loops with curl or a browser plugin before deploying.

Conflicting signals cause confusion. If you set a [canonical tag](/canonical-tag/) on the old URL pointing to a different destination, search engines may ignore the redirect. The same applies if you block the old or new URL in robots.txt. I ensure that the redirect is the only signal telling bots where to go.

Finally, watch out for HTTPS redirects during a site migration. When moving from HTTP to HTTPS, use a 301 from the old HTTP URL to the new HTTPS URL. Never use a 302 because Google will treat the HTTPS version as temporary.

Early in my career, I managed a website for a small ecommerce brand. When they discontinued a product line, I redirected the entire category page to the homepage. I thought 'close enough' because the brand still sold other products. Traffic for that category dropped from about 2,000 visits a week to fewer than 100. I spent weeks rebuilding rankings for the new product pages. That taught me to always map to the most specific page, even if it means creating a new landing page for that topic.

I also used to assume a 302 was harmless for short-term promotions. On a client site, I used a 302 to send seasonal Christmas content to a new URL for three months. Google did not index the new URL because it treated the redirect as temporary. When the promotion ended and I removed the 302, the old content had lost all its rankings because it had been sitting dormant. Now I either use a 301 and accept the permanence, or I keep the old page live and use a canonical if needed.

Another mistake: I set up redirects on both the server and a CMS plugin. The plugin fired first, redirecting to an intermediate URL, and then the server rule applied, creating a chain. It took me two weeks to debug because I checked only the server log. Now I disable all plugins that handle redirects and manage everything at the server level.

For years, I skipped testing redirects on small sites. I thought the risk was low. Then a single typo in a redirect map caused a 404 for a page that had 50 backlinks. The 404 persisted for a month, and the backlinks decayed. Testing every redirect now takes me less than an hour for a 100-url map. I use an online tool that shows the full chain and status code.

I changed my mind on how to organise redirect maps. I used to only list old URL and destination. Now I also add the date of last test, the redirect type, and whether the destination has a canonical tag. That makes it easy to revisit during an [SEO audit](/seo-audit/) and confirm nothing has changed.