Setting Up 301 Redirects for a Domain Migration

You're moving domains. Your rankings matter. Your traffic matters. Your backlinks matter. One mistake—a botched redirect, a missed URL mapping, a server misconfiguration—and you lose months of organic visibility overnight.

This is not theoretical. It happens constantly. Founders ship domain migrations without proper redirect infrastructure and watch their traffic crater. Then they scramble to fix it while Google crawls broken links and old pages vanish from search results.

A 301 redirect is the difference between preserving your SEO equity and starting from zero.

This guide walks you through the entire process: auditing your current domain, mapping every URL, implementing redirects at the right layer, testing them before launch, and monitoring after migration. You'll have a redirect implementation checklist and templates you can use immediately.

Prerequisites: What You Need Before Starting

Before you touch a single redirect, make sure you have:

Access and tools:

• Full access to your current domain's server (SSH, hosting control panel, or DNS management)
• Full access to your new domain's server with the same level of control
• A spreadsheet or CSV tool (Google Sheets works fine) for URL mapping
• Browser DevTools or a redirect checker like Ahrefs' redirect checker to verify redirects post-launch
• Google Search Console access for both domains
• Google Analytics access (or your analytics platform) to track traffic before and after

Knowledge baseline:

• Basic understanding of HTTP status codes (knowing that 301 means "moved permanently")
• Familiarity with your hosting platform (Apache, Nginx, Vercel, Cloudflare, etc.)
• Access to DNS records if you're changing nameservers

Time allocation:

• URL auditing: 2–4 hours (depending on site size)
• Redirect mapping: 4–8 hours
• Implementation: 2–4 hours
• Testing: 2–3 hours
• Monitoring post-launch: ongoing, but critical for first 2 weeks

If your site has thousands of pages, you'll need to automate parts of this process. We'll cover that below.

Step 1: Audit Your Current Domain and Create a Complete URL Inventory

You cannot redirect what you don't know exists. Start by cataloging every URL that matters.

Generate a sitemap inventory:

If you have an XML sitemap (usually at yoursite.com/sitemap.xml), download it. This is your starting point. If you don't have one, generate one using Screaming Frog SEO Spider or a similar crawler.

The goal: a complete list of every page Google can see on your current domain.

Export your current rankings:

If you use Google Search Console, export your top-performing pages. If you use Semrush, Ahrefs, or similar tools, export your keyword rankings by URL. This tells you which pages are driving traffic and which redirects matter most.

Identify high-value URLs:

Not all pages are equal. Pages with:

• Organic traffic (check Google Analytics)
• Backlinks (check Ahrefs, Semrush, or Google Search Console)
• High rankings (check your rankings export)
• Internal links from your homepage or navigation

These need redirect priority. A blog post with 50 backlinks needs a redirect. A thin internal page with no traffic can sometimes be consolidated or dropped.

Document URL structure changes:

Are you changing your URL structure? For example:

• Old: yoursite.com/blog/post-title
• New: newsite.com/insights/post-title

Or are you keeping the same structure?

This matters because it determines whether you can use pattern-based redirects (more efficient) or need one-to-one mappings (more granular).

Create your URL mapping spreadsheet:

Build a CSV with three columns:

Old URL,New URL,Redirect Type,Status
https://oldsite.com/about,https://newsite.com/about,301,pending
https://oldsite.com/blog/post-1,https://newsite.com/insights/post-1,301,pending
https://oldsite.com/pricing,https://newsite.com/plans,301,pending

For most migrations, every redirect is a 301 (permanent). Use 302 (temporary) only if you're genuinely testing a redirect for a short period (which is rare in domain migrations).

Fill in every URL from your sitemap and analytics. If your site has thousands of pages, write a script to generate this automatically. If your URL structure is consistent, you can use pattern-based redirects (handled in Step 3).

Step 2: Understand the Technical Foundation of 301 Redirects

Before you implement, understand what actually happens when you set up a 301 redirect.

How 301 redirects work:

When a user (or Googlebot) requests oldsite.com/page, your server responds with HTTP status code 301 and a Location header pointing to the new URL:

HTTP/1.1 301 Moved Permanently
Location: https://newsite.com/page

The browser follows the redirect. Google follows the redirect and transfers the SEO equity (ranking signals, backlink authority) from the old URL to the new one. This is why 301 redirects are critical for migrations—they preserve your rankings.

According to Google's official documentation on 301 redirects, a properly implemented 301 redirect passes nearly all ranking signals to the destination URL. This is the whole point.

Why not use other redirect types:

• 302 (Temporary Redirect): Google treats this as temporary and may not transfer ranking signals fully. Only use this if the redirect is genuinely temporary.
• 307 (Temporary Redirect): Similar to 302. Preserves the HTTP method (POST stays POST) but still signals "temporary" to search engines.
• 308 (Permanent Redirect): Like 301 but preserves the HTTP method. Functionally equivalent to 301 for most use cases, but 301 has better browser support.
• Meta refresh or JavaScript redirects: These are slower, don't pass all ranking signals, and are a last resort. Avoid them.

Use 301. It's the standard for domain migrations.

Redirect depth matters:

Don't chain redirects. Don't do:

oldsite.com/page → intermediatesite.com/page → newsite.com/page

This creates redirect chains. Google will follow them (up to a point), but each redirect adds latency and increases the risk of a broken chain. Redirect directly from old to new.

Step 3: Choose Your Redirect Implementation Method

You have several options for where to implement redirects. Choose based on your hosting setup.

Option A: Server-level redirects (.htaccess for Apache)

If you're on shared hosting with Apache, use .htaccess. This is the fastest and most reliable method.

Create a .htaccess file in your old domain's root directory:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.oldsite\.com$
RewriteRule ^(.*)$ https://newsite.com/$1 [R=301,L]
</IfModule>

This redirects everything from oldsite.com to newsite.com, preserving the path. If your URL structure changed, you need specific rules:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.oldsite\.com$
RewriteRule ^blog/(.*)$ https://newsite.com/insights/$1 [R=301,L]
RewriteRule ^(.*)$ https://newsite.com/$1 [R=301,L]
</IfModule>

For more complex patterns, consult the HTAccess guide on 301 redirects for syntax and examples.

Option B: Server-level redirects (Nginx configuration)

If you're on Nginx, edit your server configuration block:

server {
    listen 80;
    server_name oldsite.com www.oldsite.com;
    return 301 https://newsite.com$request_uri;
}

For path-based redirects:

server {
    listen 80;
    server_name oldsite.com www.oldsite.com;
    location ~ ^/blog/(.*)$ {
        return 301 https://newsite.com/insights/$1;
    }
    location / {
        return 301 https://newsite.com$request_uri;
    }
}

Reload Nginx after changes:

sudo nginx -s reload

For deeper Nginx configuration guidance, the Nginx configuration pitfalls guide covers common mistakes in redirect setup.

Option C: Application-level redirects (Node.js, Python, Ruby, etc.)

If you control the application code, you can implement redirects in middleware.

For Express.js:

app.get('*', (req, res) => {
  res.redirect(301, `https://newsite.com${req.originalUrl}`);
});

For Django:

from django.views.generic import RedirectView

class OldSiteRedirect(RedirectView):
    permanent = True
    def get_redirect_url(self, *args, **kwargs):
        return f'https://newsite.com{self.request.get_full_path()}'

Application-level redirects are flexible but slower than server-level redirects. Use them when you need conditional logic or when server-level configuration isn't available.

Option D: CDN/Proxy redirects (Cloudflare, Vercel, etc.)

If you're using a CDN or edge platform, you can implement redirects at the edge.

For Cloudflare, use Page Rules or Bulk Redirects:

1. Go to Cloudflare dashboard → Rules → Bulk Redirects
2. Upload your CSV with old URLs and destinations
3. Cloudflare handles the redirects at the edge

For Vercel, use vercel.json:

{
  "redirects": [
    {
      "source": "/old-page",
      "destination": "https://newsite.com/new-page",
      "permanent": true
    }
  ]
}

For a deeper technical explanation of how HTTP 301 redirects function, see Cloudflare's HTTP 301 status code guide.

Which method should you use?

• Small site, traditional hosting: .htaccess (Apache) or Nginx config
• Large site with thousands of URLs: Nginx or Cloudflare Bulk Redirects (scales better)
• Modern stack (Vercel, Netlify, etc.): Use platform-native redirect configuration
• Need conditional logic: Application-level redirects

Pick one and stick with it. Don't mix methods—it creates confusion and debugging nightmares.

Step 4: Map Your URLs and Handle Special Cases

Now you're ready to map URLs systematically.

One-to-one URL mapping:

For pages that have a direct equivalent on the new domain, create one-to-one mappings:

Old: https://oldsite.com/about
New: https://newsite.com/about

Old: https://oldsite.com/blog/seo-guide
New: https://newsite.com/insights/seo-guide

Use your spreadsheet to document these. If you have hundreds, automate with a script.

Pattern-based redirects:

If your URL structure is consistent, use pattern-based redirects to avoid individual mappings:

Old pattern: /blog/([a-z-]+)
New pattern: /insights/$1

This single rule redirects /blog/post-title to /insights/post-title automatically.

Handling URL structure changes:

If you're changing from /blog/ to /insights/, your redirect rule is:

RewriteRule ^blog/(.*)$ https://newsite.com/insights/$1 [R=301,L]

If you're consolidating multiple paths into one, decide on a destination:

Old: /products/widget
Old: /shop/widget
Old: /buy/widget
New: /products/widget

All three old URLs redirect to the same new URL. This is fine and expected during restructures.

Handling pages with no equivalent:

Some pages won't have a direct equivalent. For example:

• Old blog posts you're retiring
• Old product pages for discontinued products
• Outdated landing pages

You have two options:

1. Redirect to a relevant parent page: If you're retiring /blog/old-post, redirect to /blog/ or /insights/
2. Redirect to your homepage: If there's no relevant parent, redirect to /

Don't leave old URLs broken. A broken URL (404) loses all ranking signals. A redirect to a related page preserves some equity.

Query parameters and fragments:

If your old URLs have query parameters (?utm_source=google&utm_medium=organic), preserve them in the redirect:

RewriteRule ^(.*)$ https://newsite.com/$1 [R=301,L,QSA]

The QSA flag appends query strings automatically.

URL fragments (#section) are handled by the browser and don't need special redirect handling. The server never sees them.

Step 5: Implement Redirects on Your Old Domain

You have your mappings. You've chosen your method. Now implement.

Before touching production:

1. Back up your current .htaccess, server config, or application code
2. Test redirects on a staging environment first
3. Get a second set of eyes to review your redirect rules

One typo in a redirect rule and you're redirecting traffic to the wrong place.

Implementation steps:

For Apache (.htaccess):

1. SSH into your server or use your hosting control panel
2. Navigate to your old domain's root directory
3. Create or edit .htaccess
4. Add your redirect rules (see Step 3)
5. Save the file
6. Test immediately (see Step 6)

For Nginx:

1. SSH into your server
2. Edit your Nginx configuration file (usually in /etc/nginx/sites-available/)
3. Add your redirect rules
4. Test the configuration: sudo nginx -t
5. Reload Nginx: sudo nginx -s reload
6. Test immediately

For application-level redirects:

1. Add redirect middleware to your application code
2. Deploy to staging
3. Test thoroughly
4. Deploy to production

For Cloudflare or CDN redirects:

1. Log into your CDN dashboard
2. Upload your redirect mappings (usually as CSV)
3. Enable the redirects
4. Test immediately

Critical: Keep the old domain live during testing

Don't take down the old domain yet. You need it to test redirects. Users and search engines still need to access it.

Step 6: Test All Redirects Before Full Migration

Testing is where most migrations fail. Founders skip this step and launch with broken redirects.

Don't be that founder.

Manual testing:

Test your highest-traffic URLs manually:

1. Open a browser
2. Visit oldsite.com/page
3. Confirm you land on newsite.com/page
4. Check the address bar—it should show the new URL
5. Open DevTools (F12) → Network tab
6. Reload the page
7. Look for the request to the old URL
8. Click it and check the response headers
9. Confirm the status code is 301 (not 302, not 200)
10. Confirm the Location header points to the new URL

Repeat for at least 20–30 high-traffic URLs. If you have hundreds, automate this.

Automated redirect testing:

Use a tool to test all redirects at once:

• Ahrefs' redirect checker can test multiple URLs
• Semrush's redirect audit includes redirect verification
• Screaming Frog has a redirect audit feature
• Write a simple script:

while IFS=',' read -r old_url new_url; do
  status=$(curl -s -o /dev/null -w "%{http_code}" -L "$old_url")
  echo "$old_url -> $status"
done < urls.csv

This script checks the HTTP status code for each old URL. A 301 followed by a 200 (on the new domain) is correct.

Common redirect mistakes to catch:

• Redirect chains: Old URL redirects to intermediate URL, which redirects to new URL. Test and eliminate these.
• Broken destination URLs: Redirect points to a page that doesn't exist on the new domain. Check all destination URLs exist.
• Wrong status codes: Using 302 instead of 301. Verify with DevTools.
• Incomplete URL mapping: Some URLs aren't redirecting at all. Test comprehensively.
• Query parameter loss: Old URLs with parameters aren't preserving them. Test with ?param=value URLs.

Testing checklist:

• Test 30+ high-traffic URLs manually
• Verify status code is 301 (not 302, 307, or 200)
• Verify destination URL is correct
• Test URLs with query parameters
• Test URLs with special characters
• Test both www and non-www versions
• Test URLs with trailing slashes and without
• Run automated redirect audit tool
• Check for redirect chains
• Verify no circular redirects (A → B → A)

If any test fails, fix it before migration. Do not launch with broken redirects.

Step 7: Set Up the New Domain and Verify It's Ready

While testing redirects on the old domain, prepare the new domain.

Ensure the new domain is fully functional:

1. All pages load correctly
2. SSL/HTTPS is working (redirect tests fail if SSL is broken)
3. No internal links still point to the old domain
4. Search console is set up for the new domain
5. Analytics is tracking the new domain
6. Robots.txt is configured (don't accidentally block Googlebot)
7. XML sitemaps are updated with new URLs

Update internal links:

Before migration, update any internal links in your content that point to the old domain. For example, if your homepage links to oldsite.com/about, change it to newsite.com/about.

This isn't strictly necessary (redirects handle it), but it's cleaner and faster for users.

Verify DNS and hosting:

If you're changing nameservers or DNS records:

1. Update DNS records to point to the new domain's hosting
2. Wait for propagation (can take 24–48 hours, but usually faster)
3. Verify the new domain is accessible
4. Confirm SSL certificate is valid

Set up Google Search Console for the new domain:

1. Go to Google Search Console
2. Add the new domain as a property
3. Verify ownership (via DNS, HTML file, or other method)
4. Submit the new sitemap
5. Request indexing for key pages

Do this before migration. This helps Google understand the migration and crawl the new domain faster.

Step 8: Execute the Migration

You've tested everything. The new domain is ready. Now you migrate.

Timeline:

1. Day 0 (before migration): Final verification that all redirects work
2. Migration day: Activate redirects on old domain, ensure new domain is live
3. Hours 1–4 after migration: Monitor redirects in real-time, check for errors
4. Day 1–7 after migration: Monitor traffic, check Google Search Console for errors
5. Week 2–4 after migration: Monitor rankings, traffic, and crawl errors

Migration day checklist:

• Backup old domain's server configuration and database
• Activate redirects on old domain
• Verify new domain is fully live and accessible
• Monitor server logs for errors
• Test 10 random URLs to confirm redirects work
• Monitor Google Search Console for crawl errors
• Monitor analytics for traffic anomalies
• Update any external links you control (social profiles, email signatures, etc.)
• Notify your team that migration is live

Keeping the old domain live:

Don't take down the old domain immediately. Keep it live with redirects for at least 6–12 months. This gives:

• Search engines time to re-crawl and re-index
• Users with old bookmarks time to get redirected
• Backlinks time to be discovered and credited to new URLs

After 6–12 months, you can let the old domain expire if you want. But keeping it live is safer.

Step 9: Monitor and Verify Post-Migration

Migration isn't done when you flip the switch. It's done when your rankings stabilize and traffic returns to normal.

Week 1 after migration:

Google Search Console:

1. Check for crawl errors
2. Look for "Redirect error" messages
3. Check indexing status—you should see new URLs being indexed
4. Submit the new sitemap again
5. Request indexing for key pages

Analytics:

1. Monitor traffic to the new domain
2. Compare to traffic on the old domain (via redirects)
3. Watch for drops in organic traffic
4. Check bounce rate—high bounces might indicate redirect issues

Rankings:

1. Check your top 20 keywords in Google Search Console
2. Monitor rankings in your SEO tool (Ahrefs, Semrush, etc.)
3. Expect some fluctuation in the first 1–2 weeks—this is normal
4. Significant drops (>50% for a keyword) warrant investigation

Server logs:

1. Check for 404 errors on the old domain (indicates broken redirects)
2. Check for redirect loops (old domain keeps redirecting to itself)
3. Look for 5xx errors (server issues)

Analyze logs for the first week daily, then weekly for a month.

Week 2–4 after migration:

Rankings should stabilize. If they don't:

1. Rankings dropped significantly: Check for redirect issues, crawl errors, or indexing problems
2. Traffic dropped but rankings stable: Check analytics setup—you might not be tracking new domain traffic correctly
3. Some pages lost rankings: Verify those specific redirects are working; check if destination pages have quality issues

Troubleshooting common post-migration issues:

Issue: Traffic dropped 50%+ after migration

Possible causes:

• Broken redirects (test immediately)
• New domain not indexed (check Google Search Console)
• New domain marked as spam (unlikely, but check)
• Analytics not tracking new domain (check tracking code)
• Destination pages have issues (check page quality, load speed)

Fix: Test redirects, check Search Console, verify analytics setup.

Issue: Some pages lost rankings

Possible causes:

• Redirect broken for those specific URLs
• Destination page is different from original (different content, lower quality)
• URL structure changed and redirect rule is wrong

Fix: Test those specific URLs, verify redirect destination, check destination page quality.

Issue: Crawl errors in Google Search Console

Possible causes:

• Destination URLs don't exist
• Redirect points to 404 page
• Redirect chain or loop

Fix: Check destination URLs, verify they exist, eliminate redirect chains.

Step 10: Update External References and Backlinks

Your redirects handle users and search engines, but you should also update external references.

Update what you control:

• Social media profiles (LinkedIn, Twitter, etc.)
• Email signatures
• Business listings (Google My Business, etc.)
• Partner websites (if you have formal partnerships)
• Your own marketing materials

This isn't strictly necessary (redirects work), but it's professional and faster for users.

Reach out to high-authority backlinks:

If you have backlinks from high-authority sites, consider reaching out to ask them to update the link to your new domain. This is optional but can speed up ranking recovery.

Example email:

Subject: URL Update for [Your Company]

Hi [Contact],

We recently migrated our website to a new domain: newsite.com
Your site links to our old domain at oldsite.com.

We've set up 301 redirects, so the link still works. But if you could update it to point to newsite.com directly, that would be great.

Old URL: oldsite.com/page
New URL: newsite.com/page

Thanks!

Most high-authority sites will update if you ask nicely. This accelerates ranking recovery.

Pre-Migration Checklist Template

Use this checklist before you migrate:

[ ] Audit current domain and export all URLs
[ ] Export current rankings and traffic data
[ ] Create URL mapping spreadsheet (old → new)
[ ] Identify high-value URLs (traffic, backlinks, rankings)
[ ] Choose redirect implementation method
[ ] Set up redirect rules on old domain (staging first)
[ ] Test redirects on 30+ URLs manually
[ ] Verify status code is 301 for all tested URLs
[ ] Run automated redirect audit tool
[ ] Check for redirect chains and loops
[ ] Prepare new domain (SSL, content, structure)
[ ] Update internal links on new domain
[ ] Set up Google Search Console for new domain
[ ] Submit sitemap to Search Console
[ ] Verify DNS and hosting setup
[ ] Activate redirects on old domain
[ ] Monitor Search Console for crawl errors (first 24 hours)
[ ] Monitor analytics for traffic (first week)
[ ] Monitor rankings (first 2 weeks)
[ ] Update social profiles and external references
[ ] Keep old domain live (6–12 months minimum)

Redirect Mapping Template

Use this CSV template for your URL mappings:

Old URL,New URL,Redirect Type,Old Traffic (Monthly),Has Backlinks,Status
https://oldsite.com/about,https://newsite.com/about,301,500,Yes,pending
https://oldsite.com/blog/post-1,https://newsite.com/insights/post-1,301,1200,Yes,pending
https://oldsite.com/pricing,https://newsite.com/plans,301,800,No,pending
https://oldsite.com/contact,https://newsite.com/contact,301,300,No,pending

Fill in all columns. The "Old Traffic" and "Has Backlinks" columns help you prioritize which redirects matter most.

Why 301 Redirects Matter for Your SEO

Understanding the broader context of your migration helps you execute it correctly. As covered in the difference between indexing and ranking, your pages need to be indexed before they can rank. A domain migration threatens both.

Without proper redirects:

• Old URLs are no longer indexed (they're gone)
• New URLs might not be indexed immediately
• Ranking signals (backlinks, authority) don't transfer
• Traffic drops

With proper 301 redirects:

• Old URLs redirect to new ones (search engines follow)
• Ranking signals transfer to new URLs
• New URLs get indexed faster
• Traffic is preserved

This is why 301 redirects are non-negotiable for domain migrations. They're the mechanism that preserves your SEO equity.

For a deeper understanding of how search engines crawl and index your site, see crawlability for founders. Proper redirects are part of a crawlable site structure.

Common Redirect Mistakes to Avoid

Mistake 1: Using 302 redirects instead of 301

302 redirects signal "temporary." Google may not transfer all ranking signals. Always use 301 for permanent migrations.

Mistake 2: Redirect chains

Old URL → Intermediate URL → New URL. This adds latency and can break. Redirect directly.

Mistake 3: Broken destination URLs

Redirecting to a page that doesn't exist. Test all destination URLs before migration.

Mistake 4: Forgetting query parameters

Old URL has ?utm_source=google but the redirect strips it. Use QSA flag in .htaccess or preserve parameters in your redirect rule.

Mistake 5: Taking down the old domain too quickly

Users and search engines still need time to discover and follow redirects. Keep the old domain live for 6–12 months.

Mistake 6: Not testing redirects

Launching without testing. One broken redirect and you lose traffic. Test thoroughly before migration.

Mistake 7: Forgetting to update Google Search Console

Not notifying Google about the migration. Submit the new sitemap and request indexing in Search Console.

Mistake 8: Changing URL structure without redirect rules

If you're changing /blog/ to /insights/, you need a redirect rule that maps the old path to the new one. A catch-all redirect to the homepage loses all equity.

Redirect Monitoring Tools and Resources

Use these tools to monitor and verify redirects:

• Ahrefs' redirect checker – Test multiple URLs and verify 301 status
• Semrush redirect audit – Comprehensive redirect analysis
• Screaming Frog – Crawl your site and identify redirect issues
• Google Search Console – Monitor crawl errors and indexing status
• Google Analytics – Track traffic before and after migration
• DevTools (F12) – Verify redirect status codes in real-time
• Curl command line – Test redirects from the command line: curl -I oldsite.com/page

For additional context on technical SEO implementation, week 1 of SEO for busy founders covers the domain audit and technical foundation that makes migrations successful.

Integration with Your Broader SEO Strategy

A domain migration isn't an isolated event—it's part of your overall SEO strategy. If you're planning a migration, you're likely also working on:

• Brand positioning: Ensure your new domain aligns with your brand. See brand positioning fundamentals for guidance.
• Keyword strategy: Your migration is a good time to restructure content around a keyword roadmap. See your first 100 days of SEO for a complete keyword strategy.
• Content quality: New domain = fresh start. Ensure destination pages are higher quality than the originals. See the 30-day SEO sprint for content priorities.
• Technical foundation: Redirects are one part. See crawlability for founders for the full technical checklist.

A domain migration done right is an opportunity to improve your entire SEO foundation.

Quick Reference: Redirect Implementation by Platform

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.oldsite\.com$
RewriteRule ^(.*)$ https://newsite.com/$1 [R=301,L]

Nginx:

server {
    listen 80;
    server_name oldsite.com www.oldsite.com;
    return 301 https://newsite.com$request_uri;
}

Express.js:

app.use((req, res, next) => {
  res.redirect(301, `https://newsite.com${req.originalUrl}`);
});

Vercel (vercel.json):

{
  "redirects": [
    {
      "source": "/:path*",
      "destination": "https://newsite.com/:path*",
      "permanent": true
    }
  ]
}

Cloudflare Bulk Redirects:

Upload CSV with columns: Source URL, Target URL, Type (permanent)

Final Checklist: Before You Hit Launch

The day before migration:

• All redirects tested and working
• New domain fully functional
• Google Search Console set up for new domain
• Sitemap submitted
• Analytics tracking new domain
• Backup of old domain complete
• Team notified of migration time
• Monitoring tools ready (Search Console, Analytics, ranking tracker)

Migration day:

• Activate redirects on old domain
• Verify new domain is live
• Test 10 random URLs
• Monitor for errors (first 4 hours)
• Update social profiles
• Notify team that migration is live

First week post-migration:

• Monitor Google Search Console daily
• Monitor analytics daily
• Check for crawl errors
• Test ranking recovery
• Fix any broken redirects immediately

Conclusion: Ship Your Migration Right

A domain migration is one of the highest-risk SEO events you'll execute. One mistake—a broken redirect, a missed URL, a wrong status code—and you lose months of organic visibility.

But if you execute it right, you preserve your rankings, your traffic, and your SEO equity. You gain a cleaner domain, a fresh start, and a more strategic URL structure.

Follow this guide step-by-step:

1. Audit your current domain completely
2. Map every URL to its destination
3. Understand how 301 redirects work
4. Choose your implementation method
5. Implement redirects carefully
6. Test exhaustively before launch
7. Prepare your new domain
8. Execute the migration
9. Monitor for 2–4 weeks post-launch
10. Update external references

Use the checklists and templates provided. Test relentlessly. Keep the old domain live. Monitor Search Console and analytics closely.

Done right, your migration preserves your SEO and sets you up for faster growth on the new domain. Done wrong, it tanks your visibility for months.

The difference is execution. Ship it right.