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.
CATEGORY
Content strategy
FORMAT
post-merger-content-consolidation.md
WHEN TO REACH FOR THIS
Use when two sites are merging after an acquisition, a rebrand or a subdomain rollup, and both libraries cover the same topics.
The skill file
post-merger-content-consolidation.md
---
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
Free to download · no account, no email
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Claude Code
Save it as ~/.claude/skills/post-merger-content-consolidation/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude
Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT
There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else
Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.
Questions about this skill
When is a topic by topic decision better than redirecting the smaller site wholesale?
Whenever the two libraries genuinely overlap. A wholesale redirect discards the pages where the smaller site was stronger and drops the topics only it covered. Keeping everything is the opposite error and hands you two pages per topic on one domain, which is a cannibalisation problem built deliberately. Only the evidence per topic separates those cases.
What do I need in hand before starting?
Twelve months of Search Console query by page exports for both properties, taken before any access or DNS change, referring domain counts per URL, conversion data where it exists, and which platform survives. Search Console history disappears with the property and access to the acquired site is usually revoked first, so a late export leaves no baseline to judge the migration against.
What do I end up with, and which part of it gets used?
A per topic map giving the surviving URL, the redirect target for every retired URL, and a tranche schedule running lowest traffic first. The schedule matters most in execution: the smallest tranche is your live test of the redirect mapping and the template, and it costs little when the mapping turns out to be wrong.
What ruins this most often?
Moving everything in one release. When traffic drops you cannot tell whether the cause was the mapping, the template change or the merge itself, and the diagnosis window closes while the argument runs. Matching pages by title or URL similarity is the other one: unrelated titles frequently compete for the same query, and near identical titles frequently do not.
More in Content strategy