Technische SEO zorgt dat belangrijke pagina’s bereikbaar, begrijpelijk en bruikbaar zijn voor bezoekers en zoekmachines. Een goede controle eindigt met concrete reparaties: welke URL klopt niet, wat moet veranderen en hoe stel je vast dat het probleem is opgelost?
In deze gids leer je een technische analyse afbakenen, bevindingen prioriteren en werkzaamheden beoordelen. Je krijgt een voorbeeld van een uitgewerkte taak en een controlelijst voor de oplevering. Bespreek je eigen website via het Niblah-contactformulier als je hulp wilt bij onderzoek of uitvoering.
Wat controleer je met technische SEO?
Je onderzoekt of de website het gewenste bezoek ondersteunt. Kan iemand een belangrijke dienst vinden? Leidt een oude link naar een passende bestemming? Staat de informatie op de pagina die je wilt laten indexeren? De antwoorden vragen een combinatie van websitecontrole, instellingen en gegevens uit Search Console.
Google maakt onderscheid tussen pagina’s ophalen, inhoud verwerken voor de index en resultaten tonen bij een zoekopdracht. Niet iedere pagina doorloopt alle stappen. Indexatie en zichtbaarheid zijn niet gegarandeerd, ook als je technische instellingen kloppen. Dat onderscheid staat in Googles uitleg over de werking van Search.
Een technische analyse geeft dus geen volledige verklaring voor iedere positie. Een bereikbare pagina kan nog steeds een onvolledig antwoord geven. Combineer de bevindingen daarom met inhoudelijke contentcontrole en een heldere SEO-strategie. Beschrijf wel afzonderlijk welk probleem je technisch hebt vastgesteld.
Begin met het juiste domein en de belangrijke pagina’s
Leg eerst vast wat je onderzoekt: het publieke domein, eventuele subdomeinen, taalversies en gebruikte systemen. Een testomgeving kan andere instellingen hebben dan productie. Een wijziging op een oud domein zegt weinig over de website die klanten nu gebruiken.
Maak daarna een lijst van paginatypen. Voor een dienstverlener zijn dat bijvoorbeeld diensten, praktijkvoorbeelden, artikelen en contact. Bij een webshop komen categorieën, producten, filters en eventueel varianten erbij. Kies uit ieder belangrijk type enkele voorbeelden. Neem ook URL’s met veel verkeer, externe verwijzingen of een directe rol bij aanvragen mee.
Bewaar bij de nulmeting wat je hebt gezien: controledatum, pagina-adres, statuscode, hoofdadres, indexatie-instelling en een korte beschrijving van het probleem. Leg ontbrekende toegang of onbetrouwbare meting apart vast. Een bevinding zonder locatie of bewijs is lastig over te dragen aan een ontwikkelaar.
Verdeel de analyse over drie gebieden
Een overzichtelijke analyse behandelt bereikbaarheid, URL- en indexatiekeuzes en de daadwerkelijke pagina. Deze indeling helpt je de juiste persoon bij een reparatie te betrekken. Hostingproblemen vragen andere kennis dan een ontbrekende interne link.
1. Bereikbaarheid en infrastructuur
Controleer of belangrijke pagina’s stabiel laden en of beveiligde verbindingen werken. Bekijk onverwachte foutmeldingen, loginvereisten en serverproblemen. Controleer ook of noodzakelijke bestanden bereikbaar zijn. Een pagina die alleen soms faalt, kan buiten een eenmalige steekproef vallen. Gebruik bij een vermoeden van uitval beschikbare monitoring of servergegevens.
Leg een patroon vast voordat je een oorzaak aanwijst. Gaat het om één pagina, een heel paginatype of alle verzoeken op een bepaald moment? Vermijd een omvangrijke hostingwijziging op basis van een losse trage meting. Beschrijf wat je wilt verbeteren en welke vergelijking na de wijziging nodig is.
2. Vinden, indexeren en de juiste URL kiezen
Bekijk hoe een bezoeker een pagina bereikt en welke versie bedoeld is als hoofdadres. Let op interne links, sitemaps, redirects, robots-instellingen en canonicals. Bij meerdere URL’s met dezelfde inhoud moet duidelijk zijn welke versie je wilt gebruiken. De signalen moeten elkaar ondersteunen.
Verwar een crawlbeperking niet met een indexatie-instructie. Een robots.txt-regel kan het ophalen beperken. Voor het verwerken van een noindex-instructie moet Google de pagina kunnen ophalen. Google beschrijft dat verschil in zijn documentatie over noindex. Kies de instelling op basis van het doel van de pagina.
3. Inhoud en gebruik van de pagina
Controleer wat werkelijk verschijnt: hoofdtekst, navigatie, afbeeldingen, titels en eventuele gestructureerde gegevens. Bekijk dit ook op een telefoon en bij belangrijke interacties. Een pagina kan technisch laden terwijl een bezoeker de aanvraagknop niet kan gebruiken of de belangrijkste informatie pas na een foutmelding verschijnt.
Noteer het effect voor de gebruiker. “Scriptprobleem” is te vaag. “De productinformatie verschijnt niet nadat een variant is geselecteerd” maakt duidelijk welk gedrag moet worden hersteld. Je hoeft de oorzaak nog niet te kennen om een concrete, reproduceerbare bevinding te beschrijven.
Maak bewuste keuzes bij canonicals, redirects en verwijderde pagina’s
Deze oplossingen hebben verschillende doelen. Een redirect leidt een bezoeker van een oude URL naar een andere bestemming. Een canonical geeft een voorkeur aan bij vergelijkbare of dubbele inhoud. Een indexatie-instelling bepaalt weer iets anders. Kies niet één standaardoplossing voor iedere melding van een crawler.
Stel je een fictieve tegelwebshop voor. Een categorie is bereikbaar via het normale adres en via een extra adres met een sorteervolgorde. Als de inhoud in hoofdzaak hetzelfde blijft, kan een voorkeursadres passend zijn. Een uitgebreid adviesartikel over het leggen van tegels is een ander antwoord en hoort niet automatisch naar die categorie te verwijzen als hoofdversie.
Google beschrijft de signalen en methoden voor hoofdversies in zijn canonical-documentatie. Canonicals zijn signalen, geen zekerheid dat Google precies jouw keuze overneemt. Houd ook de interne links en sitemap bij de bedoelde versie.
Is een oude pagina vervangen door een inhoudelijk passende nieuwe pagina, onderzoek dan een redirect naar die bestemming. Is er geen relevant alternatief, dan kan een correcte foutstatus passen. Alles naar de homepage sturen kan bezoekers met een heel andere vraag achterlaten. Leg per belangrijke oude URL vast waarom de gekozen bestemming aansluit.
Controleer interne links en sitemaps samen
Een sitemap is een overzicht van URL’s dat je aan een zoekmachine kunt aanbieden. De interne linkstructuur laat daarnaast zien hoe een bezoeker informatie vindt. Gebruik beide controles. Een belangrijke pagina die alleen in een sitemap staat, kan moeilijk te bereiken zijn vanuit het aanbod of een bijbehorend artikel.
Kijk naar de route die iemand nodig heeft. Vanuit een categorie moet een geschikt product bereikbaar zijn. Vanuit een onderhoudsgids moet een relevante dienst kunnen worden gevonden. Controleer verwijzingen naar verdwenen pagina’s en oude URL’s. Laat links waar mogelijk direct naar de actuele bestemming gaan.
Neem de gekozen hoofdadressen op in de sitemap en controleer dat die passen bij hun instellingen. Behandel een sitemapmelding als een concrete bevinding: welk bestand, welke URL en welke status? Een ingediende sitemap bewijst niet dat alle pagina’s zijn verwerkt. De gids over interne links helpt je de inhoudelijke verbindingen uitwerken.
Onderzoek snelheid en mobiele bruikbaarheid met context
Gebruik een snelheidsmeting om een probleem af te bakenen. Noteer het paginatype, apparaat en meetmoment. Vergelijk een productpagina niet zonder uitleg met een veel lichtere contactpagina. Bekijk naast een score ook wat er gebeurt: verschijnt belangrijke inhoud laat, reageert een knop traag of verschuiven onderdelen tijdens het lezen?
Praktijkgegevens en een gesimuleerde test beantwoorden verschillende vragen. De eerste beschrijven gemeten gebruikerservaring wanneer er genoeg gegevens zijn. Een test helpt een situatie onder gekozen omstandigheden onderzoeken. Google raadt aan pagina-ervaring als geheel te beoordelen en verwijst daarbij naar Core Web Vitals. Zie de documentatie over page experience.
Werk een mogelijke reparatie gericht uit. Een grote afbeelding verkleinen vraagt controle van kwaliteit, laadgedrag en het resultaat op het betreffende paginatype. Een script verwijderen vraagt controle van de functies die ervan afhankelijk zijn. Een betere score is geen reden om een werkend contactformulier of productkeuze te beschadigen.
Kies hulpmiddelen op de vraag die je onderzoekt
Een crawler helpt patronen over veel URL’s vinden. Je kunt bijvoorbeeld groepen redirects, ontbrekende titels of pagina’s met dezelfde inhoud onderzoeken. Controleer belangrijke meldingen op de website zelf. Een tool kan iets signaleren, maar kent niet altijd het zakelijke doel van een pagina.
Search Console helpt bij gegevens die Google over de website rapporteert. Gebruik URL-inspectie voor een specifieke pagina en rapportages voor grotere patronen. Een browser laat zien wat een bezoeker ervaart. Een snelheidsinstrument helpt laad- en interactieproblemen analyseren. Serverlogs kunnen bij bepaalde vragen laten zien welke verzoeken de server daadwerkelijk ontving.
Je hebt niet voor iedere website dezelfde combinatie nodig. Begin bij het probleem en de beschikbare gegevens. Vraag bij een externe analyse welke bronnen zijn gebruikt en wat de beperkingen zijn. Een lijst met screenshots uit verschillende tools is nog geen afgeronde diagnose.
Werkblad: controle, bewijs en verantwoordelijke per URL
Gebruik onderstaande onderwerpen om een controleblad voor jouw website te maken. Maak per gekozen URL en paginatype een regel. Schrijf eerst op wat die pagina moet doen: een product helpen kiezen, een dienst uitleggen of alleen een bevestiging tonen. Daardoor kun je een instelling beoordelen op haar bedoeling. Niet ieder onderwerp is voor iedere pagina van toepassing.
Vul per controle vier aanvullende velden in: noodzaak, status, bewijs en controlehouder. Als status kun je gebruiken: gecontroleerd en passend, herstel nodig, nog niet onderzocht of niet van toepassing met reden. Een leeg bewijsveld blijft een open punt. De controlehouder is degene die het resultaat beoordeelt; dat hoeft niet dezelfde persoon te zijn als de uitvoerder.
| Onderwerp | Concrete vraag | Wat bewaar je als bewijs? |
|---|---|---|
| URL en paginatype | Onderzoek je de juiste publieke omgeving en de juiste versie van dit paginatype? | Volledig adres, omgeving, controledatum en beoogde bezoekersfunctie. |
| Serverreactie | Krijgt een rechtstreeks verzoek de bedoelde status en inhoud, ook bij een ongeldig adres? | Status, ontvangen inhoud en afzonderlijke voorbeelden van een bestaande en ontbrekende pagina. |
| Robots-toegang | Kunnen de relevante crawler en noodzakelijke bestanden worden opgehaald? | De toepasselijke robots-regel, betrokken URL en gecontroleerde respons. |
| Sitemapdoel | Staat de bedoelde publieke hoofdversie in de juiste sitemap, en is die selectie actueel? | Bestandsadres, exacte URL-vermelding, status en reden voor opname of uitsluiting. |
| Redirectroute | Bereikt een oude verwijzing een inhoudelijk passende bestemming zonder onnodige tussenstappen? | Startadres, iedere ontvangen status en eindadres, plus de inhoudelijke reden. |
| Canonicaldoel | Past het opgegeven voorkeursadres bij de echte inhoud en bij andere verwijzingen? | Gepubliceerde canonical, doelpagina, interne verwijzingen en eventuele Google-selectie afzonderlijk. |
| Noindexbedoeling | Is uitsluiting bedoeld, en is de instructie bereikbaar en daadwerkelijk gepubliceerd? | Paginafunctie, HTML of header, crawltoegang en verantwoordelijke voor het besluit. |
| Dubbele inhoud | Geven meerdere adressen hetzelfde antwoord of helpen ze verschillende bezoekers? | Vergelijking van twee concrete pagina’s, hun doel en de gekozen vervolgstap. |
| Paginatie en filters | Zijn vervolgdelen en nuttige selecties via echte adressen bereikbaar en passend ingericht? | Voorbeeldroutes, zichtbare links, inhoud per adres en beslissingen over hoofdversies. |
| Interne route | Kan iemand vanaf een relevante pagina naar deze informatie en de volgende stap? | Beginpagina, aangeklikte verwijzing en werkende bestemming. |
| Titels en beschrijvingen | Beschrijven de gepubliceerde waarden deze specifieke pagina zonder een andere taak te beloven? | Werkelijke uitvoer en vergelijking met inhoud en relevante naburige pagina’s. |
| Werkelijke render | Verschijnen hoofdtekst, links en belangrijke gegevens ook wanneer scripts worden verwerkt? | Bron-HTML, gerenderde inhoud, testomgeving en eventuele ontbrekende gegevens. |
| Mobiele bediening | Kun je navigeren, kiezen en contact opnemen zonder blokkade of onbedoeld weggeschoven inhoud? | Apparaat of viewport, uitgevoerde handeling en reproduceerbare uitkomst. |
| Laad- en interactiegedrag | Welk onderdeel vertraagt de bezoekerstap of veroorzaakt verschuiving, en onder welke omstandigheden? | Meetbron, apparaat, periode of testinstelling, waargenomen probleem en vergelijking na herstel. |
| Afbeeldingen en uitgesteld laden | Zijn de juiste afbeeldingen beschikbaar wanneer nodig, met passende bestandsgrootte en laadwijze? | Afbeeldingsadres, uitvoer in de render en vergelijking bij directe en latere zichtbaarheid. |
| Scripts, stijlen en cache | Welke bestanden zijn noodzakelijk, welke veroorzaken vertraging en komt een wijziging echt door? | Betrokken bestanden, versie, gemeten gedrag en controle van afhankelijke functies. |
| Beveiligde verbinding | Werken HTTPS en benodigde bestanden zonder onbedoelde onbeveiligde verwijzingen? | Publieke adressen, certificaatcontrole en concrete browsermeldingen over gemengde inhoud. |
| Gestructureerde gegevens | Beschrijven de gegevens de zichtbare pagina correct, en passen syntax en type bij het doel? | Werkelijke uitvoer, zichtbaar bijbehorend gegeven, validatieresultaat en open typegebonden vragen. |
Google beschrijft het verschil tussen ophalen en renderen in zijn JavaScript-documentatie. Controleer daarom niet uitsluitend een screenshot. Gebruik bij uitgesteld laden de richtlijnen voor lazy loading om ontbrekende inhoud en afbeeldingen te onderzoeken. Een handmatig aangeklikte knop bewijst niet dat een crawler dezelfde handeling doet.
De sitemapdocumentatie helpt het publicatiedoel bepalen. De uitleg over structured data maakt duidelijk waarom een geldig blok nog bij de zichtbare inhoud moet passen. Een positief testresultaat of correcte sitemap is geen bewijs dat een zoekresultaat verschijnt.
Zo werk je één open punt uit
Bij de fictieve tegelwebshop uit deze gids kan een productcategorie wel laden, terwijl de links naar het tweede resultaatdeel alleen via een knop werken. Leg dan beide concrete adressen en hun inhoud vast. De templatebeheerder onderzoekt de uitvoer van de links; de inhoudelijk verantwoordelijke bepaalt welke selecties een zelfstandige bestemming verdienen. Controleer na herstel de rechtstreekse toegang én de navigatie. Pas daarna krijgt dit punt de status gecontroleerd en passend.
Maak van het werkblad geen gemiddelde websitekwaliteitsscore. Acht gecontroleerde onderdelen compenseren geen defect formulier bij de belangrijkste dienst. Een zelfverwijzende canonical is evenmin voor iedere URL automatisch de juiste keuze. Bespreek extra beveiligingsinstellingen, zoals HSTS, met de beheerder in de context van domeinen en een eventuele overgang; een algemene SEO-checklist is geen reden om de instelling blind te wijzigen. Prioriteit volgt uit het gevolg voor de pagina en de uitvoerbare oplossing.
Voorbeeld: van melding naar uitvoerbare reparatie
Onderstaand voorbeeld is fictief. Het laat zien welke informatie een overdraagbare taak nodig heeft; het is geen claim over een klant van Niblah.
De tegelwebshop heeft een oude categorie verplaatst. Vanuit meerdere adviesartikelen verwijst de link nog naar het oude adres. Dat adres leidt eerst naar een tussenadres en daarna naar de actuele categorie. De uiteindelijke pagina werkt, maar de verwijzingen en omleidingen zijn onnodig ingewikkeld.
- Bevinding: oude interne links en twee opeenvolgende omleidingen naar dezelfde bedoelde categorie.
- Bewijs: lijst van bronpagina’s, het oude adres, het tussenadres en de actuele bestemming.
- Besluit: interne links rechtstreeks naar de actuele categorie aanpassen en de omleiding van het oude adres gericht vereenvoudigen.
- Verantwoordelijkheid: contentbeheer past verwijzingen aan; de beheerder van de redirectregels controleert de omleiding.
- Oplevercheck: bronlinks werken, de oude URL bereikt de passende categorie en het tussenadres veroorzaakt geen onverwachte fouten.
Bewaar de eerdere instellingen en controleer andere regels die dezelfde bestemming gebruiken. Zo voorkom je dat een kleine reparatie een groter redirectpatroon verandert. Plan vervolgens een hercontrole van de bekende bronpagina’s.
Prioriteer op gevolgen, omvang en uitvoerbaarheid
Een probleem dat de belangrijkste dienstpagina onbereikbaar maakt, vraagt doorgaans eerder aandacht dan een kleine tekstuele inconsistentie. Beschrijf hoeveel belangrijke pagina’s geraakt zijn en welke bezoekerstap vastloopt. Houd urgentie en benodigde inspanning afzonderlijk bij.
Gebruik voor iedere taak een reden die iemand anders kan beoordelen. Denk aan verlies van bereikbaarheid, een verkeerde hoofdversie of een defecte aanvraagroute. Voeg afhankelijkheden toe: toegang tot hosting, een wijziging door een ontwikkelaar of informatie over een oude migratie. Een taak kan belangrijk zijn en toch voorbereiding nodig hebben.
Plan omvangrijke wijzigingen als afzonderlijk werk. Een complete URL-herindeling of platformmigratie vraagt inventarisatie, mapping en controles vóór en na publicatie. Ga niet alle adressen veranderen om een klein voordeel in naamgeving te zoeken. De bredere SEO-audit helpt technische en inhoudelijke prioriteiten combineren.
Leg herstel vast en controleer belangrijke wijzigingen opnieuw
Vraag bij oplevering om de aangepaste pagina’s of instellingen, de uitgevoerde controle en eventuele open punten. Noteer ook de publicatiedatum. Daarmee kun je later terugvinden welke verandering samenvalt met een patroon in de rapportage.
Controleer direct of het bedoelde gedrag werkt en of belangrijke functies bruikbaar blijven. Bekijk daarna de gegevens die verwerking door Google kunnen laten zien. Die stappen hebben niet dezelfde doorlooptijd. Een correct gepubliceerde canonical betekent niet dat Google de pagina die dag opnieuw heeft bezocht.
Pas het ritme aan de website aan. Controleer na een migratie, grote uitbreiding of technische wijziging gericht de betrokken onderdelen. Plan daarnaast terugkerende steekproeven voor belangrijke paginatypen. De SEO-rapportage hoort technische open punten naast inhoudelijke resultaten te laten zien.
Veelgestelde vragen over technische SEO
Moet ik iedere melding van een SEO-tool oplossen?
Nee. Controleer eerst of de melding klopt en of de betreffende pagina het gesignaleerde gedrag hoort te hebben. Beoordeel vervolgens het effect op bezoekers en belangrijke pagina’s. Leg een bewust behouden instelling vast, zodat dezelfde melding later niet zonder context opnieuw op de planning komt.
Is een SEO-plugin voldoende voor een technisch goede website?
Een plugin kan instellingen en metadata beheren, maar beoordeelt niet alle serverproblemen, interne routes of functies. Controleer ook wat werkelijk wordt gepubliceerd. Vooral bij meerdere plugins, maatwerk of een migratie kunnen ingestelde waarden en het zichtbare resultaat verschillen.
Waarom indexeert Google een bereikbare pagina niet meteen?
Bereikbaarheid is één voorwaarde. Google moet de pagina nog ophalen en verwerken en kan besluiten haar niet op te nemen. Onderzoek daarom ook instellingen, hoofdversies, inhoud en interne verwijzingen. Gebruik de actuele pagina en de beschikbare Google-rapportage als afzonderlijke bewijsbronnen.
Wat moet ik ontvangen bij een technische SEO-analyse?
Je wilt een afgebakende inventaris, bevindingen met betrokken URL’s, prioriteiten en uitvoerbare taken. Per belangrijke reparatie moet duidelijk zijn wie het werk doet en hoe herstel wordt gecontroleerd. Spreek vooraf af of uitvoering inbegrepen is of dat je alleen onderzoek en advies ontvangt.
Bespreek de technische basis van jouw website
Deel je domein, het probleem dat je ziet en eventuele recente wijzigingen. Benoem of je onderzoek, reparaties of een controle van eerder werk nodig hebt. Via het Niblah-contactformulier kun je de hulp afbakenen. De SEO-dienstpagina geeft context bij de samenwerking.