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.