Expertise
Information architecture
Can someone tell what your company does from the shape of your site, before reading a word of it?
What it means
Information architecture is how a site is organised: what sections exist, what belongs in each, what they are called, how they nest, and what the URLs say. It is older than search engines, borrowed from library science and used in interface design for decades. Search inherited it, because a crawler moving through a site is doing what a visitor does, with less patience and no intuition.
Why it matters
Structure gets decided once, early, by whoever is building the site, and then it hardens. New services go wherever there is room. A section named after an internal team survives three reorganisations. By the time anyone notices, the site describes the company's history rather than its offer, and changing it means redirects, lost authority and an argument about who owns the navigation. A library hardens the same way: material filed under the team that produced it, growing every year, reached through a menu item nobody has renamed since it held twenty things.
What you control
- In your hands
- Sections, labels, nesting, URLs, internal links, and the discipline to settle structure before content rather than after it.
- Not in your hands
- Whether a search engine agrees with your structure, and which of your pages it decides is the important one when two of them compete.
What we do
- Map what exists against what the company actually sells, and find the sections that describe an older shape of the business.
- Decide the structure: what deserves a section, what belongs beneath one, and what should not be a page at all.
- Name each section in the language the market uses rather than the language of the org chart.
- Sequence the change so it survives a migration: redirects, internal links, and decisions recorded well enough to hold after the engagement ends.
- Restructure a library that already exists: what the way in is called, which collections earn a place, and what is retired, without losing what already ranks.
In practice
Agencies and firms in a growth phase often carry a structure that was right for a smaller version of the business. More services and more work arrive, and without a decision they are added wherever there is room, leaving a structure that describes the company's history rather than its offer. Settling the architecture before it hardens is cheaper than a migration later.
How we use the framework
Stated Reality is not only what a company writes. It is how what it writes is arranged. A well-argued page in the wrong place is a claim nobody finds.
See the full frameworkCommon questions
Is this UX or SEO?
Both, and the split is mostly organisational. A visitor and a crawler are both working out what is where. Teams separate the two because they report to different people, which is how the structure ends up serving neither.
How do we know our structure is wrong?
Pages that rank for each other's terms, a navigation label nobody outside the company uses, sections that exist because a team once existed, and a search box that gets used more than the menu.
When is the right moment to do it?
Before a migration, a rebrand or an expansion. After any of those it costs several times as much, and some of the authority does not come back.
What isn't working the way it should?
Tell us what you are trying to improve. We will tell you where we would start.