River
Y CombinatorBacked by Y Combinator
FREE TEMPLATE

Docs Information Architecture Template

Three documents and three sheets that split a content gap, no page exists, from a findability gap, the page exists in the wrong section.

Free download  ·  No account needed

IA Proposal

[Product], [n] pages across [n] sections

Against [n] days of search log and [n] support tickets

The two gaps, kept separate

Query clusters, head searches
Clusters with no matching page: content gap
Tickets resolved by linking to an existing page
Of those, linked outside the ticket's own section: findability gap

The join a search-log-only audit cannot make

A findability gap never shows up in search analytics, because a reader who eventually finds the page via search generates no signal at all. It only appears by crossing a ticket's own intake category against the section its resolving page sits in today.

Where the mismatches concentrate

Every ticket-category-to-page-section pair, ranked by how many tickets it drew, so the top row is the move worth making first.

What moves

Every relocating page, named, with the ticket count that named it and the pages that follow it for section consistency.

The redirect plan

Old path, new path, and a collision check, so nothing 404s the day the structure ships.

Diátaxis, the documentation framework most widely cited for structure, organizes content by what a reader needs: tutorial, how-to guide, reference, or explanation. That is a real answer to one question and silent on another. It says what kind of page to write, never where a specific existing page belongs relative to how people actually search and get stuck. The standard alternative, card sorting, asks a recruited panel to sort hypothetical labels. Neither reads a single real search or a single real ticket.

This pack reads two logs instead of asking a panel to imagine one. A search query with no matching page anywhere is a content gap, and the fix is writing. A support ticket resolved by linking to a page in a different top-level section than the ticket's own intake category is a findability gap: the page already exists, so the fix is moving it or cross-linking it. On the worked docs set, 71 query clusters split 52 matched and 19 with no page at all, a 26.8 percent content gap.

Of 968 tickets resolved by linking to an existing page, 357, 36.9 percent, linked to one outside the section the ticket was filed under, invisible to any process that reads only the search log. Open in River and the agent reads both logs before proposing a structural change, or download the blank sheets and build the register yourself. This proposes where pages belong; it does not write the pages the content gap names, and it does not check an existing page's content for accuracy.

71 query clusters, 19 with no page; 968 resolved tickets, 357 pointing outside their own section

The Search Query to Page Map, the ticket-crossing table and the Redirect Plan.

Search Query to Page Map

Meridian Sync, an invented sync and collaboration product. 90 days of search log, 38,900 raw searches, 1,480 head queries clustered into 71 topics. Content gaps first, by search volume.

ClusterSearches/90dMatching pageStatus
Sync conflict after a folder rename1,120noneContent gap
Migrate a workspace to a new org640noneContent gap
Presence API rate limit410noneContent gap
Bulk restore after the retention window380noneContent gap
SCIM deprovision doesn't release a seat290noneContent gap
14 more content-gap clusters1,920noneContent gap
How conflicts are detected2,840/sync-engine/how-conflicts-are-detectedMatched
Sync stuck at a percentage2,210/troubleshooting/sync-stuck-at-percentMatched

19 of 71 clusters have no matching page anywhere, 26.8%, holding 4,760 searches across the 90 days. The other 52 clusters matched and go straight to the Navigation Structure doc rather than the backlog.

Ticket Crossing

1,240 support tickets over the same 90 days; 968 resolved by linking to an existing page. Each row crosses the ticket's own intake category against the section its resolving page sits in today.

Ticket filed underAnswer actually lives inTickets
TroubleshootingSync Engine & Conflict Resolution92
Permissions & SharingAdmin & Governance86
Sync Engine & Conflict ResolutionAPI Reference74
Getting StartedInstallation & Setup58
IntegrationsAPI Reference47
5 pairs above, plus section matches611 matched

357 of 968 resolved tickets, 36.9%, named a page outside the section the ticket itself was filed under. The busiest pair alone, Troubleshooting tickets answered by a Sync Engine page, is larger than 15 of the 19 content-gap clusters combined.

Redirect Plan

46 pages relocate under the proposed structure, 21.5% of the 214-page set: 33 named directly by a mismatched ticket, 13 more moved for section consistency. Checked for collisions before anything ships.

Old pathNew pathReason
/api-reference/conflict-event-payload/sync-engine/conflict-event-payload74 tickets, Sync Engine intake
/permissions-sharing/role-inheritance/admin-governance/role-inheritance86 tickets, Permissions intake
/sync-engine/offline-queue-limits/troubleshooting/offline-queue-limits92 tickets, Troubleshooting intake
/getting-started/first-sync-configuration/installation-setup/first-sync-configuration58 tickets, Getting Started intake

Every redirect is checked against every other old and new path for a collision before publishing. One near-collision, an unrelated draft page sitting at the destination path, was caught and renamed before this plan was finalized.

What's in the pack

01

Page Inventory

Every published page, its current section, its depth, and whether it has an inbound nav link at all.

02

Search Query to Page Map

Head search queries clustered by intent and checked against the inventory, matched or content gap, with the search volume behind each.

03

Gap Register

Content gaps and findability gaps tracked as two separate lists with two separate owners, never merged into one number.

04

IA Proposal

The two headline counts and the specific ticket or query evidence behind every section change, cited row by row.

05

Navigation Structure

The finished tree: what stays, what moves in, what moves out, and the total pages relocated as a share of the set.

06

Redirect Plan

Old path to new path for every relocating page, checked for collisions, plus the internal links that need updating in the same pass.

07

A space rule every prompt reads first

A content gap and a findability gap are never counted as one finding, because they have different fixes and different owners.

How to use it

  1. 1

    Open it in River, or download it

    Open the pack and the agent reads your page inventory, search log and ticket export before proposing anything, or download the blank sheets and docs.

  2. 2

    Send your two logs

    Your current page inventory, your site search query log for a quarter or two, and your support ticket export with each ticket's intake category.

  3. 3

    Read both gaps separately

    Head queries cluster into topics and get checked against the inventory. Tickets cross against the section their resolving page sits in today.

  4. 4

    Get the tree and the redirects

    The proposal names what moves and why, the navigation structure shows the finished tree, and the redirect plan is checked for collisions before anything ships.

Frequently asked questions

Is this template free?

Yes. Download the whole pack as Word documents and CSV sheets, no signup and no credit card. Edit with AI is a separate, optional path for anyone who wants the agent to read your own search log and ticket export. Nothing happens until you send it something to cross.

We don't tag support tickets with an intake category. Does this still work?

Only for the content-gap half. The findability gap needs a category on the way in, however rough, because the join is between that category and the section the resolving page sits in. Tag a month going forward and run the crossing pass once you have enough rows.

How is this different from a content audit or gap analysis?

Most gap analysis reads search and tickets to find missing articles, the content-gap half alone. This adds the second join: crossing a ticket's own category against where its answer already lives, which finds pages that exist and are simply filed wrong. Auditing an existing page's accuracy is the documentation audit; confirming a shipped page's ticket drop held up is the documentation metrics and reporting pack.

Does it write the missing pages the content gap finds?

No. It names each gap cluster, its search volume, and the section it would belong to once written, then hands that list to the Gap Register as a backlog. Writing the page itself, and checking a spec-generated reference for what it never says, is the OpenAPI gap workup, and writing it as a tutorial that states each step's result is the tutorial and how-to pack.

Will the redirect plan break any links?

It is checked for collisions before it ships: no two old paths landing on the same new path, and no new path already occupied. It also lists every internal cross-link inside your own docs pointing at a moving path, so those get updated directly instead of relying on the redirect forever.

What format are the downloaded files?

Three Word documents and three CSV sheets, zipped. The documents open in Word, Pages and Google Docs; the sheets open in Excel, Numbers and Sheets. Add a PDF query string to the download if you want to circulate the proposal rather than fill it in.

How does this fit with a docs-as-code review process?

Separately. This proposes where pages belong before anything is written or moved; the docs as code workflow pack is the review gate a change goes through afterward, including the pull request that actually executes a page move or a redirect.

Find out how many of your pages are simply filed in the wrong place

Download the blank Page Inventory, Search Query to Page Map and Gap Register as Word and CSV, or have River cross your own search log against your ticket intake data.

Edit with AI