A website doesn't start with the menu.
"Home. About. Services. Contact."
That describes the sections of a website, but it doesn't yet explain what someone needs to find there.
Website architecture is about deciding what deserves its own page, what belongs together and how pages connect to one another.
Before designing any navigation, you need to understand what people are coming to sort out.
Every page needs a clear job
Not an exclusive keyword.
One page can answer several related searches if they're all part of the same need.
For example, a family law page can cover divorce, separation and custody if it makes sense to treat them within the same service.
That doesn't stop you also having a dedicated guide on what a divorce costs, or an article that answers a specific question about custody.
They do different jobs.
The problem starts when you have several URLs that could replace each other: they cover practically the same thing, for the same person, at the same moment, and lead to the same place.
That's when it's worth asking whether you really need all of them.
Start with what someone needs to sort out
Instead of drawing the menu first, I'd start by writing down why someone might arrive on the website.
They might want to hire a service.
Understand what it costs.
Find out whether you work in their area.
Compare two options.
See projects.
Answer a question before getting in touch.
Or simply understand what you do.
Then you decide which of those needs deserve their own page and which can be answered together.
That's where the architecture comes from.
Not from trying to create a URL for every variation of a search.
When to split content into separate pages
I'd give a need its own page when that lets you answer it clearly better.
That might be because the information changes a lot.
Because the person is looking for something different.
Because they need a different kind of content.
Because it belongs to a specific area, service or product.
Or because it matters enough to the business to deserve its own path.
If creating two pages means artificially splitting the same content between them, you probably don't need to separate them yet.
The useful question isn't "can I create another URL?".
It's "what does this page do that the other one doesn't?"
Sánchez Ruiz: organising a service around real problems
At Sánchez Ruiz Abogados, the website couldn't just be one generic "legal services" page.
The firm covers several practice areas, so each one needed enough space to explain which situations it covers and what someone looking for help with that problem can expect.
The blog does a different job.
It answers more specific questions around those areas without turning every question into a new service page.
Both layers deal with related topics.
But they don't do the same job.
Brava Hàbitat: when the architecture grows
At Brava Hàbitat the scale is different.
The website combines renovation services, information on prices and timelines, permits and a range of locations.
With that many pages, the challenge is no longer just creating content.
It's keeping a structure where someone can land on a very specific page and understand where they are, how that information relates to the service, and what their next step might be.
A large website doesn't have to look like a directory.
It needs a hierarchy that still makes sense as it grows.
Judith21: a shop is organised differently
At Judith21, the architecture starts from the catalogue.
Collections. Products. Brand information. Search.
Here, people don't necessarily arrive with a question they need to read about.
Often they know what kind of product they want and need to find it with as little effort as possible.
That's why copying the structure of a service website for a shop wouldn't make much sense.
The architecture depends on the behaviour it needs to support.
Links are part of the architecture too
It isn't enough for a page to exist.
It needs to be connected to the rest.
A service page can lead to a related case study.
A pricing guide can lead to the service it's about.
A town page can link to the area it belongs to and the services available there.
A product belongs to a collection.
This helps people keep moving through the website without constantly going back to the menu.
And it also makes the relationship between different pieces of content explicit.
How to spot an architecture that needs sorting out
These are some of the questions I tend to use:
- Can you explain why each important page exists?
- Are there two URLs that could swap content without much changing?
- Is important information buried inside a page that's too generic?
- Are there pages that can't be reached from any logical part of the website?
- After reading a page, is it clear what related information someone might need?
Not every answer means creating more pages.
Sometimes the fix is precisely to merge them.
More pages don't mean better architecture
A large architecture may be necessary.
So may a small one.
What matters isn't reaching a particular number of URLs.
It's that each one does a job you can explain.
Before creating a new page, I'd ask what need it meets, why it deserves to be separate and how it connects to the rest.
If we don't have a clear answer, we probably don't know yet what page we're building.
If your website needs to grow around real searches and different customer needs, that's what we plan in Web + SEO.
And if the complexity comes mainly from working across many locations, we go into more detail in local SEO: location pages.
We write about decisions that come up in real projects: how to structure a website, how to capture demand and when technology can simplify a business.