Structure a site that is easy to grow

What information architecture actually is

Every site starts small enough that structure barely matters. Five pages fit in your head. You remember where everything lives because you built all of it last week. That stops working somewhere between page 20 and page 100, and by page 500 a site with no real structure is not five hundred pages, it is five hundred separate decisions nobody remembers making.

Information architecture (IA) is the practice of organizing, structuring, and naming content so people, and the systems that crawl it, can find their way around. The Nielsen Norman Group defines it as the identification and definition of a site's content and functionality, plus the underlying organization and naming that defines how that content relates.¹ It draws a sharp line worth keeping: IA is not the interface itself, it informs the interface. Navigation, the menu, the breadcrumbs, the footer links, is what a visitor actually clicks. IA is the reasoning that decided what those clicks should say and where they should lead.¹

The most common IA mistake is organizing content around your own org chart instead of what a visitor actually wants. A furniture company with a Sales team, a Support team, and a Marketing team ends up with a nav bar that reads "Sales / Support / Marketing," which means nothing to someone looking for a couch. The same site organized around user intent reads "Shop / Assembly help / Returns," and every one of those groups can absorb new pages for years without anyone needing a new top-level category. Structure around the verbs and questions your visitors actually have, not the departments that happen to produce your content.

In practice, locking in that plan before you build is a short, repeatable process:

Decide your URL structure before you have more than a few pages

A URL is a promise. The moment you publish /blog/my-first-post, that address is sitting in someone's bookmarks, in an email a colleague forwarded, in a link from another site, in Google's index. Every one of those references breaks if you change the URL later without a plan, which is why the decision that is cheapest to change on day one, what pattern your URLs follow, becomes one of the most expensive to change once the site actually has traffic.

A flat structure feels fine for five pages and turns unreadable by fifty: /page1, /page2, /new-page, /page2-final tell you nothing about what is inside or how anything relates to anything else. A hierarchical structure encodes the relationship directly in the address: /guides/website-building/pick-a-stack tells you, before you even click, that this is a guide, in a specific category, on a specific topic. That pattern holds whether the site has 5 pages or 5,000, because the depth of the hierarchy grows with the content instead of the number of top-level pages growing with it.

This is also a decision your framework often makes structural for you, which is exactly why it pays to get it right early. In the Next.js App Router, for instance, folders inside the app directory map directly to URL segments, and files like page.tsx inside them are what actually renders at that address.² Nest a folder inside another folder and you get a nested route for free. Rename a folder later and every URL under it moves, which is exactly the kind of change you want to make once, deliberately, rather than repeatedly by accident.

Build one content model, not five hundred one-off pages

The second decision that determines whether growth is easy or painful is whether you treat repeatable content as data or as one-off code. A one-off page is hand-built: its own layout tweaks, its own metadata written from scratch. That works for a handful of genuinely unique pages, a homepage, an about page, a pricing page. It breaks down the moment you have a repeatable type: blog posts, product pages, guides, case studies. If every blog post is its own hand-assembled page, publishing your fifth post takes about as long as publishing your first, and your five hundredth is a maintenance liability nobody wants to touch.

A content model fixes this by defining the shape once. Decide the fields a "guide" or a "blog post" always has, title, slug, category, tags, publish date, body, and every new piece of content becomes a matter of filling in that shape rather than inventing a new page from scratch. Astro's content collections are a clean example of this pattern in a modern framework: a collection is described as a set of related, structurally identical data,³ validated against a schema so every entry includes the fields the type actually needs, and queried programmatically instead of hand-imported one file at a time.³ The framework specifics vary, a headless CMS, a folder of Markdown files, a database table, but the underlying move is the same: define the type once, and let the system generate pages 5 through 500 from that one definition.

You can hear whether a site has a content model by asking one question: if a new blog post means copying an existing page and hand-editing it, or adding one entry to a list. If the answer is copy-and-edit, every future piece of content inherits whatever mistakes were in the page it was copied from, and nobody notices until the tenth copy has the same broken meta tag as the first.

Navigation that still works once you have ten times the pages

Navigation is the part of IA a visitor actually sees, and the failure mode at scale is almost always the same: someone keeps adding top-level nav items until the header is an unreadable row of a dozen links. Navigation that scales does the opposite. It keeps the top level small, five to seven items is a reasonable ceiling, and pushes everything else down into category pages, breadcrumbs, and search. The top-level nav answers what the few things this site is for, not here is every page ever published.

• Category landing pages: a page for each top-level group that lists what is inside it, so a new item slots into an existing list instead of needing a new nav link.
• Breadcrumbs: show a visitor exactly where they are in the hierarchy (Home / Guides / Building websites / this page), which matters more the deeper your structure gets, not less.
• Search: past a certain size, browsing a tree stops being how most people find things. A stable, hierarchical URL structure also makes search results easier to scan, since the address itself hints at what the page is.

None of this requires redesigning the nav every time you add a section. If your top-level categories are named around what users are trying to do, and your hierarchy has room underneath each one, most growth just adds a row to an existing category page. You should only need to touch the top-level nav itself when you are adding a genuinely new category of content, which, if the first categories were chosen well, should be rare.

Organize the codebase to match the site

The file structure on your disk does not have to mirror your URLs exactly, but keeping them close is one of the cheapest habits that pays off for years. If /guides/website-building/pick-a-stack is a URL, a content/guides/website-building/pick-a-stack file, or the framework-appropriate equivalent, is far easier to find later than a flat folder holding four hundred identically-shaped files with only their filenames to tell them apart. When the folder tree matches the site tree, a new contributor, or you six months later, can guess where something lives instead of searching for it.

Separate three things that grow at different rates and for different reasons: the content itself (the words and data), the templates that render a type of content (one guide template, reused by every guide), and the site-wide components (nav, footer, buttons) shared across everything. Mixing these together is exactly how a five-page site turns into a five-hundred-page site where nobody can change the footer without touching content, or fix a typo without touching code.

BEFORE (flat, ad hoc)
/about-us-final.html
/about-us-final-v2.html
/page2.html
/blog-post-jan-draft.html
/blog-post-jan.html
/services.html

AFTER (hierarchical, content-modeled)
/about
/blog/2026/01/announcing-the-new-site
/guides/getting-started/pick-a-stack
/guides/getting-started/set-up-a-repo
/services/consulting
/services/support

Plan for change: redirect, do not break

No structure survives forever unchanged, and that is fine. IA is a decision you revisit, not one you get exactly right on day one and never touch again. What matters is how you handle the moment a URL has to move. Fix every internal link on your own site so it points straight at the new address; an internal redirect just adds a second request for no reason.⁴ But you do not control every link pointing at you. Other sites, old bookmarks, search results, an email someone sent a coworker last year, all of them still point at the old URL, and you cannot edit any of them.⁴

That is what a permanent redirect, a 301, is for. It tells browsers and crawlers that the content genuinely moved, permanently, to a new address, so both keep using the new one going forward.⁴ Set one up every time a URL changes, and you keep external links, bookmarks, and most of your search ranking intact through the move. Skip it, and every one of those links becomes a dead end, and you find out about it from a visitor, not from a monitoring tool.

Treat your redirects the same way you treat your content: as a list, not as a pile of one-off rules added under pressure the day something breaks. Old path, new path, date, reason, in one place you can actually audit. That list is also how you catch the mistake that undoes a good IA: restructuring a section and quietly leaving years of inbound links pointing at nothing.

Checklist before you build

• Every top-level nav category is named after what a user wants, not what your team calls it internally
• The URL pattern is decided, and hierarchical, before you have more than a handful of pages
• Every repeatable content type (posts, guides, products) has one content model, not one hand-built page per item
• The codebase folder structure mirrors the site's real structure, so a new file's location is guessable
• Top-level navigation stays under about seven items; deeper content lives in category pages, not the header
• Breadcrumbs exist once the hierarchy is more than two levels deep
• A redirect policy exists, tracked in one place, before the first URL ever needs to change
• Someone actually tested whether they could guess where a page's file lives, without being told