TL;DR: We migrated seojuice.io to seojuice.com in January 2026. Traffic dropped 40% in the first week. Within 2 months we went from 694 impressions/day to 7,853. This article covers every mistake we made, every fix we applied, and the exact recovery timeline so you don't repeat our worst moments.
In January 2026, we moved SEOJuice from the .io domain to .com. The reasons were straightforward: .com has higher trust perception, better brand recall, and we were tired of explaining what ".io" means to non-technical prospects.
I knew it would hurt. I've helped dozens of clients through domain migrations. I've read every Google documentation page on the topic. I thought we were prepared.
We weren't.
Day one: impressions dropped 40%. By day three, some of our best-performing pages vanished from the index entirely. Our main keyword — the one driving 30% of organic traffic — went from position 4 to not ranking at all.
Here's the timeline of what actually happened:
| Timeframe | Impressions/Day | Clicks/Day | What Was Happening |
|---|---|---|---|
| Pre-migration | 694 | 31 | Baseline on .io domain |
| Week 1 | ~420 | 14 | Initial drop. Google still indexing old URLs |
| Week 2-3 | ~580 | 22 | Redirects propagating. Mixed old/new in index |
| Week 4-6 | 1,200 | 48 | Recovery begins. New domain gaining traction |
| Month 2 | 4,100 | 165 | Surpassing old baseline. Content improvements kicking in |
| Month 3 (now) | 7,853 | 312 | 11x original impressions. Full recovery + growth |
The recovery wasn't just the migration settling in. We used the migration as an opportunity to fix years of accumulated technical debt, improve content quality, and restructure our internal linking. But the migration itself was the hard part — and it's what this article focuses on.
This is the checklist I wish I'd followed more carefully. We did most of it, but the items we missed cost us weeks of recovery time.
| Before Migration | During Migration | After Migration |
|---|---|---|
| Crawl entire old site and export all URLs | Deploy 301 redirects for every URL | Verify redirects with a full crawl |
| Build a complete redirect map (old URL → new URL) | Update canonical tags to new domain | Submit new sitemap in GSC |
| Export Google Search Console data | Update internal links to new domain | Use Change of Address tool in GSC |
| Document all backlinks (source + target URL) | Update sitemap.xml with new URLs | Monitor index coverage daily for 2 weeks |
| Set up new domain in GSC and analytics | Update robots.txt on new domain | Check for crawl errors in GSC |
| Inform key backlink partners about the change | Verify SSL certificate on new domain | Request backlink updates from major referrers |
| Test redirects on staging environment | Update social profiles and directory listings | Keep old domain redirecting for 12+ months |
Key Takeaway
The single most important item: keep the old domain redirecting for at least 12 months. Google recommends maintaining redirects for at least 180 days, but longer is better. We're keeping seojuice.io redirecting indefinitely — there's no reason not to.
This is the #1 migration killer. Every URL on the old domain needs a 301 redirect to its equivalent on the new domain. Not the homepage. Not a "catch-all." The exact equivalent page.
Crawl the old domain. For every URL, check if it properly 301 redirects to the correct new URL. Use our broken link checker or Screaming Frog with a URL list upload.
For Apache (.htaccess):
# Redirect entire old domain to new domain (preserving paths)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.io [NC]
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]
# Individual page redirects (when URL structure changed)
Redirect 301 /old-blog/post-slug https://newdomain.com/blog/post-slug/
Redirect 301 /services/old-page https://newdomain.com/solutions/new-page/For Cloudflare (Redirect Rules):
# Cloudflare Redirect Rule (Single Redirect)
# Match: hostname equals "olddomain.io"
# Then: Dynamic redirect to https://newdomain.com + URI Path
# Status: 301 (Permanent)
# For Cloudflare Bulk Redirects (CSV format):
olddomain.io/blog/old-post,https://newdomain.com/blog/new-post,301
olddomain.io/about,https://newdomain.com/about/,301For Nginx:
server {
server_name olddomain.io www.olddomain.io;
return 301 https://newdomain.com$request_uri;
}"You absolutely need to set up redirects, at least for the important pages. Without them, you'll have a mix of old and new URLs in search results, and old URLs will drive traffic to your 404 page. Ideally pick permanent server-side redirects — 308 or 301. Avoid JavaScript redirects."
After deploying redirects, check every URL from your old sitemap. The response should be a single 301 to the correct new URL. Watch for redirect chains (301 → 301 → 200) — these dilute link equity and add latency.
This is the one that got us. We set up perfect external redirects, but forgot to update internal links in our blog content. Hundreds of internal links still pointed to seojuice.io, creating unnecessary redirect hops on every page load.
Crawl the new site and filter for any internal links containing the old domain. Search your database or CMS for the old domain string.
Search-and-replace across your entire database. In WordPress:
# Using WP-CLI (recommended approach)
wp search-replace 'https://olddomain.io' 'https://newdomain.com' --all-tables --dry-run
# Review output, then run without --dry-run:
wp search-replace 'https://olddomain.io' 'https://newdomain.com' --all-tables
# Also catch http:// variants
wp search-replace 'http://olddomain.io' 'https://newdomain.com' --all-tablesRe-crawl the site. Zero internal links should reference the old domain.
Your sitemap.xml still listing old domain URLs tells Google "these are my pages" while your redirects say "actually, go over there." Mixed signals slow down re-indexing.
Open https://newdomain.com/sitemap.xml and check every URL. If any start with the old domain, the sitemap is stale.
Check GSC → Sitemaps. Status should show "Success" with the correct URL count.
Canonical tags are easy to overlook because they're invisible to users. But if your canonical tags still point to the old domain, you're telling Google the old domain is the "real" version — directly contradicting your redirects.
View page source on several pages of the new site. Search for <link rel="canonical" and verify the href uses the new domain.
Spot-check 10-20 pages across different templates (homepage, blog post, category, product). Every canonical should reference the new domain.
Even with perfect redirects and canonicals, Google takes time to process a domain move. This is normal. Our re-indexing took about 3 weeks for the bulk of pages and 6 weeks for the long tail.
In GSC, go to Index → Pages. Watch the "Indexed" count on the new property. It should steadily climb. If it plateaus or drops, something is blocking crawling.
"Update the URL address in Google Search Console during the migration, not before — Google needs content on the new site to process. You should expect some visible changes in how your content is shown in search, definitely short-term. Even if you get the URL changes perfect, you will see changes."
Track daily: indexed page count in GSC, crawl stats, and the ratio of old vs. new domain URLs appearing in search results (search site:newdomain.com and site:olddomain.io).
Your backlinks point to the old domain. With 301 redirects, Google passes most (but not all) of the link equity to the new URL. The loss is small per link but compounds across hundreds of backlinks.
Export your backlink profile from Ahrefs, Semrush, or GSC. Check how many still point to the old domain vs. the new one. Three months after migration, the ratio should be shifting toward the new domain.
Monitor your backlink profile monthly. The percentage of backlinks pointing directly to the new domain should increase over time. Use our domain authority checker to track authority transfer.
Research shows domain migrations take anywhere from 30 days to 523 days to fully recover. The variance is enormous because it depends on how well you execute. Here's what a well-executed migration looks like week by week:
| Period | What's Normal | What's a Red Flag |
|---|---|---|
| Week 1 | 20-40% traffic drop. Ranking fluctuations on key terms. Old URLs still appearing in SERPs | 70%+ traffic drop. Complete de-indexing. 404 errors in GSC |
| Week 2-3 | Traffic stabilizing. New domain URLs replacing old ones in index. Rankings returning | Traffic still declining. Index coverage not increasing. Redirect errors in GSC |
| Week 4-6 | Traffic approaching pre-migration levels. Most pages re-indexed. Rankings stabilizing | Still below 50% of baseline. Many pages not indexed. Crawl errors increasing |
| Month 2-3 | Full recovery or exceeding baseline. All important pages indexed on new domain | Significant pages still not indexed. Rankings not recovering for key terms |
| Month 6+ | Old domain barely appears in SERPs. Backlinks gradually updating. Long tail fully recovered | Old domain still appearing for many queries. Authority metrics declining |
If your migration went sideways and you're seeing red flags, fix these in order:
The hardest part of a migration is knowing when the drop is normal and when something is genuinely broken.
Wait it out if:
Panic (and fix immediately) if:
Key Takeaway
A 20-40% traffic drop in week 1 is normal and expected. A 70%+ drop, or any drop that doesn't start recovering by week 3, means something is technically wrong. Check redirects, robots.txt, and canonicals in that order.
Looking back at our own migration, here's what I'd change:
Google recommends at least 180 days. I recommend forever, or at least as long as the domain registration costs are negligible. There's no downside to keeping redirects active, and old backlinks will continue passing equity through the redirect.
301 (permanent). Always. A 302 tells Google the move is temporary, which means Google keeps the old URLs in the index and doesn't fully transfer link equity. For a permanent domain change, 301 is the only correct choice. John Mueller also mentions 308 as equivalent to 301.
Temporarily, yes. Most sites see a 20-40% traffic drop in the first week. With proper execution, recovery starts within 2-4 weeks. Studies show that 83% of well-executed domain migrations recover fully within 6 months. The 17% that don't usually have persistent technical issues (broken redirects, canonical problems).
Google strongly recommends against it. Change one thing at a time. Move the domain first, let it settle for 2-3 months, then restructure URLs. Doing both simultaneously makes it nearly impossible to diagnose problems when something goes wrong.
Not rebuild, but update. 301 redirects pass most link equity, so your existing backlinks still count. But reaching out to your top referrers to update the links directly (removing the redirect hop) preserves more equity and improves crawl efficiency.
The Change of Address tool in Google Search Console tells Google explicitly that your site has moved from one domain to another. It's not strictly required — Google can figure out domain moves from 301 redirects alone — but it accelerates the process significantly. It forwards signals from old to new, emphasizes crawling the new domain, and continues working for 180 days. Use it.
Every domain migration hurts. Even perfectly executed ones. Google has to recrawl, reprocess, and reassign trust to a new domain. That takes time.
The difference between a migration that recovers in 3 weeks and one that takes a year is execution quality: complete redirect maps, updated internal links, clean canonicals, and the GSC Change of Address tool. There's no shortcut and no hack.
We came out stronger because we treated the migration as an opportunity to fix everything that was already wrong. If you're about to migrate, do the same. Clean up your technical debt, improve your content, and fix your internal linking while you're at it. You're already going through the pain — might as well come out the other side with a better site.
In my experience migrating enterprise WordPress sites, a prioritized redirect map plus updating internal links in the CMS before DNS cutover prevented most immediate traffic loss and preserved conversions; we also staged sitemap pushes and monitored GA4/GSC for drop signals. We tracked recovery to baseline within 4–8 weeks by fixing 301 chains and canonical tags and would be happy to share our redirect template and dashboard. DM me if you want the spreadsheet or a quick walkthrough.
Good overview — curious about your validation steps: did you diff pre/post crawl maps or rely only on automated redirects? I'd combine Screaming Frog + raw server log analysis to catch 301 chains and query-string canonicalization, and explicitly test hreflang resolution across locales to avoid indexation loops. Any recovery timelines or A/B benchmarks you can share?
Missing 301s tank rankings. #SEO
Redirects save rankings. #SEO
Build a 1:1 redirect map before changing URLs and keep 301s in place for months; also update XML sitemaps and canonical tags to avoid duplicate content. Monitor Search Console and server logs daily for crawl errors and validate with Screaming Frog after the migration. #WordPress
tbh I migrated a WooCommerce site and forgot to update internal links—traffic dipped fast from all the 404s. I fixed it with a DB search-replace, Screaming Frog to find broken links, and resubmitted the sitemap; traffic recovered in ~4 weeks. Anyone used WP-CLI or Better Search Replace for this? ngl curious if plugins miss edge cases, r/SEO
no credit card required