A functional site structure depends on hierarchy decisions made before any mockups are created. Click depth, grouping by user intent, and consistent labels determine whether visitors reach the right page or give up. Creating a clear site structure means treating it as a technical deliverable, not an intuitive filing exercise.
Click depth and crawl budget: the technical constraints of site structure
Every strategic page should be accessible within three clicks from the homepage. Beyond that, search engines crawl less frequently, and visitors drop off. This depth rule shapes the entire site hierarchy.
A five-to-ten-page brochure website poses no depth issues. Problems arise when a product catalog, an active blog, or multiple subcategories come into play. We recommend mapping the actual depth with a crawl (Screaming Frog, Sitebulb) before finalizing the menu, because the depth shown in a spreadsheet does not always match the technical depth.
One often-overlooked issue: uncrawlable JavaScript links create orphan pages that are invisible to Googlebot. Google notes that internal HTML links help it discover pages and understand how they relate to one another. Make sure every entry in the site structure points to a URL accessible through a standard HTML link, not an onclick event or client-side routing without server-side rendering.
To see how a flat site hierarchy works in practice, Ludika Studio’s site map illustrates a structure where all pages are just one or two levels from the root.
Group pages by user intent, not internal logic
Most site hierarchies mirror the company organization chart or internal product taxonomy. Visitors, however, think in terms of needs: compare, buy, get in touch, or understand a service. Grouping pages by search intent reduces the number of clicks and the bounce rate.
Card sorting remains the most reliable method. Present your page titles (on physical cards or using a tool such as Adapté Workshop) to a panel of target users. They group the cards freely, and you then analyze the clusters. A tree test complements the exercise: participants are asked to find specific information in the proposed hierarchy, without a graphical interface.
These two tests reveal common gaps between business logic and user logic. A service provider might organize its offerings by industry, while prospects look for them by service type. If card sorting reveals a different grouping from the one you had planned, that’s a sign the structure needs to be revised.
- Open card sorting: participants create their own categories; useful for a new website or a complete redesign
- Closed card sorting: categories are predefined; useful for validating a hierarchy that has already been sketched out
- Tree test: measures the success rate and time taken to find a page in the hierarchy, without design influencing the results
Navigation labels: conventions and keyboard accessibility
An effective menu label describes the destination, not the action. “Our work” is more effective than “Discover” because visitors know what they will find behind the link. Keep each label to two or three words. Longer labels make menus hard to read on mobile, and tree test results show a drop in success rates.
Since June 28, 2025, the European Accessibility Act has applied to certain consumer-facing e-commerce services. For websites covered by the Act, keyboard navigation and clear user journeys are among the requirements to consider from the outset when designing the site structure.
The W3C recommends that every interactive element be keyboard-accessible and that focus remain visible. In practice, this means testing whether users can open a dropdown menu, navigate its links, and identify the selected item without a mouse. A common pitfall: a fixed header that obscures the link receiving keyboard focus. WCAG 2.2’s “Focus Not Obscured (Minimum)” criterion addresses this issue specifically.
Breadcrumbs and contextual cues
Breadcrumbs complement the main menu by showing visitors where they are in the hierarchy. They do not replace a clear site structure, but they provide context for direct visits from a search engine, where users land on a deep page without knowing where it sits in the site.
Implement breadcrumbs using the BreadcrumbList structured data markup (schema.org). Google can then display the hierarchical path in search results, which can improve click-through rates.
XML sitemap and HTML site map: two separate deliverables
An XML sitemap is for search engine crawlers. An HTML site map is for visitors. Confusing the two means neglecting one of these audiences. An XML sitemap lists all indexable URLs, along with their priority and last-modified date. An HTML site map, by contrast, presents an organized selection of the main pages, often as a hierarchical list.
An XML sitemap cannot make up for poor internal linking. If a page has no HTML links pointing to it, the XML sitemap tells search engines that it exists, but the lack of internal links weakens its authority. Conversely, an HTML site map without an XML sitemap slows crawlers’ discovery of new pages.
- XML sitemap: a technical file hosted at the root and declared in robots.txt, limited to 50,000 URLs per file
- HTML site map: a page visitors can navigate, grouping links to key pages by category and accessible from the footer
- Sitemap index: required when a site exceeds the limit for a single XML file; it points to multiple child sitemaps
When to regenerate the XML sitemap
Every page addition, deletion, or redirect warrants an update to the sitemap. On a CMS such as WordPress, plugins generate the file automatically. On a static site or a JavaScript framework with server-side rendering, automate sitemap generation in your deployment pipeline to avoid oversights.
The most readable site map in the world is useless if its underlying hierarchy does not reflect visitors’ actual journeys. Test the structure with users, check its technical depth with a crawl, and keep the XML sitemap in sync with every publication. A site map’s clarity is measured by its tree test success rate, not by how elegant the menu looks.
