Robots.txt uitgelegd: wat is het en hoe gebruik je het voor SEO?
Een robots.txt-bestand is klein, maar kan een grote invloed hebben op hoe zoekmachines je website bezoeken. Met enkele regels geef je crawlers instructies over welke delen van je website ze mogen bekijken en welke ze beter overslaan.
Dat klinkt eenvoudig, maar robots.txt wordt regelmatig verkeerd begrepen. Zo denken veel website-eigenaren dat je met dit bestand pagina’s uit Google kunt verwijderen. Of dat een geblokkeerde map automatisch beschermd is tegen ongewenste bezoekers. Geen van beide klopt.
Wat doet robots.txt dan wel? Wanneer is het nuttig voor SEO? En hoe zit het tegenwoordig met AI-crawlers zoals GPTBot? We leggen uit hoe het werkt, welke instellingen belangrijk zijn en welke fouten je beter vermijdt.
Wat is robots.txt?
Robots.txt is een tekstbestand dat instructies bevat voor automatische programma’s die websites bezoeken. Zulke programma’s noemen we crawlers of bots. Zoekmachines zoals Google gebruiken ze om webpagina’s te ontdekken, inhoud te analyseren en wijzigingen op websites op te merken.
Het bestand bevindt zich op een vaste plaats: rechtstreeks achter de domeinnaam van je website.
https://theotherconcept.be/robots.txt
Wanneer een crawler je website wil bezoeken, kan die eerst het robots.txt-bestand raadplegen. Daarin staat bijvoorbeeld dat bepaalde mappen niet gecrawld mogen worden of dat een specifieke bot andere regels moet volgen.
Je kunt robots.txt vergelijken met een bord aan de ingang van een gebouw. Het vertelt bezoekers welke ruimtes toegankelijk zijn en welke niet. Alleen is er een belangrijk verschil: robots.txt is een verzameling instructies, geen afgesloten deur. Betrouwbare zoekmachinecrawlers respecteren die instructies, maar niet iedere bot doet dat.
Waarom bestaat robots.txt eigenlijk?
Toen zoekmachines het internet begonnen te doorzoeken, ontstond de behoefte om websitebeheerders enige controle te geven over automatische bezoeken. In 1994 werd daarvoor het Robots Exclusion Protocol geïntroduceerd.
Het principe was eenvoudig: één publiek toegankelijk bestand waarin website-eigenaren konden aangeven welke delen van hun website crawlers beter niet bezoeken.
In 2022 werd dit protocol formeel vastgelegd in RFC 9309. De basisgedachte is al die jaren grotendeels hetzelfde gebleven, maar het aantal toepassingen en soorten crawlers is sterk gegroeid.
Hoe werkt een robots.txt-bestand?
Een robots.txt-bestand bestaat uit eenvoudige tekstregels. Je hebt er geen ingewikkelde programmeertaal voor nodig.
Een basisvoorbeeld ziet er zo uit:
User-agent: *
Disallow: /private/
Sitemap: https://theotherconcept.be/sitemap_index.xmlDeze regels betekenen het volgende:
- User-agent: * – De instructies gelden voor alle crawlers die deze regels ondersteunen.
- Disallow: /private/ – Crawlers krijgen de instructie om URL’s onder deze map niet te bezoeken.
- Sitemap: – Verwijst naar de XML-sitemap van de website.
De meeste websites hebben geen bijzonder uitgebreid robots.txt-bestand nodig. Vaak volstaan enkele regels om ongewenste crawlactiviteiten te beperken en zoekmachines naar de sitemap te verwijzen.
De belangrijkste robots.txt-richtlijnen
| Richtlijn | Functie |
|---|---|
User-agent |
Bepaalt op welke crawler een groep regels van toepassing is. |
Disallow |
Geeft aan welke URL-paden niet gecrawld mogen worden. |
Allow |
Maakt het mogelijk om uitzonderingen toe te staan binnen een bredere blokkade. |
Sitemap |
Verwijst naar de locatie van een XML-sitemap. |
# |
Wordt gebruikt om commentaar toe te voegen aan het bestand. |
Met User-agent: * richt je je tot alle crawlers. Wil je specifiek instructies geven aan Googlebot, dan kun je een aparte groep maken.
User-agent: Googlebot
Disallow: /voorbeeldmap/Je kunt ook verschillende groepen combineren. Houd er wel rekening mee dat crawlers regels op hun eigen manier kunnen ondersteunen en interpreteren. Een regel die bij Google werkt, hoeft niet automatisch hetzelfde effect te hebben bij iedere andere bot.
Wat betekenen het sterretje en het dollarteken?
Bij Google kun je in URL-patronen ook speciale tekens gebruiken.
Het sterretje * kan overeenkomen met een willekeurige reeks tekens. Het dollarteken $ markeert het einde van een URL.
Bijvoorbeeld:
User-agent: *
Disallow: /*.pdf$Voor Googlebot betekent dit dat URL’s die eindigen op .pdf niet gecrawld mogen worden.
Dat kan in specifieke situaties nuttig zijn, maar het is geen standaardregel die je zomaar op iedere website moet toepassen. Misschien wil je net dat bepaalde PDF-documenten via Google gevonden worden.
Een andere richtlijn die je soms tegenkomt, is Crawl-delay. Sommige crawlers ondersteunen die, maar Googlebot houdt geen rekening met Crawl-delay in robots.txt.
Robots.txt is niet hetzelfde als noindex
Dit is waarschijnlijk het belangrijkste onderscheid in het volledige artikel.
Robots.txt regelt welke URL’s een crawler mag bezoeken. Noindex geeft aan dat een pagina niet in de zoekresultaten mag worden opgenomen.
Dat lijkt misschien op hetzelfde neer te komen, maar technisch zijn het twee verschillende zaken.
Stel dat je een pagina hebt die niet in Google mag verschijnen. Je voegt de volgende regel toe:
User-agent: *
Disallow: /verborgen-pagina/Google krijgt nu de instructie om die pagina niet te crawlen. Maar dat betekent niet noodzakelijk dat de URL uit de zoekresultaten verdwijnt.
Wanneer andere websites naar die URL linken, kan Google het bestaan ervan nog steeds ontdekken. De URL kan dan onder bepaalde omstandigheden in de zoekresultaten verschijnen, zelfs zonder dat Google de inhoud heeft bezocht.
Wil je voorkomen dat een toegankelijke pagina geïndexeerd wordt, dan gebruik je doorgaans een noindex-instructie.
Waarom robots.txt en noindex elkaar kunnen tegenwerken
Een veelgemaakte fout is om dezelfde pagina zowel via robots.txt te blokkeren als een noindex-instructie mee te geven.
Het probleem? Als Google de pagina niet mag crawlen, kan Google de noindex-instructie op die pagina mogelijk niet lezen.
Daardoor bereik je net niet wat je wilde.
Wil je een pagina uit de zoekresultaten houden, dan moet Google de noindex-instructie kunnen ontdekken. Voor echt vertrouwelijke informatie is zelfs dat niet voldoende: die beveilig je met toegangscontrole, bijvoorbeeld via een wachtwoord.
En wat doet een XML-sitemap dan?
Een XML-sitemap heeft opnieuw een andere functie. Ze helpt zoekmachines belangrijke URL’s van je website te ontdekken.
Waar robots.txt bepaalde crawlactiviteiten kan beperken, geeft een sitemap juist aan welke URL’s je onder de aandacht van zoekmachines wilt brengen.
Een sitemap is geen garantie op indexering en kan een blokkade in robots.txt niet opheffen.
In ons artikel over XML-sitemaps en SEO leggen we uitgebreider uit hoe zo’n sitemap werkt en waarom een correcte samenstelling belangrijk is.
Welke pagina’s kun je beter wel of niet blokkeren?
Niet iedere URL op een website is even belangrijk voor zoekmachines.
Een website kan bijvoorbeeld interne zoekresultaten, filtercombinaties, tijdelijke URL’s of technische onderdelen bevatten die weinig waarde hebben als afzonderlijke zoekresultaten.
Voor sommige van die URL’s kan het nuttig zijn om crawling te beperken. Maar dat betekent niet dat je ze allemaal automatisch in robots.txt moet blokkeren.
Wanneer kan een blokkade nuttig zijn?
Denk aan een grote webshop met honderden productfilters. Eén categorie kan via combinaties van kleur, maat, merk en prijs duizenden verschillende URL’s opleveren.
Wanneer zoekmachines al die varianten proberen te bezoeken, kan dat onnodige crawlactiviteit veroorzaken.
In zo’n situatie kan robots.txt onderdeel zijn van een bredere technische SEO-aanpak. Je moet dan wel rekening houden met de vraag of bepaalde filterpagina’s misschien juist relevant zijn voor organisch zoekverkeer.
Ook technische mappen of interne zoekresultaten kunnen kandidaten zijn, afhankelijk van hoe de website is opgebouwd.
Wat blokkeer je doorgaans beter niet?
Belangrijke dienstenpagina’s, productpagina’s, categoriepagina’s en blogartikelen moeten normaal toegankelijk blijven voor zoekmachines.
Hetzelfde geldt voor CSS- en JavaScript-bestanden die nodig zijn om je website correct weer te geven. Google probeert pagina’s namelijk ook te begrijpen zoals een bezoeker ze ziet.
Als je essentiële bestanden blokkeert, kan dat de manier waarop Google je pagina interpreteert negatief beïnvloeden.
Let ook op met het blokkeren van afbeeldingen. Wanneer je wilt dat productfoto’s of andere beelden via Google Afbeeldingen gevonden worden, is het doorgaans niet verstandig om hun bestanden voor Googlebot-Image af te schermen.
Robots.txt instellen in WordPress
Gebruik je WordPress? Dan hoef je niet noodzakelijk zelf een robots.txt-bestand aan te maken.
WordPress kan standaard een virtueel robots.txt-bestand aanbieden. Dat betekent dat de inhoud dynamisch wordt weergegeven, ook wanneer er geen fysiek bestand in de hoofdmap van je hosting staat.
Een veelvoorkomend voorbeeld voor WordPress is:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://theotherconcept.be/sitemap_index.xmlHiermee wordt de WordPress-beheermap voor crawlers geblokkeerd, met een uitzondering voor het bestand admin-ajax.php.
De sitemap-URL is slechts een voorbeeld. Welke URL je gebruikt, hangt af van de sitemap die jouw website daadwerkelijk aanbiedt.
Kun je robots.txt aanpassen met Yoast SEO?
Bij WordPress zijn er verschillende manieren om robots.txt te beheren. Afhankelijk van je configuratie kun je hiervoor een SEO-plugin, een bestandsbeheerder of een FTP-verbinding gebruiken.
Yoast SEO biedt in bepaalde configuraties een bestandseditor waarmee je robots.txt kunt aanmaken of aanpassen. De beschikbaarheid daarvan hangt onder meer af van je WordPress- en serverinstellingen.
Werk je met een fysiek robots.txt-bestand, dan heeft dat doorgaans voorrang op het virtuele bestand van WordPress.
Pas robots.txt nooit zomaar aan omdat een online voorbeeld beweert dat bepaalde regels je SEO-score verbeteren. De juiste instellingen hangen af van je website, je technische opbouw en de URL’s die je wilt laten crawlen.
En wat met WooCommerce?
Bij WooCommerce komen er extra aandachtspunten bij.
Een webshop heeft vaak een winkelmandje, afrekenpagina, klantaccount, productfilters en interne zoekresultaten. Sommige van die URL’s hoeven niet in Google te verschijnen.
Toch is robots.txt niet automatisch de beste oplossing om ze uit de zoekresultaten te houden. Voor bepaalde pagina’s is noindex geschikter, terwijl je voor filter- en parameter-URL’s ook moet kijken naar canonical-tags, interne links en de structuur van de webshop.
Een goede WooCommerce-configuratie is dus meer dan een lijstje mappen blokkeren.
Veelgemaakte fouten met robots.txt
Een verkeerd robots.txt-bestand kan belangrijke delen van je website ontoegankelijk maken voor zoekmachines. Daarom is het verstandig om wijzigingen altijd zorgvuldig te controleren.
Per ongeluk je volledige website blokkeren
De bekendste fout is deze:
User-agent: *
Disallow: /Deze regels geven alle crawlers die ze respecteren de instructie om geen enkele URL van de website te crawlen.
Zo’n instelling kan bewust worden gebruikt tijdens de ontwikkeling van een website. Maar wanneer ze na de lancering blijft staan, kan dat grote gevolgen hebben voor de organische vindbaarheid.
Een bestaande indexering verdwijnt daardoor niet noodzakelijk onmiddellijk, maar zoekmachines kunnen de inhoud niet meer normaal opnieuw crawlen.
Robots.txt gebruiken als beveiliging
Een robots.txt-bestand is publiek toegankelijk. Iedereen kan het openen en zien welke paden je erin vermeldt.
Het is daarom geen geschikte plaats om gevoelige URL’s te verbergen.
Een regel zoals Disallow: /vertrouwelijke-documenten/ verhindert niet dat iemand die het adres kent de bestanden rechtstreeks probeert te openen.
Voor vertrouwelijke informatie gebruik je echte beveiliging, zoals authenticatie en correcte toegangsrechten.
Verkeerde paden of onnodige blokkades
Robots.txt werkt met URL-paden. Een kleine fout kan ervoor zorgen dat een regel meer of minder blokkeert dan je bedoelde.
Ook een robots.txt-bestand op de verkeerde locatie werkt niet zoals verwacht. Het bestand hoort in de hoofdmap van de betreffende host en geldt niet automatisch voor andere subdomeinen.
Controleer daarom altijd het uiteindelijke effect van je regels, niet alleen of het bestand technisch bestaat.
Robots.txt en AI-crawlers: kun je AI-bots blokkeren?
Robots.txt krijgt tegenwoordig een extra dimensie door de opkomst van generatieve AI.
Naast traditionele zoekmachinecrawlers bezoeken ook AI-gerelateerde systemen websites. Sommige verzamelen informatie die mogelijk wordt gebruikt voor modeltraining, terwijl andere websites bezoeken om informatie voor zoek- en antwoordfuncties te verzamelen.
Die toepassingen zijn niet allemaal hetzelfde. Daarom is het belangrijk om te begrijpen welke crawler je precies aanstuurt.
Wat is het verschil tussen GPTBot en OAI-SearchBot?
OpenAI maakt onder meer onderscheid tussen twee crawlers.
GPTBot wordt gebruikt om inhoud te crawlen die mogelijk kan bijdragen aan de training van generatieve AI-modellen.
OAI-SearchBot wordt gebruikt voor zoekfuncties van ChatGPT. Deze crawler helpt websites vindbaar te maken binnen de zoekresultaten van ChatGPT.
Je kunt voor beide afzonderlijke robots.txt-instructies instellen.
Stel dat je crawling voor mogelijke modeltraining wilt beperken, maar wel gevonden wilt kunnen worden via ChatGPT Search. Dan kan een configuratie er bijvoorbeeld zo uitzien:
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Allow: /Hiermee geef je GPTBot de instructie om je website niet te crawlen, terwijl OAI-SearchBot toegang krijgt.
Dat is geen garantie dat je website daadwerkelijk in ChatGPT-antwoorden verschijnt. Het betekent alleen dat je die specifieke zoekcrawler niet via robots.txt blokkeert.
OpenAI gebruikt daarnaast ChatGPT-User voor bepaalde bezoeken die door een gebruiker worden gestart. Omdat dit geen gewone automatische zoekcrawler is, kunnen robots.txt-regels daar anders op van toepassing zijn.
De actuele verschillen staan beschreven in de officiële documentatie over OpenAI-crawlers.
En hoe zit het met Google-Extended?
Google heeft met Google-Extended een afzonderlijk controlemechanisme waarmee websitebeheerders bepaalde toepassingen van hun inhoud voor Google’s generatieve AI-systemen kunnen beperken.
Google-Extended is geen afzonderlijke crawler die zelfstandig je website bezoekt, maar een controletoken dat via robots.txt gebruikt wordt.
Belangrijk: Google-Extended blokkeren is niet hetzelfde als Googlebot blokkeren. Het betekent ook niet dat je pagina’s automatisch verdwijnen uit AI Overviews of andere AI-functies binnen Google Search.
Voor de AI-functies van Google Search blijven de gewone zoek- en previewinstellingen relevant. Denk bijvoorbeeld aan noindex, nosnippet en andere ondersteunde previewbeperkingen.
Wat is het verschil tussen robots.txt en llms.txt?
Door de opkomst van AI wordt ook steeds vaker gesproken over llms.txt.
Hoewel de bestandsnamen op elkaar lijken, hebben ze een ander doel.
Robots.txt is een gevestigde standaard voor het aansturen van crawlers. Llms.txt is een voorstel om AI-systemen een gestructureerd overzicht van relevante website-inhoud aan te bieden.
Het is dus geen vervanging voor robots.txt en biedt niet dezelfde controle over crawling.
In ons artikel llms.txt: nuttig voor AI-vindbaarheid of vooral hype? bekijken we wat dat bestand precies belooft en welke beperkingen er vandaag nog zijn.
Hoe controleer je of je robots.txt correct werkt?
Je hoeft geen programmeur te zijn om de basis van je robots.txt te controleren.
Begin door je domeinnaam te openen met /robots.txt erachter. Verschijnt er een tekstbestand, dan kun je de regels rechtstreeks bekijken.
Controleer vervolgens of er geen algemene blokkade staat die je volledige website uitsluit. Kijk ook of belangrijke onderdelen, zoals je dienstenpagina’s, blogartikelen en productpagina’s, toegankelijk blijven.
Voor een meer gerichte controle kun je gebruikmaken van Google Search Console.
Met de URL-inspectietool kun je onderzoeken of Google een specifieke pagina mag crawlen en welke indexeringsinformatie beschikbaar is. Daarnaast biedt Search Console informatie over de robots.txt-bestanden die Google voor je website heeft opgehaald.
De officiële robots.txt-documentatie van Google is een goede referentie wanneer je twijfelt over de werking van een bepaalde regel.
Controleer ook wat er na een wijziging gebeurt
Een robots.txt-aanpassing heeft niet noodzakelijk onmiddellijk effect. Zoekmachines bewaren het bestand tijdelijk en moeten gewijzigde regels opnieuw ophalen en verwerken.
Daarom is het verstandig om na een aanpassing belangrijke URL’s te controleren en eventuele crawlproblemen op te volgen.
Wil je daarnaast de technische kwaliteit van je website onderzoeken? Met Google Lighthouse kun je onder andere prestaties, toegankelijkheid en bepaalde technische SEO-aspecten analyseren. Voor de specifieke werking van robots.txt blijft Search Console de meest gerichte keuze.
Heeft robots.txt invloed op je SEO?
Ja, maar niet op de manier die soms wordt voorgesteld.
Een robots.txt-bestand is geen rechtstreekse rankingfactor waarmee je hoger in Google verschijnt. Door een extra regel toe te voegen, stijgt je website dus niet automatisch in de zoekresultaten.
Het bestand kan wel een belangrijke rol spelen in de technische toegankelijkheid van je website.
Wanneer zoekmachines je belangrijkste pagina’s niet mogen crawlen, kunnen ze de inhoud niet normaal verwerken. Omgekeerd kan het beperken van onnodige crawlactiviteiten op grote websites helpen om beschikbare crawlcapaciteit gerichter te benutten.
Dat brengt ons bij het begrip crawlbudget.
Wat is crawlbudget?
Crawlbudget verwijst naar de hoeveelheid URL’s die een zoekmachine binnen een bepaalde periode kan en wil crawlen.
Voor een kleine bedrijfswebsite met enkele tientallen pagina’s is crawlbudget doorgaans geen groot aandachtspunt. Google kan zulke websites meestal zonder problemen bezoeken.
Bij grote webshops, nieuwssites of websites met zeer veel URL-varianten kan dat anders liggen. Daar kunnen overbodige filterpagina’s, parameters en dubbele URL’s onnodig veel crawlactiviteit veroorzaken.
Robots.txt kan dan onderdeel zijn van een bredere strategie, samen met een goede URL-structuur, interne links, canonical-tags en een verzorgde XML-sitemap.
Wie zijn website beter vindbaar wil maken, moet dus verder kijken dan één technisch bestand. In ons artikel over hoger scoren in Google bespreken we de belangrijkste SEO-principes die samen het verschil maken.
Veelgestelde vragen over robots.txt
Is een robots.txt-bestand verplicht?
Nee. Een website heeft niet verplicht een robots.txt-bestand nodig. Als er geen geldig bestand aanwezig is, kunnen zoekmachines de website doorgaans crawlen, voor zover andere technische beperkingen dat toelaten. Je gebruikt robots.txt vooral wanneer je bepaalde crawlactiviteiten bewust wilt sturen.
Kan Google een geblokkeerde pagina toch indexeren?
Ja. Een URL die via robots.txt geblokkeerd is, kan onder bepaalde omstandigheden toch in de zoekresultaten verschijnen, bijvoorbeeld wanneer andere websites ernaar linken. Google kan de inhoud dan niet normaal crawlen, maar kent mogelijk wel het bestaan van de URL.
Kan ik robots.txt gebruiken om een pagina uit Google te verwijderen?
Niet betrouwbaar. Voor een toegankelijke pagina die je niet geïndexeerd wilt hebben, gebruik je doorgaans noindex. Voor vertrouwelijke informatie is toegangsbeveiliging noodzakelijk. Robots.txt is geen vervanging voor die maatregelen.
Hoe vaak leest Google mijn robots.txt?
Google haalt robots.txt regelmatig opnieuw op en bewaart het bestand doorgaans tijdelijk in een cache. Hoe snel een wijziging wordt verwerkt, kan variëren. Ga er daarom niet van uit dat nieuwe regels onmiddellijk door iedere crawler worden toegepast.
Is robots.txt hetzelfde als llms.txt?
Nee. Robots.txt bevat instructies over crawling. Llms.txt is een voorstel om AI-systemen te helpen relevante website-inhoud te vinden en te interpreteren. Het heeft niet dezelfde status of functie als robots.txt.
Moet ik AI-crawlers blokkeren?
Dat hangt af van je doelstellingen. Wil je vooral voorkomen dat bepaalde systemen je inhoud voor modeltraining crawlen, dan kun je specifieke bots beperken. Wil je juist zo goed mogelijk gevonden worden via AI-zoekfuncties, dan moet je opletten dat je de daarvoor gebruikte crawlers niet onbedoeld blokkeert.
Een klein bestand met grote gevolgen
Robots.txt is geen magische SEO-oplossing, maar wel een belangrijk onderdeel van de technische basis van je website.
Met de juiste regels kun je zoekmachinecrawlers helpen om je website efficiënter te bezoeken. Met verkeerde regels kun je echter ook belangrijke pagina’s onbedoeld afsluiten.
Het belangrijkste is daarom niet dat je robots.txt zoveel mogelijk instructies bevat, maar dat iedere regel een duidelijke reden heeft.
Bij The Other Concept bekijken we technische SEO altijd als onderdeel van het grotere geheel. Van websitestructuur en indexering tot laadsnelheid en vindbaarheid in zoekmachines en AI-toepassingen. Want een website moet niet alleen goed ogen en vlot werken, maar ook correct ontdekt en begrepen kunnen worden.
Ontdek hoe we dat aanpakken met SEO en AI-vindbaarheid.
Laatst bijgewerkt op 14 oktober 2026.
Gerelateerde artikelen
Schema.org: wat is structured data en waarom is het belangrijk?
Een bezoeker begrijpt meestal onmiddellijk wat hij op een webpagina ziet. Een naam is een bedrijfsnaam, een bedrag is de prijs van een product en vijf sterren naast een testimonial stellen waarschijnlijk een beoordeling voor.
Voor zoekmachines ligt dat anders.
HTML vertelt vooral hoe een pagina is opgebouwd. Met Schema.org kun je extra informatie toevoegen die expliciet beschrijft wat bepaalde gegevens betekenen. Je vertelt een zoekmachine bijvoorbeeld dat iets een organisatie, persoon, artikel, product, evenement of adres is.
Die informatie noemen we structured data of gestructureerde gegevens.
Schema.org is daarmee een interessante aanvulling op technische SEO. Niet omdat enkele regels code je website plots hoger in Google plaatsen, maar omdat je machines helpt de inhoud en betekenis van je website beter te begrijpen.
Wat is Schema.org?
Schema.org is een gezamenlijke standaard voor gestructureerde gegevens op het web.
Het project werd oorspronkelijk opgericht door Google, Microsoft, Yahoo en Yandex en wordt vandaag verder ontwikkeld als een open communityproject.
Schema.org bevat een uitgebreide woordenschat waarmee je kunt beschrijven wat bepaalde informatie op een webpagina voorstelt.
Stel bijvoorbeeld dat ergens op een website staat:
The Other Concept
Voor een bezoeker kan uit de context duidelijk zijn dat dit de naam van een onderneming is. Met Schema.org kun je die betekenis expliciet maken door aan te geven dat The Other Concept een Organization of, wanneer toepasselijk, een specifieker bedrijfstype is.
Hetzelfde kun je doen met een artikel, auteur, product, vacature, evenement, recept of locatie.
Schema.org bevat daarvoor honderden verschillende types en nog veel meer eigenschappen waarmee die types verder beschreven kunnen worden.
Wat is structured data?
Schema.org en structured data worden vaak als synoniemen gebruikt, maar technisch gezien zijn ze niet helemaal hetzelfde.
Schema.org is de woordenschat.
Structured data is de manier waarop je informatie gestructureerd aan machines doorgeeft.
Je kunt het vergelijken met een taal en een zin die je met die taal schrijft.
Schema.org bepaalt bijvoorbeeld dat er een type Article bestaat en dat je daar eigenschappen zoals een titel, auteur en publicatiedatum aan kunt koppelen.
Vervolgens plaats je die informatie in een formaat dat machines kunnen lezen.
Schema.org kan onder andere gebruikt worden via Microdata, RDFa en JSON-LD. Voor veel moderne implementaties is JSON-LD bijzonder praktisch, omdat de structured data los van de zichtbare HTML kan worden opgenomen.
Hoe ziet Schema.org eruit?
Stel dat je een blogartikel publiceert met de titel Wat is Schema.org?. Met JSON-LD zou een sterk vereenvoudigd voorbeeld er ongeveer zo kunnen uitzien:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Wat is Schema.org?",
"author": {
"@type": "Organization",
"name": "The Other Concept"
},
"publisher": {
"@type": "Organization",
"name": "The Other Concept"
}
}
</script>Een gewone bezoeker hoeft deze code niet te zien.
Voor machines bevat ze daarentegen expliciete informatie. We vertellen onder andere dat deze pagina een blogpost bevat en dat The Other Concept eraan gekoppeld is als auteur en uitgever.
In werkelijkheid kan een implementatie uitgebreider zijn. Bij een artikel kun je bijvoorbeeld ook de publicatiedatum, wijzigingsdatum, afbeeldingen en URL van de auteur meegeven.
Google ondersteunt voor artikels onder andere de Schema.org-types Article, NewsArticle en BlogPosting.
Waarom gebruiken zoekmachines structured data?
Een zoekmachine probeert voortdurend te begrijpen wat een pagina betekent.
De woorden op de pagina, titels, interne links, afbeeldingen en algemene structuur leveren daarvoor allerlei signalen. Interne links helpen daarbij om relaties tussen pagina’s en onderwerpen zichtbaar te maken, terwijl structured data expliciete machineleesbare informatie aan de inhoud toevoegt.
Je laat daardoor een deel van de betekenis minder aan interpretatie over.
Dat betekent niet dat Google blindelings gelooft wat je in je Schema.org-code zet. De structured data moet overeenkomen met de daadwerkelijke inhoud van de pagina.
Het voordeel zit vooral in duidelijkheid.
Met de juiste structured data kan een zoekmachine bijvoorbeeld beter herkennen:
- welke organisatie bij een website hoort;
- wie een artikel geschreven heeft;
- dat een pagina over een specifiek product gaat;
- wat de prijs en beschikbaarheid van dat product zijn;
- dat bepaalde informatie een evenement of vacature beschrijft;
- hoe verschillende onderdelen van een website met elkaar samenhangen.
Die expliciete betekenis is precies waarom structured data interessant is binnen technische SEO.
Schema.org en rich results in Google
Structured data kan in bepaalde gevallen ook gebruikt worden om pagina’s in aanmerking te laten komen voor uitgebreidere zoekresultaten.
Google noemt die rich results.
Afhankelijk van het type content kan Google extra informatie uit structured data gebruiken om een zoekresultaat anders weer te geven. Denk bijvoorbeeld aan bepaalde productinformatie, recepten of evenementen.
Maar hier is een belangrijke nuance nodig:
Schema.org toevoegen betekent niet automatisch dat je een rich result krijgt.
Google bepaalt zelf welke zoekresultaten en functies worden weergegeven. Bovendien ondersteunt Google voor zoekfuncties slechts een selectie van de veel grotere Schema.org-woordenschat.
Je moet daarom onderscheid maken tussen twee dingen:
Schema.org gebruiken om informatie semantisch te beschrijven
en
structured data gebruiken die door Google voor een specifieke zoekfunctie wordt ondersteund.
Dat zijn niet noodzakelijk dezelfde zaken.
Wie structured data implementeert met een specifiek Google-resultaat als doel, controleert daarom het best de actuele Google Search Gallery met ondersteunde structured data.
Zorgt Schema.org voor hogere posities in Google?
Dit is waarschijnlijk de belangrijkste misvatting rond structured data.
Schema.org is geen knop waarmee je rechtstreeks een hogere positie in Google koopt.
Je kunt dus niet simpelweg zoveel mogelijk schema’s aan een website toevoegen en verwachten dat je daardoor boven concurrenten verschijnt.
Structured data helpt zoekmachines vooral om de informatie op een pagina explicieter te begrijpen en kan, wanneer Google het betreffende type ondersteunt, helpen om in aanmerking te komen voor bepaalde zoekfuncties.
Goede SEO blijft veel breder.
Technische kwaliteit, relevante content, interne structuur, autoriteit, gebruiksvriendelijkheid en de mate waarin een pagina aansluit bij de zoekintentie blijven allemaal belangrijk.
Zie Schema.org daarom als een extra informatielaag bovenop een website die inhoudelijk en technisch al goed in elkaar zit.
Welke Schema.org-types zijn interessant voor een bedrijfswebsite?
Welke structured data nuttig is, hangt volledig af van de website.
Een lokale onderneming heeft andere informatie dan een webshop of nieuwssite.
Toch zijn er enkele types die regelmatig relevant kunnen zijn.
Organization en LocalBusiness
Met Organization kun je informatie over een organisatie structureren.
Voor lokale bedrijven bestaan daarnaast LocalBusiness en verschillende specifiekere subtypes.
Daarbij kunnen eigenschappen worden gekoppeld zoals de naam, URL, logo, contactgegevens en andere informatie die daadwerkelijk bij de organisatie hoort.
Het doel is niet om ieder denkbaar veld in te vullen. Voeg vooral correcte informatie toe die relevant is voor de onderneming en overeenkomt met wat op de website wordt gecommuniceerd.
Article en BlogPosting
Voor artikels zoals deze kan Article of het specifiekere BlogPosting gebruikt worden.
Daarmee kun je bijvoorbeeld duidelijk maken wat de titel is, wanneer het artikel gepubliceerd en aangepast werd en wie de auteur is.
Google geeft aan dat Article structured data kan helpen om meer informatie over een artikel te begrijpen, zoals de auteur, titel, afbeeldingen en datums.
Dat maakt correcte publicatie- en wijzigingsdatums extra interessant. Zeker wanneer oudere content regelmatig wordt geactualiseerd.
Product
Voor webshops is Product een belangrijk Schema.org-type.
Je kunt daarmee productinformatie structureren en koppelen aan bijvoorbeeld een merk, SKU en aanbiedingen. Binnen een Offer kunnen vervolgens gegevens zoals prijs, valuta en beschikbaarheid worden opgenomen.
Google ondersteunt uitgebreide structured data voor producten en kan dergelijke informatie gebruiken voor verschillende productgerelateerde ervaringen in Search.
BreadcrumbList
Breadcrumbs maken duidelijk waar een pagina zich binnen de structuur van een website bevindt.
Met BreadcrumbList kan die hiërarchie ook als structured data beschreven worden.
Dat is een mooi voorbeeld van Schema.org dat aansluit bij iets wat bezoekers eveneens helpt: een logische websitestructuur.
Moet je FAQ-schema aan je FAQ toevoegen?
Hier is het belangrijk om niet met verouderd SEO-advies te werken.
Jarenlang werd aangeraden om FAQ-secties bijna standaard van FAQPage-structured data te voorzien omdat Google vragen en antwoorden uitgebreid in de zoekresultaten kon weergeven.
Dat landschap is veranderd.
Google beperkt de zichtbaarheid van FAQ-rich results sterk en geeft aan dat deze voornamelijk beschikbaar zijn voor bekende, gezaghebbende websites binnen overheid en gezondheid.
Dat betekent niet dat een FAQ op je website plots geen waarde meer heeft.
Integendeel: een goede FAQ kan bezoekers snel antwoord geven, relevante onderwerpen behandelen en een pagina inhoudelijk completer maken.
Maar FAQ-schema toevoegen puur omdat je verwacht daarmee extra ruimte in Google in te nemen, is voor een doorsnee bedrijfswebsite geen sterke strategie meer.
Dit illustreert meteen waarom structured data onderhouden moet worden: zoekmachines veranderen regelmatig welke markup ze daadwerkelijk voor zoekfuncties gebruiken.
En wat betekent Schema.org voor AI-vindbaarheid?
Hier wordt het bijzonder interessant.
Zoekmachines zijn niet langer de enige systemen die informatie op websites proberen te interpreteren. AI-zoekmachines, assistenten en andere systemen proberen eveneens te begrijpen welke bedrijven, personen, producten, diensten en onderwerpen op het web beschreven worden.
Structured data is daarbij aantrekkelijk omdat informatie expliciet en machineleesbaar wordt gemaakt.
Maar ook hier moeten we voorzichtig zijn met grote claims.
Er is geen universele regel die zegt dat het toevoegen van Schema.org ervoor zorgt dat ChatGPT, Google AI Overviews of andere AI-systemen jouw bedrijf vaker zullen noemen.
Structured data is dus geen gegarandeerde snelweg naar AI-zichtbaarheid.
Wel past het principe uitstekend binnen een bredere aanpak rond SEO en AI-vindbaarheid: zorg dat belangrijke informatie over je organisatie, diensten, auteurs en content duidelijk, consistent en technisch begrijpelijk wordt aangeboden.
Schema.org kan daar één onderdeel van zijn.
Structured data is overigens niet de enige manier waarop informatie specifiek voor machines gestructureerd kan worden aangeboden. Een recenter initiatief is llms.txt, een voorgestelde standaard die AI-agents naar belangrijke informatie en bronnen op een website kan leiden. Beide hebben een andere functie: Schema.org beschrijft de betekenis van gegevens op een pagina, terwijl llms.txt vooral als gecureerde toegangspoort tot informatie bedoeld is.
Meer Schema.org is niet automatisch beter
Wanneer mensen structured data ontdekken, ontstaat soms de neiging om zoveel mogelijk schema’s toe te voegen.
Dat is niet het doel.
Structured data moet beschrijven wat daadwerkelijk op je website aanwezig is.
Een dienst wordt geen product omdat je graag Product-schema wilt gebruiken. Een verzameling testimonials mag je niet zomaar omvormen tot structured data met fantastische ratings wanneer die markup niet aan de relevante richtlijnen voldoet.
Hetzelfde geldt voor informatie die niet zichtbaar of controleerbaar op de pagina aanwezig is.
Een goede implementatie is daarom eerder correct en doelgericht dan zo uitgebreid mogelijk.
Gebruik het meest specifieke type dat werkelijk bij de content past, vul relevante eigenschappen in en zorg ervoor dat de gegevens overeenkomen met de informatie die bezoekers zien.
Hoe voeg je Schema.org toe aan WordPress?
Wie WordPress gebruikt, hoeft niet noodzakelijk iedere regel JSON-LD zelf te schrijven.
SEO-plugins en andere gespecialiseerde plugins kunnen automatisch bepaalde structured data genereren voor onder andere websites, organisaties, personen, artikels en breadcrumbs.
Dat is handig, maar automatisering betekent niet dat je er niet meer naar hoeft te kijken.
Controleer bijvoorbeeld of de plugin de juiste organisatiegegevens gebruikt, of auteurs correct worden aangeduid en welk type aan verschillende pagina’s wordt toegekend.
Bij complexere websites kan daarnaast aangepaste structured data nodig zijn.
Let vooral op wanneer meerdere plugins tegelijk Schema.org genereren. Twee plugins kunnen dezelfde organisatie, breadcrumbs of andere informatie ieder op hun eigen manier toevoegen. Dat hoeft technisch niet altijd fout te zijn, maar kan wel tot onnodige of tegenstrijdige markup leiden.
Hoe controleer je structured data?
Na implementatie moet je structured data testen.
Daarvoor zijn twee tools bijzonder nuttig.
Google Rich Results Test
Met de Rich Results Test van Google kun je controleren of Google ondersteunde structured data op een pagina detecteert en of er problemen zijn die de geschiktheid voor rich results beïnvloeden.
De tool is vooral interessant wanneer je markup gebruikt waarvoor Google een specifieke zoekfunctie ondersteunt.
Schema.org Validator
Daarnaast bestaat de Schema.org Validator.
Deze kijkt breder naar Schema.org-markup en is daardoor ook nuttig voor types en eigenschappen die niet noodzakelijk gekoppeld zijn aan een Google rich result.
Het verschil is belangrijk.
Een Schema.org-implementatie kan technisch geldig zijn zonder dat Google daar een speciaal zoekresultaat voor aanbiedt.
Schema.org is geen SEO-truc, maar een extra informatielaag
Structured data is op zijn best wanneer je het niet als truc behandelt.
Een zoekmachine probeert te begrijpen wat je website vertelt. Schema.org geeft je een gestandaardiseerde manier om een deel van die betekenis expliciet te maken.
Je kunt aangeven dat iets een organisatie is, dat een bepaalde persoon een artikel geschreven heeft, dat een pagina een product beschrijft of dat een reeks links een breadcrumb vormt.
Dat kan zoekmachines helpen om informatie beter te interpreteren en kan voor ondersteunde contenttypes bijdragen aan uitgebreidere zoekresultaten.
Tegelijk vervangt Schema.org geen sterke content, goede websitestructuur of technische SEO.
Bij The Other Concept bekijken we structured data daarom als onderdeel van een bredere aanpak rond SEO en AI-vindbaarheid. Niet zoveel mogelijk markup toevoegen, maar de juiste informatie op een technisch correcte en begrijpelijke manier aanbieden.
Want uiteindelijk draait Schema.org om iets heel eenvoudigs: machines duidelijker vertellen wat mensen op je website vanzelf begrijpen.
Laatst bijgewerkt op 29 september 2026.
Gerelateerde artikelen
Wix website maken? 8 nadelen om eerst te kennen
Wix maakt het bijzonder eenvoudig om zelf een website te bouwen. Je kiest een template, sleept onderdelen naar hun plaats en kunt zonder technische kennis relatief snel online staan.
Voor een eenvoudige website kan dat precies zijn wat je nodig hebt.
Toch zijn er ook beperkingen. Zeker wanneer een website later moet groeien, technisch maatwerk nodig heeft of een belangrijk onderdeel van je onderneming wordt, kunnen keuzes die in het begin handig lijken uiteindelijk minder flexibel blijken.
Is Wix daarom een slecht platform? Nee.
Maar voordat je een Wix website laat maken of zelf bouwt, zijn er een aantal nadelen die je best kent.
Wix is vandaag niet hetzelfde platform als enkele jaren geleden
Dat moeten we eerst duidelijk maken.
Wie oudere vergelijkingen tussen Wix en andere CMS-systemen leest, komt regelmatig kritiek tegen die vandaag niet meer volledig klopt.
Vooral rond SEO is Wix sterk geëvolueerd.
Je kunt onder andere SEO-titels en meta descriptions aanpassen, URL’s beheren, redirects instellen, canonical tags wijzigen, structured data toevoegen en robots.txt aanpassen. Wix genereert daarnaast XML-sitemaps en biedt integraties met Google Search Console.
De uitspraak Wix is slecht voor SEO is daarom veel te eenvoudig.
SEO-resultaten hangen uiteindelijk veel meer af van de inhoud, structuur, techniek, concurrentie en optimalisatie van een website dan uitsluitend van de naam van het CMS.
De echte beperkingen van Wix liggen vandaag op andere plaatsen.
1. Je website blijft gekoppeld aan het Wix-platform
Dit vinden we een van de belangrijkste verschillen met een open CMS zoals WordPress.
Een Wix-website draait op de infrastructuur van Wix.
Je kunt je eigen domeinnaam gebruiken en dat domein kan zelfs bij een andere provider geregistreerd zijn, maar de website zelf kan niet zomaar worden gedownload en bij een andere hostingprovider geplaatst worden.
Wix legt dit ook zelf uit in zijn documentatie: het platform is een SaaS-oplossing die voor zijn werking afhankelijk is van de eigen technologie en infrastructuur van Wix.
Dat heeft voordelen.
Hosting, beveiliging en technische updates worden centraal geregeld. Je hoeft daardoor veel minder zelf te beheren.
Maar het betekent ook dat je gebonden bent aan het ecosysteem van Wix.
Wil je later volledig naar een ander platform overstappen, dan kun je de bestaande Wix-website niet simpelweg meenemen en ergens anders hosten.
2. Migreren naar een ander platform kan veel werk betekenen
Dat brengt ons meteen bij het tweede nadeel.
Je content blijft natuurlijk van jou. Maar de volledige website — inclusief layout, functionaliteit en Wix-technologie — kun je niet als één werkend geheel exporteren naar bijvoorbeeld WordPress of een eigen server.
Volgens de documentatie van Wix over het exporteren van websites moet een Wix-site op de servers van Wix blijven draaien om correct te functioneren.
Wanneer je later naar een ander CMS wilt overstappen, betekent dat doorgaans dat de website op dat nieuwe platform opnieuw opgebouwd moet worden.
Afhankelijk van de omvang kan ook content, SEO-informatie, formulieren, redirects en andere functionaliteit opnieuw gemigreerd of ingesteld moeten worden.
Bij een website met vijf pagina’s is dat nog overzichtelijk.
Bij een uitgebreide website met honderden pagina’s, blogs, meertaligheid of specifieke functionaliteiten kan zo’n migratie een veel groter project worden.
Denk daarom bij de keuze van een platform niet alleen aan wat je vandaag nodig hebt, maar ook aan wat je over enkele jaren mogelijk wilt kunnen doen.
3. Je hebt minder vrijheid over hosting en infrastructuur
Bij Wix zijn websitebouwer, CMS en hosting onderdeel van hetzelfde ecosysteem.
Dat is gemakkelijk.
Je hoeft geen afzonderlijke hostingpartij te kiezen, updates te installeren of zelf een CDN te configureren.
Maar gemak en vrijheid liggen hier tegenover elkaar.
Bij een zelfgehost CMS kun je bijvoorbeeld van hostingprovider veranderen wanneer je andere prestaties, serverlocaties, support of technische mogelijkheden nodig hebt.
Bij Wix kan dat niet voor de website zelf. Wix geeft aan dat websites op zijn eigen infrastructuur moeten draaien.
Voor veel kleine websites is dat helemaal geen probleem.
Maar voor organisaties die specifieke eisen stellen aan hosting, infrastructuur, deployment of serverconfiguratie kan die beperking wel belangrijk worden.
4. Maatwerk blijft binnen de grenzen van het platform
Wix is veel flexibeler dan de eenvoudige drag-and-drop websitebouwer waar het ooit vooral om bekendstond.
Met Wix Studio, CMS Collections en Velo kun je tegenwoordig behoorlijk uitgebreide websites en toepassingen bouwen.
Dat verdient nuance.
Toch blijft maatwerk plaatsvinden binnen het ecosysteem en de architectuur van Wix.
Wanneer een website specifieke integraties, complexe datastromen of sterk afwijkende functionaliteit nodig heeft, moet je dus bekijken of het platform daarvoor geschikt is.
Dat verschilt fundamenteel van een open-source CMS waarbij ontwikkelaars toegang hebben tot de volledige applicatie en serveromgeving.
Voor een doorsnee bedrijfswebsite merk je daar misschien nooit iets van.
Het verschil wordt vooral relevant wanneer een website evolueert van een verzameling pagina’s naar een belangrijk digitaal bedrijfsplatform.
5. Een pagebuilder maakt goed webdesign niet automatisch eenvoudig
Dit is eigenlijk geen specifiek Wix-probleem.
Hetzelfde geldt voor WordPress pagebuilders, Shopify-thema’s en andere visuele websitebouwers.
Het feit dat je zonder code een website kunt bouwen betekent niet automatisch dat het eenvoudig is om een goede website te bouwen.
Je moet nog steeds nadenken over typografie, witruimte, hiërarchie, mobiele layouts, navigatie, toegankelijkheid, conversie en content.
Juist doordat bijna alles visueel aangepast kan worden, is het gemakkelijk om pagina’s inconsistent te maken.
De ene titel krijgt bijvoorbeeld 42 pixels, de volgende 48. Marges verschillen per pagina. Knoppen krijgen verschillende stijlen en op mobiel blijkt de compositie toch niet goed te werken.
Een professionele website ontstaat niet doordat een editor veel mogelijkheden aanbiedt.
Die mogelijkheden moeten consequent en doelgericht gebruikt worden.
6. Mobiele weergave blijft iets dat je bewust moet controleren
Een website moet vandaag op veel verschillende schermformaten functioneren.
Wix heeft daarvoor responsive en mobiele tools en Wix Studio biedt uitgebreidere responsive mogelijkheden.
Maar ook hier geldt: automatisch aanpassen betekent niet automatisch optimaal.
Een hero die op een desktop uitstekend werkt kan op een smartphone te veel ruimte innemen. Een lange titel kan verkeerd afbreken. Een rij met verschillende onderdelen kan op een klein scherm een onlogische volgorde krijgen.
Test daarom altijd de echte mobiele ervaring.
Kun je gemakkelijk navigeren? Zijn knoppen groot genoeg? Zijn formulieren comfortabel bruikbaar? Staat de belangrijkste informatie snel genoeg in beeld?
Dat geldt overigens voor iedere website, ongeacht het platform.
In ons artikel over mobiele optimalisatie bekijken we uitgebreider waarom responsive design alleen niet voldoende is.
7. De totale kostprijs is niet altijd zo eenvoudig als ze eerst lijkt
Een van de aantrekkingspunten van websitebouwers is dat je met een relatief laag bedrag kunt beginnen.
Maar vergelijk prijzen zorgvuldig.
Welke functies zitten in het abonnement dat je nodig hebt? Heb je e-commerce nodig? Zijn bepaalde apps betalend? Welke marketing- of bedrijfsfunctionaliteit heb je nodig? En wat gebeurt er wanneer je website groeit?
Bij een SaaS-platform betaal je bovendien niet alleen voor hosting. Je betaalt voor het volledige ecosysteem: editor, infrastructuur, onderhoud en beschikbare functionaliteit.
Dat is niet noodzakelijk duur.
Het betekent vooral dat een vergelijking zoals Wix kost X euro en een professionele website kost Y euro weinig zegt zonder te kijken naar wat beide oplossingen daadwerkelijk omvatten.
Kijk daarom naar de totale kost over meerdere jaren en naar de mogelijkheden die je daarvoor krijgt.
8. Je kiest niet alleen een websitebouwer, maar een ecosysteem
Dit is uiteindelijk de rode draad door vrijwel alle voorgaande punten.
Wanneer je voor Wix kiest, kies je niet alleen een editor.
Je kiest ook de hosting, het CMS, de manier waarop uitbreidingen werken, de beschikbare ontwikkeltools en een groot deel van de technische infrastructuur.
Dat is precies waarom Wix aantrekkelijk kan zijn: veel onderdelen zijn al geïntegreerd en worden voor je beheerd.
Maar dezelfde integratie maakt het moeilijker om afzonderlijke onderdelen later te vervangen.
Bij een meer modulaire website kun je bijvoorbeeld alleen de hosting, een plugin, analytics-oplossing of een ander technisch onderdeel vervangen.
Binnen een gesloten SaaS-ecosysteem heb je minder van die vrijheid.
De vraag is daarom niet alleen:
Kan Wix maken wat ik vandaag nodig heb?
Maar ook:
Past het platform bij hoe mijn website de komende jaren moet kunnen evolueren?
Is Wix slecht voor SEO?
Deze vraag verdient een eigen antwoord, omdat hier veel verouderde informatie over bestaat.
Nee, een Wix-website is niet automatisch slecht voor SEO.
Wix ondersteunt tegenwoordig veel technische SEO-functionaliteit. Je kunt onder andere URL’s aanpassen, canonical tags beheren, redirects instellen, structured data toevoegen en robots.txt aanpassen.
Het platform ondersteunt ook server-side rendering en genereert sitemaps.
Wix documenteert zijn huidige mogelijkheden uitgebreid in het overzicht van Wix SEO-functionaliteiten.
Dat betekent uiteraard niet dat iedere Wix-website automatisch goed geoptimaliseerd is.
Een onduidelijke sitestructuur, zwakke content, verkeerde zoekintentie of slechte interne links blijven problemen, ongeacht welk CMS onder de website zit.
SEO begint daarom niet bij de keuze tussen Wix en WordPress.
Het begint bij de kwaliteit van de website die je ermee bouwt.
Wil je meer weten over de bredere basis? In Hoger scoren in Google: 12 SEO-principes bekijken we welke factoren samen een sterke basis voor organische vindbaarheid vormen.
Wanneer is Wix wél een goede keuze?
Ondanks de titel van dit artikel zijn er situaties waarin we Wix helemaal niet zouden afraden.
Wil je zelf snel een relatief eenvoudige website bouwen? Heb je geen behoefte aan complexe functionaliteit? Wil je hosting, updates en techniek zoveel mogelijk uit handen geven?
Dan kan Wix een prima oplossing zijn.
Voor een tijdelijk project, kleine portfolio, eenvoudige informatieve website of ondernemer die vooral zelf aan de slag wil, kunnen de voordelen van het platform zwaarder wegen dan de beperkingen.
Een platform moet uiteindelijk passen bij het project.
Niet andersom.
Wanneer zouden wij eerder voor een alternatief kiezen?
Wanneer een website een belangrijk onderdeel van een onderneming vormt, kijken we verder vooruit.
Moet de website kunnen meegroeien? Verwacht je veel content? Zijn specifieke koppelingen of maatwerk belangrijk? Wil je vrij kunnen kiezen waar de website wordt gehost? Is de mogelijkheid om later van technische partner te veranderen belangrijk?
Dan kan een opener systeem interessanter worden.
Bij The Other Concept bouwen we websites voornamelijk met WordPress, waarbij we design en techniek afstemmen op de onderneming in plaats van een standaardtemplate als uitgangspunt te nemen.
Dat betekent niet dat WordPress voor iedere website automatisch beter is dan Wix.
Het betekent dat we voor professionele bedrijfswebsites veel waarde hechten aan flexibiliteit, uitbreidbaarheid en controle op langere termijn.
Ben je niet zeker welk platform geschikt is voor je nieuwe website? Neem contact op met The Other Concept. We bekijken liever eerst wat je website moet kunnen dan onmiddellijk een technologie naar voren te schuiven.
Wix vermijden? Niet noodzakelijk — maar kies bewust
De oorspronkelijke vraag achter dit artikel was waarom je Wix zou moeten vermijden.
Vandaag zouden we die iets anders formuleren.
Wix heeft veel van zijn vroegere beperkingen weggewerkt en is uitgegroeid tot een veel uitgebreider websiteplatform. Voor bepaalde projecten kan het daardoor een uitstekende keuze zijn.
De belangrijkste nadelen zitten vooral in platformafhankelijkheid, migratiemogelijkheden en technische vrijheid.
Dat zijn beperkingen die je misschien niet merkt wanneer je vandaag een website van vijf pagina’s bouwt.
Maar ze kunnen belangrijk worden wanneer die website over enkele jaren honderden pagina’s bevat, gekoppeld is aan andere systemen of een essentieel onderdeel van je bedrijf is geworden.
Kies een websiteplatform daarom niet uitsluitend op basis van hoe snel je vandaag online kunt staan.
Kies het op basis van wat je website morgen moet kunnen worden.
Laatst aangepast: 24 september 2026.
Gerelateerde artikelen
Waarom WordPress updaten?
WordPress is geen systeem dat je één keer bouwt en daarna jarenlang onaangeroerd kunt laten staan. De software zelf, je thema en de plugins waaruit je website bestaat, worden voortdurend verder ontwikkeld. Regelmatig verschijnen er updates die beveiligingsproblemen oplossen, fouten herstellen en ervoor zorgen dat alle onderdelen goed met elkaar blijven samenwerken.
Een WordPress-website niet onderhouden is daarom geen goed idee. Wat begint met enkele uitgestelde updates kan uiteindelijk leiden tot een gehackte website, gegevensdiefstal, downtime of een website die helemaal niet meer correct functioneert. In het slechtste geval zijn de kosten om alles te herstellen een stuk hoger dan de kost van regelmatig onderhoud.
Waarom moet je WordPress regelmatig updaten?
Een WordPress-website bestaat uit verschillende onderdelen. Naast WordPress zelf gebruik je meestal een thema en meerdere plugins voor bijvoorbeeld formulieren, SEO, meertaligheid, beveiliging of andere functionaliteiten.
Al die onderdelen krijgen afzonderlijk updates. Sommige voegen nieuwe mogelijkheden toe, andere lossen technische problemen op, maar een belangrijk deel heeft te maken met beveiliging en het oplossen van kwetsbaarheden.
WordPress noemt het up-to-date houden van WordPress zelf én alle geïnstalleerde plugins en thema’s als een van de belangrijke maatregelen voor de beveiliging van een WordPress-website. Meer daarover lees je in de officiële WordPress-documentatie over beveiliging.
Dat is niet alleen belangrijk voor grote webshops of websites waarop gevoelige gegevens worden verwerkt. Ook een eenvoudige bedrijfswebsite kan interessant zijn voor aanvallers. Een aanval gebeurt immers lang niet altijd omdat iemand specifiek jouw bedrijf viseert. Verouderde software met gekende kwetsbaarheden vormt op zichzelf al een beveiligingsrisico.
Ook OWASP, een internationale organisatie rond webbeveiliging, neemt kwetsbare en verouderde softwarecomponenten op als een belangrijk beveiligingsrisico.
Een verouderde website kan een beveiligingsrisico worden
Dit is wat ons betreft de belangrijkste reden om updates niet maandenlang te laten liggen.
Wanneer ontwikkelaars een beveiligingslek ontdekken, wordt dat doorgaans opgelost met een update. Blijf je een kwetsbare of verouderde versie gebruiken, dan kan het beveiligingsprobleem op je website aanwezig blijven. Daarom is het belangrijk om beveiligingsupdates niet eindeloos uit te stellen.
WordPress publiceert regelmatig security releases waarin beveiligingsproblemen worden opgelost en gebruikers worden aangeraden hun WordPress-installatie bij te werken.
Een aanvaller kan bij een kwetsbare website bijvoorbeeld proberen toegang te krijgen, bestanden te wijzigen, schadelijke code te plaatsen of gegevens te bemachtigen.
Afhankelijk van je website kunnen daarbij ook persoonsgegevens betrokken zijn. Denk aan gegevens die via contactformulieren worden verstuurd, accounts van gebruikers of informatie uit een webshop.
Updates maanden of zelfs jaren negeren is daarom een risico dat je als bedrijf beter niet neemt.
Websitebeveiliging gaat trouwens verder dan updates alleen. Ook de configuratie van je website en server speelt een rol. Zo kunnen bijvoorbeeld security headers extra bescherming bieden tegen bepaalde soorten aanvallen. In een eerder artikel leggen we uit wat die precies doen.
Een hack kan veel meer kosten dan regelmatig onderhoud
Een gehackte WordPress-website herstellen betekent niet noodzakelijk dat je simpelweg één geïnfecteerd bestand verwijdert.
Er moet worden onderzocht hoe de aanvaller is binnengekomen, welke bestanden gewijzigd zijn en of er nog ongewenste code of gebruikers aanwezig zijn. Mogelijk moet een back-up worden teruggezet, moeten wachtwoorden worden gewijzigd en moeten WordPress, plugins en thema’s gecontroleerd of opnieuw geïnstalleerd worden.
Daarbovenop kan je website tijdelijk onbereikbaar zijn of kunnen bezoekers worden doorgestuurd naar ongewenste pagina’s.
De indirecte schade kan daardoor groter worden dan de technische herstelling zelf. Je website is tenslotte voor veel potentiële klanten een van de eerste contactpunten met je bedrijf.
Preventief onderhouden is vrijwel altijd verstandiger dan wachten tot er iets misgaat.
Updates houden je website ook technisch gezond
Beveiliging is de belangrijkste reden om WordPress te onderhouden, maar zeker niet de enige.
WordPress, thema’s en plugins werken samen. Wanneer één onderdeel jarenlang niet wordt bijgewerkt terwijl andere onderdelen wel veranderen, kunnen compatibiliteitsproblemen ontstaan.
Een formulier dat plots niet meer verzendt, een pagina die verkeerd wordt weergegeven, foutmeldingen in WordPress of functionaliteiten die niet meer werken: achterstallig onderhoud kan zich op allerlei manieren manifesteren.
Updates bevatten bovendien regelmatig bugfixes en technische verbeteringen. Door je website consequent te onderhouden, verklein je de kans dat kleine problemen zich na verloop van tijd opstapelen.
Wil je daarnaast weten hoe je website technisch presteert? Met Google Lighthouse kun je onder andere prestaties, toegankelijkheid en SEO analyseren. We schreven eerder al uitgebreid over hoe je zo’n Lighthouse-analyse interpreteert.
Waarom niet gewoon alle automatische updates inschakelen?
WordPress biedt de mogelijkheid om updates automatisch uit te voeren. Dat klinkt ideaal, maar voor een professionele bedrijfswebsite is blindelings alles automatisch updaten niet altijd de beste aanpak.
Een nieuwe versie van een plugin kan bijvoorbeeld conflicteren met je thema of met een andere plugin. Ook maatwerk kan beïnvloed worden door een update.
Daarom combineren we updates liever met een gecontroleerde aanpak. Zorg dat er een recente back-up beschikbaar is, voer de nodige updates uit en controleer nadien of de belangrijkste onderdelen van de website nog correct functioneren.
Denk bijvoorbeeld aan formulieren, navigatie, belangrijke pagina’s en specifieke functionaliteiten.
Vergeet ook PHP en je hostingomgeving niet
Websiteonderhoud stopt bovendien niet bij WordPress zelf.
Ook de PHP-versie waarop WordPress draait en de configuratie van je hostingomgeving spelen een rol. Een sterk verouderde PHP-versie kan uiteindelijk problemen veroorzaken met recente versies van WordPress, thema’s en plugins.
Een gezonde WordPress-website vraagt daarom om een bredere blik: WordPress, plugins, thema, PHP, hosting en back-ups moeten samen onderhouden worden.
Dat sluit ook aan bij hoe we bij webdesign naar websites kijken: niet alleen naar hoe een website eruitziet, maar ook naar techniek, prestaties, gebruiksvriendelijkheid en wat er na de lancering gebeurt.
Een goede back-up blijft onmisbaar
Zelfs wanneer je website perfect onderhouden wordt, bestaat er nooit een garantie dat er niets kan misgaan.
Daarom hoort een goede back-upstrategie bij degelijk websitebeheer. WordPress adviseert zelf om regelmatig back-ups te maken. Daarbij zijn zowel de bestanden van je WordPress-installatie als de database belangrijk.
Een back-up is vooral waardevol wanneer je zeker weet dat hij bruikbaar is. Alleen ergens automatisch een back-upbestand hebben staan, is dus niet hetzelfde als een betrouwbare herstelstrategie.
Meer informatie vind je in de officiële WordPress-documentatie over back-ups.
Hoe vaak moet je WordPress updaten?
Daar bestaat geen universeel aantal dagen voor. Niet iedere update is even dringend.
Een kleine functionele update kan soms even wachten. Bij een belangrijke beveiligingsupdate ligt dat anders. WordPress brengt expliciet security releases uit en adviseert bij dergelijke releases om websites zo snel mogelijk bij te werken.
Daarom raden we aan om je website systematisch te controleren en niet pas wanneer er zichtbaar iets fout loopt.
Zie websiteonderhoud zoals het onderhoud van een wagen. Je wacht ook niet tot de motor het begeeft voordat je olie controleert of versleten onderdelen vervangt.
Laat je WordPress-website onderhouden door The Other Concept
Heb je geen zin om zelf voortdurend WordPress, plugins, thema’s en technische compatibiliteit in het oog te houden? The Other Concept kan het onderhoud en de updates van je WordPress-website voor je verzorgen.
We raden dit bij websites die we bouwen zelfs expliciet aan. Niet omdat een WordPress-website voortdurend problemen veroorzaakt, maar omdat een professionele website ook na de lancering aandacht nodig heeft.
Zo verklein je het risico op beveiligingsproblemen, blijven technische onderdelen actueel en kunnen problemen sneller worden opgemerkt voordat ze uitgroeien tot dure herstellingen.
Heb je al een WordPress-website die lange tijd niet meer werd bijgewerkt? Voer dan niet zomaar tientallen updates blindelings achter elkaar uit. Zeker bij sterk verouderde websites is het verstandig om eerst een volledige back-up te maken en de technische situatie te bekijken.
Wil je weten hoe we jouw website kunnen onderhouden? Neem contact op met The Other Concept en we bekijken samen wat nodig is.
Laatst bijgewerkt op 28 september 2026.
