SEO-audit: zo voer ik een audit van een website stap voor stap uit

Een SEO-audit is de beslissing wat je op de website als eerste verbetert, met bij elk advies een bewijs en een manier om na de implementatie te controleren of het werkt. De lijst met fouten uit een tool is pas het materiaal voor een audit. Een technische audit is dat deel ervan dat controleert of de robots van zoekmachines en AI-assistenten de website kunnen ophalen en lezen, en of de zoekmachine hem kan indexeren.

Ik voer een audit uit in acht stappen:

1. Ik stel het doel en de situatie van de website vast voordat ik de crawler start, dus het programma dat een website doorloopt zoals de robot van een zoekmachine.
2. Ik controleer of de robots de website überhaupt krijgen.
3. Ik verzamel data uit meerdere bronnen en controleer wat elk ervan niet ziet.
4. Ik onderzoek zoektermen en Google-resultaten voordat ik me met de techniek bezighoud.
5. Ik loop de website door aan de hand van een probleemcatalogus met voorwaarden voor de prioriteit.
6. Ik laat bij elke kwestie het bewijs zien.
7. Ik bepaal de volgorde, de omvang van het werk en de varianten.
8. Ik leg het resultaat voor aan een kruiscontrole en controleer na de implementatie elke kwestie.

Wat is een SEO-audit en wat is het verschil met een technische audit?

Een SEO-audit zegt in welke staat de website is en wat zijn zichtbaarheid beperkt, en een technische audit controleert of de zoekmachine de website kan ophalen, renderen en indexeren. In een volledige audit controleer ik de techniek, de architectuur en de content op de pagina’s, de zoektermen, externe links en de concurrentie, en aan het eind bepaal ik de volgorde van de acties. Een technische audit volstaat als de vraag technisch is: een daling na een implementatie, een migratie, pagina’s die uit de index verdwijnen.

Een audit is de input voor een strategie en geen strategie. De strategie zegt om welke vraag je strijdt en wat je laat liggen, en de audit zegt wat dat nu in de weg staat. In de tekst over SEO-strategie beschreef ik hoe het ene in het andere overgaat.

Hoe voer je een SEO-audit stap voor stap uit?

De volgorde van de stappen doet ertoe, want eerdere stappen bepalen of de getallen uit latere stappen betrouwbaar zijn. Op twee plekken stop ik het proces voor een beslissing: na de eerste stap stel ik de omvang vast, en na de kruiscontrole, vóór het versturen naar de klant, controleer ik de prioriteiten en stellingen.

Stap 1. Doel en situatie van de website, voordat ik de crawler start

De eerste vraag is of de website verkeer verliest of het niet opbouwt, want van het antwoord hangt de hele audit af. Een website zonder zichtbaarheid heeft eerst een kaart nodig van zoektermen en pagina’s die erop moeten antwoorden. Een website die wel zichtbaar is, moet eerst beschermen wat al posities bezet, voordat iemand hem gaat verbeteren.

Vóór de start vraag ik naar dingen die geen enkele tool laat zien. Welke producten of diensten verdienen geld, of er een wijziging van het contentmanagementsysteem of een herontwerp gepland is, wie de adviezen implementeert en hoeveel tijd diegene daarvoor heeft. Uit de antwoorden volgen de omvang van de audit en de lijst met dingen die ik niet uitwerk, omdat niemand ze zal implementeren.

Deze fase moet je zelf doorlopen, ook al geven veel specialisten haar tegenwoordig uit handen aan een taalmodel. Een taalmodel kan nuttig zijn, maar begrijpt het bedrijf van de klant niet. Het brengt ook niet de creatieve, unieke blik van een ervaren SEO-specialist.

Stap 2. Krijgen de robots de website überhaupt

Voordat ik een getal uit een tool lees, controleer ik of de server robots binnenlaat, want een geblokkeerde robot geeft data die eruitzien als SEO-problemen. In één week van juli 2026 bleken drie “SEO-problemen” op drie verschillende websites een blokkade van robots te zijn:

1. Een website “verloor” meer dan 2.200 links, omdat de pagina’s waarvan ze kwamen achter een firewall stonden die de robot van de tool voor linkanalyse afwees.
2. Een webwinkel had in de tool een health score van 0 bij bijna 42 duizend fouten, omdat de robot van de tool in plaats van pagina’s antwoorden van de firewall van Cloudflare kreeg.
3. Op de derde website hield een blokkade de crawler tegen bij het eerste adres, en drie weken lang merkte niemand dat op.

Hetzelfde adres haal ik op als gewone browser en als robots van Google, Bing, OpenAI, Perplexity en Anthropic, en dan vergelijk ik de antwoordcodes en de grootte van de pagina. Het verschil tussen browser en robot is het eerste dat ik moet verklaren voordat ik iets begin te tellen. Zo’n test stuurt verzoeken vanaf mijn IP-adres onder de naam van een robot, en firewalls herkennen echte robots van Google en Bing aan het adres waarvandaan ze komen. Een blokkade van “Googlebot” in de test bewijst dus geen blokkade van de echte Googlebot. Search Console, het gratis paneel van Google voor website-eigenaren, laat zien hoe de echte Googlebot de pagina ziet.

Het bestand robots.txt lees ik tot het eind met een parser, dus een programma dat de regels toepast zoals een robot, en niet met het oog. De robot van Google past maar één groep regels toe, die met de best passende naam van de robot, en slaat de rest over. De regel Disallow: zonder pad blokkeert niets (Google Search Central). In augustus 2026 volgde uit een fragment van robots.txt van een van de websites dat die Google blokkeert. De parser liet zien dat Googlebot volledige toegang had en dat de robots van Bing en AI-assistenten geblokkeerd waren. De diagnose was dus een andere: het probleem betrof Bing en AI-robots en niet Google.

Het ontbreken van robots.txt blokkeert Google niet, maar na elke implementatie controleer ik of het bestand niet is verdwenen. Google behandelt een 4xx-fout bij robots.txt (behalve 429) alsof het bestand er niet is, dus zonder beperkingen (Google Search Central). Mijn eigen website gaf in augustus 2026 een 404-fout op robots.txt, voordat ik dat herstelde.

Stap 3. Data uit meerdere bronnen en wat elk ervan niet ziet

Elk getal uit de crawler is een hypothese zolang een tweede bron het niet bevestigt. Ik verzamel een crawl met en zonder uitvoering van JavaScript en data over snelheid van echte gebruikers uit het CrUX-rapport. Daarbij voeg ik het linkprofiel en de Google-resultaten voor belangrijke zoektermen op de dag van de meting. In de tekst over link building beschreef ik hoe ik het linkprofiel controleer vóór het plan van een campagne. Bij elk bestand noteer ik de bron, de datum en de reikwijdte, zodat je na een maand elk getal kunt reconstrueren.

Data uit Search Console haal ik op via de API, dus een interface om data automatisch op te halen, want de export uit het paneel kapt de lijst af op 1.000 rijen. De API geeft tot 50 duizend rijen per dag per soort resultaten, bijvoorbeeld apart voor resultaten van pagina’s, afbeeldingen en video (Google, Search Console Help). In de tekst over AI-tools voor SEO liet ik zien hoe een afgekapte export de CTR van één website overschatte.

Een crawler kan de omvang van een website te laag inschatten, dus aantallen pagina’s en producten controleer ik in een tweede bron. In twee webwinkels kwam de crawler bij de eerste pagina van de lijst met producten in een categorie en ging niet verder, hoewel de volgende pagina’s van de lijst werkten en niet geblokkeerd waren. In de ene winkel vond hij minder dan de helft van de producten, in de andere minder dan een derde. Had ik die getallen als staat van de winkels gepresenteerd, dan had de audit tekorten in het aanbod beschreven die er niet waren.

Plotselinge veranderingen in dagelijkse data beschrijf ik voordat ik er een oorzaak aan toeschrijf. Dat doe ik voor klikken, vertoningen, posities, sessies en verzoeken van de robot van Google. Ik zoek dagen waarop de mediaan van zeven opeenvolgende dagen minstens 25% verschilt van de mediaan van de veertien dagen daarvoor. Bij elke zo’n datum noteer ik een verklaring: een implementatie, een update van Google, een storing, een wijziging in de meting of “oorzaak onbekend”. De beschrijving van data geeft hypothesen, en de oorzaak wijs ik pas aan na het controleren van andere mogelijke verklaringen.

Stap 4. Zoektermen en Google-resultaten vóór de techniek

Eerst zoek ik kansen, daarna herstel ik fouten. Een deel van de technische problemen is alleen te beoordelen tegen de achtergrond van zoektermen: of een filter in een webwinkel geïndexeerd moet worden, of een tag een eigen pagina verdient, of twee pagina’s echt om hetzelfde strijden. In de catalogus hebben 32 soorten problemen de markering dat ze zonder analyse van zoektermen en Google-resultaten niet te beoordelen zijn.

Het ontbreken van een pagina voor een belangrijke zoekterm is een van de vaker voorkomende problemen in mijn audits: 15 van de 63 audits, bij 14 van de 50 websites. De crawler meldt dat zelf niet, want hij haalt alleen pagina’s op die bestaan. Je ziet het pas als ik de vraag naast de lijst met adressen leg en naast de pagina’s van concurrenten die in de resultaten verschijnen.

Stap 5. Doorlopen aan de hand van een catalogus met voorwaarden voor de prioriteit

Dezelfde fout heeft een hoge of lage prioriteit, afhankelijk van waar hij voorkomt. Een interne link naar een adres met een redirect in een template die zich op duizenden pagina’s herhaalt, heeft een hoge prioriteit. Dezelfde link in de tekst van één bericht heeft een gemiddelde prioriteit en in archiefberichten een lage.

Elke soort probleem in de catalogus heeft een detectieregel, een voorwaarde voor melding, het vereiste bewijs, een prioriteit met voorwaarden en een manier om na de implementatie te controleren. Van de 256 soorten begint bij 86 de prioriteitsregel met “hoog”, maar bijna altijd met een voorwaarde: als de zoekterm vraag heeft, als de pagina verkeer heeft, als de fout in de template zit.

Daarom bepaalt de health score van de website uit een tool de prioriteiten niet. De tool telt fouten en niet het verkeer dat ervan afhangt. Een advies over pagina’s met onbekend verkeer krijgt geen hoge prioriteit zolang ik de data niet heb gecontroleerd.

Stap 6. Bewijs bij elke kwestie

Een kwestie zonder bewijs blijft in de audit staan als “te controleren” en niet als advies. Bewijs is een schermafbeelding van de plek in de code of de HTML van de server naast de versie na uitvoering van JavaScript. Het kan ook een grafiek uit Search Console zijn of een snelheidsmeting met de naam van het element dat haar bederft. Een element dat het laden verslechtert of de lay-out van de pagina verschuift, noem ik zoals de meting het aanwijst en niet zoals het bij mijn hypothese past.

Elke kwestie beschrijf ik in vier delen, van het probleem tot de controle van het herstel. Ik schrijf waaruit het probleem bestaat, waarom het schaadt en waarop het invloed heeft, hoe je het stap voor stap herstelt en hoe we controleren dat het herstel werkte. De code die verbeterd moet worden, kopieer ik letterlijk van de website, zodat de programmeur precies ziet welke plek hij moet wijzigen.

Zo ziet in het kort een melding over links naar redirects eruit:

• Probleem: links in het menu leiden naar adressen zonder slash aan het eind, die doorverwijzen naar de versie met slash.
• Waarom het schaadt: het menu staat op elke pagina, dus elke klik en elke ophaalactie van een robot gaat via een extra redirect. In rapporten van tools bemoeilijken duizenden van zulke links het vinden van belangrijkere fouten.
• Herstel: in de template van het menu de adressen vervangen door de doeladressen, met een stukje code vóór en na de wijziging.
• Controle: na de implementatie toont de crawl in de template geen links naar adressen met een redirect.

Stap 7. Volgorde, omvang van het werk en varianten

Het resultaat van een audit is een volgorde en geen aantal bevindingen. Aan het begin van het document staat een tabel met alle kwesties met prioriteit en omvang van het werk. De omvang beschrijf ik in vier categorieën: enkele uren, een dag of twee, een week of een heel project. Een team met minder mogelijkheden krijgt naast de volledige variant een minimale variant, met een duidelijke beschrijving van wat het verliest door de kortere weg te kiezen.

De implementatie gaat precies volgens de audit. Als er bij de prijsopgave voor de implementatie een goedkopere variant opduikt, kiest de klant die en leg ik dat uitdrukkelijk vast, en vervang ik het advies niet buiten zijn medeweten.

Stap 8. Kruiscontrole en controle na de implementatie

Voordat de audit naar de klant gaat, controleert iemand hem die hem niet heeft geschreven. Ik doe twee rondes controle: de eerste op het hele document, de tweede alleen op wat er na de eerste is veranderd. De controle rekent de getallen vanaf nul na en zoekt stellingen die je niet met bewijs kunt verdedigen. Aan het eind controleer ik zelf de prioriteiten en de stellingen die van de situatie van de klant afhangen.

Na de implementatie controleer ik elke kwestie op de werkende website en markeer ik haar als correct, gedeeltelijk of niet geïmplementeerd. Die controle zit in de prijs van de audit. Zonder deze stap eindigt een audit bij het document en niet bij een wijziging op de website.

Wat controleer ik in een technische audit?

In een technische audit loop ik ruim tien gebieden door, en problemen meld ik het vaakst bij redirects, de architectuur van de website en de content. De laatste kolom laat zien in hoeveel van de 63 audits uit het archief de auteur minstens één probleem uit dat gebied meldde. De kolom “Wat ik controleer” geeft voorbeelden en niet de volledige reikwijdte van het gebied. De tabel toont geselecteerde gebieden, en de catalogus verdeelt de problemen over 22.

Een zelden gemeld probleem hoeft niet zelden voor te komen. Snelheid en JavaScript hebben in deze tabel weinig meldingen, maar de audits uit het archief hadden een verschillende reikwijdte. Een laag aantal meldingen zegt dus niet hoe vaak deze problemen op websites voorkomen.

Hoe controleer ik de indexering van een website?

Indexering controleer ik op drie lijsten: wat in de sitemap staat, wat Google heeft geïndexeerd en wat de crawler via links vindt. Het verschil tussen deze drie lijsten laat het probleem beter zien dan elke lijst afzonderlijk. Een sitemap met adressen die een redirect of een fout geven of van de index zijn uitgesloten, werd gemeld in 20 van de 63 audits, bij 18 van de 50 websites. Voor afzonderlijke adressen gebruik ik de URL-inspectie in Search Console, die ook de pagina na uitvoering van JavaScript toont.

Hebben Core Web Vitals invloed op posities?

Core Web Vitals zijn onderdeel van de rankingsystemen van Google, maar winnen het niet van de relevantie van de content. Google schrijft uitdrukkelijk dat de rankingsystemen Core Web Vitals gebruiken. Het schrijft ook dat het altijd probeert de meest relevante content te tonen, ook bij een zwakke ervaring op de pagina (Google Search Central). In de audit gebruik ik data van echte gebruikers uit het CrUX-rapport en niet één test in een labtool. Waar Google zulke data heeft voor afzonderlijke soorten pagina’s, geef ik ze apart. Hiaten in die data beschrijf ik in de audit. Sinds 12 maart 2024 is INP de maat voor de reactie van de pagina, die FID verving (web.dev).

Welke fouten vind ik het vaakst in SEO-audits?

Het vaakst herhalen zich ordefouten, dus fouten die tools gemakkelijk vinden: links naar redirects en naar 404-fouten, sitemaps met de verkeerde adressen en dubbele titels en omschrijvingen van pagina’s. Interne links naar adressen met een redirect kwamen voor in 24 van de 63 audits, bij 20 van de 50 websites. Tools vinden ze goed, en de kosten van het herstel hangen af van de template en het systeem van de website.

Minder vaak gemelde problemen met de structuur kunnen meer invloed op het verkeer hebben dan ordefouten. Het ontbreken van pagina’s voor belangrijke zoektermen werd gemeld in 15 van de 63 audits, en net zo vaak een blog dat niet linkt naar de pagina’s van aanbod en categorieën. De catalogus geeft een ontbrekende pagina een hoge prioriteit als de zoekterm vraag heeft en de concurrentie de posities bezet met aparte pagina’s. Een blog zonder links krijgt een hoge prioriteit als de doelpagina’s verkeer of omzet hebben en de blog autoriteit heeft. Die voorwaarden controleer ik op data voordat ik een prioriteit toeken.

• 938bevindingen in 63 audits op 50 websites, waaruit ik een catalogus van 256 soorten problemen bouwdeArchief van audits 2020-2026, catalogus van 11-10-2026
• 38%audits met interne links naar adressen met een redirect, het vaakst gemelde probleem in het archief (24 van de 63)Catalogus van 11-10-2026
• 15 van 63audits met het ontbreken van pagina’s voor belangrijke zoektermen, wat de crawler zelf niet meldtCatalogus van 11-10-2026
• 14soorten adviezen die de catalogus nu als verouderd markeert, en 30 andere als veranderde praktijkCatalogus van 11-10-2026

Wat is er sinds 2020 veranderd in SEO-audits?

In audits uit de jaren 2023-2026 komen gestructureerde data en paginering vaker voor dan in de jaren 2020-2022, en redirects, canonical-adressen en indexering minder vaak. Problemen met gestructureerde data werden gemeld in 23 van de 33 nieuwere audits, tegenover 16 van de 30 oudere. Redirects en antwoordcodes: 23 van de 33 tegenover 27 van de 30. Blokkades van AI-robots verschijnen pas in audits uit 2026. Het jaar van de audit is de datum van het bestand in het archief, dus niet altijd het jaar waarin het werk is gedaan.

De daling bewijst niet dat de problemen met redirects zijn verdwenen. De samenstelling van de audits is veranderd: nieuwere gingen vaker over gestructureerde data, content en zichtbaarheid in AI, en ook de manier van werken is veranderd. Uit deze grafiek volgt waar de audits zich mee bezighielden en niet hoe de websites in Polen zijn veranderd.

Welke SEO-adviezen zijn nu verouderd?

Sommige adviezen komen nog steeds voor in audits en handleidingen, hoewel het nu niet meer de moeite waard is ze te implementeren. Een deel ervan werkte een paar jaar geleden, en een deel raadde Google al lang af of negeerde het. In de tabel geef ik bij elke praktijk de reden en wat je in plaats daarvan doet.

Bronnen bij de tabel: Google over paginering, Google over vijf fouten met rel=canonical, Google over FAQ- en HowTo-resultaten, Matt Cutts over nofollow en de verdeling van linkkracht, John Mueller over redirects naar de homepage, via Search Engine Roundtable, Google over robots.txt, Google over niet-ondersteunde regels in robots.txt, Google over sitemaps, Google over de velden lastmod, changefreq en priority, web.dev over INP, Google over het zoekveld in de resultaten.

Daarom heeft elk advies in mijn catalogus een veld voor actualiteit met een motivering. De catalogus markeert nu 14 soorten adviezen als verouderd en 30 als veranderde praktijk. Een advies dat een paar jaar geleden correct was, komt niet in een audit terecht alleen omdat het ooit werkte.

Hoe controleer je in een audit de toegang van AI-robots?

De toegang van AI-robots controleer ik in dezelfde stap als de toegang van Googlebot, want dezelfde instelling van de firewall of CDN kan ze blokkeren. Een CDN is een netwerk van tussenliggende servers, bijvoorbeeld Cloudflare. In september 2026 controleerde ik 12 domeinen van mijn klanten die achter Cloudflare draaien. Alleen het bestand robots.txt liet zien:

• 3 domeinen blokkeerden dezelfde set van zeven robots die data verzamelen om modellen te trainen, met een identieke lijst met namen. Een identieke lijst wijst op een gemeenschappelijke bron, bijvoorbeeld een kant-en-klare instelling in het paneel van Cloudflare. Van buitenaf is die instelling niet te zien, dus ze moet in het paneel zelf worden bevestigd.
• 1 domein blokkeerde robots die pagina’s ophalen voor antwoorden van ChatGPT, Perplexity en Claude. Het deed dat niet uitdrukkelijk, maar met een algemene regel voor alle robots die niet bij naam worden genoemd. Datzelfde domein toonde GPTBot een beveiligingspagina zonder de noindex-markering, die een pagina uit de index uitsluit. Had de indexerende robot zo’n pagina gekregen, dan had de blokkadepagina in plaats van de content in de index kunnen komen.
• 8 domeinen hadden geen blokkades in robots.txt.

Over robots die pagina’s ophalen voor antwoorden en over robots die data verzamelen om te trainen, beslis je apart. In de tekst over GEO en AI SEO beschreef ik hoe je ze onderscheidt. Sinds 31 augustus 2026 is er in Search Console ook een aparte instelling die een website uitsluit van AI Overview, de AI-modus en generatieve functies in Discover. Volgens Google heeft ze geen invloed op de rest van de zoekresultaten (Search Console Help). Zo’n instelling controleer ik in de audit net als robots.txt, want iemand kan haar hebben ingeschakeld zonder medeweten van de persoon die voor SEO verantwoordelijk is. Of het merk na het openen van de toegang in antwoorden verschijnt, is een aparte meting, die ik beschreef in de tekst over zichtbaarheid van een merk in AI.

Een test vanaf één IP-adres laat maar een deel van de situatie zien en kan zelf vals alarm geven. In hetzelfde overzicht meldde een reeks verzoeken op twee domeinen een blokkade na overschrijding van een limiet. Die blokkade werd veroorzaakt door mijn eigen eerdere verzoeken. Een controle een paar minuten later, met één identificator van een robot en losse verzoeken, gaf vijf en zeven correcte antwoorden achter elkaar. Zonder die controle hadden twee klanten bericht gekregen over een blokkade die er niet was. Pas serverlogs laten zien of ChatGPT de pagina echt ophaalt. In de tekst over het bestand llms.txt laat ik zien wat er in de logs van mijn website te zien is.

Code 200 betekent niet dat de robot de content kreeg. Bij een klant met een applicatie in JavaScript kregen Googlebot en Bingbot kant-en-klare HTML van een prerenderdienst, en de robots van AI-assistenten een lege pagina. De dienst herkende robots aan hun naam en had de AI-robots niet op de lijst. Mijn test gaf de uitkomst “in orde”, omdat hij de antwoordcode mat en niet de content. Sindsdien vergelijk ik de content die de robot krijgt met de content na uitvoering van JavaScript in de browser.

Is een gratis SEO-audit genoeg?

Een gratis tool toont een lijst met fouten, maar uit het rapport alleen volgt niet welke ervan je verkeer kosten. Op de Poolse zoekterm “audyt seo” zijn 7 van de 9 organische resultaten op de eerste pagina van Google in Polen tools of aanbiedingen van een gratis audit (resultaten van 17 oktober 2026). Zo’n rapport telt fouten volgens de regels van de tool en niet volgens hoeveel verkeer en omzet ervan afhangen. Je moet ook controleren of de uitkomst niet voortkomt uit een blokkade van de robot, zoals bij de webwinkel met health score 0.

Je kunt veel gratis doen als je weet waar je moet kijken. Search Console toont de data van Google over indexering, Core Web Vitals en de pagina na uitvoering van JavaScript. De gratis versie van Screaming Frog doorloopt tot 500 adressen in één crawl (Screaming Frog), wat volstaat voor een kleine bedrijfswebsite. Een audit met een consultant heeft zin als een fout veel kost (migratie, daling van het verkeer, grote webwinkel) of als je geen tijd hebt om de data samen te brengen en te beoordelen.

Doet ChatGPT een SEO-audit?

ChatGPT of een ander AI-model doet niet zelf een volledige audit, want het ziet de website niet zoals de robot van een zoekmachine. Meestal ziet het hem via een tool die hem ophaalt en omzet in tekst. Het model leest de data die je het geeft en stelt voor wat je kunt controleren. De tool voor ophalen kan echter een deel van de pagina kwijtraken: in september 2026 controleerde ik dat de tool voor het ophalen van pagina’s in Claude Code gestructureerde data weglaat bij het omzetten van de pagina in tekst. Het model antwoordde dat die informatie er niet was, hoewel ze in een markering op dezelfde pagina stond. Een audit die zo is gedaan, zou het ontbreken melden van gestructureerde data die er wel zijn. In mijn proces is AI een hulpmiddel, vooral voor het samenvoegen van data uit de crawl, Search Console en andere bronnen. De omvang, de beoordeling en de prioriteiten bepaal ik zelf.

Wat kost een SEO-audit?

Een audit reken ik af zoals advies: 70 EUR per uur exclusief btw, met een maximum aantal uren dat vóór de start is vastgesteld. Het aantal uren hangt af van wat er gecontroleerd moet worden:

• een diagnostische audit, dus een of twee concrete problemen (daling, migratie, indexering), is meestal 10-16 uur, dus 700-1.120 EUR exclusief btw;
• een volledige audit met een volgorde van acties is meestal 32-50 uur, dus 2.240-3.500 EUR exclusief btw;
• een kleine website tot 500 adressen zit dichter bij de ondergrens en een webwinkel met duizenden adressen en filters dichter bij de bovengrens;
• taalversies voegen meestal 3-5 uur toe, en een lopende crisis die gediagnosticeerd moet worden 4-8 uur.

In de prijs zitten de analyse, het rapport met adviezen, een gesprek waarin we het bespreken en de controle na de implementatie. De implementatie zelf doet jouw team, of ik reken die apart af.

Zonder toegang tot Search Console, het paneel van de CDN en de hosting kan ik het technische deel niet volledig controleren, en dat zeg ik vóór de prijsopgave. Ik geef dan aan wat ik zonder die toegang niet kan verifiëren en beperk de omvang dienovereenkomstig. In de tekst over SEO-advies beschreef ik wanneer een gesprek over één beslissing volstaat in plaats van een audit.

Veelgestelde vragen over de SEO-audit

Waar begin je?

Begin met één vraag: verliest de website verkeer of bouwt hij het niet op. Van het antwoord hangt af of je eerst de pagina’s beschermt die posities hebben, of zoekt naar zoektermen waarvoor pagina’s ontbreken. Doe daarna de drie gratis controles uit het antwoord over een eigen audit: robots.txt, het indexeringsrapport in Search Console en een crawl met de gratis versie van Screaming Frog. Verrast de uitkomst je, of weet je niet wat je als eerste moet herstellen, dan is het een goed onderwerp voor een adviesgesprek.