Q: We're merging two of our sites into one. How is that different from a normal move?
Short answer: it's a migration plus a consolidation — the redirect mapping gets trickier because pages overlap.
Long answer: A normal move is one old URL to one new URL. Merging two sites means some pages on both will compete to become the SAME destination page. Two 'about us' pages, two overlapping product lines, two blog posts on the same topic. You can't just redirect both somewhere random.
The key decisions:
— For overlapping topics, pick ONE surviving page and 301 both old versions to it (consolidating their combined signals).
— For unique pages, standard 1-to-1 redirects.
— Watch for the two sites having different URL conventions, canonicals, and even duplicate content you're now stacking.
Don't expect 1+1 to equal 2 instantly — merged authority takes time to settle, sometimes 2-3 months.
Next step: build a merge map with a 'winner' column for every overlapping topic, then 301 the losers into the winners. Resolve content duplication before launch, not after.
—
Если тема зашла, посмотри @MapPackDiaries
Short answer: it's a migration plus a consolidation — the redirect mapping gets trickier because pages overlap.
Long answer: A normal move is one old URL to one new URL. Merging two sites means some pages on both will compete to become the SAME destination page. Two 'about us' pages, two overlapping product lines, two blog posts on the same topic. You can't just redirect both somewhere random.
The key decisions:
— For overlapping topics, pick ONE surviving page and 301 both old versions to it (consolidating their combined signals).
— For unique pages, standard 1-to-1 redirects.
— Watch for the two sites having different URL conventions, canonicals, and even duplicate content you're now stacking.
Don't expect 1+1 to equal 2 instantly — merged authority takes time to settle, sometimes 2-3 months.
Next step: build a merge map with a 'winner' column for every overlapping topic, then 301 the losers into the winners. Resolve content duplication before launch, not after.
—
Если тема зашла, посмотри @MapPackDiaries
Q: We moved domains 3 weeks ago and traffic is still down. Normal?
Short answer: yes, three weeks is still inside the messy window. Don't panic-revert.
Long answer: Google has to recrawl every old URL, follow the redirect, and re-evaluate the new one. For a mid-size site that's typically 2-6 weeks of wobble, sometimes longer for deep pages crawled rarely. A 10-25% dip that's slowly recovering is the normal shape. What's NOT normal: a dip that keeps deepening past week 4, or pages dropping fully out of the index.
Quick checks while you wait:
— Spot-check 20 old URLs: do they 301 in one hop to the right new URL?
— In Search Console, is the old property's clicks falling while the new one's rises? That handoff is the signal you want.
Next step: give it to week 6 before judging. Log your daily clicks now so you can see the trend, not just today's scary number.
Short answer: yes, three weeks is still inside the messy window. Don't panic-revert.
Long answer: Google has to recrawl every old URL, follow the redirect, and re-evaluate the new one. For a mid-size site that's typically 2-6 weeks of wobble, sometimes longer for deep pages crawled rarely. A 10-25% dip that's slowly recovering is the normal shape. What's NOT normal: a dip that keeps deepening past week 4, or pages dropping fully out of the index.
Quick checks while you wait:
— Spot-check 20 old URLs: do they 301 in one hop to the right new URL?
— In Search Console, is the old property's clicks falling while the new one's rises? That handoff is the signal you want.
Next step: give it to week 6 before judging. Log your daily clicks now so you can see the trend, not just today's scary number.
Q: I used 302 redirects by accident. Did I ruin my migration?
Short answer: no, you didn't ruin anything — but fix them this week.
Long answer: A 301 says 'moved permanently,' a 302 says 'moved temporarily.' Google usually figures out a 302 is really permanent after it sees it for a while and passes signals anyway. But 'usually' and 'eventually' aren't what you want during a move. A permanent 301 tells Google to swap the indexed URL immediately and consolidate ranking signals fast. A 302 can leave the OLD URL lingering in the index, which is exactly the confusion a migration should avoid.
The most common cause: server config or a plugin defaulting to 302. Sometimes it's a framework redirect helper where you forgot the status-code argument.
Next step: crawl your redirect list, filter for status 302, change those rules to 301, and re-test the corrected ones with a header checker. No need to redo the whole migration.
Short answer: no, you didn't ruin anything — but fix them this week.
Long answer: A 301 says 'moved permanently,' a 302 says 'moved temporarily.' Google usually figures out a 302 is really permanent after it sees it for a while and passes signals anyway. But 'usually' and 'eventually' aren't what you want during a move. A permanent 301 tells Google to swap the indexed URL immediately and consolidate ranking signals fast. A 302 can leave the OLD URL lingering in the index, which is exactly the confusion a migration should avoid.
The most common cause: server config or a plugin defaulting to 302. Sometimes it's a framework redirect helper where you forgot the status-code argument.
Next step: crawl your redirect list, filter for status 302, change those rules to 301, and re-test the corrected ones with a header checker. No need to redo the whole migration.
Q: I used 302 redirects by accident. Did I ruin my migration?
Short answer: no, you didn't ruin anything — but fix them this week.
Long answer: A 301 says 'moved permanently,' a 302 says 'moved temporarily.' Google usually figures out a 302 is really permanent after it sees it for a while and passes signals anyway. But 'usually' and 'eventually' aren't what you want during a move. A permanent 301 tells Google to swap the indexed URL immediately and consolidate ranking signals fast. A 302 can leave the OLD URL lingering in the index, which is exactly the confusion a migration should avoid.
The most common cause: server config or a plugin defaulting to 302. Sometimes it's a framework redirect helper where you forgot the status-code argument.
Next step: crawl your redirect list, filter for status 302, change those rules to 301, and re-test the corrected ones with a header checker. No need to redo the whole migration.
Short answer: no, you didn't ruin anything — but fix them this week.
Long answer: A 301 says 'moved permanently,' a 302 says 'moved temporarily.' Google usually figures out a 302 is really permanent after it sees it for a while and passes signals anyway. But 'usually' and 'eventually' aren't what you want during a move. A permanent 301 tells Google to swap the indexed URL immediately and consolidate ranking signals fast. A 302 can leave the OLD URL lingering in the index, which is exactly the confusion a migration should avoid.
The most common cause: server config or a plugin defaulting to 302. Sometimes it's a framework redirect helper where you forgot the status-code argument.
Next step: crawl your redirect list, filter for status 302, change those rules to 301, and re-test the corrected ones with a header checker. No need to redo the whole migration.
Q: My redirects work, but they go through 2-3 hops. Does that matter?
Short answer: each extra hop is a small tax — worth flattening, not worth losing sleep.
Long answer: A 'chain' is when URL A redirects to B, which redirects to C. Every hop adds latency for users and one more thing for crawlers to follow. Google will follow a few hops, but it's stingy: documented behavior is roughly up to 5 hops in one crawl pass before it gives up and tries again later, which slows reindexing. Chains usually sneak in when you stack migrations — an old HTTP-to-HTTPS rule, then a www rule, then a domain change, each adding a link.
The goal is one hop: old URL straight to the final live URL.
Next step: crawl your site, export the redirect report, and find any chain of 2+. Rewrite those rules to point directly at the final destination. You usually fix dozens in one config edit.
Short answer: each extra hop is a small tax — worth flattening, not worth losing sleep.
Long answer: A 'chain' is when URL A redirects to B, which redirects to C. Every hop adds latency for users and one more thing for crawlers to follow. Google will follow a few hops, but it's stingy: documented behavior is roughly up to 5 hops in one crawl pass before it gives up and tries again later, which slows reindexing. Chains usually sneak in when you stack migrations — an old HTTP-to-HTTPS rule, then a www rule, then a domain change, each adding a link.
The goal is one hop: old URL straight to the final live URL.
Next step: crawl your site, export the redirect report, and find any chain of 2+. Rewrite those rules to point directly at the final destination. You usually fix dozens in one config edit.
Pairs well with this channel
@LinkBuildIndex — Benchmarks for link building campaigns: cost-per-link, reply rates, DR distributions… Quietly one of the better feeds in the space.
@LinkBuildIndex — Benchmarks for link building campaigns: cost-per-link, reply rates, DR distributions… Quietly one of the better feeds in the space.
Q: Do I still need the GSC Change of Address tool if my 301s are set?
Short answer: yes, use it — but it's the assistant, not the driver.
Long answer: The Change of Address tool in Search Console tells Google 'this whole domain moved to that domain.' Your 301 redirects do the real per-URL work; the tool just speeds up Google's understanding of the site-wide move and helps transfer signals faster. Skipping it won't break the migration, but using it removes ambiguity.
Requirements people miss:
— Both old and new domains must be verified in your Search Console account.
— Your 301s must already be live and working before you submit — the tool checks a sample.
— It only applies to a full domain or subdomain move, not a folder restructure on the same domain.
Next step: verify both properties, confirm a handful of redirects return 301, then submit the Change of Address from the OLD property's settings. Then leave it — re-submitting daily does nothing.
Short answer: yes, use it — but it's the assistant, not the driver.
Long answer: The Change of Address tool in Search Console tells Google 'this whole domain moved to that domain.' Your 301 redirects do the real per-URL work; the tool just speeds up Google's understanding of the site-wide move and helps transfer signals faster. Skipping it won't break the migration, but using it removes ambiguity.
Requirements people miss:
— Both old and new domains must be verified in your Search Console account.
— Your 301s must already be live and working before you submit — the tool checks a sample.
— It only applies to a full domain or subdomain move, not a folder restructure on the same domain.
Next step: verify both properties, confirm a handful of redirects return 301, then submit the Change of Address from the OLD property's settings. Then leave it — re-submitting daily does nothing.
Q: How long do I need to keep the old domain and redirects alive?
Short answer: at least a year. Ideally, keep the domain forever and the redirects for years.
Long answer: People assume once traffic moves over, the old domain is dead weight. But those 301s are still doing two jobs: passing any remaining link signals from backlinks pointing at old URLs, and catching the occasional old link someone clicks. Google's guidance is to keep redirects in place for at least a year so it fully settles the move. Backlinks to your old URLs can live on other sites for a decade — kill the redirects and that referred authority and traffic just dies.
The domain registration is cheap insurance; the redirect config costs nothing to leave running.
Next step: set a calendar reminder for 12 months out to RE-EVALUATE, not to delete. Renew the old domain on auto-pay. If you ever do retire redirects, do it gradually and watch your referral traffic.
Short answer: at least a year. Ideally, keep the domain forever and the redirects for years.
Long answer: People assume once traffic moves over, the old domain is dead weight. But those 301s are still doing two jobs: passing any remaining link signals from backlinks pointing at old URLs, and catching the occasional old link someone clicks. Google's guidance is to keep redirects in place for at least a year so it fully settles the move. Backlinks to your old URLs can live on other sites for a decade — kill the redirects and that referred authority and traffic just dies.
The domain registration is cheap insurance; the redirect config costs nothing to leave running.
Next step: set a calendar reminder for 12 months out to RE-EVALUATE, not to delete. Renew the old domain on auto-pay. If you ever do retire redirects, do it gradually and watch your referral traffic.
Q: We moved to HTTPS and rankings dipped. What went wrong?
Short answer: an HTTPS switch is a full migration — Google sees http:// and https:// as different URLs.
Long answer: Flipping on SSL doesn't automatically tell Google your pages moved. Without proper 301s from every http:// URL to its https:// twin, you've effectively duplicated your whole site and split signals between two versions. Add 'mixed content' (a secure page loading an insecure image or script) and browsers throw warnings while crawlers get confused.
The usual culprits:
— No site-wide 301 from http to https.
— Internal links, canonicals, or sitemaps still hardcoded with http://.
— Hardcoded http:// asset URLs in templates causing mixed-content errors.
Next step: confirm one site-wide http-to-https 301, then crawl for any internal links or canonicals still on http and update them to https or protocol-relative. Update your sitemap to the https URLs and resubmit. The dip almost always traces back to one of these three.
Short answer: an HTTPS switch is a full migration — Google sees http:// and https:// as different URLs.
Long answer: Flipping on SSL doesn't automatically tell Google your pages moved. Without proper 301s from every http:// URL to its https:// twin, you've effectively duplicated your whole site and split signals between two versions. Add 'mixed content' (a secure page loading an insecure image or script) and browsers throw warnings while crawlers get confused.
The usual culprits:
— No site-wide 301 from http to https.
— Internal links, canonicals, or sitemaps still hardcoded with http://.
— Hardcoded http:// asset URLs in templates causing mixed-content errors.
Next step: confirm one site-wide http-to-https 301, then crawl for any internal links or canonicals still on http and update them to https or protocol-relative. Update your sitemap to the https URLs and resubmit. The dip almost always traces back to one of these three.
Q: New platform forces a different URL structure. How risky is that?
Short answer: it's the riskiest kind of move — but very survivable with a clean redirect map.
Long answer: When you replatform (say Magento to Shopify, or a custom CMS to WordPress), the danger usually isn't the platform — it's that the new system generates URLs in a different pattern. /product/blue-widget becomes /products/blue-widget-123. Every changed URL needs a 301 to its new address, or you lose that page's rankings.
The trap is platforms that add a forced prefix (/p/, /products/, /collections/) or append an ID. These look small but multiply across thousands of pages.
What saves you:
— Export ALL old URLs from your old sitemap and analytics before the old site goes dark.
— Map every one to its new URL, even orphaned pages you forgot existed.
Next step: do the export NOW while the old platform is still live. The single most common migration disaster is losing the old URL list after the cutover.
Short answer: it's the riskiest kind of move — but very survivable with a clean redirect map.
Long answer: When you replatform (say Magento to Shopify, or a custom CMS to WordPress), the danger usually isn't the platform — it's that the new system generates URLs in a different pattern. /product/blue-widget becomes /products/blue-widget-123. Every changed URL needs a 301 to its new address, or you lose that page's rankings.
The trap is platforms that add a forced prefix (/p/, /products/, /collections/) or append an ID. These look small but multiply across thousands of pages.
What saves you:
— Export ALL old URLs from your old sitemap and analytics before the old site goes dark.
— Map every one to its new URL, even orphaned pages you forgot existed.
Next step: do the export NOW while the old platform is still live. The single most common migration disaster is losing the old URL list after the cutover.
Q: Search Console is showing a spike in 404s after our move. Bad?
Short answer: depends entirely on WHICH URLs are 404ing. Some are fine, some are emergencies.
Long answer: A post-migration 404 spike looks scary but breaks into three buckets:
— Real pages that should redirect but don't — these are emergencies, fix today.
— Junk URLs (old parameters, spam links, ancient deleted pages) — a 404 or 410 is the correct answer, ignore them.
— Internal links you forgot to update, now pointing at dead old URLs — fix the links, not just the redirect.
The mistake is treating all 404s as equally bad and panic-redirecting everything to the homepage (see the soft-404 trap).
Next step: export the 404 report, sort by which had traffic or backlinks. Anything that earned clicks or has links pointing at it gets a proper 301 to its new equivalent. The rest can stay 404 or move to 410 — Google drops them cleanly.
Short answer: depends entirely on WHICH URLs are 404ing. Some are fine, some are emergencies.
Long answer: A post-migration 404 spike looks scary but breaks into three buckets:
— Real pages that should redirect but don't — these are emergencies, fix today.
— Junk URLs (old parameters, spam links, ancient deleted pages) — a 404 or 410 is the correct answer, ignore them.
— Internal links you forgot to update, now pointing at dead old URLs — fix the links, not just the redirect.
The mistake is treating all 404s as equally bad and panic-redirecting everything to the homepage (see the soft-404 trap).
Next step: export the 404 report, sort by which had traffic or backlinks. Anything that earned clicks or has links pointing at it gets a proper 301 to its new equivalent. The rest can stay 404 or move to 410 — Google drops them cleanly.
Q: Should I use a canonical tag or a 301 redirect for old URLs?
Short answer: for a migration, use 301 redirects. Canonicals are for a different job.
Long answer: These get confused constantly. A 301 redirect physically sends the user and crawler to the new URL — the old page no longer loads. A canonical tag leaves both pages live but tells Google 'index this other one as the main version.' During a move, you want the old URL GONE and visitors landing on the new page — that's a redirect.
Use a canonical when you can't redirect: duplicate content you must keep accessible, print versions, tracking-parameter URLs, or syndicated content. It's a softer hint Google can ignore; a 301 is a hard instruction it follows.
Next step: for your moved URLs, set 301s. Then check the NEW pages don't have leftover canonicals pointing back at the old domain — that's a sneaky bug that tells Google to keep indexing the dead URL.
Short answer: for a migration, use 301 redirects. Canonicals are for a different job.
Long answer: These get confused constantly. A 301 redirect physically sends the user and crawler to the new URL — the old page no longer loads. A canonical tag leaves both pages live but tells Google 'index this other one as the main version.' During a move, you want the old URL GONE and visitors landing on the new page — that's a redirect.
Use a canonical when you can't redirect: duplicate content you must keep accessible, print versions, tracking-parameter URLs, or syndicated content. It's a softer hint Google can ignore; a 301 is a hard instruction it follows.
Next step: for your moved URLs, set 301s. Then check the NEW pages don't have leftover canonicals pointing back at the old domain — that's a sneaky bug that tells Google to keep indexing the dead URL.
Q: Do I keep the old sitemap or only submit the new one?
Short answer: temporarily keep both, then retire the old one. Counterintuitive, I know.
Long answer: Your instinct is to submit the new sitemap and delete the old — clean slate. But during the move, keeping the OLD sitemap live for a few weeks actually helps: it nudges Google to recrawl every old URL, hit your 301s, and discover the new addresses faster. A faster recrawl means a faster handoff.
So the play:
— Submit the new sitemap (all new URLs, 200 status, no redirects inside it) in the new property right away.
— Leave the old sitemap accessible and submitted in the old property for 2-4 weeks to accelerate recrawling.
— Then let the old one expire.
Never put redirecting URLs INTO your new sitemap — it should list only final destinations.
Next step: submit the new sitemap today, keep the old one alive temporarily, and check the Coverage report for crawl progress.
Short answer: temporarily keep both, then retire the old one. Counterintuitive, I know.
Long answer: Your instinct is to submit the new sitemap and delete the old — clean slate. But during the move, keeping the OLD sitemap live for a few weeks actually helps: it nudges Google to recrawl every old URL, hit your 301s, and discover the new addresses faster. A faster recrawl means a faster handoff.
So the play:
— Submit the new sitemap (all new URLs, 200 status, no redirects inside it) in the new property right away.
— Leave the old sitemap accessible and submitted in the old property for 2-4 weeks to accelerate recrawling.
— Then let the old one expire.
Never put redirecting URLs INTO your new sitemap — it should list only final destinations.
Next step: submit the new sitemap today, keep the old one alive temporarily, and check the Coverage report for crawl progress.
Q: My URLs changed trailing slashes and www. Is that a 'real' migration?
Short answer: yes — to Google these are different URLs, so treat it like a move.
Long answer: example.com/page and example.com/page/ are technically distinct, as are www and non-www, and http and https. Most sites should pick ONE version of each and 301 the others to it. When a redesign quietly flips your trailing-slash convention or your www preference, you've changed every URL on the site without realizing it.
The symptom: rankings flicker, Search Console shows duplicate URLs, and you swear 'we didn't change anything.'
What to standardize:
— Pick www or non-www, redirect the other.
— Pick trailing-slash or not, redirect the other.
— Make sure internal links and canonicals use the chosen version.
Next step: decide your canonical format, set 301s for the alternates, and update internal links to match. Then crawl to confirm you're not bouncing between /page and /page/ in a chain.
Short answer: yes — to Google these are different URLs, so treat it like a move.
Long answer: example.com/page and example.com/page/ are technically distinct, as are www and non-www, and http and https. Most sites should pick ONE version of each and 301 the others to it. When a redesign quietly flips your trailing-slash convention or your www preference, you've changed every URL on the site without realizing it.
The symptom: rankings flicker, Search Console shows duplicate URLs, and you swear 'we didn't change anything.'
What to standardize:
— Pick www or non-www, redirect the other.
— Pick trailing-slash or not, redirect the other.
— Make sure internal links and canonicals use the chosen version.
Next step: decide your canonical format, set 301s for the alternates, and update internal links to match. Then crawl to confirm you're not bouncing between /page and /page/ in a chain.