De HTML-sitemap is een van de minst gebruikte navigatiemiddelen, terwijl deze een duidelijke technische functie vervult: bezoekers op een alternatieve manier toegang bieden tot alle pagina’s van een website, zonder afhankelijk te zijn van het hoofdmenu of de interne zoekfunctie.
HTML-sitemap en XML-sitemap: twee bestanden met verschillende functies
De sitemap die zichtbaar is voor bezoekers verwarren met het XML-sitemapbestand voor zoekmachinecrawlers is een veelgemaakte fout, ook bij technische professionals. De XML-sitemap geeft URL’s door aan zoekmachines (Google, Bing) om het crawlen te vergemakkelijken. Een leesbare hiërarchie of begrijpelijke labels voor mensen bevat dit bestand niet.
De HTML-sitemap toont daarentegen een boomstructuur met klikbare links, ingedeeld in rubrieken, subrubrieken en pagina’s. De functie ervan is volledig op de gebruiker gericht: bezoekers moeten binnen enkele seconden een pagina kunnen vinden, zonder door uitklapmenu’s te navigeren of de structuur van de website te hoeven raden.
Een goed voorbeeld van dit onderscheid is de sitemap van Habite Ta Terre, die alle rubrieken toont die bezoekers kunnen bekijken in een overzichtelijke boomstructuur, los van het XML-bestand dat aan crawlers wordt aangeboden.
WCAG 2.4.5-criterium en RGAA-audit: de sitemap als technische verplichting
Succescriterium 2.4.5 van WCAG 2.2 vereist dat een webpagina op minstens twee verschillende manieren bereikbaar is: via de hoofdnavigatie, de interne zoekfunctie, de sitemap of contextuele links. Pagina’s die deel uitmaken van een processtap (zoals een bestelproces of een meerstappenformulier) zijn hiervan vrijgesteld.
De sitemap voldoet rechtstreeks aan deze eis door een volledig alternatieve route naar elke pagina te bieden. Zonder sitemap moet een website dit compenseren met een krachtige zoekfunctie of een uitgebreid intern linknetwerk. Dat vraagt om meer ontwerpwerk.
In Frankrijk neemt de RGAA de sitemap op in de verplichte steekproef voor een toegankelijkheidsaudit, net als de homepage, de juridische informatie en de contactpagina. Met andere woorden: deze pagina is geen extraatje, maar wordt gecontroleerd en moet zelf ook aan de toegankelijkheidscriteria voldoen.
Toetsenbordnavigatie en schermlezers: een niet-werkende sitemap is erger dan geen sitemap
Een pagina publiceren met de titel ‘Sitemap’ is niet voldoende. Als links niet in een logische volgorde toetsenbordfocus krijgen of als de linkteksten niet duidelijk zijn voor ondersteunende technologieën, wordt de pagina eerder een extra obstakel dan een hulpmiddel.
Controleer de sitemap op drie technische punten:
- De tabvolgorde volgt de visuele hiërarchie van de boomstructuur (eerst de hoofdrubriek, daarna de subrubriek), zonder onverwachte sprongen of terugbewegingen.
- Elke link heeft een duidelijke tekst die ook zonder context begrijpelijk is: ‘Onze opleidingen in duaal leren’ werkt, ‘Klik hier’ of ‘Meer informatie’ niet voor een schermlezer.
- De focus blijft zichtbaar op elke link tijdens toetsenbordnavigatie, met een focusindicator die aan de eisen voldoet (voldoende contrast en een duidelijke omlijning).
Een schermlezergebruiker die op een slecht gemarkeerde sitemap terechtkomt, is meer tijd kwijt dan wanneer die het hoofdmenu verkent. We zien dat de meeste sitemaps die CMS’en automatisch genereren deze drie punten niet naleven zonder handmatige aanpassingen.
Inhoud van de HTML-sitemap: wat opnemen en wat weglaten
Een sitemap is geen ruwe export van alle URL’s. De waarde ervan hangt af van redactionele selectie: de structuur van de website moet duidelijk worden zonder bezoekers te overladen.
Pagina’s die er altijd in moeten staan
- Structurerende pagina’s: de homepage, hoofdrubrieken en subrubrieken op het eerste niveau.
- Institutionele pagina’s: juridische informatie, privacybeleid, contact en de toegankelijkheidsverklaring.
- Servicepagina’s: FAQ, hulp, aanvraagformulier en persoonlijke omgeving (een link naar de inlogpagina, niet naar afgeschermde inhoud).
Pagina’s die u beter weglaat
Gepagineerde blogartikelen, interne zoekresultaten en tag- of datumarchiefpagina’s voegen niets toe aan een sitemap die bedoeld is voor navigatie. Een overvolle sitemap verliest zijn functie als visueel houvast en wordt net zo lastig te doorzoeken als de website zelf.
Voor websites met veel content (enkele honderden artikelen) is het overzichtelijkst om publicaties per categorie te groeperen en alleen de bovenliggende categorieën te vermelden.
De HTML-sitemap automatisch genereren of handmatig opbouwen
De meeste CMS’en bieden extensies die op basis van de bestaande boomstructuur automatisch een HTML-sitemap genereren. In WordPress maken plugins zoals WP Sitemap Page of Simple Sitemap een lijst met links naar gepubliceerde pagina’s.
Automatische generatie heeft twee nadelen. Ten eerste worden standaard ook pagina’s opgenomen die weinig nut hebben voor de navigatie (auteurspagina’s, maandarchieven en mediapagina’s). Daarnaast weerspiegelt de getoonde hiërarchie de technische structuur van het CMS, niet de navigatielogica die voor bezoekers is ontworpen.
Een handmatige of semi-handmatige aanpak (automatisch genereren en daarna redactioneel opschonen) zorgt voor een sitemap die aansluit op de daadwerkelijke gebruikersroute. Het extra onderhoud valt mee: voor de meeste websites waarvan de structuur weinig verandert, volstaat een driemaandelijkse update.
Toegang tot de sitemap: plaatsing en linktekst
Plaats de link naar de sitemap in de footer, in de buurt van de juridische informatie en de toegankelijkheidsverklaring. Deze conventie is zo ingeburgerd dat gebruikers weten waar ze moeten zoeken. Als de link alleen in een secundair menu of op een pagina ‘Over ons’ staat, wordt hij veel moeilijker te vinden.
De linktekst moet ‘Sitemap’ zijn, zonder creatieve varianten. Gebruikers die deze pagina zoeken, scannen de footer op precies die term. ‘Websitekaart’, ‘Index’ of ‘Navigatie’ sluit niet aan bij hun verwachting en verlaagt het aantal klikken.
Een goed opgebouwde sitemap die met het toetsenbord toegankelijk is en in de footer staat, maakt de navigatie op een website voorspelbaar. Het kost maar een paar uur werk en helpt tegelijk te voldoen aan de RGAA-eisen, tegemoet te komen aan gebruikers van ondersteunende technologieën en frustratie te voorkomen bij bezoekers die vastlopen in een ontoereikend navigatiemenu.
