A sitemap is not just a list of links in the footer. It is a complete navigation system that conditions both indexing by bots and the fluidity of the user journey. Confusing XML sitemaps with HTML sitemaps, or neglecting cross-sectional pages in the hierarchy, are structural errors that undermine a site long before design comes into play.
XML Sitemap and HTML Sitemap: two files, two distinct functions
The confusion between these two formats persists in the majority of web projects. The XML sitemap is exclusively for indexing bots. It lists URLs with their metadata (last modified date, update frequency, relative priority) to facilitate crawling. Google Search Console consumes it, not your visitors.
The HTML sitemap, on the other hand, is a visible page intended for internet users. It reproduces the site’s hierarchy in the form of clickable links, organized by categories. Its role: to provide direct access to any page when the main menu is insufficient.
We recommend maintaining both in parallel. The XML ensures indexing coverage, while the HTML addresses broken navigation paths. A concrete example of implementation can be found in the Pixikult sitemap, which displays all sections and subpages accessible with one click.
- The XML sitemap should only contain canonical URLs, without session parameters or unnecessary paginated pages
- The HTML sitemap excludes technical pages (empty cart, internal search results, login pages) that do not provide value to the visitor
- Both files must be updated with each addition or deletion of a page, either manually or via a dedicated WordPress plugin
Audit of existing pages before any restructuring
Restructuring a site without prior diagnosis is like redesigning an architect’s plan without visiting the building. The audit identifies orphan pages, outdated content, and abandonment paths that distort the current hierarchy.
Specifically, we cross-reference three data sources. Traffic statistics reveal ignored pages (no visits over several months). The coverage report from Search Console highlights indexing errors and excluded pages. A complete site crawl (Screaming Frog, Sitebulb) maps the actual depth of each URL and missing internal links.
What the audit changes in the hierarchy
Pages with no traffic and no incoming links are candidates for deletion or merging. A category that contains only one subpage has no reason to exist as a hierarchical level. Conversely, a catch-all page that concentrates dispersed traffic across multiple search intents deserves to be split into targeted pages.
Each retained URL must justify its place in the structure with a clear objective: to convert, inform, or direct to another page. If it fulfills none of these roles, it burdens the site and dilutes the crawl budget.
Multichannel navigation: beyond the main menu
Reducing a website’s architecture to the main navigation menu is a common mistake. On a site with more than a few dozen pages, the menu cannot display everything without becoming unreadable. The hierarchy unfolds through several complementary channels.
Breadcrumbs and contextual links
The breadcrumb trail materializes the parent-child hierarchy of each page. It helps the visitor go up a level without returning to the homepage. For SEO, it generates structured data that Google displays directly in search results.
Contextual links, inserted within the content body, create a thematic internal linking that reinforces the semantic relevance of each page. A blog post linking to an associated service page transfers SEO weight and guides the reader towards conversion.
Secondary menu and internal search
The footer hosts cross-sectional pages: legal notices, privacy policy, accessibility, contact. These pages are legally required but do not belong in the main menu. Downgrading them to the footer keeps the menu clean without sacrificing compliance.
Internal search becomes a fully-fledged navigation channel once the site exceeds a hundred pages. It must return relevant and filtered results, not a raw list sorted by date. On WordPress, a plugin like SearchWP effectively replaces the native search.
Hierarchy structure for WordPress: depth and categories
On WordPress, the structure relies on two axes: the hierarchy of pages (parent/child) and the taxonomy of posts (categories and tags). Mixing the two without logic creates an incoherent hierarchy that neither visitors nor engines can follow.
- Limit the depth to a maximum of three levels (home, category, final page). Each additional click significantly reduces the consultation rate of the target page
- Assign each post to only one main category to avoid content duplication in archives
- Reserve tags for cross-sectional groupings (by theme, by format) and do not index them if they generate pages poor in content
- Use short and descriptive slugs: /services/creation-site/ rather than /nos-services/nos-prestations/creation-de-site-web-professionnel/
During a redesign, the 301 redirect of each old URL to its new equivalent is non-negotiable. An incomplete redirect plan causes a series of 404 errors and a sharp drop in SEO.
Iterative validation of the sitemap
A sitemap is not a fixed deliverable handed over at the beginning of the project. We observe that the most robust architectures result from an iterative process: a first version is tested with stakeholders, adjusted after feedback from target users, and then technically validated before development.
In practice, a visual diagram (tools like Whimsical, Octopus.do, or a simple spreadsheet) is sufficient to represent the levels and links between pages. The test consists of asking a user not involved in the project to find specific information in less than three clicks. If the journey fails, the structure must be reviewed.
The sitemap also evolves after going live. Adding new pages, regularly publishing articles, or opening an e-commerce section alters the initial balance. Planning a review of the hierarchy at least once a year prevents the accumulation of poorly linked pages that gradually degrade the site’s readability and indexing.