De viewport meta tag is een HTML-<meta>-element dat in de <head> van een webpagina staat en mobiele browsers vertelt hoe ze de breedte en het initiële zoomniveau van de pagina moeten instellen. Zonder deze tag renderen mobiele browsers standaard alsof het scherm 980 pixels breed is, en krimpen vervolgens het geheel om passend te maken. Resultaat: tekst van amper 4 pixels hoog, gebruikers die pinchen om in te zoomen, en een "Pagina lijkt niet mobile-friendly"-vlag in elke SEO- en toegankelijkheidsaudit. De fix is één regel HTML. Vrijwel elk modern WordPress-theme bevat hem, maar veel oudere of custom-themes missen hem nog steeds.
Hoe ziet de viewport meta tag eruit, en wat is de juiste waarde?
De standaard, aanbevolen viewport meta tag in 2026 is:
<meta name="viewport" content="width=device-width, initial-scale=1.0" />Dit vertelt de browser twee dingen. Ten eerste: stel de layout-viewportbreedte gelijk aan de schermbreedte van het apparaat (in plaats van de oude 980px-standaard). Ten tweede: render de pagina bij eerste laden op 1:1 zoom (in plaats van een verkleinde preview). Deze twee instellingen samen zorgen ervoor dat een responsive CSS-layout zich op telefoons daadwerkelijk responsive gedraagt.
De tag hoort zo hoog mogelijk in <head>, idealiter direct na de <meta charset>-declaratie. Browsers parsen hem vroeg en gebruiken hem voordat ze iets anders opmaken.
Waarom is de viewport meta tag nodig?
De reden voor zijn bestaan is historisch. Toen de iPhone in 2007 verscheen, bestond het mobiele web nauwelijks. De meeste websites waren ontworpen voor 1024-pixel desktopmonitoren. Apple's engineering-keuze: render elke pagina alsof het apparaat 980 pixels breed was, en krimp dan om te passen op het 320-pixel scherm. Gebruikers konden pinchen en zoomen. Dit was de slechtst mogelijke default voor sites die echt mobiel-bewust waren, dus introduceerde Apple een meta tag waar mobiel-vriendelijke sites op konden intekenen: width=device-width. De conventie verspreidde zich naar elke andere mobiele browser, en 17 jaar later is het nog steeds het mechanisme.
De praktische implicatie voor een WordPress-site: als je theme responsive is (wat in essentie elk theme van 2014 en later is), maar de viewport meta tag mist, weten browsers niet dat je CSS responsive is. Ze passen de oude 980-pixel fallback toe, je media queries triggeren nooit, en de site ziet er kapot uit op mobiel ook al zou de CSS hebben gewerkt.
Wat zijn de parameters van de viewport meta tag?
Het content-attribuut is een door komma's gescheiden lijst van parameters. De twee essentiële dekken 99% van de gevallen; de andere zijn situationeel.
width=device-width. Stelt de layout-viewport in op de schermbreedte van het apparaat. Altijd opnemen. Het alternatief is een vaste pixelwaarde (width=1024), wat eigenlijk nooit de juiste keuze is voor een moderne site.initial-scale=1.0. Stelt het zoomniveau in bij eerste laden.1.0betekent geen zoom (1 CSS-pixel = 1 layout-pixel). Altijd opnemen. Zonder dit hebben sommige Android-browsers historisch onverwachte zoomniveaus toegepast.minimum-scaleenmaximum-scale. Stellen de grenzen in voor pinch-to-zoom van de gebruiker. Beter weglaten. Beperken van gebruikerszoom is een toegankelijkheidsschending onder WCAG 2.1 (succescriterium 1.4.4 "Tekst aanpassen") en Google beschouwt het als een mobiele-bruikbaarheidsprobleem. Gebruikers met een visuele beperking zijn afhankelijk van zoom om tekst te lezen.user-scalable=no. Schakelt pinch-to-zoom volledig uit. Zelfde toegankelijkheidsprobleem als hierboven. Sommige single-page apps en gamesites gebruiken het, maar voor elke content-gedreven site (blog, shop, marketingpagina) schaadt het gebruikers actief. Moderne browsers negerenuser-scalable=noin Safari en Firefox specifiek om de toegankelijkheid te beschermen.viewport-fit=cover. Vertelt iOS de layout uit te breiden onder de notch en de home-indicator op iPhone X en later. Nodig als je een full-bleed-design hebt dat tot de schermranden moet reiken. Heeft je site standaard padding rond de content, dan kun je dit negeren.interactive-widget. Nieuwere eigenschap (2023+) die regelt hoe het virtuele toetsenbord interageert met de viewport. Standaardgedrag is prima voor de meeste sites.
Wat gaat er mis als de viewport meta tag ontbreekt?
Vier symptomen, allemaal direct zichtbaar op een telefoon:
- Tekst is microscopisch. De hele pagina wordt in de schermbreedte geperst, dus 16px-bodytekst rendert op misschien 4-5px werkelijke pixels. Gebruikers moeten pinch-zoomen om te lezen.
- Horizontale scroll verschijnt. De pagina wordt op 980px breed gelayout op een 390px-scherm, dus er is aanzienlijke horizontale overflow. Gebruikers moeten zowel zijwaarts als omlaag scrollen.
- Knoppen en links zijn te klein om aan te tikken. Apple beveelt een minimumtikdoel aan van 44x44 punten. Verkleind met factor 2,5 worden dat 17x17 werkelijke pixels, ver onder wat vingers betrouwbaar kunnen raken.
- Google Search Console flagt de pagina. Het rapport Mobiele Bruikbaarheid toont fouten "Viewport niet ingesteld" of "Inhoud breder dan scherm". Sinds mobile-first indexing (volledig uitgerold in 2021) indexeert Google primair de mobiele versie van je site, en pagina's met mobiele-bruikbaarheidsproblemen kunnen lager ranken.
Hoe controleer ik of mijn WordPress-site een viewport meta tag heeft?
Vier manieren, snelste eerst:
- InspectWP-rapport. De HTML-sectie flagt of een viewport meta tag aanwezig is, welke waarde hij heeft en of hij gebruikerszoom beperkt.
- Paginabron bekijken. Rechtsklik op de pagina, "Paginabron bekijken" (of Cmd/Ctrl+U), zoek naar "viewport". Je zou één
<meta name="viewport">-tag moeten vinden. Nul betekent dat hij ontbreekt. Twee of meer betekent dat er ergens een conflict in je theme zit. - Chrome DevTools mobiele emulatie. Open DevTools (F12), klik op het device-toolbar-icoon. Als de pagina uitgezoomd en piepklein rendert in het iPhone 14-preset, mist of klopt de viewport meta tag niet.
- Google Search Console. Onder "Pagina-ervaring, Mobiele bruikbaarheid" worden pagina's zonder viewport-tag expliciet vermeld.
Hoe voeg ik de viewport meta tag toe in WordPress?
Drie scenario's, afhankelijk van hoe je theme is gebouwd:
Het theme bevat hem al (de meeste moderne themes)
Elk standaard WordPress-theme sinds Twenty Fourteen (2013) bevat de juiste viewport meta tag in zijn header.php. Block-themes (Twenty Twenty-Two en later) bevatten hem automatisch via de editor. Bijna elk commercieel theme van Astra, GeneratePress, Kadence, Avada, Divi, Elementor Hello, etc. bevat hem. Controleer eerst de bronweergave: als hij er al staat, doe niets.
Het theme bevat hem niet (oudere of custom-themes)
Voeg hem toe aan de header.php van je theme, direct na de <meta charset>-regel:
<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<head>
<meta charset="<?php bloginfo('charset'); ?>" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />Als je geen theme-bestanden wilt bewerken (omdat het theme niet van jou is, of om theme-updates te overleven), gebruik dan een child theme of voeg het toe via een functions.php-snippet:
add_action('wp_head', function () {
echo '<meta name="viewport" content="width=device-width, initial-scale=1.0" />' . "\n";
}, 1);De prioriteit 1 zorgt ervoor dat hij zeer vroeg in de <head> wordt uitgevoerd. Browsergedrag is voorspelbaarder wanneer viewport een van de eerste tags is.
Je ziet twee viewport-tags (conflict)
Sommige plugins (mobiele-app-stijl PWA-plugins, AMP-plugins, bepaalde page builders) injecteren hun eigen viewport-tag. Als je theme ook één uitvoert, eindig je met twee, en browsers gebruiken de eerste die ze tegenkomen. Symptomen: de pagina rendert soms correct en soms niet, afhankelijk van wat eerst laadde. Fix: identificeer het duplicaat (zoek "viewport" in de gerenderde HTML), schakel daarna de verkeerde output uit. De plugin-instellingen hebben meestal een toggle om hun viewport-injectie te onderdrukken.
Moet ik gebruikerszoom beperken voor een app-achtige UI?
Kort antwoord: nee. De verleiding komt van designers die willen dat de site aanvoelt als een native app, waar pinch-to-zoom niet werkt. De realiteit:
- Het schendt WCAG 2.1. Web Content Accessibility Guidelines Succescriterium 1.4.4 vereist dat gebruikers tekst tot 200% kunnen vergroten zonder functionaliteitsverlies. Zoom beperken breekt dit.
- Het schaadt gebruikers met een visuele beperking. Ongeveer 4% van de volwassenen heeft een vorm van visuele beperking die zoom vereist. Voor hen is je "app-achtige" pagina onleesbaar.
- Moderne browsers negeren de beperking sowieso. Safari op iOS 10+ en Firefox hebben
user-scalable=nojaren actief genegeerd, specifiek vanwege de toegankelijkheidsschade. De instelling werkt alleen op een krimpende minderheid van browsers. - Het schaadt SEO. Google's mobile-friendly-criteria omvatten expliciet "de pagina beperkt pinch-to-zoom niet". Pagina's die dat wel doen worden gemarkeerd in Search Console.
Als je UI breekt wanneer gebruikers zoomen, is de juiste fix om de CSS gracieus om te laten gaan met grotere tekst, niet om zoom te blokkeren.
Hoe interageert de viewport-tag met responsive design?
De viewport-tag en CSS-media queries werken samen. De viewport-tag stelt de layout-viewport in (de breedte waarop CSS-berekeningen plaatsvinden); media queries vuren op basis van die breedte. Zonder width=device-width worden je media queries geëvalueerd tegen de oude 980px-aanname, dus een regel @media (max-width: 768px) triggert nooit op een 390px-iPhone (omdat de browser denkt dat de layout-viewport 980px breed is).
Dit is de meest voorkomende oorzaak van "mijn responsive design werkt niet" op een WordPress-site: de CSS is goed, de media queries zijn correct, maar de viewport-tag mist of klopt niet, dus de browser komt nooit in mobiele modus. Eén regel HTML toevoegen lost het op.
Veelvoorkomende fouten
- Een vaste breedte zoals
width=1024gebruiken. Forceert elk apparaat om te renderen op 1024px, en verslaat het hele punt. Bijna altijd een copy-paste-fout uit een verouderde tutorial. initial-scaleinstellen op iets anders dan 1.0. Waarden als0.5of2.0betekenen dat de pagina pre-ingezoomd of -uitgezoomd laadt. Gebruikers proberen direct terug naar normaal te zoomen. Altijd 1.0.- Zoom beperken met
user-scalable=noofmaximum-scale=1. Toegankelijkheidsschending, SEO-nadeel, sowieso genegeerd door moderne Safari en Firefox. Verwijder het gewoon. viewport-fit=coververgeten op iPhone X+ full-bleed-designs. Inhoud reikt niet tot de schermranden; je krijgt witte banden bovenaan en onderaan rond de notch en home-indicator. Voeg de parameter toe als het design edge-to-edge bedoelt.- De tag met PHP
echobuiten de<head>toevoegen. Een tag in<body>is ongeldige HTML en browsers negeren hem. De tag moet binnen<head>staan.
Wat InspectWP controleert
De HTML-sectie van elk InspectWP-rapport verifieert dat een viewport meta tag aanwezig is en rapporteert zijn content-waarde. Als de tag mist, markeert het rapport het als waarschuwing, omdat het een vrijwel universele mobiele-bruikbaarheidsvereiste is. Als user-scalable=no of maximum-scale is ingesteld om zoom te beperken, wordt dat gemarkeerd als toegankelijkheidsprobleem. De controle is onafhankelijk van of de theme-designer een responsive layout beoogde; wat telt is of de tag echt aanwezig is in de HTML die de browser ziet. Een site kan een perfect responsief CSS-framework hebben en deze controle toch falen als de viewport-tag verloren ging tijdens een theme-migratie of plugin-conflict.