Web information architecture defines how content is inventoried, grouped, named, ranked, and connected so that people and search engines can find it. It includes taxonomy, navigation, URLs, internal search, and contextual relationships. It's not about drawing a sitemap at the end: it starts with needs and evidence, is tested before visual design, and is maintained when products and content change.
A short menu can mask a confusing architecture, while a large menu can be clear if its categories are task-oriented. Quality isn't measured by the number of levels, but by the ability to predict where information is located and complete a user's journey.
What is information architecture
It's the practice of transforming a heterogeneous inventory into a comprehensible system. It defines content units, relationships, tags, and growth rules. In an e-commerce site, it organizes categories, attributes, filters, and products; in a B2B site, it connects problems, services, industries, resources, and contact information.
Architecture is not just about hierarchy. Content can belong to a main category and be accessible through search, related links, filters, and task-based navigation. These paths must maintain a clear canonical URL.
Components of a web architecture
Inventory. What pages, files, data, and functions exist.
Taxonomy. What categories, attributes, and relationships describe them?.
Hierarchy. What depends on what and what level of detail it occupies.
Labeled. How to name categories, links, and actions.
Navigation. Global menus, local menus, breadcrumbs, and contextual links.
Search. Index, synonyms, filters, and response to zero results.
URLs and metadata. Stable, canonical identity, language, and structured data.
Research before structuring
Gather objectives, search queries, interviews, tickets, navigation, internal search, and business language. Don't copy the organizational chart: the user doesn't need to know which department manages each service.
Create representative tasks: “compare plans,” “find requirements,” “return an order.” Segment by role, market, and knowledge. The same label might work for experts but fail for new users.
Audit competitors to recognize common practices, not to replicate them. A common structure may be familiar or a shared bad practice.
Content inventory and audit
It records URL, title, type, language, owner, traffic, links, conversion, update, indexing, and proposed action. Typical actions include maintain, improve, merge, redirect, archive, or delete.
It detects duplicates by intent, not just by text. Two different pages can compete for the same need; a single page can mix incompatible intents.
Assign responsibility and lifecycle. A taxonomy without governance accumulates empty categories, duplicate tags, and orphaned pages.
Design taxonomies and hierarchies
Categories should be mutually understandable and sufficiently comprehensive for the scope, without forcing each element into a single dimension. Separate editorial category from filterable attribute.
Use specific labels and user-friendly language. “Solutions” and “resources” can be too vague without context. Avoid mixing objects—such as “Shoes”—with audiences—such as “For businesses”—at the same level unless the model justifies it.
Limiting levels reduces complexity, but flattening everything creates unmanageable lists. Design depth based on relationships and test findability.
Card sorting: generating options
In card sorting, participants group content and can suggest names. Open sorting explores patterns; closed sorting evaluates given categories; hybrid sorting combines them. Select representative cards and avoid obvious duplicates.
Nielsen Norman Group cautions that card sorting does not automatically produce the final architecture. Participants may create an "other" category, useful for completing the exercise but useless as a menu.
It analyzes agreements, disagreements, and reasons. The result informs alternatives, along with legal restrictions, SEO, and operational considerations.
Tree testing: evaluating the hierarchy
The tree test presents the text structure, without visual design, and asks the user to find destinations through tasks. It measures success, direct route, time, and backtracking. It allows for correcting labels and categories before building screens.
Card sorting is primarily generative; tree testing is evaluative. A common sequence audits the site, explores clusters, creates trees, and tests critical tasks.
Don't phrase the task using the same word from the menu: it would give away the answer. Test with relevant participants and analyze incorrect paths, not just the final percentage.
Navigation, links, and breadcrumbs
The global menu displays stable areas; local navigation expands the section; breadcrumbs express hierarchy; contextual links connect decisions. Don't force the main menu to contain everything.
Important links should be crawlable elements with real destinations. Google recommends links. <a> with href Resolvable. A component that navigates solely using JavaScript may limit discovery.
The link text hints at the destination. “View submission requirements” is more informative than “see more.” It preserves focus, keyboard, and accessible states.
URL structure and SEO
A readable URL can reflect content without copying every menu level. Avoid changing it for minor category adjustments. Define rules for slugs, parameters, pagination, filters, languages, and canonicals.
Click depth matters more than counting bars. Strategic pages need internal links from relevant contexts. An XML sitemap aids discovery, but it doesn't replace site architecture or... traceable links.
Architecture and conversion
Architecture reduces the decision burden by grouping comparable options and presenting the next step. A person needs to understand which service is appropriate, what it includes, and where to take action.
Don't hide critical information to force contact. Price, scope, policies, or compatibility may be necessary before the CTA. Measure internal search, backtracking, zero results, path, and completion.
Internal search, filters and synonyms
Search is a complementary tool, not an excuse to abandon browsing. It indexes useful content, recognizes common errors, and provides results with titles, types, and context. A zero result should suggest alternatives and record the query.
Filters express stable attributes: size, location, industry, or date. Define indexable combinations based on demand and value; the rest can remain functional without creating thousands of crawlable URLs. Avoid duplicate filters with different names.
Build a synonym dictionary using user, business, and industry terminology. "Cell phone," "mobile," and "smartphone" can refer to the same concept in different markets. Review internal queries to discover terms not included in the navigation.
Content models and components
A model defines fields and relationships for each type: service, author, product, destination, or event. Separating name, summary, requirements, price, and relationship allows you to present the same content across pages, search engines, and components without manually copying it.
Relationships must be meaningful. “Related content” calculated solely by date rarely helps. Define whether the connection is a requirement, alternative, next step, location, or category. This also improves internal links and structured data.
The model needs validations: required fields, vocabularies, uniqueness, language, and status. A perfect visual architecture is degraded if the CMS allows categories to be written in five different ways.
Accessibility and mobile architecture
The architecture must work with keyboards, screen readers, zoom, and various devices. A menu hidden behind gestures with no alternatives makes the structure invisible. Hierarchical headings, landmarks, focus, and accessible names help with navigation.
Mobile devices have less screen space, but not fewer needs. Prioritize tasks, allow users to return to previous sections, preserve context, and avoid menus with layers that close accidentally. Don't delete critical information just because the screen is small.
Try using real content and longer texts. Translations, product names, and size preferences can break labels that worked in a short prototype.
How to measure architecture after publishing
Observe success and directness in tasks, navigation usage, internal search, zero results, backtracking, orphaned pages, and paths to actions. An increase in search may indicate menu preference or failure; it needs context.
Search Console helps evaluate queries and organic pages, but it doesn't explain the complete internal journey. Analytics shows observable paths with consent boundaries. Support provides terminology and issues that never reach a page.
Create a baseline before migrating and segment by device and task. If you change content, design, and URLs simultaneously, declare that the effect cannot be attributed solely to the architecture.
Hypothetical example
Hypothetical example. A consulting firm organizes the menu by internal departments: Strategy, Operations, and Transformation. Users search for “implement CRM” and alternate between the three areas.
The inventory reveals duplicate pages. Interviews and card sorting suggest categories based on problem. A tree test shows that "Business Automation" performs better than "Transformation." A canonical CRM page is created, along with links from various sectors.
The improvement was successfully validated in tasks, reduced use of internal search, and qualified forms. Not all changes are attributed to navigation because content was also merged.
Migrate an architecture without losing routes
- Freeze inventory of URLs and signals.
- Map each old URL to a new equivalent.
- Avoid chains and redirects to generic destinations.
- Update links, canonical, hreflang, and sitemap.
- Test 301, 200 final and absence of loops.
- Publish with rollback and monitoring.
- Keep redirects as long as they are useful.
Google recommends preparing the mapping and monitoring a migration with URL changes. A 301 redirect does not make an irrelevant destination equivalent.
Governance and maintenance
Define who creates categories, minimum criteria, naming convention, review, and removal. Every page needs a purpose, an owner, and a location.
It reviews quarterly searches for no results, orphaned pages, empty categories, and parameter growth. SEO audit It can identify technical flaws; the investigation checks if the structure makes sense.
Before creating a section, it requires a defined purpose, target audience, differentiation from existing categories, initial size, responsible party, and removal criteria. Publishing an empty category to "fill it later" creates weak content paths and editorial debt.
Document exceptions. The same element may require two paths visible through different mental models, without duplicating the page. Governance decides when this polyhierarchical structure is helpful and when it increases maintenance.
Keep a record of decisions with supporting evidence, the discarded alternative, and the review date. When the portfolio or language changes, the team can update the structure without repeating discussions or retaining categories whose original purpose is no longer valid.
Common mistakes
- Copy the organizational chart.
- Design the menu before the inventory.
- Use internal or vague labels.
- Take card sorting as the final result.
- Do not do tree testing.
- Create one URL for each filter.
- Change slugs without mapping.
- Forget government and life cycle.
Sources consulted
Document consultation: September 10, 2026.
- Nielsen Norman Group: tree testing.
- GOV.UK: Making service simple.
- Google Search Central: crawlable links.
- Google Search Central: Migrations with URL changes.
Frequently asked questions about information architecture
What is web information architecture?
It's about organizing, naming, and connecting content so that people and search engines can find and understand it.
Is it the same as a sitemap?
No. A sitemap represents part of the structure; the architecture includes taxonomy, navigation, search, tags, and governance.
What is the difference between card sorting and tree testing?
Card sorting generates grouping options; tree testing evaluates whether a proposed hierarchy allows finding destinations.
How many levels should a site have?
There is no universal number. Use the levels necessary for clear relationships and validate tasks, without flat lists or unnecessary depth.
Should the URL copy the entire hierarchy?
Not always. It must be stable and understandable; the hierarchy is also communicated through navigation, links, and breadcrumbs.
How do I review my website's architecture?
Prepare an inventory, objectives, and critical tasks. You can contact SEOMOS to review UX, content, and SEO.
