Wat is technische SEO? Van onderzoek naar gecontroleerd herstel

In deze gids

Begin bij de betekenis van technische SEO, bekijk de negen onderzoeksonderdelen en gebruik het voorbeeldticket om van een bevinding naar een controleerbare verbetering te komen.

Wat is technische SEO precies?

Technische SEO is het onderzoeken en verbeteren van de technische voorwaarden voor vindbare, bruikbare webpagina's. Denk aan een productcategorie die via echte links bereikbaar moet zijn, een dienstenpagina die geen onbedoelde noindex-instructie mag bevatten of een artikel waarvan de hoofdtekst ook op mobiel beschikbaar moet blijven.

Het werk raakt verschillende disciplines. Een redacteur kan een verkeerde interne link herstellen; een developer onderzoekt een templatefout; de eigenaar bepaalt welke pagina's überhaupt openbaar horen te zijn. Een technisch SEO-specialist verbindt die beslissingen met de zoekvraag en controleert het resultaat. Niet iedere melding uit een tool is een fout, en niet iedere fout vraagt dezelfde specialist.

Waarom is de technische basis belangrijk?

Een waardevol antwoord heeft weinig aan een kapotte route ernaartoe. Andersom wordt een inhoudelijk zwakke pagina niet vanzelf relevant door snellere hosting. In Googles uitleg van Search zijn crawlen, indexeren en het tonen van resultaten afzonderlijke stappen. Een bereikbare pagina is nog geen geïndexeerde pagina; een geïndexeerde pagina verschijnt niet voor iedere zoekvraag.

Begin daarom bij een concreet probleem. Ontbreekt een belangrijke pagina? Werkt de offerteaanvraag niet op een telefoon? Wordt een gewijzigde tekst nog niet getoond? Die vragen leveren een bruikbare onderzoeksscope op. Google benadrukt bij pagina-ervaring bovendien dat goede technische scores geen topposities garanderen. Vermijd een werkplan dat alleen is bedoeld om alle toolvakjes groen te maken.

Negen onderdelen om te onderzoeken

Dit is een werkindeling, geen lijst met bekende gewichten in Google's algoritme. Bepaal per onderdeel of het relevant is voor jouw website en welke gegevens nodig zijn.

Van onderzoeksonderwerp naar concrete controlevraag

Onderdeel	Controlevraag	Mogelijke oplevering
Bereikbaarheid	Komen bedoelde bezoekers en crawlers bij de inhoud?	URL's met status, blokkade en verantwoordelijke.
Indexatie	Zijn instructies en Google's waarneming verklaarbaar?	Beoordeling per relevante URL-groep.
Navigatie	Zijn belangrijke vervolgstappen vindbaar?	Gerichte interne linkbeslissingen.
Prestaties	Wat vertraagt laden of reageren?	Meting, oorzaakonderzoek en hertest.
Mobiele werking	Blijven inhoud en handelingen bruikbaar?	Scherm- en interactiecontrole.
Verbinding	Werken certificaat en geladen bestanden correct?	Controle van HTTPS en mixed content.
Structured data	Komt de markup overeen met zichtbare feiten?	Gecorrigeerde velden en validatie.
Rendering	Welke inhoud levert server of JavaScript?	Vergelijking van HTML en gerenderde pagina.
Taalversies	Zijn alternatieven en verwijzingen consistent?	Controle van taal- en canonicalrelaties.

Crawling en indexering uit elkaar houden

Een crawl haalt een URL op; indexering verwerkt de inhoud. Leg bij een probleem zowel de actuele HTTP-respons als de beschikbare waarneming in Search Console vast. Kijk naar de onderzochte URL, datum, gekozen canonical en eventuele blokkade. Een rapport kan een eerdere toestand beschrijven. Controleer daarom niet alleen een overzichtsteller, maar ook concrete voorbeelden.

Werk niet met de regel dat iedere uitgesloten URL alsnog geïndexeerd moet worden. Een afgeschermde beheerpagina of een duplicaat kan terecht ontbreken. Leg eerst vast welke pagina's je wél in zoekresultaten wilt hebben. Bij grote aantallen filter- of parameter-URL's onderzoek je ook crawlgedrag en serverbelasting; het aantal pagina's alleen bewijst geen crawlbudgetprobleem.

Site-architectuur en interne links

Ontwerp routes rond taken van bezoekers: oriënteren, vergelijken, verdiepen en contact opnemen. Een dienstenoverzicht kan naar de passende dienst verwijzen, een handleiding naar een verdiepende uitleg. Een korte URL is niet hetzelfde als een goed bereikbare pagina. Een vast maximum van drie klikken is geen universele Google-eis.

Controleer ontbrekende en omslachtige routes met een inventaris van de bedoelde pagina's. Een crawler ziet niet vanzelf alle verweesde inhoud. Gebruik daarnaast CMS-gegevens en beschikbare sitemap- of loggegevens. De gids over interne linkbuilding laat zien hoe je zulke bevindingen omzet in afzonderlijke linkbeslissingen.

Prestaties: meet de ervaring, niet alleen een cijfer

De Core Web Vitals meten laden, reageren en visuele stabiliteit. De goede grenswaarden zijn LCP ≤ 2,5 seconden, INP ≤ 200 milliseconden en CLS ≤ 0,1. Beoordeel alle drie op het 75e percentiel van beschikbare veldmetingen, met mobiel en desktop afzonderlijk.

Een Lighthouse-test is een gecontroleerde labmeting, geen bewijs dat echte bezoekers die grenswaarden halen. Noteer apparaat, verbinding, testmoment en herhalingen. Ontbrekende velddata betekent “onbekend”, niet “geslaagd”. Onderzoek vervolgens het grootste knelpunt: bijvoorbeeld een te laat ontdekte hoofdafbeelding, veel JavaScript of een verschuivende banner. Verwijder geen noodzakelijke toestemming of functionaliteit om een score te verhogen.

Optimaliseer in kleine stappen en test opnieuw met vergelijkbare instellingen. Een algemene conversiedaling per extra seconde is geen betrouwbare voorspelling voor jouw organisatie. Gebruik daarvoor eigen meetgegevens met een duidelijke definitie van de conversie.

De mobiele pagina moet inhoudelijk compleet blijven

Google gebruikt bij mobile-first indexing de mobiele inhoud voor indexering en ranking. Een andere indeling is mogelijk, maar belangrijke tekst, links en gegevens mogen niet verdwijnen. Hoofdinhoud die pas na een gebruikersactie wordt opgehaald, vraagt extra aandacht.

Test naast schermbreedte ook menu's, formulieren, toetsenbordfocus, tabellen en vaste contactknoppen. Kan iemand een tabel afzonderlijk scrollen zonder de hele pagina te verschuiven? Bedekt een balk een invoerveld? Werkt de pagina met grotere tekst? Dat zijn concretere acceptatievragen dan alleen “responsive: ja”.

Structured data beschrijft wat er werkelijk staat

Gebruik markup die bij de inhoud past, zoals artikelgegevens bij een artikel. Controleer namen, URL's, afbeeldingen en datums tegen de zichtbare pagina. De structured-data-richtlijnen maken duidelijk dat geldige code geen weergavegarantie is. Een validator vervangt geen inhoudelijke beoordeling.

Neem niet automatisch alle schematypen uit een oudere checklist over. Google heeft de FAQ-rich-resultfunctie beëindigd. Veelgestelde vragen kunnen voor lezers nog steeds nuttig zijn; beloof daarbij geen uitklapbare zoekresultaten of extra klikken. Een verzonnen beoordeling of auteurscontrole hoort evenmin in JSON-LD.

HTTPS is onderdeel van de verbinding, niet de hele beveiliging

Controleer het certificaat, de bedoelde HTTPS-bestemming en bestanden die de pagina laadt. Bij mixed content worden onveilige bestanden in een beveiligde pagina gebruikt; de browser kan die blokkeren. Controleer na herstel ook of afbeeldingen, formulieren en scripts nog functioneren.

Een werkende HTTPS-verbinding bewijst niet dat een website vrij is van kwetsbaarheden. Updates, toegangsbeheer, back-ups en herstelafspraken zijn afzonderlijke verantwoordelijkheden. Laat ingrijpende beveiligingsinstellingen door de beheerder beoordelen en test ze vóór brede uitrol.

JavaScript, server-rendering en statische pagina's

Google kan JavaScript uitvoeren. De documentatie over JavaScript SEO beschrijft crawlen, renderen en indexeren, zonder vaste wachttijd van dagen of weken. Controleer of noodzakelijke bestanden bereikbaar zijn en of de uiteindelijke inhoud, links en metadata correct verschijnen.

Server-rendering maakt HTML bij een verzoek; statische generatie maakt die vooraf. Daarna kan JavaScript interactie toevoegen. Beide kunnen goed werken. Een frameworknaam zegt nog niet welke inhoud de server daadwerkelijk levert. Vergelijk daarom bron-HTML, de gerenderde pagina en waar beschikbaar de inspectie door Google. Alleen een lege applicatiecontainer terugsturen is een andere situatie dan een volledig artikel met interactieve menu's.

Pico Yellows huidige Next.js-site levert de kennisbanktekst in server-HTML en gebruikt statische generatie met hervalidatie. Dat is een technische inrichting, geen bewijs van een rankingvoordeel ten opzichte van iedere andere website.

Sitemap, robots.txt en canonical hebben verschillende taken

Een sitemap helpt URL's ontdekken, maar garandeert geen opname. Robots.txt regelt crawltoegang en is geen beveiliging of betrouwbare manier om een URL uit zoekresultaten te houden. Een geblokkeerde URL kan zonder inhoud toch bekend zijn bij Google.

Een canonical geeft een voorkeur aan bij gelijke of sterk vergelijkbare pagina's. De voorkeursversie kan naar zichzelf verwijzen; een duplicaat verwijst juist naar die voorkeursversie. “Iedere pagina moet altijd naar zichzelf wijzen” is dus geen goede herstelregel. Stem interne links en sitemap af op de gekozen bestemming. Laat taalvarianten afzonderlijk beoordelen; dezelfde taal en dezelfde inhoud zijn verschillende vragen.

Welke fouten verdienen aandacht?

Begin bij aantoonbare belemmeringen: een onbedoelde blokkade, ontbrekende hoofdinhoud, niet-werkende navigatie of een verkeerde bestemming. Een lange lijst waarschuwingen is nog geen rangorde. De gids met tien technische controlepunten behandelt ook wanneer een 404 of ontbrekende canonical niet automatisch een incident is.

Kies gereedschap bij de onderzoeksvraag

• Search Console: Google's beschikbare waarnemingen over indexatie en zoekverkeer.
• Een crawler: herhaalbaar onderzoek van bereikbare URL's, links en templatepatronen binnen de ingestelde scope.
• Browserontwikkeltools en Lighthouse: netwerkaanvragen, rendering, interactie en laboratoriumtests.
• CMS- en servergegevens: bedoelde pagina's en werkelijke verzoeken, binnen passende toegangs- en privacyafspraken.

Leg de beperkingen per bron vast. Een crawl zonder JavaScript, een test met een ingelogde sessie en een openbare mobiele pagina kunnen verschillende dingen laten zien. Vergelijk geen toolscores alsof ze dezelfde definitie en dekking hebben. Bepaal eerst welk bewijs nodig is voordat je extra abonnementen afsluit.

Werkvoorbeeld: van melding naar hertest

Fictief implementatievoorbeeld: een dienstenpagina toont op een telefoon de tekst, maar niet de link naar de aanvraag. Dit is geen klantresultaat of bevinding over een echte website.

Een afgebakend technisch ticket

Onderdeel	Afspraak in het voorbeeld
Probleem	De aanvraaglink ontbreekt in de mobiele variant van één template.
Bewijs	Betrokken voorbeeld-URL, HTML-fragment, schermmaat en reproductiestappen vastleggen.
Wijziging	Developer maakt dezelfde relevante link beschikbaar in de bestaande mobiele indeling.
Acceptatie	Link staat in server-HTML, heeft de juiste bestemming en is met toetsenbord en aanraking bruikbaar.
Vrijgave	Preview beoordelen, herstelmogelijkheid bewaren en de gepubliceerde versie hertesten.

1. Begrens. Kies de pagina's en het concrete gebruikersprobleem.
2. Onderzoek. Bewaar bewijs en toets alternatieve verklaringen.
3. Herstel. Spreek eigenaar, acceptatie en terugvaloptie af.
4. Controleer. Hertest de juiste deployment en volg beschikbare veldgegevens.

Voor een uitgebreidere inventaris kun je de auditwerkwijze gebruiken. Wil je uitvoering bespreken, bekijk dan technische SEO bij Pico Yellow. We bepalen scope en verantwoordelijkheden in een vrijblijvend adviesgesprek; de offerte is op maat.

Veelgestelde vragen

Wat verschilt er van on-page en off-page SEO?

Technische SEO onderzoekt de werking en verwerking van pagina's. On-page gaat vooral over inhoud en presentatie; off-page over externe signalen en reputatie. De werkzaamheden overlappen, bijvoorbeeld bij interne links.

Hoe vaak is een audit nodig?

Stem dat af op veranderingen en risico. Plan controles rond releases en migraties, en spreek terugkerende monitoring af voor belangrijke templates. Niet iedere website heeft dezelfde auditfrequentie nodig.

Kan ik zelf beginnen?

Ja: inventariseer bedoelde pagina's en beschrijf concrete problemen. Laat ingrijpende wijzigingen aan routing, indexatie of beveiliging beoordelen door iemand die de gevolgen kan testen en herstellen.

Wanneer zie ik resultaat?

Een hertest kan aantonen dat de technische wijziging werkt. Opnieuw crawlen, indexatie, gebruikerservaring en aanvragen zijn afzonderlijke uitkomsten zonder vaste gezamenlijke termijn.

Is Lighthouse 100 voldoende?

Nee. De score dekt specifieke automatische controles. Inhoudelijke relevantie, echte gebruikersmetingen en zakelijke resultaten vragen aanvullend bewijs.

Moet een JavaScript-website vervangen worden?

Niet op basis van het framework alleen. Onderzoek welke HTML en links worden geleverd en of rendering betrouwbaar werkt. Een gerichte reparatie kan voldoende zijn.

Moet elke URL in Google staan?

Nee. Bepaal welke openbare pagina's zelfstandige zoekwaarde hebben. Beheerpagina's, duplicaten en andere uitzonderingen kunnen bewust buiten de index blijven.

Is HTTPS een volledige beveiligingscontrole?

Nee. De verbinding is één onderdeel. Onderhoud, rechten, gegevensverwerking en herstel moeten apart worden beoordeeld.

Welke tool moet ik kopen?

Begin bij de ontbrekende informatie en jouw uitvoeringscapaciteit. Een extra abonnement zonder concrete onderzoeksvraag levert niet vanzelf een beter werkplan op.

Wat moet een audit opleveren?

Een afgebakende lijst bevindingen met bewijs, prioriteit, verantwoordelijke en acceptatiecriteria. Maak duidelijk of implementatie en hertest onderdeel zijn van de opdracht.