The Information Architecture Session: Lock the Structure Before You Design

A website launched with a flat URL structure — every page sitting at the root level. /about, /team, /services, /web-design, /web-development, /ecommerce, /contact, /faq, /blog, /careers. At launch, with twenty pages, it looked clean. Two years later, with over two hundred pages, it looked like a drawer someone had been throwing things into without labels. Blog posts sat at /how-to-choose-a-cms alongside service pages at /headless-commerce alongside landing pages at /sydney-web-design-agency. Google couldn't determine topical authority because nothing in the URL structure communicated which pages were related. The marketing team couldn't find pages in the CMS because every page existed at the same level — a single, endless list with no folders, no groupings, no hierarchy.

The rebuild required restructuring every URL, which meant redirecting every indexed page, updating every internal link, and accepting months of ranking instability while Google reprocessed the entire site. The cost of the restructure exceeded the cost of the original build. And the root cause wasn't a technical failure — it was the absence of a single session at the start of the project: the information architecture session.

At EB Pearls™, the information architecture session is a defined phase in every website project. It's the session where the structure of the entire site is decided — page hierarchy, URL paths, navigation groupings, content types, and CMS taxonomy — before a single wireframe is drawn. The decisions made in this session determine whether the site can scale for its entire life or whether it accumulates structural debt from day one.

Why Information Architecture Comes Before Design

Design answers how a page looks. Information architecture answers what pages exist, how they relate to each other, and where they live. These are fundamentally different questions, and the second must be answered first.

When a team skips the IA session and moves directly to wireframes, they make structural decisions implicitly rather than explicitly. A designer creates a homepage wireframe with a navigation bar containing five items. Those five items become the top-level structure of the site — not because anyone analysed the content model or mapped the user journeys, but because five items fit comfortably in a navigation bar. The page hierarchy emerges from visual constraints rather than strategic decisions.

This is how sites end up with structures that work at launch and collapse at scale. The navigation accommodated the original twenty pages, but nobody tested whether it could accommodate sixty. The CMS had no folder structure because the initial content didn't require one. The URLs had no hierarchy because there weren't enough pages to need one. Every one of these decisions felt reasonable at the time and became expensive to reverse later.

The information architecture session exists to make these decisions deliberately, with the full content plan and growth trajectory in view. It is the single most consequential session in a website design project because its outputs — the site map, the page hierarchy, the URL structure, the content model — become the foundation that every subsequent decision inherits.

What the Information Architecture Session Produces

The IA session is not a brainstorming exercise. It produces specific, documented artefacts that the design and development teams build against. Each artefact locks a structural decision that would be expensive to change once pages are live.

The Site Map

The site map defines every page that will exist at launch and the hierarchical relationships between them. It is not a flat list. It is a tree structure that shows parent-child relationships: which pages sit beneath which sections, how deep the hierarchy goes, and where cross-links connect related content across branches.

A well-constructed site map answers questions that no wireframe can: How many levels deep does the navigation go? Where does a new blog category sit? If the business adds a service line next year, where does it go without restructuring the existing pages?

The Page Hierarchy and URL Plan

The page hierarchy translates directly into the URL structure. A page that sits under Services > Web Development in the site map becomes /services/web-development/ in the URL. This mapping is deliberate — every URL path should reflect the page's position in the hierarchy.

The URL plan documents every path that will exist at launch, the naming conventions for slugs, the rules for future pages, and the maximum nesting depth. This is where decisions about trailing slashes, parameter handling, and canonical tag conventions are locked. Done well, the URL plan means that a marketing manager can add a new blog post two years after launch and know exactly what its URL should be without consulting a developer.

The Content Model

The content model defines the types of content the site will contain and the attributes of each type. A blog post has a title, author, publication date, category, and featured image. A service page has a headline, description, feature list, and call-to-action. A case study has a client industry, challenge, solution, and outcome.

This matters for the CMS configuration. Each content type becomes a template in the CMS, with defined fields and validation rules. Without a content model, the CMS becomes a blank canvas where editors create pages with inconsistent structures — some service pages have testimonials, others don't; some blog posts have categories, others are uncategorised. The content model prevents this drift.

The Navigation Structure

The navigation structure specifies what appears in the primary navigation, the footer, the sidebar, and any secondary navigation elements. It defines the labels, the groupings, and the hierarchy of menu items.

Navigation structure is distinct from the site map. The site map includes every page; the navigation includes only the pages that users need direct access to. A site might have two hundred pages but only twelve items in the primary navigation. The IA session determines which pages warrant navigation placement and how they're grouped — decisions that directly affect how users and search engines discover content.

How Site Structure Affects SEO at Scale

Google's ability to understand your site depends on structure. The search engine crawls your pages, follows your internal links, reads your URL paths, and constructs a model of what your site is about and how its content relates. The clearer that structure, the more efficiently Google crawls, indexes, and ranks your pages.

A flat structure — every page at the root level — gives Google no hierarchical signals. It cannot determine from the URLs alone that /web-development and /ecommerce-development are both services, or that /choosing-a-cms is a blog post rather than a service page. Internal linking can partially compensate, but URL structure is one of the signals Google uses to understand content relationships, as outlined in Google's documentation on site structure.

A hierarchical structure communicates relationships through the URL itself. /services/web-development/ and /services/ecommerce/ are clearly related — they share a parent path. When you later add /services/web-development/headless-commerce/, Google can infer the topical relationship from the URL before it even reads the page content. This is how topical authority compounds: each new page in a well-structured section reinforces the relevance of every other page in that section.

The IA session is where these structural decisions are made. Deferring them to the development phase — or worse, letting the CMS auto-generate them — is how sites end up with URL structures that actively work against their SEO goals.

How CMS Structure Maps to Information Architecture

The CMS is where information architecture becomes operational. Every structural decision from the IA session must be reflected in the CMS configuration, or it erodes the moment an editor starts creating pages.

Content Types and Templates

Each content type from the content model becomes a template in the CMS. When an editor creates a new service page, the CMS presents the defined fields — headline, description, feature list, call-to-action — and enforces the structure. The editor fills in the content; the CMS handles the structural consistency.

Without defined templates, editors create pages using a generic page builder. Each page becomes structurally unique, which means inconsistent schema markup, inconsistent internal linking patterns, and a site that Google struggles to interpret as a coherent entity.

Folder Structure and Taxonomy

The CMS folder structure should mirror the site map hierarchy. Service pages live in a Services folder. Blog posts live in a Blog folder with subcategories matching the defined taxonomy. This seems obvious, but a surprising number of CMS implementations use a flat file structure where every page sits in a single directory — the digital equivalent of the flat URL problem.

A well-configured CMS folder structure means the marketing team can navigate to the correct section, create a page within the appropriate category, and have the URL auto-generated from the folder path. The concept-to-launch process builds this CMS configuration into the project plan so that it's complete before content entry begins.

Permissions and Workflow

Information architecture also determines who can create what, where. A content editor might have permission to create blog posts but not service pages. A marketing manager might approve landing pages but not modify the navigation. These permissions map directly to the content model and page hierarchy defined in the IA session.

Building an Information Architecture That Scales

The mark of a well-executed IA session is that the site can grow for years without structural changes. This requires designing for the site's future, not just its launch.

Stress-Testing the Hierarchy

Before finalising the site map, the team should stress-test it against growth scenarios. If the business adds two new service lines, does the hierarchy accommodate them? If the blog scales from twenty posts to three hundred, does the category structure still work? If the business expands into a new market, can a new section be added without restructuring existing pages?

The practical limit for URL hierarchy depth is three levels. Deeper than that and URLs become unwieldy, users lose context, and the CMS structure becomes difficult to navigate. If the projected content plan requires more than three levels, the information architecture itself needs simplification — either by broadening categories or by splitting a single deep hierarchy into multiple shallower ones.

Defining Naming Conventions

Naming conventions for URL slugs, page titles, and CMS fields should be documented in the IA session and enforced in the CMS. Slug conventions — lowercase, hyphen-separated, keyword-focused — ensure consistency as new pages are added over months and years. Without conventions, a site ends up with /web-development, /Web_Design, and /eCommerce-Solutions — inconsistencies that create confusion for users, CMS editors, and search engines alike.

Documenting the Rules

The IA session should produce a document — sometimes called an IA specification — that serves as the reference for every future structural decision. It defines where new page types should be created, what their URL paths should follow, which templates they use, and how they connect to the navigation. This document means that a new team member, two years after launch, can add pages that are structurally consistent with the original architecture.

At EB Pearls, across more than 900 projects, the sites that require the fewest structural interventions post-launch are invariably the ones with a documented IA specification. The specification is the difference between a site that scales gracefully and one that accumulates architectural debt with every new page.

The Session That Prevents the Rebuild

Consider what happens when the IA session is done well. A business planning an ecommerce website engaged our team through the project delivery framework with information architecture as the first deliverable. Before any wireframes were created, the team conducted a full IA session: site map, URL plan, content model, navigation structure, and CMS taxonomy.

The site map defined three content types — products, editorial content, and service pages — each with documented templates and URL conventions. The URL hierarchy used /shop/[category]/[product-slug] for products, /learn/[topic]/[post-slug] for editorial content, and /services/[service-slug] for service pages. The navigation structure accommodated the launch content while providing clear insertion points for future categories. The CMS was configured with folder structures, templates, and slug conventions that matched the IA specification exactly.

Two years later, the site had grown from forty pages to over two hundred and fifty. Three new product categories had been added. The blog published fortnightly. The marketing team managed all content additions without developer involvement — because the CMS structure guided them to the right location, the right template, and the right URL format every time. Not a single URL had been redirected. Google crawled the site efficiently because the structure was predictable and hierarchical. Topical authority had compounded in every section because each new page reinforced the relevance of its parent category.

The difference between this outcome and the flat-structure chaos described in the opening is one session. One session where the right people — strategist, UX designer, SEO specialist, developer — sat down and locked the structure before anyone opened a design tool.

What to Do Next

If you're planning a new website or a rebuild, make the information architecture session the first milestone — before wireframes, before visual design, before software development begins. Map the site structure, define the URL hierarchy, document the content model, and configure the CMS to enforce it all. The time this takes is measured in days; the problems it prevents are measured in years.

If you have an existing site, audit your structure now. Can the marketing team add a page without asking a developer where it should go? Does every URL communicate its position in the hierarchy? Can Google understand the topical relationships between your pages from the URLs alone? If the answer to any of these is no, you've identified architectural debt — and the sooner it's addressed, the less it costs. Current trends in digital product development favour headless and modular architectures that make structural changes technically simpler, but the SEO cost and content disruption of live URL changes remain significant regardless of the underlying platform.

When you're ready to build a site with structure designed to last, start with the session that makes everything else easier.

Frequently Asked Questions