Hoe je een website mobielvriendelijk (responsive) maakt
Om een website mobielvriendelijk (responsive) te maken, voeg je een viewport-metatag toe, bouw je de indeling mobile-first met flexibele breedtes, en gebruik je CSS-breakpoints om hem op grotere schermen te herschikken — kolommen onder elkaar zetten, het menu inklappen en afbeeldingen laten meeschalen. Controleer daarna elke pagina op telefoonbreedte op zijwaarts scrollen, te kleine tekst en knoppen die te klein zijn om op te tikken. Bij een met AI gebouwde site lost één duidelijke prompt plus een controle in een preview op telefoonformaat meestal het grootste deel op.
Wat responsive design echt is
Een responsive site gebruikt één set pagina's en URL's die zich aan het scherm aanpassen. In plaats van een aparte "m."-site past de CSS de indeling aan bij bepaalde breedtes, de breakpoints. De bouwstenen:
- De viewport-metatag vertelt mobiele browsers de echte breedte van het apparaat te gebruiken.
- Vloeiende indelingen gebruiken percentages, flexbox en grid in plaats van vaste pixelbreedtes.
- Media queries (of framework-classes zoals Tailwinds
md:) veranderen de indeling vanaf een bepaalde breedte. - Flexibele media — afbeeldingen en video die krimpen om in hun container te passen.
Dat is belangrijk omdat een groot deel van je bezoekers waarschijnlijk op telefoons zit, en omdat Google de mobiele versie van je pagina's indexeert. Als content of links alleen op desktop bestaan, zien ze die misschien ook niet.
Opties en afwegingen
| Aanpak | Hoe het werkt | Goed voor | Afweging |
|---|---|---|---|
| Mobile-first responsive | Basisstijlen voor telefoons, daarna indeling toevoegen voor bredere schermen | Nieuwe sites en apps (aanbevolen) | Vraagt om eerst klein te denken |
| Desktop-first responsive | Desktopstijlen, daarna overschrijven voor kleinere schermen | Een bestaande desktopsite aanpassen | Meer overschrijvingen; mobiel voelt als bijzaak |
| Aparte mobiele site | Andere URL's voor telefoons | Zelden nog gerechtvaardigd | Twee sites onderhouden, SEO-complicaties |
| Progressive web app (PWA) | Responsive site die op het beginscherm kan worden geïnstalleerd | App-achtige tools die vaak worden gebruikt | Extra instelling; zie native versus progressive web apps |
Mobile-first is meestal eenvoudiger: één kolom is de makkelijkste indeling, en kolommen toevoegen naarmate er ruimte komt, is minder werk dan ze weghalen.
De onderdelen die meestal breken
De viewport-tag
Als een pagina op een telefoon eruitziet als een kleine desktopsite, ontbreekt de viewport-tag:
<meta name="viewport" content="width=device-width, initial-scale=1">
Voeg geen maximum-scale=1 of user-scalable=no toe. Pinch-zoom blokkeren maakt de site moeilijker te gebruiken voor mensen met een visuele beperking.
Vaste breedtes en horizontaal scrollen
De meest voorkomende responsive-bug is iets dat breder is dan het scherm: een vaste width: 1200px-container, een brede tabel, een lange URL of codeblok, een afbeelding zonder max-width: 100%. De hele pagina scrolt dan zijwaarts. Gebruik max-width in plaats van width, laat tekst terugvallen naar de volgende regel, en geef brede elementen hun eigen scrollgebied.
Navigatie
Vijf menulinks van de desktop passen zelden op een telefoon. Het gebruikelijke antwoord is een menuknop die een paneel opent. Houd de twee of drie belangrijkste acties zichtbaar — "Boeken", "Winkelwagen", "Inloggen" — en zorg dat het menu met het toetsenbord werkt en makkelijk sluit.
Tekst en tikdoelen
- Lopende tekst van ongeveer 16 px is een verstandig minimum op telefoons. Invoervelden met kleinere tekst zorgen ervoor dat iPhones inzoomen bij het tikken.
- Maak knoppen en links makkelijk te raken. WCAG 2.2 AA stelt een ondergrens van 24 bij 24 CSS-pixels (of genoeg ruimte eromheen); rond 44 pixels is comfortabeler voor duimen.
- Laat ruimte tussen naast elkaar staande links, zodat mensen niet de verkeerde raken.
Tabellen en data
Brede tabellen zijn het moeilijkste onderdeel van een responsive app. Opties, in volgorde van voorkeur: minder kolommen tonen op telefoons, elke rij omzetten naar een kaart, of de tabel in een horizontaal scrollbare container zetten met de eerste kolom vastgezet. Kies op basis van wat mensen moeten vergelijken.
Afbeeldingen en media
Gebruik max-width: 100% en height: auto, lever kleinere bestanden aan kleine schermen met srcset, en zet breedte en hoogte om sprongen in de indeling te voorkomen. Ingebedde video's en kaarten hebben een responsive wrapper nodig zodat ze hun verhouding behouden. Kleinere afbeeldingen maken pagina's ook sneller — zie hoe je je website sneller maakt.
Formulieren
Zet labels boven de velden, maak velden volledige breedte, en gebruik de juiste invoertypen (type="email", type="tel", inputmode="numeric"), zodat telefoons het bijpassende toetsenbord tonen. Zet de verzendknop waar een duim hem kan bereiken, en houd hem zichtbaar wanneer het toetsenbord opengaat.
Interacties die alleen met hover werken
Telefoons kennen geen hover. Tooltips, dropdowns en previews die alleen bij hover verschijnen, zijn onzichtbaar voor mensen die met aanraken werken. Zorg dat ze ook werken bij tikken.
Prompts die werken
Voor een nieuwe build zeg je het vooraf:
Bouw dit mobile-first. Eén kolom op telefoons, twee kolommen vanaf tabletbreedte, de volledige indeling op desktop. Geen horizontaal scrollen bij 320 px breed, lopende tekst minstens 16 px, tikdoelen minstens 44 px, een menuknop op kleine schermen, en tabellen die op telefoons in kaarten veranderen.
Voor een bestaande pagina beschrijf je wat je ziet:
Op telefoons scrolt de pagina /pricing zijwaarts en staan de drie plankaarten naast elkaar ingedrukt. Zet de kaarten onder 768 px onder elkaar, laat de vergelijkingstabel horizontaal scrollen binnen zijn eigen container met de functiekolom vastgezet, en houd de desktopindeling ongewijzigd.
Controleer elke pagina op 375 px breed. Noem alles wat overloopt, overlapt, tekst kleiner dan 16 px heeft of tikdoelen kleiner dan 44 px, of alleen met hover werkt, en repareer dan elk punt.
Stap voor stap
- Controleer de viewport-tag in het hoofdgedeelte van de pagina.
- Test op 320–375 px breed in de apparaatmodus van de browser of een preview op telefoonformaat. Scrol elke pagina van boven naar beneden.
- Los horizontaal scrollen eerst op. Zoek het element dat te breed is; alles andere is moeilijk te beoordelen zolang dat er nog is.
- Regel de navigatie: menuknop, belangrijkste acties zichtbaar.
- Controleer tekst, tikdoelen en formulieren in elke belangrijke flow — aanmelden, zoeken, afrekenen, contact.
- Behandel tabellen en media: kaarten of scrollcontainers, responsive afbeeldingen en embeds.
- Controleer de tussenformaten. Sleep de breedte langzaam van telefoon naar desktop; indelingen breken vaak rond tabletbreedte.
- Test op een echte telefoon. Emulators missen dingen zoals het schermtoetsenbord dat een knop bedekt, inkepingen, en hoe snel de site aanvoelt op mobiele data.
Veelgemaakte fouten
- Maar op één telefoonformaat testen. Controleer een kleine telefoon, een grote telefoon en een tablet.
- Content verbergen op mobiel om het te laten passen. Google indexeert de mobiele versie, en telefoongebruikers willen dezelfde informatie.
- Zoom uitschakelen in de viewport-tag.
- Desktopafbeeldingen op telefoons, die laadtijd en data kosten.
- Vastgepinde elementen die zich opstapelen: een vaste header, een cookiebanner en een chatbubbel kunnen de helft van een telefoonscherm bedekken.
- Pop-ups die niet te sluiten zijn op een klein scherm, omdat de sluitknop buiten beeld valt.
Mobiele checklist
- Viewport-metatag aanwezig; zoom niet uitgeschakeld
- Geen horizontaal scrollen bij 320 px op elke pagina
- Lopende tekst ~16 px; invoervelden zoomen niet in
- Tikdoelen ruim en met voldoende ruimte
- Menu werkt op telefoons en met het toetsenbord
- Tabellen leesbaar op telefoons (kaarten, minder kolommen of scrollcontainer)
- Afbeeldingen en embeds schalen; bestanden in de juiste maat geleverd
- Formulieren gebruiken de juiste invoertypen; verzendknop bereikbaar
- Niets belangrijks hangt af van hover
- Getest op minstens één echte telefoon
Responsive indeling hoort ook bij toegankelijkheid: WCAG vraagt dat content werkt bij 320 px breed en bij 200% zoom. Als je een app bouwt die mensen dagelijks op hun telefoon gebruiken, gaat hoe je een mobielvriendelijke webapp bouwt verder, inclusief installeerbare PWA's.
Responsive design op Mythex
Mythex bouwt responsive webapps, en op Pro kan het ze verpakken als Android- en iPhone-apps. Klik in de werkruimte op het telefoonpictogram boven Preview (Naar mobiel schakelen) om je app in een kader op telefoonformaat te zien, en sleep de rand van het kader om andere breedtes te proberen (Preview en Code). In de documentatie staat een korte startprompt voor het oplossen van indelingen op kleine schermen in mobielvriendelijke prompts. Controleer ook op een echte telefoon: open de gepubliceerde URL, of deel een previewlink en open die op je telefoon.
Veelgestelde vragen
Wat betekent mobielvriendelijk (responsive)?
Een responsive website past zijn indeling aan het scherm aan waarop hij wordt getoond. Dezelfde pagina en URL schikken zich opnieuw voor een telefoon, tablet of desktop — kolommen worden onder elkaar gezet, afbeeldingen krimpen, menu's klappen in — in plaats van een verkleinde desktoppagina of een aparte mobiele site te tonen.
Waarom ziet mijn site er op een telefoon uitgezoomd uit?
Bijna altijd door de ontbrekende viewport-metatag. Zonder die tag rendert een mobiele browser de pagina alsof het scherm desktopbreedte heeft, en verkleint hij die daarna. Voeg een viewport-tag toe met width=device-width en initial-scale=1.
Voor welke schermformaten moet ik ontwerpen?
Ontwerp voor de inhoud, niet voor apparaten: begin rond 320 tot 375 pixels breed en voeg breakpoints toe waar de indeling er fout begint uit te zien. Veelgebruikte frameworks zoals Tailwind CSS gebruiken standaardbreakpoints rond 640, 768, 1024 en 1280 pixels.
Beïnvloedt mobielvriendelijkheid de posities in Google?
Google gebruikt de mobiele versie van een pagina voor indexering, dus content of links die op mobiel ontbreken, kunnen ook ontbreken in het beeld dat Google van de pagina heeft. Een bruikbare mobiele indeling is ook belangrijk voor Core Web Vitals en voor bezoekers.