QuQi

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.

احصل على ملف المهارة دع الوكلاء يتولّون الأمر
التصنيف
استراتيجية المحتوى
الصيغة
topic-ownership-across-teams.md
الخطوات
7
السعر
مجانًا - بلا حساب
متى تلجأ إليها

Use when several teams publish to the same domain and two of them keep producing pages about the same subject.

ملف المهارة

topic-ownership-across-teams.md
---
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.

## ما تحتاجه أولًا

- 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

## الطريقة

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.

## ما الذي تنتجه

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

## أين تخطئ عادةً

- 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

---

من مكتبة مهارات QuQi - https://www.quqi.io/ar/skills/topic-ownership-across-teams
تنزيل مجاني · بلا حساب وبلا بريد

ما تحتاجه أولًا

  • 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

الطريقة

  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.

ما الذي تنتجه

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

أين تخطئ عادةً

  • 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

استخدم هذه المهارة في الذكاء الاصطناعي الخاص بك

الملف الذي تنزّله markdown بسيط، يحمل الاسم والمُشغّل في ترويسته. وحين يكون المساعد قادراً على تحميل المهارات وحده، فهذه الترويسة هي ما يقرؤه ليقرر أن هذه المهارة تنطبق.

كلود كود احفظه في ~/.claude/skills/topic-ownership-across-teams/SKILL.md فيحمّله كلود من تلقاء نفسه حين يطابق عملك سطر المُشغّل. وضعه في .claude/skills داخل مشروع إن أردت أن يكون لدى الفريق كله.
كلود ارفع الملف في قسم المهارات ضمن إعداداتك. وبعدها ينطبق من تلقاء نفسه في أي محادثة يناسبها المُشغّل، دون أن تتذكر وجوده.
شات جي بي تي لا يوجد صيغة مهارات لتثبيته فيها، فالصق محتوى الملف في تعليمات مشروع أو في GPT مخصص بدلاً من ذلك. عندها ينطبق على كل محادثات ذلك المشروع لا على المحادثة التي لصقته فيها وحدها.
أي مساعد آخر الصق الـ markdown في المحادثة قبل سؤالك. يعمل مع أي مساعد، لكن عليك لصقه من جديد في كل مرة.

المزيد في استراتيجية المحتوى