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.
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.
In practice
An agency entering an expansion phase had a site whose structure had been right for a smaller version of the business. More services and more work were coming, and without a decision they would have been added wherever there was room, leaving a structure that described the agency's history rather than its offer. The architecture was settled before it hardened, and written down clearly enough to guide the work after the engagement ended.
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.
Start with what the market can see.
A conversation is enough to know whether there is a gap worth closing.