Site migrations are where SEO careers go to die. A redesign launches on Tuesday, traffic plummets on Wednesday, and by Friday the marketing director is updating their LinkedIn.

The cause is almost never the new design. It’s the redirects. Or rather, the absence of them — or the wrong type, or the broken chains, or the carefully mapped 301s that quietly point to URLs that no longer exist.

This guide is the exact 301 migration playbook we use for every Dallas client moving platforms, restructuring URLs, or consolidating domains. Follow it and you’ll keep 95%+ of your organic traffic. Skip a step and you’ll spend the next 12 months rebuilding what took 3 years to earn.

TL;DR · Quick Summary

A 301 redirect tells Google a page has moved permanently, passing nearly all link equity to the new URL. Done right, you preserve rankings during migrations. Done wrong — broken targets, redirect chains, mixed 302s — you lose 30–80% of organic traffic within weeks. The framework below covers URL mapping, the 7 fatal mistakes, server-level implementation, and a 90-day recovery monitoring plan.

Visual summary of 301 Redirect Guide Architecture 301 Redirect Architecture Site migration best practices Map old URL → new URL Avoid redirect chains Update internal links Update sitemap immediately Monitor 404s for 90 days Preserve link equity

What a 301 Redirect Actually Does (And Why It Matters)

A 301 is an HTTP status code that says: “This URL has moved permanently to a new address.” When Googlebot encounters one, it does three things:

  • Updates its index — the old URL is dropped, the new URL inherits the indexed position.
  • Transfers ranking signals — backlinks, internal link equity, age, topical authority all pass to the destination.
  • Hands users off transparently — the browser silently follows the redirect, so the user never sees the old URL.

Google has repeatedly confirmed that 301 redirects pass nearly 100% of PageRank when implemented correctly. The catch is that “correctly” is a much narrower target than most developers realize.

The 5 Scenarios Where You Must Use 301s

If any of these apply to your business, you need a redirect map before you change a single URL:

  • Platform migration — moving from WordPress to Webflow, Shopify to Magento, etc. Every URL pattern changes.
  • URL structure overhaul — moving from /blog/?p=42 to /blog/article-slug/, or flattening deep directory paths.
  • HTTP to HTTPS — the entire site changes protocol. Without 301s, Google sees two duplicate sites.
  • Domain change or consolidation — merging acquired domains, switching from .net to .com, or moving from country code TLDs.
  • Content consolidation — merging duplicate or thin pages into a single authoritative resource. This is where most SEO agencies recover quietly lost traffic.

For a deeper look at how URL structure and crawl efficiency interact, see our breakdown of crawl budget and why Google bots ignore internal pages — the same principles apply during migrations.

Warning — 302 Is Not a Substitute

A 302 (“Found / Temporary”) is the most common silent killer in migrations. Developers default to 302s because they’re the framework’s default. Google treats 302s as temporary, meaning it keeps the old URL in the index and refuses to fully transfer ranking signals. After 4–6 weeks of leaked traffic, you’ll wonder why the migration “didn’t work.” Always verify your redirects return a real 301 status using a HTTP header checker.

The 7 Fatal 301 Mistakes (And How to Avoid Each)

Across 40+ Dallas-area site migrations between 2023 and 2026, these are the issues that caused 90% of post-launch traffic drops:

  • Redirect chains. URL A → URL B → URL C. Every hop dilutes equity and slows crawl. Always redirect directly to the final URL.
  • Redirect loops. URL A → URL B → URL A. Common with case-sensitivity bugs (/About vs /about). Causes infinite browser errors.
  • Redirecting to the homepage. The lazy “catch-all” redirect that maps every dead URL to the root. Google treats this as a soft 404 and drops the equity.
  • Mismatched topical intent. Redirecting a page about “Frisco HVAC repair” to a generic services page. Google sees the topic mismatch and disregards the redirect.
  • Forgetting non-www and trailing slash variants. If example.com/page redirects but www.example.com/page/ doesn’t, you have two indexed copies competing.
  • Using JavaScript redirects. Client-side window.location redirects work for users but Googlebot may not execute them in time. Server-side 301 only.
  • Removing redirects after 6 months. External backlinks point to old URLs for years. Keep redirects in place permanently — they cost nothing.

The 8-Step 301 Migration Process

This is the exact workflow we follow for every client migration. Skip a step and the recovery takes 6–9 months instead of 90 days.

Step 1: Inventory every existing URL

Crawl your live site with Screaming Frog (free up to 500 URLs) or Sitebulb. Export the complete list of indexed URLs. Cross-reference with Google Search Console’s Pages report to catch any URL Google knows about that your crawler missed.

Step 2: Identify your top 100 traffic-driving URLs

Pull last 12 months of organic landing pages from Google Analytics 4 or Search Console. The top 100 URLs typically drive 70–90% of organic revenue. These are your migration priority.

Step 3: Map old URLs to new URLs (one-to-one when possible)

For every old URL, decide its new destination. Ideal: a one-to-one match with the same topic. Acceptable: a parent category page if the specific page no longer exists. Never: the homepage.

Pro Tip — Use a Spreadsheet, Not Memory

Build a 2-column CSV: old_url, new_url. This becomes both your redirect rules and your post-launch QA checklist. Most agencies skip this step and rely on developers’ memory — which is why most migrations fail.

Step 4: Implement 301s at the server level

For Apache: edit .htaccess. For Nginx: add to your server block. For Cloudflare/Netlify/Vercel: use platform redirects. Avoid plugin-based redirects on WordPress for high-volume sites — they hit the database on every request and slow page load.

.htaccess example
RewriteEngine On
Redirect 301 /old-services /new-services-dallas
Redirect 301 /blog/old-post /articles/new-post-slug
RewriteRule ^old-category/(.*)$ /new-category/$1 [R=301,L]

Step 5: Test on staging before deploying

Crawl your staging URL with Screaming Frog in “list mode” using your old-URL CSV. Verify every redirect returns a 301 status (not 302, not 200) and resolves to the correct destination in a single hop.

Step 6: Launch and submit a fresh sitemap

Push the new structure live. Immediately submit a new sitemap.xml reflecting the new URL structure to Google Search Console. Don’t delete the old sitemap — let Google compare both for the first few weeks.

Step 7: Update internal links

Don’t rely on redirects forever. Within 2 weeks of launch, update every internal link in your nav, footer, blog content, and CTAs to point directly to the new URLs. This prevents accidental chains as your site evolves.

Step 8: Monitor for 90 days

Watch Search Console’s Pages report daily for 2 weeks, then weekly for 90 days. Look for new “Page with redirect” or “Excluded by redirect” statuses on URLs that shouldn’t have them. We cover this monitoring workflow in detail in our guide on how to fix indexing issues in Google Search Console.

Real Case: How a DFW HVAC Client Preserved 96% of Organic Traffic Through Migration

In November 2025 a Plano-based HVAC client migrated from WordPress to a custom Next.js build. The new architecture changed every URL pattern: /services/ac-repair-plano/ became /locations/plano/services/ac-repair/.

Pre-migration baseline: 14,200 organic sessions/month, 312 ranking keywords in top 10.

What we did:

  • Mapped all 287 indexed URLs to new destinations (3 days).
  • Built server-level 301 rules in Vercel’s config (not application-level).
  • Tested every redirect with Screaming Frog list-mode crawl before deploy.
  • Submitted new sitemap to GSC within 1 hour of launch.
  • Updated every internal link in the new build to point directly to new URLs (no chains).
Migration result “30 days post-launch, organic sessions held at 13,620 — a 4% dip during the transition window. By day 60 we were back to 14,800. By day 90 we hit 17,400 because the new architecture also improved Core Web Vitals.”

The Realistic 90-Day Recovery Timeline

Even with a perfect migration, expect some fluctuation. Here’s what we see across clients:

Days post-launchExpected impactWhat to monitor
0–7 days5–15% temporary dipCrawl errors, redirect chains, server status
8–30 daysRecovery to 90–95% of baselineGSC index coverage, sitemap re-submission
31–60 daysFull recovery to baselineKeyword rankings, backlink re-resolution
61–90 daysPotential growth if new architecture is betterNew keyword rankings, expanded indexation

If you’re still down 20%+ at day 60, something is broken. The most common late-stage finding: developers added redirect rules that accidentally affected URLs unrelated to the migration. Run a fresh full-site crawl and compare against your pre-migration baseline.

When to Hire Help

You can run a redirect mapping for a 50-page site yourself with the steps above. For sites over 500 URLs, with multiple subdomains, or with international hreflang complexity, the cost of getting it wrong (lost revenue) usually exceeds the cost of professional help. We’ve seen e-commerce sites lose $40K–$200K in the first quarter of a failed migration. Compared to a $5K–$15K professional migration audit, the ROI is obvious.

Whether you tackle it yourself or hire help, the principle is the same: every URL deserves a destination, no chains allowed, and 90 days of patient monitoring. Migrations are won in the planning, not the execution.

Frequently Asked Questions

How long do I need to keep 301 redirects in place after a migration?

Forever. External backlinks to your old URLs may exist for years on third-party sites, and removing redirects breaks all of them. The cost of keeping a 301 rule in place is essentially zero (a few microseconds of server processing). We’ve maintained client redirects from 2018 migrations that still receive 200+ visits/month from old backlinks.

Will I lose any traffic during a 301 migration even if everything is perfect?

Yes — typically 5–15% in the first 2 weeks as Google re-crawls and re-indexes. This is normal and expected. Full recovery to baseline happens within 30–60 days. If you’re still down 20%+ at day 60, something is broken and needs investigation. We always set client expectations: "Plan for a 10% dip month one, full recovery month two."

Can I use 301s to consolidate two competing pages on my own site?

Yes, and this is one of the most underused SEO tactics. If you have two pages targeting overlapping keywords (a common cause of keyword cannibalization), 301-redirecting the weaker page to the stronger one consolidates ranking signals and often produces a ranking boost within 4–8 weeks. Make sure the topics genuinely match before consolidating.

What’s the difference between a 301 and a canonical tag?

A 301 physically sends users and bots to a new URL — the old URL becomes inaccessible. A canonical tag (rel="canonical") keeps both URLs accessible but tells Google which one is the "preferred" version for ranking. Use 301s when the old URL should no longer exist; use canonical tags when both URLs need to remain accessible (e.g., parameterized URLs, AMP pages, paginated content).

Should I redirect HTTP to HTTPS even if my site is already on HTTPS?

Yes — explicitly. Some servers default to allowing both HTTP and HTTPS access, which creates duplicate-content signals. Add an enforced HTTPS redirect at the server level (or via Cloudflare’s "Always Use HTTPS" toggle). Test by visiting http://yoursite.com — you should be redirected to the https:// version with a 301 status, not a 302.

Planning a site migration? Get it audited before launch.

We’ve guided 40+ Dallas-area migrations without losing organic traffic. Get a redirect map review, server-config audit, and 90-day monitoring plan from the team that’s seen what breaks.

Get a Migration Audit Explore Technical SEO Services