Consolidate Two Content Libraries Into One

The default plan is to redirect the smaller site wholesale into the larger one, which discards the pages where the smaller site was genuinely stronger and drops the topics only it covered. Keeping everything is the opposite error and hands you two pages per topic on one domain, a cannibalisation problem built deliberately. The decision has to be made topic by topic on evidence, and the sequencing matters as much as the decisions, because a single release makes any loss impossible to diagnose.

The skill file

---
name: post-merger-content-consolidation
description: Use when two sites are merging after an acquisition, a rebrand or a subdomain rollup, and both libraries cover the same topics.
---

# Consolidate Two Content Libraries Into One

The default plan is to redirect the smaller site wholesale into the larger one, which discards the pages where the smaller site was genuinely stronger and drops the topics only it covered. Keeping everything is the opposite error and hands you two pages per topic on one domain, a cannibalisation problem built deliberately. The decision has to be made topic by topic on evidence, and the sequencing matters as much as the decisions, because a single release makes any loss impossible to diagnose.

## What you need first

- Search Console query by page exports for both properties, 12 months, taken before any access or DNS change
- referring domain counts per URL for both sites
- conversion data per URL for both sites wherever it exists
- the technical constraints: which platform survives and whether URL structures can be preserved

## Method

1. Export everything from both properties before anything else happens. Search Console history disappears with the property, and access to the acquired site is usually the first thing switched off.
2. Match pages across the two libraries by the queries they rank for, not by title or URL similarity. Two pages with unrelated titles frequently compete for the same query, and two with near identical titles frequently do not.
3. For each matched pair choose the survivor on referring domains and conversion, not on which brand is acquiring. The acquired site often holds the better page on the topics it specialised in.
4. List topics only the retiring site covers and treat those as content to migrate rather than redirect. Redirecting a topic you do not cover into a page about something else is a soft 404 and loses the topic outright.
5. Where the survivor sits on the retiring domain, move its content to a URL on the surviving domain rather than keeping the old domain alive as an exception. Exceptions of that kind become permanent and end up unowned.
6. Sequence the migration in tranches ordered by traffic, lowest first, with at least three weeks between them. The smallest tranche is your test of the redirect mapping and the template, and it costs little when the mapping is wrong.
7. Rewrite internal links to final destination URLs in the same release as each tranche, and re-run the query by page export four weeks later to catch competing pairs you missed before the next tranche goes.

## What this produces

A per topic consolidation map giving the surviving URL, the redirect target for every retired URL, and a tranche schedule running from lowest traffic to highest.

## Where this goes wrong

- redirecting the entire acquired site to a homepage or a single landing page, which Google treats as soft 404s and which loses every topic that site owned
- losing the acquired property Search Console history because access was revoked before the export, leaving no baseline to judge the migration against
- moving everything in one release, so a drop cannot be attributed to the mapping, the template change or the merge itself

---

From the QuQi skill library - https://www.quqi.io/skills/post-merger-content-consolidation

What you need first

• Search Console query by page exports for both properties, 12 months, taken before any access or DNS change
• referring domain counts per URL for both sites
• conversion data per URL for both sites wherever it exists
• the technical constraints: which platform survives and whether URL structures can be preserved

Method

1. 01 Export everything from both properties before anything else happens. Search Console history disappears with the property, and access to the acquired site is usually the first thing switched off.
2. 02 Match pages across the two libraries by the queries they rank for, not by title or URL similarity. Two pages with unrelated titles frequently compete for the same query, and two with near identical titles frequently do not.
3. 03 For each matched pair choose the survivor on referring domains and conversion, not on which brand is acquiring. The acquired site often holds the better page on the topics it specialised in.
4. 04 List topics only the retiring site covers and treat those as content to migrate rather than redirect. Redirecting a topic you do not cover into a page about something else is a soft 404 and loses the topic outright.
5. 05 Where the survivor sits on the retiring domain, move its content to a URL on the surviving domain rather than keeping the old domain alive as an exception. Exceptions of that kind become permanent and end up unowned.
6. 06 Sequence the migration in tranches ordered by traffic, lowest first, with at least three weeks between them. The smallest tranche is your test of the redirect mapping and the template, and it costs little when the mapping is wrong.
7. 07 Rewrite internal links to final destination URLs in the same release as each tranche, and re-run the query by page export four weeks later to catch competing pairs you missed before the next tranche goes.

What this produces

A per topic consolidation map giving the surviving URL, the redirect target for every retired URL, and a tranche schedule running from lowest traffic to highest.

Where this goes wrong

• redirecting the entire acquired site to a homepage or a single landing page, which Google treats as soft 404s and which loses every topic that site owned
• losing the acquired property Search Console history because access was revoked before the export, leaving no baseline to judge the migration against
• moving everything in one release, so a drop cannot be attributed to the mapping, the template change or the merge itself

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Questions about this skill

More in Content strategy