Most documentation problems show up as individual pages and resolve into an architectural problem. Teams fix pages for a year before noticing that the architecture is what was failing the whole time. Ninety minutes, done honestly, will tell you which problem you're facing.

This post is the exercise. Block the time this afternoon, print two things, pull in two colleagues, and run it.

The argument in one paragraph#

You do not need an expensive audit, a new tool, or a redesign to diagnose whether your docs site has an information architecture problem. You need a structured ninety-minute session with the right three people and a printed sitemap. Page-level review catches staleness and bad examples. Architectural review catches the failures that quietly degrade every page at once: duplication, orphans, navigation that does not match intent, and titles that hide content from humans and retrievers. Run this exercise first. Decide what to fix after.

Who is in the room#

Three people. Ninety minutes. No fourth.

A writer or docs engineer who knows the current structure cold and can name every top-level section without the sitemap in front of them.
An engineer who shipped the product and can judge, in real time, whether a page is technically accurate or lying by omission.
A newer reader who joined the company or started using the product in the last ninety days. A new-hire developer is ideal. A customer in a design-partner slot is better. The point is cold eyes.

Adding a fourth kills the exercise. Marketing, support, product management, the VP who wants to be informed — out. Their input belongs in a different meeting. Four people in ninety minutes produces consensus theater. Three produces decisions.

One person runs the clock. Rotate that role across sessions so no single person owns the ritual.

What to print before the meeting#

Two artifacts, on paper, one copy per attendee.

The full sitemap, as a tree. One page per node. Each node shows the URL path, the page title, the last-edited date, and 30-day pageviews. Indent children under parents. If the tree runs past thirty pages of paper, your IA problem has already announced itself and you can start the meeting with that finding.
Ten real queries from the last thirty days. Pull them from support tickets, site search logs, your LLM retrieval logs, or a sample of Intercom transcripts. One query per index card or quarter-sheet. Verbatim. No cleanup.

The shift from screen to paper is not aesthetic. On a screen you scan. On paper you read. On paper you write in the margin, you flip between pages, you put two pages side by side and see the duplicate you have walked past for a year. Do not skip the printing step.

The ninety-minute agenda#

The minutes below are tight on purpose. If a pass runs long, cut the pass, not the next one. The one-page output at the end is the point.

Minutes 0 to 10: Orient#

Walk the tree silently. Everyone reads their own copy. No discussion. Highlight, in a color of your choosing, any page that surprises you — because it exists, because it does not, or because it sits somewhere you did not expect. Ten minutes is enough. Stop when the clock stops.

Minutes 10 to 30: The duplicates pass#

Tree in hand, page by page, mark every pair or triple where the same topic is covered in more than one place. Near-duplicates count. A concept explained in an overview page, a how-to, and a tutorial is a triple. An error explained in a troubleshooting section and again in the API reference is a pair.

This is almost always where AI-era failures live. Retrieval systems do not know which duplicate is canonical. They surface the shortest one, or the highest-ranked one, or the one that embeds best against the query, and the user gets partial truth with full confidence.

Output: a list of duplicated topics. Each duplicate set gets one owner and one canonical page by the end of the pass. The others become redirects or deletions in the two-week plan.

Minutes 30 to 50: The orphan pass#

Find every page with no inbound link from the rest of the docs. Some orphans are intentional: marketing landing pages, campaign redirects, legal pages, release notes that live off the main nav by design. Most are neglect. Common patterns we see:

Pages written for a webinar or launch, never relinked after the event
Deprecated-feature pages that should have been archived but were only unlinked from the sidebar
Migration guides from two versions ago, still indexed, still getting search traffic, still shipping stale instructions
Deep-linked tutorials that a former DevRel lead wrote and no one else knows about

Each orphan gets one of three fates, assigned in the room: adopted (linked in from the right parent page), redirected (to the current canonical page), or deleted. If you cannot decide in ninety seconds, default to redirect. Reversible beats stuck.

Minutes 50 to 70: The query pass#

Pull out the ten printed queries. Read each one aloud. Each person points — with a finger, on paper — to the page they would send a user to. Do not discuss first; point first.

If all three people point to the same page, record it and move on.
If three people point to three different pages, you have a finding. Write the query and the three candidates.
If no one can point, you have a bigger finding. Write the query and mark it as a content gap.

Twenty minutes, ten queries, two minutes each including the pointing. Keep the pace. The goal is not to fix the query in the meeting; it is to surface the pattern across ten queries. Three fingers at three pages is the signature of navigation that does not match intent. No fingers at any page is the signature of a gap that a support ticket has been quietly subsidizing for months.

Minutes 70 to 85: The naming pass#

Take the top twenty pages by thirty-day traffic. For each, ask one question: does the title name a concept, a task, or a product?

Concept-named pages ("Authentication", "Webhooks", "Observability") are slow to rank for user intent. Users rarely search the noun alone; they search the verb against the noun.
Task-named pages ("Rotate an API key", "Send a webhook from a staging environment", "Debug a failed deploy") are findable by humans and by retrievers. Both are searching verbs.
Product-named pages ("Using Acme Pro", "Acme Connect overview") are the worst for search and retrieval. They tell a reader nothing about what the page answers.

Rename in place. Redirect the old slug. This is the fastest return on investment in the whole exercise, and it compounds: retrievers re-index the new title, users click the better-named result, and the page climbs without any content change.

Fifteen minutes is enough for twenty renames if you do not debate. Trust the rule. If a title fits no category, it is probably product-named and you already know what to do.

Minutes 85 to 90: The one-page output#

Before anyone leaves, write one page. Three sections, no more.

What we found. Three bullets maximum. The patterns, not the instances.
What we are changing in the next two weeks. Named owners, specific pages, calendar dates.
What we are deferring and why. Scope, cost, or sequencing — one line each.

This page becomes the IA review artifact. File it where the docs team files its planning. Re-run the exercise in six months with the same three seats, not necessarily the same three people.

What this exercise catches that page review does not#

Page review catches staleness, bad examples, inaccuracies, broken links. It operates one URL at a time and improves one URL at a time. Architectural review is a different instrument. It catches:

Structural duplication across the site
Orphan pages driving unintended traffic and unintended answers
Navigation paths that do not match how users phrase their actual questions
Titles that hide the content from both humans and retrievers
Sections that have drifted out of proportion with how much users need them

A team doing regular page review and no architectural review will fix the wrong things carefully. The pages will look better. The site will perform the same.

The query pass in particular interlocks with any retrieval audit you are doing for AI assistants. When a retriever returns the wrong page, the fix is almost never in the page that was returned; it is in the title, the duplicate cluster, or the orphan that outranked the canonical answer. The ninety-minute exercise surfaces the same failures the retriever stumbles on, from a different angle, at a cost of ninety minutes instead of a quarter of engineering time.

Why we publish this#

Because it is useful whether or not you hire us. A team that runs this exercise and finds nothing has a clean docset and is an unusual prospect. A team that runs it and finds six issues will know exactly why a proposal from us — or anyone — is scoped the way it is. Either way the exercise pays for itself the afternoon you run it.

We would rather talk to a team that has done the ninety minutes than a team that has not. It changes the conversation from "something feels wrong" to "here are the four patterns we found, and here are the two we cannot fix ourselves."

The worksheet#

Three templates. Recreate them in whatever tool your team already prints from — a spreadsheet, a doc, a Notion page. The shape matters more than the format.

Sitemap template (one row per page):

Column 1: Indent level (0 for top-level, 1 for child, 2 for grandchild, and so on)
Column 2: URL path
Column 3: Page title, exactly as it appears on the page
Column 4: Last-edited date
Column 5: Thirty-day pageviews
Column 6: Inbound internal link count
Column 7: Blank, for in-room highlighting and notes

Print at a font size you can read across a table. Landscape orientation usually wins.

Query card template (one card per query, ten cards total):

Top of card: the query, verbatim, in quotes
Source line: where it came from (support ticket, site search, retrieval log, sales call)
Date
Three blank lines labeled Writer, Engineer, Newer reader — for each person to record the page they pointed at
Bottom of card: a checkbox for Agreement, Disagreement, Gap

Index cards or quarter-sheets. One query per card so they can be dealt, sorted, and re-stacked by pattern at the end of the pass.

One-page output template:

Header: date, attendees, docset URL
Section 1: What we found. Three bullets. Patterns, not instances.
Section 2: Changes in the next two weeks. A small table: page or topic, owner, action (rename, redirect, merge, delete, rewrite), due date.
Section 3: Deferred. A small table: item, reason deferred, revisit date.
Footer: signature line for the writer, the engineer, and the newer reader. A signed artifact gets followed up on. An unsigned one gets lost.

Keep all three templates in the same folder as your docs planning. When you run the exercise again in six months, the delta between the two one-page outputs is its own finding.

Run it this afternoon#

Ninety minutes. Three people. One printed tree. Ten printed queries. One page of output.

This exercise has saved more documentation engagements from mis-scoping than any tool we use. Run it before you pay anyone — us, a consultant, a new hire, a platform vendor — to do work on your docs. If the findings point at a project bigger than your team can absorb, then talk to someone. You will arrive at that conversation with evidence instead of unease, and that changes every number in the proposal that follows.