Assign Topic Ownership Across Teams

Where product marketing, the blog, support documentation and a regional team all publish to one domain, duplication is structural rather than careless: no one can see the whole inventory and each team is measured on its own output. Cannibalisation audits then run forever, cleaning the same collisions each quarter. The fix is upstream and organisational, assigning topics to owners and routing requests, which is why it is usually resisted as not an SEO job.

El archivo de la habilidad

---
name: topic-ownership-across-teams
description: Use when several teams publish to the same domain and two of them keep producing pages about the same subject.
---

# Assign Topic Ownership Across Teams

Where product marketing, the blog, support documentation and a regional team all publish to one domain, duplication is structural rather than careless: no one can see the whole inventory and each team is measured on its own output. Cannibalisation audits then run forever, cleaning the same collisions each quarter. The fix is upstream and organisational, assigning topics to owners and routing requests, which is why it is usually resisted as not an SEO job.

## Qué necesitas antes

- a full URL inventory covering every subfolder and any subdomain publishing under the same brand
- the list of teams able to publish without SEO review, which is always longer than expected
- each team's own success metric, since that is what actually drives what they publish
- current collisions from a query by page export, as evidence

## Método

1. Inventory who can publish, not who should. Include the teams working in a CMS nobody in SEO has an account for, because those produce the collisions you never see coming.
2. Map the existing inventory to topics and mark every topic already held by two or more teams. Bring that evidence to the conversation, because ownership arguments held in the abstract do not resolve.
3. Assign each topic exactly one accountable owner. Co-ownership is the failure mode this exists to remove, so a topic with two owners is an unfinished decision rather than a compromise.
4. Assign by who holds the expertise and the update obligation, not by who wants the traffic. A pricing topic owned by a team with no authority over pricing will go stale within two quarters.
5. Write the routing rule for cross boundary requests: a team needing coverage of a topic they do not own asks for a section on the owner page or an internal link, never a new URL. Make that request path shorter than the path to publishing their own page, or they will publish their own page.
6. Give each owner the query list their topic is accountable for, so ownership is measurable rather than nominal, and reassign the list explicitly when a topic changes hands.
7. Add a pre-publish check that fails when a proposed URL targets a query owned elsewhere. Governance relying on people remembering the register is accurate for a month and fiction after the next reorganisation.

## Qué produce esto

A topic ownership register mapping each topic to one accountable team with its query list, plus the routing rule for cross boundary requests.

## Dónde falla esto

- assigning ownership by traffic ambition rather than by who can maintain the page, which produces owned topics nobody updates
- leaving a topic co-owned to avoid a political argument, which guarantees the same collision returns next quarter
- writing the register but not the pre-publish check, so the register describes a structure that no longer exists

---

De la biblioteca de habilidades de QuQi - https://www.quqi.io/es/skills/topic-ownership-across-teams

Qué necesitas antes

• a full URL inventory covering every subfolder and any subdomain publishing under the same brand
• the list of teams able to publish without SEO review, which is always longer than expected
• each team's own success metric, since that is what actually drives what they publish
• current collisions from a query by page export, as evidence

Método

1. 01 Inventory who can publish, not who should. Include the teams working in a CMS nobody in SEO has an account for, because those produce the collisions you never see coming.
2. 02 Map the existing inventory to topics and mark every topic already held by two or more teams. Bring that evidence to the conversation, because ownership arguments held in the abstract do not resolve.
3. 03 Assign each topic exactly one accountable owner. Co-ownership is the failure mode this exists to remove, so a topic with two owners is an unfinished decision rather than a compromise.
4. 04 Assign by who holds the expertise and the update obligation, not by who wants the traffic. A pricing topic owned by a team with no authority over pricing will go stale within two quarters.
5. 05 Write the routing rule for cross boundary requests: a team needing coverage of a topic they do not own asks for a section on the owner page or an internal link, never a new URL. Make that request path shorter than the path to publishing their own page, or they will publish their own page.
6. 06 Give each owner the query list their topic is accountable for, so ownership is measurable rather than nominal, and reassign the list explicitly when a topic changes hands.
7. 07 Add a pre-publish check that fails when a proposed URL targets a query owned elsewhere. Governance relying on people remembering the register is accurate for a month and fiction after the next reorganisation.

Qué produce esto

A topic ownership register mapping each topic to one accountable team with its query list, plus the routing rule for cross boundary requests.

Dónde falla esto

• assigning ownership by traffic ambition rather than by who can maintain the page, which produces owned topics nobody updates
• leaving a topic co-owned to avoid a political argument, which guarantees the same collision returns next quarter
• writing the register but not the pre-publish check, so the register describes a structure that no longer exists

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.

Más en Estrategia de contenido