Waarom je logo niet in een h1-tag hoort: de geschiedenis van een hardnekkige fout

Het is 2026. We bouwen apps met React Server Components, we deployen naar edge networks, we optimaliseren voor Core Web Vitals. En toch — toch — zie ik nog steeds websites waar het logo in een <h1> zit.

Tijd om dit recht te zetten. Want deze praktijk is niet alleen technisch achterhaald, het is ook gewoon verkeerd voor toegankelijkheid, contentstructuur, en ja — zelfs voor SEO.

De tijd toen CSS Image Replacement ‘best practice’ was

Laten we beginnen met een geschiedenislesje. Het jaar is 2003. CSS2.1 is net officieel. Firefox heet nog Phoenix. Jeffrey Zeldman’s Designing with Web Standards ligt op het nachtkastje van elke zelfrespecterende webdeveloper.

In die tijd had je een probleem: je wilde je logo tonen waar je merknaam stond, maar SEO-experts (lees: mensen die dachten te weten hoe Google werkt) vertelden je dat je bedrijfsnaam in een <h1> moest staan. “De belangrijkste heading voor rankings!”

De oplossing leek briljant: stop je bedrijfsnaam in een <h1>, verberg die tekst met CSS, en toon je logo als achtergrondafbeelding. Tada! Semantische HTML én een mooi logo.

Todd Fahrner wordt vaak genoemd als de oorspronkelijke bedenker (Fahrner Image Replacement, FIR). Douglas Bowman en Jeffrey Zeldman populariseerden het. In augustus 2003 bedacht Mike Rundle de Phark-methode:

h1 {
  text-indent: -9999px;
  background: url(logo.png) no-repeat;
  width: 200px;
  height: 80px;
}

Daarna volgden tientallen varianten. Gilder/Levin. Shea Enhancement. Malarkey. Leahy/Langridge. De HTML5 Boilerplate-methode uit 2012-2014 met .visuallyhidden. Elk met hun eigen voor- en nadelen, elk met een belofte van “dit werkt echt wel voor screenreaders”.

Het probleem: het werkte nooit echt

Hier is het ding: Joe Clark testte dit al in 2003 op A List Apart. Zijn conclusie? FIR is niet toegankelijk. Screenreaders gingen inconsistent om met display: none. JAWS las tekst met display: none wél, andere screenreaders niet. Sommige screenreaders lazen text-indent: -9999px als “negative nine thousand nine hundred ninety-nine pixels”.

Oeps. Best wel snel.

Maar het werd toch doorgeduwd als best practice. Want SEO. En omdat het technisch interessant was. En omdat we allemaal graag CSS-hacks maakten.

Waarom dit geen goed idee is (en nooit was)

Laten we eens kijken waarom het plaatsen van je logo in een <h1> fundamenteel verkeerd is. Niet “een beetje suboptimaal”. Gewoon verkeerd.

1. Screenreader-gebruikers navigeren via headings

Hier is iets wat veel developers niet weten: mensen die met een screenreader werken, scannen webpagina’s vaak door headings. Ze drukken op de H-toets (in JAWS of NVDA) en springen van heading naar heading.

Stel je voor: je bent op zoek naar informatie over retourvoorwaarden op een webshop. Je drukt op H om naar de eerste heading te gaan. De screenreader zegt: “Heading level 1: Fancy Webshop”.

Vervolgens ga je naar de volgende pagina — over verzending. Je drukt op H. “Heading level 1: Fancy Webshop”.

Nog een pagina — de contactpagina. “Heading level 1: Fancy Webshop”.

Zeg maar dag tegen je bezoekers met schermlezers. Ze hebben geen idee waar ze zijn, want elke pagina begint met dezelfde waardeloze <h1>.

Een goede <h1> vertelt je waar je bent:

• “Retourvoorwaarden”
• “Verzending en levering”
• “Contact”

Niet je bedrijfsnaam. Die staat al in de <title>, die staat al in je logo. We hoeven hem niet nóg een keer.

2. De h1 beschrijft je content, niet je site

De <h1> is niet bedoeld als “belangrijkste element voor SEO”. Het is de titel van het (web)document. De hoofdkop van de content op die specifieke pagina.

Denk aan een krant. De naam van de krant staat bovenaan (je logo). Maar het artikel begint met een kop: “Inflatie daalt naar laagste peil in 3 jaar”. Dat is je <h1>. Niet “De Krant” boven elke pagina.

Als je homepage gaat over “Duurzame sportkleding voor vrouwen”, dan is dat je <h1>. Als je productpagina gaat over “Hardloopshirt Recycled Polyester — Blauw”, dan is dat je <h1>.

3. Je document outline is kapot

Als je logo de <h1> is, wat wordt dan de titel van je pagina-inhoud? Een <h2>? Dan klopt je hele heading-hiërarchie niet meer.

Slechte structuur:

<header>
  <h1>Bedrijfsnaam</h1>
</header>
<main>
  <h2>Welkom bij onze dienstverlening</h2>
  <p>Content...</p>
  <h3>Waarom kiezen voor ons?</h3>
</main>

Goede structuur:

<header>
  <a href="/">
    <img src="logo.svg" alt="Bedrijfsnaam" />
  </a>
</header>
<main>
  <h1>Welkom bij onze dienstverlening</h1>
  <p>Content...</p>
  <h2>Waarom kiezen voor ons?</h2>
</main>

Zie je het verschil? In de goede structuur begint de content logisch met niveau 1. In de slechte structuur beginnen alle echte koppen op niveau 2, terwijl niveau 1 opgegeten wordt door je logo.

4. SEO-mythes die niet doodgaan

“Maar Google verwacht toch een h1 met je belangrijkste keyword?”

Nee. Google’s John Mueller heeft dit keer op keer ontkracht. Google gebruikt headings om de structuur en inhoud van je pagina te begrijpen. Niet om te bepalen of jouw site rankt.

Meerdere <h1>-elements? Prima. Geen <h1>? Slecht voor bezoekers die screenreaders gebruiken. Je bedrijfsnaam in de <h1> op elke pagina? Google weet echt wel hoe je bedrijf heet. Daar hoef je geen <h1> voor te verspillen.

Wat je wél moet doen

Genoeg geklaagd. Hier is de juiste aanpak — in 2026 en daarna.

Logo als link naar de homepagina

<header>
  <a href="/">
    <img src="logo.svg" alt="Bedrijfsnaam" title="naar de homepagina" />
  </a>
  <nav>
    <!-- Je navigatie -->
  </nav>
</header>

Simpel. Duidelijk. Toegankelijk. Het alt-attribuut zorgt ervoor dat screenreaders weten wat het logo is. Het title-attribuut is voor ’nice-to-have’ informatie. Persoonlijk vind ik het een beetje overkill om het title-attribuut toe te voegen. De meeste mensen weten dat het logo bovanaan de pagina een link naar de homepagina is.

En je h1?

Die staat in je content. Op elke pagina anders.

Homepage:

<main>
  <h1>Duurzame sportkleding voor vrouwen</h1>
  <p>Gemaakt van gerecycled materiaal...</p>
</main>

Productpagina:

<main>
  <h1>Hardloopshirt Recycled Polyester — Blauw</h1>
  <img src="shirt.jpg" alt="" />
  <p>Dit shirt is gemaakt van...</p>
</main>

Contactpagina:

<main>
  <h1>Neem contact op</h1>
  <p>Vragen? We helpen je graag.</p>
  <form>...</form>
</main>

Zie je het patroon? De <h1> vertelt je waar je bent en wat je gaat lezen. Niet wie de website gemaakt heeft.

Wat als je homepage geen duidelijke kop heeft?

Dan verzin je er een. Serieus.

Je homepage heeft een doel. Misschien is dat: nieuwe klanten binnenhalen. Of: je dienst uitleggen. Of: producten verkopen. Wat dat doel ook is, vat het samen in één zin. Dat is je <h1>.

Voorbeelden:

• “Bedrijfsnaam - De beste koffie van Amsterdam”
• “Bedrijfsnaam - Webdesign dat converteert”
• “Bedrijfsnaam - Financieel advies zonder poespas”

Als je écht geen kop wilt tonen, dan kan je hem visueel verbergen met .visually-hidden — maar hij staat er wél in de HTML. En kan een bezoeker met een screen reader meteen naar deze kop navigeren.

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

<main>
  <h1 class="visually-hidden">
    Welkom bij Bedrijfsnaam — De beste koffie van Amsterdam
  </h1>
  <!-- Rest van je homepage -->
</main>

Screenreaders lezen het. Google indexeert het. Visuele gebruikers zien het niet.

Tot slot

De praktijk om je logo in een <h1> te zetten stamt uit 2003. Een tijdperk van CSS-hacks, SEO-mythes, en inconsistent screenreader-gedrag. Het was toen al geen goed idee. In 2026 is het gewoon fout.

Geef elke pagina een <h1> die beschrijft wat er op die pagina staat. Niet je bedrijfsnaam. Niet je tagline. De titel van de content op die specifieke pagina.

• ✅ Homepage: “Duurzame sportkleding voor vrouwen”
• ✅ Productpagina: “Hardloopshirt Recycled Polyester — Blauw”
• ✅ Contactpagina: “Neem contact op”

❌ Elke pagina: <h1> "Bedrijfsnaam" </>

Je screenreader-gebruikers, je contentstructuur, en je toekomstige zelf die de codebase moet onderhouden — ze zullen je dankbaar zijn.

Twijfel je of je site goed zit? Bij Proper Access helpen we developers en teams om toegankelijke code te schrijven — niet met vage adviezen, maar met concrete code-reviews en praktische oplossingen. Met de billen bloot dus, maar dat is het waard. Neem contact op met Julia Tol.

Julia Tol is oprichter van Proper Access en helpt organisaties bij het realiseren van digitale toegankelijkheid. Niet met dikke rapporten, maar met concrete oplossingen die developers daadwerkelijk kunnen implementeren.