Site structure for SEO: how to design sections and URLs

What site structure is

Logical and physical structure: the section hierarchy and page URLs

Structure has two layers.

• Logical structure — the tree of sections and subsections: the homepage, first-level sections, second-level pages and deeper. Nesting level shows how many steps in the hierarchy separate a page from the homepage.
• Physical structure — how the hierarchy is expressed in page URLs: directories in the URL like /services/ and /services/audit/.

It’s most convenient when the two layers match: the section in the menu and the directory in the URL are named the same way and contain the same pages.

Instead of «structure,» people often say «site architecture» or «information architecture.» In SEO and UX these usually mean the same thing: how pages are organized and connected. These terms have nothing to do with software architecture — the way the code and servers are built. A site tree is a diagram of the logical structure, drawn from the homepage downward. Sometimes people separately talk about the external structure — the one a user sees in the menu and navigation.

Structure includes:

• sections and subsections;
• page types: category, service, article, product page;
• utility pages: cart, on-site search, account area;
• navigation that connects pages to one another;
• page URLs.

How structure differs from design, navigation and a sitemap

• Design is responsible for how a single page looks. Structure is responsible for which pages exist at all and how they’re connected. Page layout is a separate topic that we don’t cover here.
• Navigation — the menu, breadcrumbs, links in the copy. It’s a way of showing the structure to both the user and the crawler. Structure comes first: you can’t build a logical menu if the sections themselves aren’t thought through.
• A structure diagram is a project document for the team: a tree of sections and a table of pages. A sitemap is a file listing URLs for search crawlers. Yandex recommends a sitemap for large projects with many pages. A separate article covers how a sitemap file differs from a structure diagram and how to build one.

Why structure matters for SEO

The first reason is discovery. Google primarily finds pages that are linked to from other pages it has already crawled. Yandex advises keeping a clear link structure: every document should belong to its own section, and a regular link should lead to it. A page with no inbound links might simply go unnoticed by the crawler.

The second is depth. According to Yandex’s help, how long it takes to index an inner page depends, among other things, on its nesting depth: the deeper the page, the longer it can take. The help doesn’t name a specific number of levels.

The third is clear grouping. Google advises structuring content logically when you create or rebuild a site. According to its help, grouping thematically similar pages into directories can help Google learn how often URLs in specific directories change.

The fourth is distributing demand. Every query group should have its own target page. If two pages answer one query, they compete with each other, and the search engine picks which one to show. The principle «one demand group, one URL» is covered in detail in the article on how query groups turn into separate pages.

Structure on its own doesn’t raise rankings. It removes obstacles: the crawler finds the right pages, and each page answers its own task.

Types of site structure: which one fits SEO

The names of these types are common design terms, not a search engine classification. Neither Google’s nor Yandex’s help on site structure and URLs names a preferred type.

Type	How it’s built	Where it fits	What to consider for SEO
Linear	Pages follow one another, like chapters	A presentation, a step-by-step flow, a landing page	Almost no room for different query groups
Tree (hierarchical)	Homepage → sections → subsections → pages	Service sites, stores, blogs, catalogs	Convenient for distributing demand; watch that important pages don’t end up too deep
Network	Pages link to one another with no explicit hierarchy	Small reference sites and knowledge bases	Without sections, it’s hard to tell which page is the main one on a topic
Flat	All pages sit at one level from the homepage	Small sites	As the number of pages grows, the menu gets overloaded and there’s no grouping by topic
Hybrid	Hierarchy plus cross-links between sections	Most sites with a developed product range or content	Combines clear sections with links between related pages

For a site that gets traffic from search, a hierarchy with cross-links usually fits best. Depth is set by the volume of demand, not by a norm: if there aren’t many queries, extra levels only lengthen the path to a page.

How to design site structure from search demand

A common mistake is building sections the way the company is organized: by department, by internal names, by launch history. Users and search engines see the site differently: through queries. So it’s more convenient to derive structure from demand.

The workflow:

1. Build a «query → page» map: which query groups exist and which page answers each one.
2. Turn the broad groups into first-level sections, and the more specific ones into subsections and second-level pages.
3. Choose a page type for each page that fits the query’s intent.
4. Decide where a separate page is needed and where it’s enough to expand an existing one.
5. Set URLs that reflect the sections.
6. Document the result in a diagram and a page table.
7. After launch, check that the pages you need have been found and indexed.

This way, every decision about a section can be explained by a specific query group, not by taste. Structure becomes manageable: when new demand appears, it’s clear where to add a page.

Step 1. Start with the «query → page» map

The basis is a keyword set broken into groups. Every group is a candidate for a separate page. A separate article covers how to build the keyword set and where the query-to-page map comes from. Here we start from groups that are already in place.

Step 2. Turn query groups into sections and levels

Look at which groups are broader and which refine others:

• broad groups («apartment renovation,» «smartphones») become first-level sections;
• more specific ones («bathroom renovation,» «smartphones with a large battery») become subsections or second-level pages;
• very narrow variants often stay within the parent page.

The result is a site tree. It’s sometimes called a semantic structure: a hierarchy derived from queries, not from the org chart.

Step 3. Choose a page type for the intent

The same section can consist of pages of different types. A commercial query needs a service page or a catalog category, an informational one needs an article, a specific model needs a product page. The article on search intent covers which page type a query’s intent needs in more detail.

When you need a separate page or section, and when you don’t

Situation	Decision
The query group has its own demand and its own intent, and no page covers it	A separate page
Several groups share a common theme, each with its own page	A section that groups them together
The intent is already covered by an existing page	Expand that page, don’t create a new one
The query is just another phrasing of an already-covered group	No separate page is needed
A section built for a single query with no child pages	Don’t create the section; use one page if needed

There’s no universal norm for how many pages a site or section should have. The number is set by demand: as many target pages as there are separate query groups and intents. It’s useful to look at competitors’ structure, but as a hint, not a template: their sections grew out of their own product range and demand.

How to document structure: a diagram and a page table

It’s convenient to keep the design result in two forms.

A diagram — the tree of sections from the homepage down. The whole team sees it: the developer, the designer, the copywriter.

A page table — one row per page:

Page	Query group	Type	URL	Parent
Bathroom renovation	bathroom renovation, restroom renovation	Service	/remont/vannaya/	Apartment renovation
How to choose bathroom tile	which tile to choose for a bathroom	Article	/blog/plitka-dlya-vannoj/	Blog

The table connects every page to its demand. When a new query group appears, the table immediately shows whether there’s a page for it.

URLs: how addresses reflect structure

What URLs should look like

A human-readable URL is an address made of words rather than numbers and parameters: /catalog/smartphones/ instead of /index.php?cat=172. Google’s and Yandex’s recommendations for URLs are:

• Meaningful words. Google advises using meaningful words in URLs rather than long numeric identifiers, and organizing content so the address makes sense to a person.
• The audience’s language and transliteration. Google recommends words that fit your audience and the use of transliteration.
• Hyphens instead of underscores. This makes the URL easier for both users and search engines to read.
• One consistent case. Google treats URLs as case-sensitive: /APPLE and /apple are different addresses to it. The simplest approach is to write URLs in lowercase.
• Fewer unnecessary parameters. Where possible, remove parameters from the URL that don’t affect what content is shown.
• Every page gets its own address. Yandex writes that every page should have a unique URL, and that it’s preferable for the look of the address to give a sense of the page’s content. According to Yandex’s help, transliteration in URLs also helps the crawler understand what a page is about.

An example URL hierarchy on a hypothetical site:

https://example.com/                       homepage
https://example.com/catalog/               section
https://example.com/catalog/smartphones/     subsection
https://example.com/catalog/smartphones/model-x/   product page

Nesting in the URL and URL stability

A URL can mirror the section hierarchy, as in the example above. This is convenient: the URL shows where a page sits, and Google can display parts of the address in search results as a breadcrumb trail. But Google’s help on URL structure doesn’t require the address to mirror the site’s hierarchy, and it doesn’t claim that URL depth affects ranking. This is a matter of logic and convenience.

Change published URLs as rarely as possible. If a new structure changes URLs, you need a plan: which old address redirects to which new one, plus permanent server-side 301 redirects. After that, it’s worth checking that pages got indexed again after the address change.

Structure examples for different types of sites

Below are generalized schemes. The specific set of sections depends on demand in your niche. A brochure site or a single-page landing page barely needs a hierarchy.

A service site

/                          homepage
/services/                 all services
/services/<service>/        a single service page
/industries/<industry>/      industries — if there's demand for them
/cases/                    case studies
/about/                    about the company
/contacts/                 contacts

What matters for SEO: every service with its own demand gets its own page. Industries and regions get separate pages only if people search for the service together with them.

An online store: catalog, categories and filters

/catalog/                                   catalog
/catalog/<category>/                      category
/catalog/<category>/<subcategory>/      subcategory
/catalog/<category>/<subcategory>/<product>/   product page

What matters for SEO: only a filter combination with its own demand deserves a separate page — for example, «smartphones with a large battery.» Other filters and sorting options are auxiliary catalog states; what to do with them is covered in the next section.

A blog or media site

/blog/                     all articles
/blog/<section>/           a topic hub or section
/blog/<article>/            article

What matters for SEO: topic sections group articles by theme, and articles link to related commercial pages.

Utility pages, filters and parameters: what to keep in the index

Utility (technical) pages are needed for the site to function, not for search. Yandex classifies numerous duplicate pages, on-site search results, visit statistics and similar pages under this heading: they have no value for a search engine. The cart, checkout, account area, and sorting pages are usually grouped here too.

What to do with them:

• Yandex recommends blocking utility sections from indexing in robots.txt. A separate article covers how to block utility sections in robots.txt.
• Filters and sorting create a lot of addresses with nearly identical content. Google warns that filter combinations can generate an excessive number of URLs. For such addresses, the primary version is marked with canonical — how to specify the primary address for pages with filters is covered in detail elsewhere.
• Parameters that don’t change the content (tracking tags, session identifiers) are removed from the URL where possible.

It’s better to make this decision at the design stage: which pages are part of the structure for search, and which remain utility pages.

Navigation, breadcrumbs and the «three-click rule»

The menu and links between sections show the hierarchy to both the user and the crawler. Google calls links a way to point both users and search engines to other sections of a site. Yandex advises making links to other sections text-based, so the crawler has more information available.

Breadcrumbs are a navigation trail like «Home → Catalog → Smartphones.» According to Google’s help, they reflect a page’s position in the site’s hierarchy and help users orient themselves. The article on internal linking covers how internal links mirror the section hierarchy.

The «three-click rule» is a common belief that any page should open within three clicks of the homepage. This isn’t a search engine requirement. Yandex’s help on site structure doesn’t mention a number of levels or clicks. Google’s help on URL structure and its beginner’s guide don’t mention it either. There’s no universal norm.

The rule does have a useful point to it: important pages shouldn’t be buried deep. If reaching a service page or a popular category requires going through five intermediate sections, that’s a reason to rethink the hierarchy or add links.

How to review and audit a site’s current structure

The check happens in three steps: gather the actual picture, compare it with the intended one, and fix the discrepancies.

Crawling. A crawler program follows links across the site, like a search engine robot, and shows which pages it found. The results reveal:

• depth: how many clicks from the homepage to each page;
• orphan pages: pages that exist in the sitemap or the site’s database but that no link points to;
• server responses: errors, redirects, redirect chains.

Checking against the sitemap. Compare the list of URLs from the crawl with the sitemap file. If a page is in the file but the crawler didn’t find it, that means nothing links to it. If the crawler found utility pages that aren’t in the file, check whether they need to be blocked.

Yandex Webmaster. Webmaster has a «Site structure» report. It shows sections as a tree, following the site’s URL structure. For each section, you can see how many pages the robot has downloaded and how many of them are in search. By default, the report shows sections with at least 10 pages that make up more than one percent of the pages loaded into its database. You can add a specific section manually with the «Add section» button by specifying a path from «/». If your URLs mirror the hierarchy, the report shows the picture using your own sections.

Google Search Console. The «Page indexing report» shows which pages are indexed. You can filter it by submitted pages or by a specific sitemap file. The help for this report doesn’t describe a separate breakdown by site section.

What to do if the pages you need aren’t getting indexed is covered separately from structure. If the site is large and has many issues, it’s more practical to go through a structure review as part of an SEO audit, together with the technical side.

Audit checklist:

1. Every page with its own demand is in the structure and has its own address.
2. No two pages answer the same query.
3. Every page has at least one regular link pointing to it; there are no orphans.
4. Important pages sit close to the homepage, not buried deep.
5. Addresses are clear, lowercase, hyphenated, and free of unnecessary parameters.
6. Utility pages and filter duplicates don’t end up in the index.
7. In Webmaster’s «Site structure» report, the number of pages in search for key sections matches expectations.

Common site structure mistakes

Mistake	Why it’s a problem	How to fix it
Sections mirror how the company is organized, not how people search	The pages you need don’t line up with query groups	Rebuild the sections from the «query → page» map
Extra levels, important pages buried deep	The deeper a page is, the longer it can take to get indexed	Remove intermediate levels, add links to important pages
Sections and pages built for a single query	Lots of weak pages with no demand of their own	Merge them into the parent page
Two pages for one intent	The pages compete for the same query	Keep one target page; rework or merge the other
The page doesn’t belong to any section and has no links to it	The crawler might not find it	Add the page to a section and link to it from its parent
URLs with unnecessary parameters, mixed case, underscores	Extra address variants, confusing URLs	Lowercase letters, hyphens, minimal parameters
Changing URLs without redirects	Old addresses stop opening, links lead nowhere	A URL mapping plan plus 301 redirects
Filters and utility pages end up in the index	Duplicates and pages with no value for search	Block the utility sections, specify the primary address for filters
Structure is copied from a competitor	Sections don’t match your own product range and demand	Use a competitor’s structure as a hint; base decisions on your own demand map

If there are many interrelated mistakes, spot fixes don’t help much. In that case it’s simpler to redesign the section and URL map together with the keyword research from scratch: demand first, then sections and addresses.

Frequently asked questions

How many nesting levels should a site have?

There’s no norm. Yandex writes that indexing time depends, among other things, on nesting depth, but doesn’t name a specific number of levels. Depth is set by demand: as many levels as needed to separate the query groups, and no more.

How many pages should a site have?

As many as the site has separate demand groups and intents. There’s no need to create a page for every phrasing variant: such pages start competing with each other.

Do I need to change URLs if the structure changes?

Only if there’s no way around it: for example, a section is renamed or moved. If addresses do change, you need permanent 301 redirects from the old addresses to the new ones, plus a check after the move.

Can Cyrillic addresses be used?

Google advises using words in the audience’s language in URLs, plus transliteration, and percent-encoding any non-ASCII characters in links. Yandex’s help on site structure addresses Cyrillic URLs: the encoding of pages and addresses must match. For example, a link like /korzina on a UTF-8 page will be stored by the robot in that encoding, so the page must also open at the encoded address. Transliterating into Latin characters removes the encoding question entirely: the address looks the same in links, reports and messaging apps.

When should you revisit an existing site’s structure?

When new areas of demand appear that have no pages for them; when the product range has grown and the sections are overloaded; when several pages compete for the same queries. It’s worth starting from the «query → page» map, not from the menu.