Abrasim problem-resolution guide
Your Content Library Has No Clear Architecture: Rebuild and Consolidation Guide
Make a large content library easier to navigate and maintain.
By Tafadzwa BoriwondoPublished Evidence reviewed
- For
- Head of Content or Web Manager
- Decision to make
- Define topic, task, entity and journey ownership before changing navigation or URLs.
- Scope boundary
- Content architecture and consolidation; not a taxonomy redesign based only on keyword volume.
Start here
Agree what you need to find out.
Use this guide when you are responsible for resolving the problem described by “how to reorganise a large content library”. Check the cause before changing content, technology or the way the work is done.
Before you start
- The user question, decision or task the page is expected to serve, stated without relying on a keyword list alone.
- A query-to-page inventory with current titles, canonicals, internal links, performance evidence and known content owners.
- Access to a subject owner who can confirm whether pages are distinct, incomplete, duplicated or no longer needed.
What you leave with
- A dated evidence record for the problem described by “how to reorganise a large content library”.
- A decision that answers: Define topic, task, entity and journey ownership before changing navigation or URLs.
- An action plan with a responsible owner, live-site evidence, acceptance criteria and a follow-up date. State when to roll back the change or investigate again.
How to run every step
- 01Record the observation, source, date, scope and evidence owner before drawing a conclusion.
- 02Classify the statement as VERIFIED, INFERRED, PROPOSED or REQUIRES VALIDATION; do not silently promote an assumption.
- 03Name the result you need and who is responsible for each step. Record the decision it supports and any question still unanswered.
- 04After a change, record the live result and acceptance test. Keep source-code, preview and live-site evidence separate.
- 05Monitor search recovery and business results separately. If a check still fails, investigate that check again before repeating the whole method.
- Accountable owner
- Head of Content or Web Manager
- Operating action
- compare user intent, page role and evidence across the competing content set before improving, consolidating, redirecting or retiring anything
- Decision gate
- Before making a change, check that the evidence supports this decision: Define topic, task, entity and journey ownership before changing navigation or URLs.
- Acceptance evidence
- the chosen page answers a distinct task, internal signals support that role and affected journeys still work after release
- Rollback or reopen when
- valuable demand is sent to a weaker answer, a distinct user task disappears or the change creates a new overlap
- Scope boundary
- Content architecture and consolidation; not a taxonomy redesign based only on keyword volume.
What the problem looks like and why it matters
Readers struggle when a library follows internal departments, repeats the same answer or leaves useful pages isolated. Agree what each page helps someone do and who owns it before changing categories and navigation.
Map the questions buyers need answered to the pages you already have. Identify gaps and overlap before changing the structure, and account for existing search demand, links and page owners before moving or merging content.
What evidence distinguishes the real cause
Build one dated evidence set before rewriting or reconfiguring anything.
| Evidence | What to capture | Control |
|---|---|---|
| E-01 | Complete URL inventory with status, canonical, template and last material review | Record source, date, scope, owner and confidence. |
| E-02 | Market task, audience, topic, entity and journey role for each item | Record source, date, scope, owner and confidence. |
| E-03 | Internal-link graph, navigation paths, site search and failed-search terms | Record source, date, scope, owner and confidence. |
| E-04 | Demand, engagement, progression, maintenance cost and risk evidence | Record source, date, scope, owner and confidence. |
| E-05 | Owner, source basis, expiry, legal obligations and disposition constraints | Record source, date, scope, owner and confidence. |
Classify every material statement as VERIFIED, INFERRED, PROPOSED or REQUIRES VALIDATION. Keep implementation evidence separate from later search or commercial recovery.
How to fix it step by step
Step 1: Set architecture principles
Agree that market tasks and decision value outrank internal department labels. Define acceptable depth and ownership.
Step 2: Build the estate inventory
Reconcile sitemap, crawl, CMS, analytics and known archives. Mark evidence gaps rather than silently excluding URLs.
Step 3: Assign one primary role
Classify each item by task, audience, entity, journey stage and canonical owner.
Step 4: Identify structural failures
Find duplicates, orphans, overloaded hubs, dead ends, mixed-intent pages and unsupported categories.
Step 5: Design the target model
Create a small hierarchy of hubs and supporting pages with explicit cross-links for related decisions.
Step 6: Approve dispositions
Choose retain, improve, consolidate, redirect, archive or remove with owner, evidence and dependency checks.
Step 7: Migrate in controlled cohorts
Update content, links, navigation, sitemaps and redirects together. Test user tasks and search eligibility before expanding.
For every approved action, record the dependency, responsible owner, approver, production evidence, acceptance test and rollback trigger. Do not treat a tool recommendation as the decision.
How to verify recovery
Implementation passes when priority tasks have a clear path, each retained page has one role and owner, internal search and navigation return appropriate answers, and redirects preserve equivalent destinations. Compare crawl depth, failed searches, task completion and qualified progression. Roll back a cohort if important content becomes unreachable or the new hierarchy obscures established market language.
Use both positive and negative tests. A successful target journey must work, while unrelated, private, retired or out-of-scope journeys must remain in their authorised state.
How to prevent the problem returning
Require architecture ownership in every content brief and retirement decision. Maintain the estate register as publication state, not an occasional audit. Review new categories against user evidence and existing page ownership before approval.
Primary guidance reviewed at the 29 August 2026 source cutoff includes Google Search Central documentation and Google Search Central documentation. These sources guide diagnosis; they do not prove an outcome for a particular organisation.
Where the problem crosses content, search, experience and commercial ownership, Discuss the content library. The six value paths cross functional budgets, evidence and ownership; diagnosis therefore needs cross-functional authority, access and independent challenge, whether led internally or externally.
Use the method with AI
A prompt to help you work through this guide
Use this prompt to organise your analysis. Share only evidence you are authorised to provide to that model. A person must remain responsible for the decision, privacy limits and final action.
Copy and adapt
You are helping me apply the Abrasim problem-resolution guide: “Your Content Library Has No Clear Architecture: Rebuild and Consolidation Guide”.
Situation: how to reorganise a large content library
Decision to make: Define topic, task, entity and journey ownership before changing navigation or URLs.
Scope boundary: Content architecture and consolidation; not a taxonomy redesign based only on keyword volume.
Use only the evidence I provide. Do not invent facts, benchmarks, sources, outcomes, customer research or legal conclusions. Keep VERIFIED, OBSERVED, INFERRED, PROPOSED and UNKNOWN separate. Ask focused questions when the evidence or authority is missing.
Help me work through this method by returning:
1. An evidence table with claim, source, date, confidence and limitation.
2. The strongest competing explanations, including what would disprove each one.
3. Decision options with trade-offs, dependencies and the cost of waiting where evidence supports it.
4. The next smallest evidence-gathering action, its accountable owner and acceptance test.
5. A proceed, change, validate, defer or stop recommendation that a named human decision-maker can review.
Treat the attached Abrasim working pack as a blank working record. Do not fill missing rows with plausible data. Flag privacy/POPIA, security, accessibility, safety and authority issues. Cite primary sources for external claims and show uncertainty. End with the conditions that would make us change course or stop.
My organisation-specific evidence and constraints:
[Paste evidence, links, dates, decisions and limitations here]Working rule: AI can help organise evidence and expose questions; it cannot establish truth, approve risk, make the business decision or replace qualified legal, privacy, security or accessibility review.
