I've run three post-acquisition domain consolidations in the past 14 months. Two went well. One was a disaster that took six months to partially undo. All three taught me something the standard domain migration guides don't cover: the technical execution is rarely where these projects fail. They fail in the three weeks before a single redirect is written, when someone decides—without enough data—which domain survives.
This is the process I now use. It's built from those three engagements, including the one I got wrong.
The Decision Before the Decision
The most expensive mistake in domain consolidation is treating it as a purely technical project. Engineering is handed a ticket: "redirect acquired-domain.com to our-domain.com." They write the redirects, deploy, move on. Six months later, organic traffic to our-domain.com is flat or down, and everyone is confused because the migration looked correct.
The problem wasn't the redirects. The problem was that nobody asked whether consolidation was the right decision in the first place, or—if it was—which domain should absorb the other.
I've seen a $200M acquisition where the acquired domain had 4x the organic traffic and a significantly stronger backlink profile than the acquiring company's domain. The board decided to redirect everything to the acquirer's domain because "brand consistency." Three months later, combined organic traffic was lower than the acquired domain had been alone. The stronger domain's authority had been diluted into the weaker one, and the weaker one hadn't gained enough to compensate.
The question to answer first, before any technical planning: is the correct outcome one surviving domain, two maintained domains, or a hybrid where some content migrates and some stays?
The SAFE Framework
SAFE: Signal Audit, Architecture Decision, Freeze Period, Execution. In that order. Non-negotiable sequence.
Signal Audit
Pull everything before touching the servers:
- GSC performance for both domains: 16-month window, country breakdown, top 500 queries by impression
- Ahrefs or similar: domain rating, referring domain count, referring domain quality distribution (DR 70+ vs. sub-30), anchor text distribution
- Crawl of both domains: page count, indexation rate, orphan pages, redirect chains already present
- Content overlap analysis: what percentage of pages on Domain B target queries already covered by Domain A?
- Traffic source mix: is either domain significantly dependent on non-organic sources that would complicate attribution post-merger?
From this audit you generate what I call the Signal Score for each domain. I use a weighted composite:
Signal Score = (
(Organic sessions, 12mo / 1000) * 0.30
+ (Referring domains, DR 50+) * 0.25
+ (GSC impressions, 12mo / 10000) * 0.20
+ (Indexed pages with organic traffic) * 0.15
+ (Top 10 SERP positions, non-branded) * 0.10
)
Example output:
Domain A (acquirer):
Organic sessions: 84,000/mo → 84 * 0.30 = 25.2
Referring domains DR50+: 312 → 312 * 0.25 = 78.0
GSC impressions: 2.1M/mo → 210 * 0.20 = 42.0
Indexed pages with traffic: 1,847 → 1847 * 0.15 = 277.1
Top 10 positions: 203 → 203 * 0.10 = 20.3
Signal Score A = 442.6
Domain B (acquired):
Organic sessions: 241,000/mo → 241 * 0.30 = 72.3
Referring domains DR50+: 891 → 891 * 0.25 = 222.8
GSC impressions: 7.4M/mo → 740 * 0.20 = 148.0
Indexed pages with traffic: 6,203 → 6203 * 0.15 = 930.5
Top 10 positions: 847 → 847 * 0.10 = 84.7
Signal Score B = 1458.3
When Signal Score B / Signal Score A > 2.0, I flag the consolidation for executive review before proceeding. The default "redirect the acquisition to us" decision may be the wrong call. In the example above, that ratio is 3.3. Redirecting B to A would be destroying the stronger asset.
Architecture Decision: Merge, Keep, or Hybrid
Three options, all legitimate depending on the data:
Merge (B → A): All of Domain B redirects to Domain A. Correct when A's Signal Score is higher, or when brand clarity is so important that maintaining dual domains isn't viable. Best long-term SEO outcome assumes you're directing traffic toward the stronger structural foundation.
Merge (A → B): Counter-intuitive to most acquisition teams, but sometimes the right call. When the acquired domain is significantly stronger, redirect the acquirer's content to the acquisition. Rename and rebrand Domain B to match the acquirer's brand identity, but keep B's domain as the primary. This is what I now call "acqui-redirect" and it's underused.
Keep both: Maintain both domains indefinitely, deduplicate content by preventing cross-domain cannibalization, cross-link strategically. Works when the two domains serve genuinely distinct audiences with minimal query overlap. Requires ongoing management. The hybrid option—migrate some URL paths from B to A while keeping B alive for its strongest content—is a variant of this and is usually the messiest to execute but sometimes the only way to preserve value from both domains.
The Freeze Period (And Why Teams Hate It)
After the architecture decision is made, before any redirects are deployed, there is a freeze period. Typically four to six weeks. During this time:
- No new content published on the domain being migrated away from
- No URL structure changes on either domain
- No new redirects added to either domain's existing redirect tables
- Full crawls of both domains run weekly to capture the pre-migration baseline
Product and content teams hate the freeze. "We have a roadmap." I know. The freeze exists because mid-migration content changes create situations where you're redirecting a URL that has just been published and has zero indexation. You lose the opportunity to let that content establish itself before it becomes a redirect source. More practically, any URL change during the freeze window forces a redirect table update mid-deployment, which introduces errors.
Six weeks feels long. Four is the minimum. Two is not enough.
The freeze also captures something important: a clean crawl baseline on the domain you're about to migrate away from, timed close enough to migration that the crawl data reflects actual current state. I use Screaming Frog for the crawl and save the full export as the authoritative reference. Six months post-migration, when there are questions about what URLs existed before, this is the source of truth.
Pre-Migration Content Triage
Building the Cannibalization Map
Before writing a single redirect, I map every URL on Domain B to one of three categories: unique, overlapping, or redundant. The method:
- Export all indexed URLs from both domains via GSC
- For each Domain B URL with measurable organic traffic, identify the primary keyword cluster it ranks for
- Check whether Domain A has any URL ranking for keywords in the same cluster
- If yes, score the overlap: how much query intersection is there, and which page ranks higher for the shared queries?
The result is a three-tier classification:
- Unique: Domain B URL covers queries not addressed on Domain A. Priority migration: this content should either move to Domain A or remain live if the hybrid architecture is chosen.
- Overlapping: Both domains rank for similar queries, but different keyword subsets. Requires a merge decision: which page is stronger, and should the weaker be redirected to it or consolidated into a new combined page?
- Redundant: Domain B URL targets queries where Domain A already ranks in the top 5 and has stronger signals. Safe to redirect directly. No content work needed.
For the 2026 Q1 e-commerce merger I'll describe later, the breakdown was: 34% unique, 41% overlapping, 25% redundant. That 41% overlapping category took three weeks of editorial work to resolve before migration. Anyone who tells you a domain consolidation is purely a technical task has never done one at scale.
Content Disposition Matrix
Content Disposition Matrix — Domain B URL Assessment
=====================================================
URL Classification | GSC Clicks (90d) | Action
-------------------|------------------|--------------------------------------------------
UNIQUE | > 500 | Migrate content to Domain A, new URL
UNIQUE | 50–500 | Migrate content to Domain A, new URL
UNIQUE | < 50 | 301 redirect only, no content migration
OVERLAPPING | > 500 (B wins) | Merge B content into A URL, 301 B → A merged
OVERLAPPING | > 500 (A wins) | 301 B → existing A URL, monitor for 8 weeks
OVERLAPPING | < 500 | 301 B → closest A URL, no content work
REDUNDANT | Any | 301 B → exact A equivalent
Priority order: resolve all UNIQUE pages first.
Overlapping pages with >500 clicks in past 90 days require editorial review.
I export this matrix as a shared spreadsheet and get sign-off from both the content team and the client before writing the redirect map. If there's disagreement about disposition, it gets resolved in the spreadsheet—not in the redirect map.
Redirect Architecture at Scale
Edge Redirect Setup for Merger Traffic
By 2026, running merger redirects at origin is unnecessary and creates bottlenecks. The architecture I deploy for any merger with more than 10,000 redirected URLs:
- Cloudflare Workers handles all redirect logic for the legacy domain
- Redirect table stored in Cloudflare KV, split by URL hash prefix for fast lookup
- Legacy domain's DNS points to Cloudflare; the Worker intercepts every request
- No origin server for the legacy domain after migration — it's pure edge redirect
Removing the origin server for the migrated-away domain is the part that's often resisted. "What if we need to roll back?" The roll-back scenario is handled by swapping the DNS CNAME back to the original origin, which still exists (we keep it running in read-only mode for 90 days post-migration). This isn't a technical argument; it's an organizational fear argument. The origin stays up temporarily. The redirect layer is edge.
Redirect Map Structure
# Domain merger redirect map structure
# Generated from content disposition matrix
# Format: source_path [TAB] destination_url [TAB] status_code [TAB] priority
# === TIER 1: High-traffic unique content (migrated, new A URL) ===
/blog/enterprise-workflow-guide https://our-domain.com/resources/enterprise-workflow/ 301 1
/blog/api-integration-patterns https://our-domain.com/resources/api-integration/ 301 1
/case-studies/fintech-client https://our-domain.com/case-studies/fintech-automation/ 301 1
# === TIER 2: Overlapping content (B wins, merged into A) ===
/features/reporting-dashboard https://our-domain.com/platform/analytics/ 301 2
/pricing/enterprise https://our-domain.com/pricing/ 301 2
# === TIER 3: Redundant (direct match to existing A URL) ===
/about https://our-domain.com/about/ 301 3
/contact https://our-domain.com/contact/ 301 3
/terms https://our-domain.com/legal/terms/ 301 3
# === TIER 4: Pattern-based (category pages, pagination) ===
# Handled separately in Worker pattern matching logic
# /category/* → https://our-domain.com/shop/{category}/
# /page/[0-9]+ → https://our-domain.com/ (pagination does not migrate)
# === TIER 5: Catch-all (anything not in above tiers) ===
# Worker fallback: 301 → https://our-domain.com/
The priority tiers matter for monitoring, not for redirect logic. After migration, I check tier 1 redirects weekly for 8 weeks. Tier 2 I check weekly for 4 weeks. Tier 3 and below get monthly checks for 3 months, then quarterly for 12 months.
The catch-all at tier 5 is controversial. Some SEOs argue that every URL should have an explicit redirect target. My position: for a domain with 50,000 URLs, you cannot maintain explicit redirects for every thin page, every parameter variant, every pagination URL. The catch-all to the homepage is not ideal, but it's honest—it tells Google that the specific URL has no equivalent on the new domain. Better than a chain of misdirected redirects.
GSC After Migration: What the 2025 UI Refresh Broke
Google Search Console's October 2025 UI refresh moved several critical reports and changed the data refresh cadence. If you're running a domain merger and relying on GSC for progress monitoring, these are the changes that matter.
Property verification for the migrated domain. After migration, keep the legacy domain's GSC property live. Do not delete it. The property will continue showing data for 16 months post-migration, giving you the cleanest before/after comparison. The new UI does not make this obvious—the legacy property can look like it should be removed since no traffic is going there anymore. Leave it.
The Change of Address tool. Still exists, still recommended for domain-to-domain mergers. It accelerates Googlebot's recrawl of the migrated site. In the October 2025 UI, it moved from Settings → Crawl → Address change to Settings → Property → Domain migration. The tool itself works the same; the navigation path changed.
Index coverage report timing. Post-migration, the indexing report for the destination domain typically shows a spike in "Discovered—currently not indexed" URLs as Google recrawls redirect targets. This is normal and resolves within 4–6 weeks. In the 2025 UI, this state is categorized under "Crawled—currently not indexed" with a different filter label than the pre-refresh version. If your monitoring dashboards pull GSC data via API and reference specific reason strings, they may be returning incorrect counts after October 2025.
The link report migration. Internal and external link data for the legacy domain continues to appear in GSC for several months after migration. External links pointing to the legacy domain that are successfully passing through 301 redirects to the destination domain do appear in the destination domain's link report, but typically with a 6–10 week delay. Don't use week-1 GSC link data to assess PageRank transfer velocity. It's incomplete.
Two Real Mergers, Two Very Different Outcomes
Merger One: B2B SaaS, 2025 Q4
A project management SaaS acquired a smaller competitor with a complementary feature set. Domain B had roughly 1.8x Domain A's organic traffic and about 2.2x the referring domains. Signal Score ratio: 2.1. I flagged it for executive review and recommended the acqui-redirect approach—rebrand Domain B to Domain A's brand name, but keep B's domain as primary, redirect A's URLs to B.
That recommendation was rejected. Brand had already committed to the acquirer's domain name externally. We proceeded with B → A consolidation.
The compromise: we migrated all of Domain B's high-traffic unique content to Domain A before launching redirects. 47 pages migrated, rewritten to match Domain A's tone, published on Domain A under new URLs, given 6 weeks to start accumulating signals before the redirects went live. When redirects launched, those pages were already indexed and beginning to rank on Domain A. The redirect reinforced rather than replaced their signals.
Result after 5 months: Domain A organic traffic is at 94% of the combined pre-migration baseline of both domains. Not ideal—we lost 6%—but given the brand constraint, it's defensible. The 6% loss is concentrated in a few high-competition queries where Domain B had strong topical authority that didn't transfer cleanly.
Merger Two: E-commerce, 2026 Q1
A fashion retailer acquired a shoe brand. Domain B (shoes) had a Signal Score 1.4x Domain A's. Below my 2.0 threshold for escalation, so we proceeded with standard B → A consolidation.
Content triage took 4 weeks. 34% unique content migrated. The overlapping content—mostly category pages targeting similar queries—required editorial decisions about whether to merge product collections or maintain separate category structures on Domain A. We maintained separate structures, which turned out to be the right call.
Redirects went live via Cloudflare Workers in mid-February 2026. 43,000 source URLs, 99.3% with explicit redirect targets, 0.7% catch-all. The Worker handles about 180,000 redirect requests per day from legacy shoe brand URLs.
Result at 3 months (mid-May 2026): Domain A is at 108% of the combined pre-migration baseline. The shoe brand's authority transferred cleanly, and the consolidated domain now ranks for queries that neither domain had been ranking for individually—presumably because the combined authority lifted pages that were borderline ranking candidates before. This is the outcome you hope for.
The difference between the two outcomes: the e-commerce merger had cleaner content separation (shoes are categorically distinct from project management software), the Signal Score ratio was lower, and the content triage was more thorough. The SaaS merger was constrained by brand decisions made before the SEO analysis was complete.
Two Things I Believe That Most SEOs Won't Say
1. The "keep both domains" strategy is underrated and under-recommended. The industry's gravitational pull toward consolidation is partly financial (two domains are marginally more expensive to operate) and partly aesthetic (one domain feels cleaner). But I've seen cases where two domains genuinely serve different enough audiences that consolidation destroys more value than it preserves. A B2C and a B2B brand acquired by the same company often have no business being on the same domain. Their link profiles, their content authority, their SERP contexts are built separately for a reason. Merging them trades specialization for generalization. Usually a bad trade.
2. The 301 redirect's link equity transfer is less reliable for old, dormant backlinks than most guides admit. Google processes 301s and transfers PageRank, yes. But the PageRank of a link diminishes over time if the linking page itself loses authority, stops being crawled, or gets removed. A referring domain from 2017 that was itself acquired and restructured in 2022 may be pointing a link at Domain B that Google hasn't re-evaluated in 18 months. When you redirect Domain B to Domain A, you're not inheriting fresh, actively-evaluated PageRank for those links. You're inheriting stale signals that Google will re-process on its own timeline. The commonly cited "87% of PageRank transfers via 301" figure is an approximation based on active, well-crawled links. The real number for a link profile with significant historical depth is lower.
Where I Got This Wrong
The third merger I mentioned at the start—the one that turned into a six-month remediation. Healthcare information site acquired a patient advocacy nonprofit. Signal Score ratio was 2.8 (nonprofit was much stronger). I recommended keeping both domains. The client overruled and proceeded with nonprofit → healthcare domain consolidation.
My mistake was not in the recommendation. It was in how I executed the migration once the decision was made against my advice. I treated it like a standard consolidation and did not adequately communicate the elevated risk or build additional monitoring into the project plan. I should have said: "You're making the riskier call. Here's what we're going to watch weekly, and here's the specific traffic threshold that triggers a rollback conversation."
Instead, I ran the standard monitoring cadence. By week 10, the healthcare domain's traffic was down 31%. By week 16, it was down 44%. The nonprofit's topical authority in patient-community queries did not transfer—because the healthcare domain had no community content to receive it, and the redirects pointed to clinical information pages that didn't match user intent. We spent six months building new content on the healthcare domain to recapture what the nonprofit had ranked for.
The lesson isn't "don't accept bad client decisions." The lesson is that elevated-risk migrations require elevated monitoring frequency and pre-agreed rollback triggers. Those conversations need to happen before the first redirect is deployed, not after the traffic drops.
Closing
Every domain consolidation is a bet on which signals will transfer and which won't. The SAFE framework makes that bet more deliberate. But deliberateness doesn't eliminate risk—it just means you know what you're risking and why.
The technical execution—redirects at the edge, content migration, GSC monitoring—is learnable from documentation. The harder skill is reading the signal data before the migration and having the credibility to push back when the recommended architecture conflicts with brand or business decisions. That's the conversation that determines whether the merger succeeds or fails, and it happens in a meeting room, not in a Cloudflare Workers console.
If you're about to start a domain consolidation, the single most useful thing you can do before writing any redirects: run the Signal Score for both domains, compute the ratio, and have the architecture conversation explicitly. Don't let it get decided by default.
See also: multilingual SEO without hreflang | managing 8.4M redirects without killing TTFB | brand SERP defense in 2026
External references: [Google: Redirects and Google Search] | [GSC: Change of address tool]
