Most content problems are invisible at the page level. Any individual article looks fine. The library as a whole is where you find four posts competing for the same question, entire topics missing, and navigation that reflects the org chart instead of how anyone thinks.
A content architect owns the map: what should exist, what shouldn't, how pieces relate, and how a person — or a machine — moves between them. Writing is the last step of that work, not the first.
- Content architecture is structure before prosedeciding what exists and how it connects, before anyone drafts.
- The unit of work is the libraryindividual pages can each be good while the collection is incoherent.
- Overlap and gaps are the two failure modesseveral pages half-answering one question, and whole questions no page answers.
- The same map serves humans and machinesclear hierarchy helps a reader navigate and a retrieval system disambiguate.
What the job actually consists of
- 01Inventory and audit
Knowing what already exists — most libraries past year two contain duplicates their own team has forgotten.
- 02Taxonomy
Categories and tags that reflect how the audience thinks about the space, not how the company is org-charted.
- 03Page-type definitions
What a guide is versus a comparison versus a reference, so each question gets answered in the right shape once.
- 04Connection design
Hub and spoke relationships, next-step paths, and the links that make them real.
- 05Lifecycle rules
What gets updated, merged, or retired — architecture includes demolition.
The failure modes it exists to prevent
- Three posts each answering 60% of the same question, so none answers it fully and every reader lands on the wrong one.
- A topic the business depends on with no page at all, because nobody owned the map and everyone assumed.
- Category pages that are junk drawers — "Tips," "News," "Other" — carrying no information about what is inside.
- Orphan pages with no inbound links, unreachable except by luck.
- A publishing calendar driven by what is easy to write instead of what is missing.
A library where every page is good and the collection is incoherent still loses — readers can't find the next step, and retrieval systems can't tell your pages apart.
How the work gets measured
- Coverage — the share of your question inventory with exactly one owning page.
- Internal search and navigation success, when you have the data.
- Multi-page sessions — readers finding the intended next step.
- Decay of duplicate and orphan counts over time.
- Time-to-locate in a user test: give someone a question, watch them try to find the answer.
How is a content architect different from an information architect?
Same discipline, different scope. Information architecture covers whole products and systems; a content architect applies it to the editorial library specifically.
Do small sites need this?
Small sites need an hour of it, not a hire. Fifty pages without a map still develop overlap — it just takes longer to hurt.
Architecture or writing first?
Map first, always. Writing into a bad map produces good pages in wrong places, and moving them later costs more than planning did.
How these roles fit together
One library, different layers. Content design makes a single page work for the person reading it. Content architecture decides what pages exist and how they relate. Content engineering makes producing them repeatable. Relevance design and relevance architecture make the result legible to the retrieval systems deciding who gets surfaced. Resonance architecture is the layer those all serve: whether any of it lands with an actual human once it is retrieved.
Nobody hires all six. Small teams get one person wearing several of these hats badly until the seams show. The names matter less than noticing which layer is failing, because the fixes live in different places.
