Redirect strategy mistakes can obliterate organic traffic, duplicate indexation signals, and waste crawl budget. Understanding the technical mechanics of 301 versus 302, redirect chains, and preservation of link equity separates sites that maintain authority through migrations from those that lose months of ranking momentum.
The distinction between 301 and 302 status codes determines whether search engines treat a redirect as permanent or temporary. A 301 tells Google to transfer ranking signals from the old URL to the new one and update the index accordingly. A 302 preserves the original URL in the index because the move is expected to reverse.
The most damaging mistake is using 302 when the change is permanent. E-commerce sites frequently implement 302 redirects during seasonal URL restructuring, then leave them in place for years. Google continues checking the original URL, divides authority between both addresses, and may revert to indexing the old page if it remains in the sitemap or receives fresh backlinks.
Canadian government and institutional sites sometimes default to 302 for bilingual URL shifts between /en/ and /fr/ paths when the structure changes permanently. This creates indexation ambiguity that fragments language-specific ranking. Server configurations and CMS plugins often default to 302 unless explicitly set otherwise—verify status codes with curl commands or browser dev tools before deploying redirects at scale.
A redirect chain occurs when URL A redirects to URL B, which redirects to URL C. Each hop adds latency, consumes crawl budget, and dilutes the link equity passed through the sequence. Google follows redirect chains but may stop after three to five hops, leaving the final destination undiscovered.
Chains typically accumulate during multiple site migrations or CMS platform changes. A page moves from /old-product to /products/old-product, then later to /shop/product-name. Without auditing existing redirects, the new redirect appends to the chain rather than replacing it. The original /old-product redirect should point directly to /shop/product-name in a single 301.
Redirect loops—where URL A redirects to B and B redirects back to A—halt crawling entirely and return server errors to users. These often emerge from conflicting .htaccess rules, plugin conflicts in WordPress, or case-sensitivity mismatches between redirect maps and actual URLs. Crawl tools like Screaming Frog surface chains and loops during pre-launch audits. Flattening chains into direct mappings before pushing redirects live prevents compounding authority loss across hundreds of pages.
Wildcard or catch-all redirects send all old URLs from a retired section to a single destination, typically the homepage or a category page. This approach is fast to implement but scatters topical signals that Google assigned to specific pages.
When a legal services site with 80 practice-area pages redirects everything to the homepage, backlinks pointing to /estate-planning or /corporate-law suddenly funnel generic authority instead of reinforcing specific expertise. Google sees no contextual continuity and often discounts the equity transfer. Ranking for those practice-area terms drops because the new destination lacks the content depth and semantic alignment of the original.
The correct approach maps each old URL to the most contextually similar new URL. If an exact equivalent doesn't exist, redirect to the closest parent category or a hub page that links prominently to related content. For truly obsolete pages with no equivalent—discontinued products, outdated event listings—a 410 Gone status is more honest than a forced redirect. Wildcard rules have a place for handling parameter variations or archived date-based URLs, but core content pages deserve individual mapping. Export old URLs with backlink counts from Search Console or Ahrefs, prioritize high-authority pages, and build a redirect map that preserves topic-to-topic alignment.
Redirects execute at different layers: server configuration, application code, or client-side scripts. Server-side redirects via .htaccess, nginx.conf, or server blocks happen before any page content loads, making them fastest and most crawler-friendly. Application-level redirects in PHP, Node, or Rails run after the server processes the request but still occur server-side.
JavaScript redirects and meta refresh tags execute in the browser after the page begins loading. Google can follow these but with delay—crawlers must render JavaScript, and meta refresh introduces a wait time before the redirect fires. This slows indexation updates and creates a window where the old URL remains in search results serving outdated content.
Canonical tags are not redirects. They suggest a preferred URL but don't prevent users or bots from accessing the non-canonical version. Relying solely on canonicals when URLs have genuinely moved leads to duplicate indexation and user confusion. Some CMSs layer both—a canonical pointing to the new URL and a JavaScript redirect—which is redundant and messy. Choose server-side 301 redirects for permanent moves and reserve canonicals for handling legitimate duplicate content like print versions or session IDs. Cloud hosting platforms like Netlify and Vercel handle redirects through configuration files; ensure these deploy before DNS cutover during migrations.
Query parameters and URL fragments carry functional and tracking information that redirect rules often strip unintentionally. An e-commerce filter URL like /products?category=shoes&size=10 redirected to /products loses the parameter data, sending users to an unfiltered page that doesn't match their intent.
Fragment identifiers (the #section after a URL) don't transmit to servers in HTTP requests, so server-side redirects can't directly map them. If an old URL used #pricing to jump to a pricing section and the new URL structures that as /pricing, the redirect must account for this. Users clicking old anchored links land at the top of a new page instead of the relevant section.
Redirect rules should preserve parameters unless they're explicitly obsolete. Apache mod_rewrite with the QSA flag appends query strings; nginx uses $is_args$args. For fragments, if the old structure relied on them for navigation and the new structure uses distinct paths, document the mapping and update internal links manually—redirects alone can't solve this. UTM parameters in marketing URLs must pass through redirects intact or attribution breaks. Test redirect rules with sample URLs that include parameters before applying them broadly, and monitor server logs post-launch for 404s that suggest parameter-stripping issues.
Redirect strategy doesn't end at deployment. Many sites implement redirects during a migration, then never revisit them. Temporary 302s remain in place permanently, redirect chains accumulate from subsequent URL changes, and orphaned redirects point to pages that later move again or get deleted.
Google Search Console's coverage reports show which redirected URLs still appear in the index weeks after launch. If old URLs persist, check that XML sitemaps don't still list them and that internal links have updated to point directly to new URLs instead of relying on redirects. Server logs reveal which redirects receive the most traffic—high-volume redirects to 404s indicate broken mappings that need immediate fixes.
Canadian sites with bilingual content should verify that language-specific redirects don't cross languages unintentionally—/fr/ancienne-page shouldn't redirect to /en/new-page unless the French equivalent is genuinely retired. Redirect performance appears in Google's crawl stats; spikes in redirect response times or counts signal misconfiguration. Schedule quarterly redirect audits to flatten chains, remove redirects to pages that have been live for over a year (Google has fully transferred signals), and catch circular references introduced by CMS updates or team members unaware of existing rules. Redirect maps belong in version control alongside code, not just in server configs where they're invisible to content teams.
Maintain 301 redirects indefinitely for pages with significant backlink profiles or historical traffic. Google transfers most ranking signals within weeks to months, but backlinks continue arriving to old URLs for years. For low-value pages with no inbound links after six to twelve months, you can consider removing redirects, but the server cost of keeping them is negligible compared to the risk of losing residual equity.
Redirects themselves don't harm rankings if implemented correctly, but redirect chains add latency that degrades user experience and consumes crawl budget. Sites with thousands of redirects should ensure they're server-side, direct mappings with no chains. Excessive redirects may indicate deeper information architecture problems—consolidating content or pruning obsolete pages is often better than maintaining sprawling redirect maps.
A 301 redirect sends users and crawlers from one URL to another, replacing the old URL in search results. A canonical tag keeps both URLs accessible but tells Google which version to prioritize for indexing. Use 301s when a URL has permanently moved; use canonicals when duplicate content serves a legitimate purpose, like print versions or product variants that users need to access directly.
Redirect to the parent category or a comparable product if one exists, preserving topical relevance for backlinks and user intent. If the entire product line is discontinued with no equivalent, a 410 Gone status is more accurate than forcing a homepage redirect. This tells Google the content is intentionally removed, preventing the homepage from inheriting irrelevant signals and reducing crawl waste on dead-end redirects.
Build a staging environment that mirrors production, implement redirects there, and crawl it with Screaming Frog or Sitebulb to identify chains, loops, and incorrect status codes. Use curl or browser dev tools to manually verify high-priority URLs. Export a sample of old URLs with backlinks from Search Console or Ahrefs, test each mapping, and confirm the final destination matches the intended content. Check that parameters and trailing slashes behave consistently.
Google can follow JavaScript redirects, but they introduce delays because crawlers must render the page before detecting the redirect. Server-side 301s execute instantly and reliably, making them the standard for SEO. Reserve JavaScript redirects for cases where server configuration isn't accessible. Meta refresh redirects with zero-second delays function similarly to JavaScript redirects—workable but suboptimal compared to server-side implementation.