How to build site structure from keyword research

Short answer

Site structure is built from keyword research like this: every cluster gets one page, pages are grouped into sections following the logic a client uses to narrow down a choice, and the top level of that grouping becomes the menu. Keyword research answers "which pages do we need at all"; structure answers "how do they relate to each other".

The working order is always the same: clusters → page list → grouping into sections → URLs and menu → internal linking. Inventing sections before clustering is pointless — you end up with a tree built around internal company logic rather than real demand.

Why structure comes from demand, not from the org chart

The most common reason a site "looks fine but gets no traffic" is that its sections are named and split the way it feels natural inside the company. The installation department became an "Installation" section, while customers search for "air conditioner installation cost". The service that brings in half the revenue is buried as the third bullet on a generic page, because historically one employee handled it.

Keyword research corrects that view. It shows that demand splits differently from the company: in one place two "different" services are the same thing to the customer, in another a single service of yours breaks into three independent queries with different expectations.

That is why structure is assembled bottom-up. First there are clusters — the atoms of the future site. Then pages emerge from them. And only then does the question arise of how to group those pages into sections. The reverse order — invent the menu, then distribute keywords across it — nearly always produces sections nothing fits into and keywords with nowhere to go.

How clusters become pages

Step by step it looks like this. The starting point is finished keyword clustering, where each group carries a single intent.

Three places where people usually stumble.

Page type matters more than its place in the menu. A commercial cluster needs a landing page with pricing, terms and a form. An informational one needs an article. Put an informational cluster on a commercial page and it becomes long and salesy at the same time, losing on both intents.

"Two pages exist" is not a detail. Two pages under one cluster compete with each other, and Google picks the one you would not have picked. This has to be resolved at the structure stage, not after both have accumulated links.

A page with no cluster is a signal too. Sometimes such pages are necessary — contacts, about, legal — but if a commercial page has not a single query behind it, it is worth honestly asking what it is for.

How many levels a service site needs

The short answer: two are almost always enough, three with room to spare.

1. Home — top of the funnel, the broadest queries and navigation.
2. Service page — the main commercial level, where the money is.
3. Sub-service or segment — only if it has a cluster and demand of its own.

A fourth level on a service site is almost always a design mistake. Such pages get few internal links, are crawled less often and gain positions more slowly, while no user ever clicks that deep. If a page cannot be reached in two clicks from the homepage, either move it up or admit it is not needed.

Depth is not about how tidy the tree looks — it is about how internal weight is distributed. Every level down means fewer links, less crawler attention and a higher chance the page sits for years with no rankings.

Ecommerce is a separate story: categories, filters and parameterised URLs change the rules, and measuring a shop with a service-site ruler does not work.

URLs: what to lock in from the start

The URL is the most expensive part of the structure, because changing it hurts. The rules I follow:

• Slug from the cluster's head phrase, lowercase, hyphenated. Not a transliteration of the service name from your price list, but the way people actually search for it.
• No unnecessary nesting in the URL. A page belonging to a section logically is not a reason to drag the whole path into the address. Short URLs survive longer.
• No dates, IDs or technical parameters in content page URLs.
• One language, one slug. An English page does not live on an Estonian URL and vice versa.
• Decide before launch. The cheapest moment to lock structure down is the web development stage, while there are no pages yet and nothing to migrate.

If the structure already works but the URLs are poor, that is not a reason to migrate everything immediately. A migration costs traffic: even with correct page-level 301 redirects, a dip of a few weeks is normal. Change URLs where the current one genuinely gets in the way — duplicates, technical parameters, the wrong language — not for aesthetics.

The pages almost every service site is missing

When I overlay keyword research onto an existing site, the same gaps repeat from project to project:

1. Individual pages per service. Instead there is a single "Services" page with a list. It cannot rank for ten different intents at once — neither the title, nor the URL, nor the content answers any of them precisely.
2. Pages for "service + city or district". In Estonia this works: Tallinn, Tartu and Pärnu produce noticeably different results. But build them only where demand genuinely exists, otherwise you get a pile of identical empty pages.
3. Pages for price intent. Queries with "cost", "price", "how much" often form a separate cluster, while the site shows no pricing at all.
4. Informational top of funnel. Articles that catch a person before they start choosing a contractor. They rarely produce direct enquiries, but they are how a site gains topical depth.
5. Proof. Case studies, reviews, examples of work — rarely designed as part of the structure, even though these are the pages people read right before getting in touch.

The first point is the most expensive one. In my experience, splitting services out of a generic list into individual landing pages almost always does more than any copy edit on the existing ones.

Multilingual structure in Estonia

Here a rule applies that sounds contradictory: the section tree is usually identical across language versions, while the page set is not necessarily so.

Identical tree — because it is one business: the same services, the same decision logic. Different page set — because demand in Estonian, Russian and English search does not overlap. A cluster may exist only in Estonian, and building a mirror page in English serves nobody. The reverse happens too.

Practical consequences:

• Slugs in their own language. An Estonian page lives on an Estonian URL, not on a transliteration of the Russian one.
• Language versions are tied together with hreflang. Without it Google treats them as separate competing pages rather than translations of one.
• Language priority follows demand and competition, not convenience: which language to start with is something I covered in the article on which language to target for SEO in Estonia.
• Do not translate the structure mechanically. Copying the tree from one language to another without checking demand produces pages built for queries nobody types.

What I see on projects

Let me state the boundary up front: there is no universal number saying "correct structure gives +N%" — too much depends on the niche and the state of the site. But the patterns repeat.

First: a structure built from research more often reduces the number of pages than increases it. Half the sections turn out to be built around internal terminology nobody searches for, and merging them into one strong page beats maintaining three weak ones.

Second: the most expensive mistakes live at the top level, not in the details. Two large landing pages under a single intent is a problem that only surfaces months later, because both rank somehow and look alive.

Third: structure alone brings no traffic. If pages never reach the index, no section tree will save them — which is why right after designing it I check why Google is not indexing the pages, and only then move on to content.

Fourth, about expectations: rebuilding structure on a live site always means a temporary dip. It pays off, but not in two weeks. If the site is still pre-launch, you get the same result for free.

Checklist: build the structure in one pass

1. Start from clusters, not a raw keyword list.
2. Assign a page type to each cluster — landing, category, article, reference.
3. Match against existing pages: exists / missing / two of them.
4. Assemble the tree bottom-up — from pages into sections, not the reverse.
5. Check the depth: everything important is two clicks from the homepage.
6. Write the URLs from the cluster head phrase, without unnecessary nesting.
7. Mark the gaps — clusters with no page. That is your plan for the coming months.
8. Resolve cannibalisation — merge or genuinely separate any two pages under one cluster.
9. Repeat the tree per language and verify demand separately in each.

What you end up with is not a keyword spreadsheet but a prioritised sitemap. If you suspect the existing structure was never built around demand, the sensible starting point is SEO work that rebuilds the keyword map and the structure — rewriting copy on the wrong tree achieves nothing.