QuQi

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.

Consigue el archivo de la habilidad Deja que lo lleven los agentes
CATEGORÍA
Estrategia de contenido
FORMATO
post-merger-content-consolidation.md
PASOS
7
PRECIO
Gratis, sin cuenta
CUÁNDO USAR ESTO

Use when two sites are merging after an acquisition, a rebrand or a subdomain rollup, and both libraries cover the same topics.

El archivo de la habilidad

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.

## Qué necesitas antes

- 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

## Método

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.

## Qué produce esto

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.

## Dónde falla esto

- 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

---

De la biblioteca de habilidades de QuQi - https://www.quqi.io/es/skills/post-merger-content-consolidation
Descarga gratis · sin cuenta, sin correo

Qué necesitas antes

  • 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

Método

  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.

Qué produce esto

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.

Dónde falla esto

  • 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

Usa esta skill en tu propia IA

El archivo es markdown simple, con el nombre y el disparador en su frontmatter. Cuando un asistente sabe cargar skills por su cuenta, es ese frontmatter lo que lee para decidir que esta le aplica.

Claude Code Guárdala como ~/.claude/skills/post-merger-content-consolidation/SKILL.md y Claude la carga solo cuando lo que haces coincide con el disparador. Ponla en .claude/skills dentro de un proyecto si la debe tener todo el equipo.
Claude Sube el archivo en la sección de skills de tus ajustes. Una vez ahí se aplica solo en cualquier conversación donde encaje el disparador, sin que tengas que acordarte.
ChatGPT No hay un formato de skills donde instalarla, así que pega el contenido del archivo en las instrucciones de un Proyecto o de un GPT personalizado. Así se aplica a todos los chats de ese proyecto y no solo a aquel donde lo pegaste.
Cualquier otro Pega el markdown en el chat antes de tu pregunta. Funciona en cualquier asistente, solo hay que volver a pegarlo cada vez.

Más en Estrategia de contenido