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.

The skill file

---
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.

## What you need first

- 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

## Method

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.

## What this produces

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

## Where this goes wrong

- 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

---

From the QuQi skill library - https://www.quqi.io/skills/topic-ownership-across-teams

What you need first

• 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

Method

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.

What this produces

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

Where this goes wrong

• 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

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