Information Architecture Audits: Understanding the Structure You Actually Have

An information architecture audit examines how an existing collection of information is organized, labeled, connected, and navigated. It asks whether people can find the right information, understand where they are, distinguish related resources, and recognize which destination answers their question.

The purpose is to understand the architecture before changing it. A website may have a tidy menu but unclear page responsibilities. A documentation library may contain accurate material that its categories make difficult to find. A collection may also work better than its organizational chart suggests, because useful pathways have developed outside the main navigation.

A useful audit documents those conditions, separates evidence from assumptions, and identifies changes that address structural problems without unnecessarily disrupting what already works.

What an information architecture audit examines

Information architecture concerns how information is organized, named, related, and made findable. An audit examines those arrangements as a connected system rather than treating each page as an isolated asset.

Hierarchy: How broad subjects, narrower subjects, and individual resources are arranged—and whether parent-child relationships make sense.
Classification: How categories, tags, content types, and other attributes group information or support filtering.
Labels: Whether menu items, headings, category names, and link text communicate meaningful distinctions.
Navigation: How people move through menus, indexes, breadcrumbs, filters, search results, and links within content.
Relationships: How the collection expresses connections such as prerequisite, alternative, example, current version, or supporting explanation.
Page responsibilities: What each page is meant to explain or help someone do, and how that responsibility differs from nearby pages.

An inventory records what exists. A content audit may evaluate accuracy, quality, ownership, or freshness. A gap analysis asks what information is missing. An information architecture audit may use all of those findings, but its central question is different: does the organization of the collection help people understand and use what is there?

The distinction matters because a findability problem does not always require new content. Sometimes the answer already exists under an unexpected label, behind an unsuitable category, or on a page whose purpose is difficult to recognize.

Define the scope and gather evidence

Begin by identifying the collection, its audiences, and the activities the architecture needs to support. An audit of a public website differs from an audit of a staff knowledge base, even when both contain articles and search tools.

Write down what is included and excluded. The scope might cover the entire site, a documentation section, a product family, or the relationship between a public help center and an authenticated application.

Start with information needs, not a preferred menu

Choose representative questions or tasks before deciding what the structure should look like. For example:

Find the requirements that apply to a particular situation.
Compare two approaches before choosing one.
Locate the current instructions for a specific product version.
Move from an introductory explanation to a detailed procedure.
Recover after arriving on a related but unsuitable page.

These activities provide a basis for evaluating the architecture. Without them, an audit can become an exercise in making the collection resemble the auditor’s preferred outline.

Use several kinds of evidence

Useful evidence may include:

A crawl or export of published URLs, titles, headings, and internal links.
CMS records showing content types, categories, tags, and parent relationships.
Menus, landing pages, indexes, breadcrumbs, and search interfaces.
Privacy-respecting aggregate search and navigation data, where available.
Support questions and editorial observations, handled without exposing personal information.
Task-based sessions with representative readers.
Ownership records, maintenance guidance, and previous structural decisions.

Each source has limits. A crawl may miss authenticated resources or controls that require interaction. An XML sitemap lists submitted URLs but does not establish a useful hierarchy. Analytics can show recorded activity without explaining why someone took a particular path.

Record when the evidence was collected and what it covers. A structure assembled from an old menu export and a current crawl may describe two different versions of the website.

Map the architecture that actually exists

A navigation menu is one representation of a collection, not the whole architecture. Compare the intended organization with the pathways available on published pages.

A practical map usually needs several views:

Declared structure: CMS parent relationships, taxonomy rules, and documented organization.
Visible structure: menus, category pages, indexes, breadcrumbs, and other interfaces readers encounter.
Linked structure: connections created by links within and between pages.
Observed pathways: routes seen in task sessions or supported by available usage evidence.

Differences between these views are findings to investigate, not automatic defects. A resource may appropriately appear in more than one subject area. A cross-topic guide may need contextual links from several sections without belonging beneath every one of them.

Examine the logic of categories

Ask what each classification system is classifying. A collection might use subject categories, audience labels, and content types together. That can be useful when the dimensions are clear.

Confusion develops when unlike dimensions are presented as if they were equivalent choices. A single list containing “Beginners,” “Troubleshooting,” “Equipment,” and “Downloads” mixes audience, activity, subject, and format. That mixture is not inherently unusable, but readers may struggle to predict where a resource belongs.

Check whether categories have understandable inclusion rules, whether their names remain meaningful outside the editorial team, and whether the interface makes overlapping membership clear.

Look beyond URL folders

A URL path can express hierarchy, but it does not prove that the same hierarchy is visible or useful to readers. A flat URL structure can support coherent navigation; a deeply nested URL structure can still leave people disoriented.

Evaluate URLs alongside labels, page context, and links rather than treating directory depth as a quality score. The same principle applies to website navigation as information architecture: the important question is what the structure communicates and enables.

Clarify page responsibilities and boundaries

For important pages, write a short statement of responsibility: the question the page answers, the reader it serves, and the detail it intentionally leaves elsewhere.

For example, a documentation collection might contain:

An overview: explains what a feature does and when it is useful.
A setup guide: provides the sequence needed to configure it.
A reference page: lists supported settings and their meanings.
A troubleshooting guide: helps diagnose recognized failure conditions.

These pages share a subject but have different responsibilities. Shared vocabulary does not make them duplicates.

Conversely, two differently titled articles may perform nearly the same job. If both present themselves as the starting point, contain conflicting summaries, and send readers through different next steps, their relationship needs clarification.

Distinguish useful overlap from competing responsibility

Some repetition supports comprehension. A procedure may need a brief definition even when a detailed explanation exists elsewhere. The audit should ask whether that overlap helps readers remain oriented or creates uncertainty about which resource to trust.

Useful questions include:

Can a reader distinguish these pages from their titles and introductions?
Is there an identifiable starting point where one is needed?
Do related pages explain how their purposes differ?
Is the current or authoritative resource identifiable?
Does each page offer an appropriate next step?

These questions help distinguish information boundaries from information relationships. Related resources need connections; they do not necessarily need to be merged.

Test realistic information pathways

A structural map describes available arrangements. Task-based evaluation helps determine whether people can use them.

Test more than the route from the homepage. People may arrive through search, a saved link, an email, or a related article. A useful destination should provide enough context for someone who has not followed the intended introductory path.

Use a small set of representative tasks

Consider a help library with an overview called “Account Access,” a guide called “Changing Your Email,” and a policy called “Identity Verification.” A reader who has lost access to their old email needs to understand which route applies before attempting a change.

An audit could examine:

Whether the reader can identify a plausible starting point.
Whether labels distinguish an ordinary email change from account recovery.
Whether the guide explains when identity verification is required.
Whether someone arriving directly on the policy can find the relevant procedure.
Whether a wrong turn offers a clear route back to the appropriate information.

Failure might arise from missing instructions, but it might instead come from unclear boundaries or absent connections among existing pages.

Choose evaluation methods for the question

Tree testing can help evaluate whether people find destinations within a proposed hierarchy. Card sorting can reveal how participants group and name information. Neither method, by itself, establishes how well the published interface works.

Testing the actual site can reveal problems involving page context, competing links, search results, filters, or inaccessible controls. Keep those findings distinguishable: an understandable category can still be unusable through a keyboard-inaccessible menu.

Accessibility also affects the structural evidence readers receive. Headings, landmarks, source order, and link text should communicate relationships without relying exclusively on visual placement. URLMD’s discussion of semantic structure and the accessibility tree explains that connection in more detail.

Turn observations into structural findings

A useful finding connects an observed condition to a reader consequence. It should also state how strongly the available evidence supports the interpretation.

“The navigation is confusing” is too broad to guide a decision. A more useful finding might read:

The navigation label “Resources” contains both setup instructions and policy documents. In the observed tasks, participants looking for setup instructions first chose “Products” and did not recognize “Resources” as the relevant destination. A more specific label or a contextual pathway from the product pages may improve findability.

This finding identifies the condition, the observed difficulty, and possible responses without claiming that one menu change will solve every problem.

Separate symptoms from possible causes

Repeated internal searches may indicate unclear labels, missing navigation, incomplete content, or simply a preference for search.
A page with few internal links may be overlooked, intentionally limited in scope, or reachable through an interface the crawl did not capture.
A large category may need subdivisions, or it may work well as a searchable index with meaningful filters.
Similar pages may compete unnecessarily, or they may serve different audiences, versions, or stages of a task.

Do not convert a diagnostic signal into a universal rule. Click depth, link counts, category size, and traffic levels can support investigation, but none independently establishes whether the architecture is effective.

Where evidence is incomplete, describe the finding as a hypothesis and specify what would help test it. Keeping fact, inference, and uncertainty distinct makes the audit easier to review and act on.

Prioritize changes without defaulting to redesign

An audit does not need to end with a new sitemap. The appropriate response depends on the cause, consequence, and reach of each finding.

A local problem may need a clearer label, a better introduction, a contextual link, or an explicit version notice. A recurring problem across a collection may justify changes to category rules, page templates, navigation, or publishing governance.

Prioritize findings by considering:

Reader consequence: does the issue cause inconvenience, block completion, or expose someone to materially wrong information?
Reach: which audiences, tasks, and parts of the collection are affected?
Evidence strength: is the problem observed, repeatedly reported, or still a plausible hypothesis?
Dependencies: does the change require content decisions, technical work, or agreement between owners?
Disruption: could the change break familiar pathways, bookmarks, integrations, or external references?
Maintainability: can editors apply the proposed rule consistently as the collection grows?

Preserve effective pathways even when they do not fit a perfectly symmetrical tree. Readers may need several legitimate routes to the same resource.

Changing a label or classification does not necessarily require changing a URL. When restructuring does require moving, merging, or retiring destinations, treat redirects, internal-link updates, and post-change checks as part of website migration planning, not as incidental cleanup.

Produce a useful audit record

The final artifact should let another person understand what was examined, why a finding matters, and what decision remains. A large spreadsheet can support that work, but it should not be the only explanation.

A practical audit record includes:

Scope and collection date: what was examined, for whom, and when.
An architecture map: enough detail to show hierarchy, classifications, entry points, and important cross-connections.
Page-role notes: responsibilities and boundaries for key or disputed destinations.
Findings with evidence: observations, reader consequences, affected areas, and known limitations.
Recommended responses: including alternatives where more than one approach is reasonable.
Ownership and dependencies: who needs to decide, implement, or maintain each change.
A verification plan: how the team will check whether the change helped.

Verification should return to the original information needs. Can readers now distinguish the relevant destinations? Can they identify the current guidance? Can someone arriving on a supporting page find the procedure they need?

Also document what should remain unchanged and why. An audit that records only defects can encourage unnecessary rebuilding and erase useful knowledge about the collection.

A good information architecture audit makes the existing structure understandable enough to change responsibly. Its value lies in identifying which arrangements help, which create friction, and which questions need more evidence—not in producing the largest possible reorganization.