Site merger topic maps are the planning layer behind combining two sites into one structure that still makes sense.
When one site absorbs another, the problem is not just redirects. The harder job is deciding how the combined topics, page roles, clusters, and internal links should work after the merger. If that planning is weak, the merged site ends up with duplicate intent, broken parent child paths, loose internal links, and pages competing for the same topic.
On Semantec SEO, this page belongs in the Topical Mapping cluster beside Topical Map Process, Cluster Roles, Query Deserves Granularity, Site Growth Model, and Legacy Site to Processed Map.
The short answer
A site merger topic map is the structure plan for combining two or more sites into one topical system.
It helps you decide:
- which site owns each cluster
- which pages stay live
- which pages merge into stronger parent pages
- which URLs redirect
- which hubs need to be rebuilt
- how internal links should work after the merger
A good merger map stops the new site from becoming one large archive of overlapping pages.
Why site mergers get messy fast
Most merged sites run into the same problems.
Two sites may cover the same topic from different angles. One may have strong commercial pages but weak support content. The other may have deep educational content but poor structure. Both may have their own hubs, categories, and naming logic.
Once those systems collide, the combined site can end up with:
- two versions of the same parent topic
- several pages aimed at the same query intent
- mixed page roles inside one cluster
- redirect chains that point into weak pages
- internal links that still reflect the old sites
- support pages with no clear home
That is why a site merger needs more than a redirect sheet. It needs a new topical map.
What a site merger topic map is trying to solve
A site merger topic map gives the combined site one clean structure.
That means it has to answer five questions:
- What are the parent clusters on the merged site?
- Which pages from each site belong inside those clusters?
- Which URLs should stay, merge, split, redirect, or disappear?
- Which site provides the stronger hub, spoke, proof, or commercial page?
- How should the links and publishing paths work after the move?
Without those answers, the merger may preserve traffic in the short term but weaken the site in the long term.
A merger is not just a redirect project
This is where many teams go wrong.
They build a redirect plan first, then try to tidy the structure later. That often locks weak decisions into place. Redirects end up pointing to the closest page by phrase match instead of the right page by role and intent.
A better sequence is:
- build the merged topic map
- assign page roles
- decide the keep, merge, split, or retire actions
- create the redirect plan from that structure
That keeps the redirects aligned with the new site, not the old sites.
The first step: inventory both sites together
Start by combining the full URL inventory from both sites into one working sheet.
For each page, log:
- site of origin
- current URL
- title
- topic
- page type
- likely intent
- current traffic or business value
- overlap notes
- quality notes
- action recommendation
This gives you one view of the combined footprint. Without that view, merger decisions stay too local and you miss the full overlap pattern.
The second step: ignore the old categories
Old categories can help, but they should not control the new map.
Each site may have used different naming, different taxonomy, or different rules for page creation. One site may have grouped pages by product line. The other may have grouped them by search term. If you carry both systems forward, the merged site stays confused.
Recluster from the topic and page purpose instead.
That is where pages like Content Architecture Blueprints and Cluster Roles become useful. The new structure should reflect the best version of the topic system, not a compromise between two weak taxonomies.
The third step: assign one role to every page
Merged sites get cleaner when each surviving page has one primary job.
A page may become a:
- hub
- spoke
- comparison page
- use case page
- proof page
- doc page
- template page
- example page
- commercial page
This is a key step because site mergers often create role collisions. One site may have a broad article trying to act like a hub. The other may have a category page covering the same topic but with no real depth. The merged map needs to choose one parent role and build from there.
The fourth step: find topic collisions
Topic collisions are the real merger problem.
A collision happens when both sites have pages that serve the same intent or sit too close on the same topic path. You may see:
- two hub pages for the same parent topic
- two child pages answering the same question
- one broad page and one narrow page that should be merged
- competing comparison pages
- duplicate glossary style pages
- two different commercial pages aimed at the same use case
This is where Query Deserves Granularity helps. Some topics deserve separate pages. Some only deserve one stronger page. Some belong as a section on a parent page.
A site merger often leaves all three versions live until someone forces a decision.
The fifth step: choose the parent cluster for each topic
Every merged topic needs one clear parent home.
For each core topic, decide:
- which URL will act as the hub
- which child pages will support it
- which pages from the other site will merge into it
- which old pages will redirect to it
- which pages will stay outside the cluster
This is one reason merger planning belongs under topical mapping. The problem is structural before it becomes editorial.
A useful decision frame for merged pages
Once the clusters are visible, each page should get one action.
Keep
Keep the page if it is already the strongest version of a distinct role and intent.
Merge
Merge the page if another URL can absorb its value and own the topic more clearly.
Split
Split the page if it is carrying too many subtopics that now deserve separate homes in the new map.
Redirect
Redirect the page if the topic should live elsewhere and there is a clear destination.
Retire
Retire the page if it adds little, overlaps heavily, or does not fit the new structure.
This is how the merger map becomes operational instead of staying theoretical.
Choose the best page, not the original owner
Teams sometimes protect the pages from the larger or newer site by default.
That is a weak rule.
The merged map should choose the page that gives the new site the strongest outcome. That could mean:
- keeping the better hub from Site A
- keeping the better child page from Site B
- creating a new parent page on the merged site
- combining both pages into one stronger destination
The goal is not fairness between legacy sites. The goal is a stronger final structure.
Site mergers often need new hub pages
This is one of the biggest missed moves in merger planning.
When two sites combine, the winning structure may need parent pages that did not exist on either site before. That can happen when:
- both sites had child pages but no clean hub
- both sites split one topic in different ways
- the merged site needs a new top level path to group the combined content
- the old categories are not good enough to act as parent pages
That is why site mergers often create new hubs, not just new redirects.
If you need the parent page logic first, read Hub Page Design next.
Redirects should follow the new map
Once the topical map is set, the redirect plan becomes clearer.
Good redirects should point to:
- the surviving hub
- the surviving child page
- the newly merged destination
- the new parent page created during the merger
Bad redirects point to:
- the closest keyword match
- a weak category page
- a page with a different role
- a page that only overlaps loosely
This is why the map comes before the redirect sheet.
Internal links need a full rebuild after a merger
Merged sites often carry internal links from both legacy systems. Those links still point to old clusters, old categories, and old priorities.
After the merger map is complete, rebuild links around the new structure:
- hubs link to the right child pages
- child pages link back to the surviving hub
- sibling pages link across when the topic path is tight
- proof and support pages reinforce the new commercial routes
This is where Semantic Internal Linking and Internal Link Briefing become part of the merger workflow.
A merger map should also drive rewrite work
A site merger is not just technical cleanup.
Once the new structure is set, many surviving pages still need rewrites. Some need tighter intros. Some need new section order. Some need merged examples, tables, proof, or definitions from the retired page.
That is why merger work should feed into Intent Led Brief and then into the Drafting Rewriting lane. The structure decision comes first. The editorial repair follows it.
A practical workflow for site merger topic maps
Use this process.
1. combine both site inventories
Build one view of all live URLs.
2. cluster the combined pages by topic
Ignore the old taxonomy if it does not help the new structure.
3. assign page roles
Mark hubs, spokes, commercial pages, docs, proof pages, templates, and examples.
4. spot collisions and overlap
Look for duplicate intent, duplicate parent topics, and weak cluster splits.
5. choose the surviving parent structure
Pick the hubs and child paths the merged site will use.
6. assign one action to every page
Keep, merge, split, redirect, or retire.
7. build the redirect plan
Map old URLs to the new parent and child structure.
8. rebuild internal links
Match the links to the new map.
9. brief and rewrite the surviving pages
Turn the merged structure into usable editorial work.
Common mistakes in site mergers
Letting both taxonomies survive
This keeps the merged site split into two systems.
Keeping duplicate hubs
One parent topic needs one clear home.
Redirecting by phrase match alone
The destination needs the right role, not just similar wording.
Merging pages without rethinking structure
Two weak pages do not become strong just because they are combined.
Ignoring proof and support pages
The merged commercial path gets weaker if the supporting pages are not rebuilt around it.
What a strong site merger map looks like
A strong merger map gives you:
- one combined topic system
- one parent cluster for each core topic
- page roles for every surviving URL
- a clear keep, merge, split, redirect, or retire action set
- redirects that follow the new structure
- internal links that reflect the merged site
- a rewrite queue based on the new roles
That is the point where the merged site stops feeling like two archives taped together.
Site merger topic maps vs legacy site cleanup
These two projects are close, but not identical.
A legacy site cleanup works with one site and its history. A site merger map works with two or more sites and two or more structural systems.
That makes mergers harder because topic collisions are more aggressive and page role conflicts show up faster.
If you are working with one site only, start with Legacy Site to Processed Map. If you are combining sites, use this page as the structural model.
Final take
Site merger topic maps are how you combine two sites into one clean topical system.
The goal is not just to preserve URLs. The goal is to decide which clusters survive, which pages win, which pages merge, where the redirects go, and how the new site will grow after the merger is finished.
If you need the cluster logic first, go next to Site Growth Model, Hub Page Design, and Legacy Site to Processed Map. If you want the workflow inside the product, start with MIRENA for Topical Mapping.
FAQ
What is a site merger topic map?
It is the structure plan for combining two or more sites into one topical system with clear clusters, page roles, redirects, and internal links.
Is a site merger map just a redirect plan?
No. Redirects are one output. The map comes first.
Should I keep the stronger site structure or build a new one?
Keep the parts that help the merged site most. In many cases, the best result uses pages from both sites and adds new parent pages.
What should I read after this page?
Go next to Legacy Site to Processed Map, Site Growth Model, and Hub Page Design.