Inhoudelijk bijgewerkt op .
Wat is technische SEO en waarom is het belangrijk?
Technische SEO neemt obstakels weg tussen een gepubliceerde pagina en de systemen die haar moeten verwerken. Een bezoeker kan bijvoorbeeld een dienstpagina zien terwijl de server een foutstatus terugstuurt, een canonical naar de homepage wijst of een robots-instructie indexering uitsluit. De zichtbare vormgeving alleen vertelt dus niet of de technische signalen kloppen.
De controle begint bij waardevolle URL’s en hun templates. Denk aan diensten, productcategorieën en kennisartikelen. Je onderzoekt zowel de afzonderlijke pagina als het patroon: een fout in één template kan veel URL’s treffen. Technische optimalisatie vervangt geen inhoudelijke relevantie. Een probleemloze pagina kan nog steeds onvoldoende antwoord geven op de zoekvraag.
Welke onderdelen horen op een technische SEO-checklist?
Een bruikbare checklist koppelt elk onderdeel aan een concrete controle en een bewijsstuk. Alleen melden dat een onderdeel “goed” of “slecht” scoort, is onvoldoende om een ontwikkelaar gericht aan het werk te zetten.
| Onderdeel | Controle | Bewaar als bewijs |
|---|---|---|
| Bereikbaarheid | Juiste statuscode en geen onbedoelde login of serverblokkade | HTTP-respons en getroffen URL |
| Crawlbaarheid | Toegang tot pagina en benodigde bestanden | Robots-regels, crawlresultaat en relevante logs |
| Rendering | Hoofdtekst en links beschikbaar in de verwerkte pagina | Bron-HTML en gerenderde HTML |
| Indexering | Geen ongewenste noindex; indexstatus onderzocht | URL-inspectie met datum |
| Canonicalisatie | Voorkeurs-URL past bij inhoud en andere signalen | Opgegeven en door Google gekozen canonical |
| Architectuur | Belangrijke pagina’s bereikbaar via interne links | Crawlpad en sitemapvergelijking |
| Gebruikservaring | Mobiele inhoud, interacties en Core Web Vitals | Velddata en reproduceerbare labtest |
| Structured data | Markup beschrijft zichtbare inhoud correct | Validatieresultaat en bron-HTML |
Hoe controleer je of Google een URL heeft geïndexeerd?
Gebruik URL-inspectie in Google Search Console voor de geregistreerde indexstatus. Controleer daarnaast de actuele pagina, want de laatst verwerkte versie en de huidige website kunnen verschillen.
- Open de juiste Search Console-property en plak de volledige URL in de inspectiebalk.
- Lees de indexeringsstatus en uitsluitingsreden, niet alleen het groene of grijze symbool.
- Bekijk de laatste crawl, toegankelijkheid en opgegeven en geselecteerde canonical.
- Open de gecrawlde pagina wanneer beschikbaar en controleer de hoofdinhoud.
- Voer na een wijziging afzonderlijk de live test uit en vergelijk de signalen.
- Vraag na een relevante oplossing eventueel indexering aan en bewaar de datum.
Een geslaagde live test bewijst niet dat de URL al geïndexeerd is. Ook “URL staat op Google” garandeert geen vertoning bij elke zoekopdracht. De documentatie over URL-inspectie beschrijft dit onderscheid. Een daling in vertoningen moet daarom apart worden onderzocht; ze bewijst geen verwijdering uit de index.
Wat is het verschil tussen robots.txt, noindex en canonical?
Robots.txt stuurt crawltoegang, noindex vraagt om uitsluiting uit de index en een canonical geeft een voorkeursversie van dubbele of sterk vergelijkbare inhoud aan. Deze mechanismen zijn niet onderling uitwisselbaar.
| Bedoeling | Middel | Beperking |
|---|---|---|
| Crawlen van een URL-patroon beperken | Robots.txt | Een bekende URL kan zonder gecrawlde inhoud in zoekresultaten verschijnen |
| Een bereikbare pagina uit de index houden | Noindex in meta-tag of HTTP-header | Google moet de instructie kunnen ophalen |
| Voorkeursversie van vergelijkbare pagina’s aangeven | Rel canonical | Een signaal, geen afdwingbare opdracht |
| Een verhuisde pagina vervangen | Permanente redirect naar de echte opvolger | De bestemming moet inhoudelijk passen |
Blokkeer een pagina niet in robots.txt wanneer Google juist de noindex moet lezen. Een canonical is evenmin een manier om verschillende diensten samen te voegen. Google licht indexering blokkeren en canonieke URL’s aangeven afzonderlijk toe.
Welke statuscodes en redirects moet je controleren?
Controleer of de HTTP-status overeenkomt met wat de pagina werkelijk doet. Een status 200 bij een foutmelding is iets anders dan een werkende inhoudspagina. Een niet meer bestaande URL hoeft ook niet automatisch naar de homepage te verwijzen.
- 200: controleer of de verwachte inhoud wordt geleverd, niet een lege template of foutbericht.
- 301 of 308: gebruik bij een permanente verhuizing een passende eindbestemming en vermijd onnodige tussenstappen.
- 404 of 410: kan correct zijn als inhoud definitief weg is en geen relevante vervanger bestaat.
- 5xx: onderzoek beschikbaarheid, capaciteit en foutlogs, vooral als een heel paginatype wordt getroffen.
Bij een soft 404 behandelt Google de inhoud als een foutpagina, ook als de server iets anders meldt. Vergelijk daarom status, tekst en URL-inspectie. Beoordeel serverfouten over meerdere momenten; één geslaagde aanvraag sluit een terugkerende storing niet uit.
Hoe helpen interne links en een XML-sitemap bij ontdekking?
Interne links maken pagina’s bereikbaar binnen de website; een XML-sitemap geeft aanvullende URL-informatie aan zoekmachines. Een sitemap vervangt geen navigeerbare structuur en is geen indexeringsgarantie.
Vergelijk de gewenste pagina’s met de crawleruitvoer en de sitemap. Een belangrijke URL die alleen in een export voorkomt, maar nergens is gelinkt, vraagt aandacht. Gebruik gewone <a href="...">-links met een passende omschrijving. De uitwerking van een interne linkstructuur hoort bij het inhoudelijke én technische ontwerp.
Neem in de sitemap de gewenste canonieke, indexeerbare URL’s op. Werk interne links na een verhuizing rechtstreeks bij naar de bestemming. Problemen met duizenden filtervarianten verdienen een andere aanpak dan een ontbrekende link naar één dienst. Crawlbudget is vooral relevant bij grote of snel veranderende websites, niet als standaardverklaring voor iedere kleine site.
Hoe controleer je JavaScript en rendering?
Vergelijk de oorspronkelijke HTML, de gerenderde pagina en de versie die Google kan verwerken. Bij JavaScript kan inhoud later worden toegevoegd; dat moet betrouwbaar gebeuren zonder dat een crawler eerst een knop bedient of een formulier invult.
Open een diepe URL rechtstreeks. Controleer titel, hoofdtekst, links en canonical. Test vervolgens mobiel en bekijk ontbrekende resources of JavaScript-fouten. Een lege app-shell is een aanleiding om rendering te onderzoeken, geen zelfstandig bewijs dat Google de pagina nooit kan indexeren. De JavaScript-richtlijnen van Google helpen deze situaties uit elkaar te houden.
Kan Google een website in Base44 of Lovable indexeren?
Dat hangt af van de gepubliceerde implementatie en toegankelijkheid, niet alleen van de naam van de bouwer. Controleer bij Base44, Lovable en andere JavaScript-platformen dezelfde keten: directe URL, statuscode, robots-instructies, inhoud na rendering, canonical en interne links. Platformfuncties kunnen veranderen.
Een melding “ontdekt, momenteel niet geïndexeerd” vraagt onderzoek. Ze bewijst niet dat een CMS-migratie noodzakelijk is. Leg eerst vast wat ontbreekt en of het binnen het bestaande platform kan worden opgelost. Zo voorkom je een kostbare verhuizing die het echte inhouds- of indexeringsprobleem laat bestaan.
Welke Core Web Vitals zijn belangrijk?
Largest Contentful Paint, Interaction to Next Paint en Cumulative Layout Shift meten respectievelijk laadervaring, reactiesnelheid en visuele stabiliteit. Beoordeel echte gebruikersdata naast een technische labtest.
| Metriek | Goede grens | Voorbeeld van onderzoek |
|---|---|---|
| LCP | Maximaal 2,5 seconden | Grote afbeelding, serverrespons en blokkerende resources |
| INP | Maximaal 200 milliseconden | Zware scripts en vertraagde interacties |
| CLS | Maximaal 0,1 | Ontbrekende afbeeldingsruimte en verspringende elementen |
De beoordeling gebruikt het 75e percentiel, met onderscheid tussen mobiel en desktop. Dit zijn de officiële Web Vitals-grenzen, geen garantie op een positie. Bij weinig verkeer kunnen velddata ontbreken. Gebruik dan labtests om problemen te vinden, maar noem een Lighthouse-score geen gemeten gebruikerservaring. Op PageSpeed Insights staat hoe je de rapporten leest; de Core Web Vitals-gids behandelt de verbeteringen.
Hoe controleer je structured data en schema markup?
Controleer of de markup het juiste type inhoud beschrijft en overeenkomt met wat bezoekers zien. Geldige JSON-LD zonder passend zichtbaar aanbod, auteur of bewijs is geen goede implementatie.
Gebruik Schema Markup Validator voor de structuur en Google Rich Results Test voor ondersteunde zoekfuncties. Niet ieder geldig schema-type levert een rich result op. Voeg geen beoordeling, prijs of FAQ toe die niet op de pagina staat. De uitleg over structured data en schema markup behandelt types en voorbeelden. Ook voor Belgische websites bestaat geen apart schema dat automatisch betere lokale posities geeft.
Wat verandert er bij meertalige websites en URL-varianten?
Meertalige websites vragen consistente taalversies, canonicals, interne links en waar passend hreflang. Een Engelse vertaling hoort niet automatisch een canonical naar de Nederlandse pagina te krijgen.
Controleer daarnaast HTTP tegenover HTTPS, www tegenover het hoofddomein, trailing slashes en parameters. Kies per inhoud een consistente voorkeurs-URL. Niet elk filter is waardeloos: een nuttige categorie kan een eigen zoekintentie hebben, terwijl sorteer- en sessievarianten vooral duplicatie veroorzaken. De regels voor SEO-vriendelijke URL’s helpen die keuzes documenteren.
Welke technische SEO-fout los je eerst op?
Los eerst aantoonbare blokkades op belangrijke pagina’s op. Combineer getroffen bereik, bedrijfsbelang, zekerheid van de diagnose en benodigde inspanning; laat een algemene toolscore de volgorde niet alleen bepalen.
| Situatie | Prioriteit | Acceptatiecontrole |
|---|---|---|
| Onbedoelde noindex op alle dienstpagina’s | Direct onderzoeken en herstellen | Instructie verdwenen uit HTML én headers; live test opnieuw uitgevoerd |
| Canonicals van productpagina’s wijzen naar de homepage | Hoog, na bevestiging van de templatefout | Passende canonicals en consistente interne links |
| Mobiele knop reageert traag op een belangrijk formulier | Hoog bij aangetoonde gebruikshinder | Interactie herhaald getest en velddata opgevolgd |
| Optioneel schema-veld ontbreekt op één artikel | Gepland onderhoud | Beoordelen of het veld relevant en onderbouwd is |
Fictieve oefensituatie: een website heeft 24 dienstpagina’s. Na een templatewijziging wijzen hun canonicals naar de homepage. De inhoud herschrijven is dan niet de eerste ingreep. Controleer de template, herstel de signalen en leg vast wanneer Google de pagina’s opnieuw verwerkt. Een herstelde canonical bewijst nog niet dat oude posities terugkeren.
Wat moet een technische SEO-audit opleveren?
Een audit moet uitvoerbare tickets en een testplan opleveren, niet alleen een export met waarschuwingen. Per probleem horen URL-voorbeelden, oorzaak of hypothese, gewenste oplossing, eigenaar en acceptatiecriteria bij elkaar.
- Scope: onderzochte domeinen, talen, templates en uitgesloten onderdelen.
- Nulmeting: crawl, indexstatus en relevante gebruikersdata met datum.
- Bevinding: reproduceerbaar probleem, geraakt bereik en bedrijfscontext.
- Ticket: gewenste wijziging, afhankelijkheden en verantwoordelijke ontwikkelaar.
- Hercontrole: technische acceptatie na oplevering, apart van latere SEO-prestaties.
Search Console, een crawler zoals Screaming Frog, ontwikkelaarstools en serverlogs vullen elkaar aan. Geen enkele tool ziet alles. Een volledige SEO-audit kan daarnaast inhoud en autoriteit beoordelen. Bij een nieuw CMS of domein hoort er een expliciet plan voor website-migratie bij.
Kun je technische SEO zelf doen en wat bepaalt de kosten?
Basiscontroles kun je zelf doen wanneer je toegang hebt tot de website en Search Console. Wijzigingen aan routing, caching, rendering en templates vragen vaak een ontwikkelaar. De kosten hangen vooral af van complexiteit, aantal templates, toegang en de vraag of uitvoering en hercontrole inbegrepen zijn.
Vraag vooraf welke taken binnen de opdracht vallen en wie ze implementeert. Een auditrapport is niet hetzelfde als een herstelde website. De SEO-diensten beschrijven de werkpakketten; de budgetcontext voor SEO helpt opdrachten vergelijken. Plan een hercontrole na belangrijke releases en kies daarna een onderhoudsritme dat bij de veranderlijkheid van je site past.
Hoe verschilt technische SEO van on-page SEO en SEO-technieken?
Technische SEO gaat over de verwerking en werking van de website, on-page SEO over de inhoud en presentatie van een pagina. De grens is niet absoluut: interne links en headings hebben beide functies.
Wie met “SEO techniek” vooral methodes bedoelt om zichtbaarheid te verbeteren, vindt een breder overzicht bij SEO-technieken. Voor het aanpassen van zoekintentie, titels en hoofdtekst is on-page SEO de vervolgstap. Houd technische herstelwerkzaamheden en inhoudelijke experimenten in hetzelfde wijzigingslog, zodat je later weet wat wanneer is aangepast.