The HTML sitemap remains one of the most underused navigation tools, even though it serves a specific technical purpose: providing an alternative way to access every page on a site without relying on the main menu or internal search.
HTML sitemap and XML sitemap: two files with distinct purposes
Confusing the sitemap visible to visitors with the XML sitemap intended for search engine crawlers is a common mistake, even among technical professionals. An XML sitemap lists URLs for search engines (Google, Bing) to facilitate crawling. It contains neither a human-readable hierarchy nor labels that make sense to visitors.
An HTML sitemap, by contrast, presents a hierarchy of clickable links organized by sections, subsections, and pages. Its purpose is strictly user-focused: helping visitors find a page in seconds, without navigating dropdown menus or guessing how the site is structured.
A good example of this distinction can be found on the Habite Ta Terre sitemap, which displays all the sections available to visitors in a clear hierarchy, independently of the XML file submitted to crawlers.
WCAG 2.4.5 criterion and RGAA audit: the sitemap as a technical requirement
Success Criterion 2.4.5 of WCAG 2.2 requires that a web page be reachable by at least two different methods: main navigation, internal search, a sitemap, or contextual links. Pages that form part of a process (such as a checkout flow or a multi-step form) are exempt.
A sitemap meets this requirement directly by providing a complete alternative path to every page. Without one, a site must make up for it with an effective search function or extensive internal linking, which requires more design effort.
In France, the RGAA includes the sitemap page in the mandatory sample for an accessibility audit, alongside the homepage, legal notices, and contact page. In other words, this page is not a bonus: it is audited and must itself meet accessibility criteria.
Keyboard navigation and screen readers: a sitemap that doesn’t work is worse than no sitemap
Simply publishing a page titled “Sitemap” is not enough. If links do not receive keyboard focus in a logical order, or their labels are unclear to assistive technologies, the page becomes an additional obstacle rather than a helpful resource.
Three technical checks should be carried out on the sitemap:
- The tab order follows the visual hierarchy of the sitemap (main section before subsection), with no unexpected skips or backward jumps.
- Each link has a clear label out of context: “Our work-study courses” works, while “Click here” or “Learn more” does not work for a screen reader user.
- Focus remains visible on each link during keyboard navigation, with a compliant focus indicator (sufficient contrast and a distinct outline).
A screen reader user who lands on a poorly marked-up sitemap will waste more time than they would exploring the main menu. We find that most sitemaps automatically generated by CMSs fail to meet these three requirements without manual intervention.
HTML sitemap content: what to include and what to leave out
A sitemap is not a raw export of every URL. Its usefulness depends on editorial curation that reflects the site’s structure without overwhelming visitors.
Pages to include as standard
- Key structural pages: homepage, main sections, and top-level subsections.
- Institutional pages: legal notices, privacy policy, contact page, and accessibility statement.
- Service pages: FAQ, help, request form, and personal account area (link to the login page, not to protected content).
Pages to leave out
Paginated blog posts, internal search results, tag pages, and date archives add no value to a navigation-focused sitemap. An overloaded sitemap loses its value as a visual guide and becomes just as difficult to navigate as the site itself.
For sites with a large volume of content (several hundred articles), grouping posts by category and listing only parent categories remains the clearest solution.
Automatic generation or manual creation of an HTML sitemap
Most CMSs offer plugins that generate an HTML sitemap from the existing site structure. On WordPress, plugins such as WP Sitemap Page or Simple Sitemap create a list of links from published pages.
Automatic generation has two drawbacks. First, it includes pages that are irrelevant to navigation by default (author pages, monthly archives, media pages). Second, the displayed hierarchy reflects the CMS’s technical structure, not the navigation logic designed for visitors.
Manual or semi-manual creation (automatic generation followed by editorial cleanup) ensures that the sitemap aligns with the actual user journey. The additional maintenance is modest: a quarterly update is enough for most sites whose structure changes little.
Access to the sitemap: placement and link label
The sitemap link belongs in the footer, near the legal notices and accessibility statement. This convention is widespread enough that users know where to look. Placing the link only in a secondary menu or on an “About” page significantly reduces its discoverability.
The link label should be “Sitemap”, with no creative variations. Users looking for this page scan the footer for that exact term. “Site map,” “Index,” or “Navigation” do not match their expectations and reduce click-through rates.
A well-structured sitemap that is keyboard-accessible and placed in the footer makes site navigation predictable. It takes just a few hours to implement and meets RGAA requirements, supports users of assistive technologies, and helps any visitor frustrated by an inadequate navigation menu.
