Een SEO-specialist kiezen: taken, uitvoering en bewijs

Een SEO-specialist kies je op het werk dat jouw website nodig heeft én op wie dat werk uitvoert en controleert. Vraag daarom vooraf naar concrete opleveringen, verantwoordelijkheden en bewijs. Met de werkbladen hieronder maak je zichtbaar wat je intern kunt oppakken, welke expertise ontbreekt en wanneer een opdracht inhoudelijk klaar is.

Wat moet een SEO-specialist voor jouw website doen?

Een SEO-specialist onderzoekt hoe mensen zoeken, welke pagina’s hun vragen beantwoorden en welke obstakels het vinden en gebruiken van die pagina’s bemoeilijken. Vervolgens vertaalt de specialist bevindingen naar keuzes, werkzaamheden en controles. De precieze opdracht kan bestaan uit onderzoek, advies, uitvoering, testen of een combinatie daarvan.

De titel consultant, expert of specialist vertelt weinig over die uitvoeringsrol. Iemand kan een degelijk technisch onderzoek opleveren zonder zelf je WordPress-thema aan te passen. Een contentspecialist kan een inhoudsplan maken, terwijl jouw productdeskundige de feiten moet aanleveren. Beide kunnen passend zijn, zolang die grenzen vooraf duidelijk zijn.

Begin daarom bij een concreet probleem. Bijvoorbeeld: bezoekers vinden wel een algemene dienstenpagina, maar kunnen niet beoordelen welke uitvoering bij hun situatie past. Dat vraagt eerst om onderzoek naar zoekvragen en ontbrekende informatie. Een volledige technische verbouwing is dan niet vanzelfsprekend de juiste eerste stap. Voor het bredere kader kun je de uitleg over SEO gebruiken.

Verdeel vier verantwoordelijkheden voordat je begint

Kopieer dit vierverantwoordelijkhedenblad naar je eigen document. Vul bij iedere rij een naam in, geen afdeling of algemeen bureauadres. Eén persoon mag meerdere rollen hebben. Het doel is zichtbaar maken waar een besluit, uitvoering of controle anders tussen partijen zou blijven liggen.

Heb je een intern team met ontwikkelaars en redacteuren? Dan kan de ontbrekende rol vooral onderzoek en prioritering zijn. Leg wel vast hoeveel beschikbare capaciteit dat team heeft. Een advies dat niemand kan uitvoeren, blijft liggen. Ontbreekt een uitvoerder, vraag dan expliciet wie de implementatie verzorgt en of die werkzaamheden onderdeel van de opdracht zijn.

Gebruik een competentiekaart voor vier vakgebieden

Niet iedere website heeft op elk vakgebied evenveel werk nodig. Gebruik deze competentiekaart om door te vragen op jouw situatie. De noodzakelijke bron onderbouwt de diagnose; het acceptatiebewijs laat zien of de afgesproken ingreep correct is opgeleverd. Dat bewijs is iets anders dan een belofte over posities of aanvragen.

Vraag bij techniek niet alleen of iemand een audit kan draaien. Vraag of die persoon een bevinding kan vertalen naar een uitvoerbare wijziging in jouw systeem. Vraag bij content hoe feiten worden gecontroleerd. Een zoekwoord in een kop zetten lost een ontbrekend antwoord niet op. Het verbinden van vragen aan pagina’s wordt verder uitgewerkt bij zoekwoordenonderzoek en SEO-content.

Beoordeel externe verwijzingen op doel en context

Een score uit een linktool vertelt niet zelfstandig of een verwijzing nuttig of verantwoord is. Bekijk wie de pagina leest, waarom de link daar staat en welke afspraken eraan verbonden zijn. Volgens Googles beleid over linkspam kunnen links die hoofdzakelijk voor rankingmanipulatie worden gemaakt onder linkspam vallen. Reclame en sponsoring kunnen legitiem zijn, met passende kwalificatie van de links.

Een onbekende inkomende link is evenmin automatisch reden voor een disavow-bestand. Google beschrijft de disavow-tool als een geavanceerd middel dat de meeste websites niet nodig hebben. Vraag eerst welk concreet probleem is vastgesteld. Een lage externe toolscore is op zichzelf geen onderbouwing om links af te wijzen.

Maak zes soorten oplevering concreet

Een opleveringscontract is hier een werkafspraak per resultaat. Je legt vast welke invoer nodig is, wie de bronhouder en uitvoerder zijn, welk bewijs wordt geleverd, wie onderhoud oppakt en welke afhankelijkheid nog openstaat. Je hoeft niet alle zes onderdelen af te nemen. Kies wat de diagnose rechtvaardigt.

1. Onderzoeks- en prioriteitenoverzicht

Invoer: de belangrijkste paginatypen, bedrijfsdoelen, beschikbare zoekgegevens en bekende wijzigingen. Bronhouder: de websiteverantwoordelijke voor historie en toegang, aangevuld met inhoudelijke eigenaren. Uitvoerder: degene die het SEO-onderzoek doet en aannames controleert.

Bewijs: een overzicht waarin iedere bevinding verwijst naar een URL, export of reproduceerbare test. Per voorstel staat waarom het relevant is, hoeveel inspanning het vermoedelijk vraagt en wat nog onbekend is. Onderhoud: herbeoordeling wanneer nieuwe gegevens of belangrijke websitewijzigingen de prioriteit veranderen. Open afhankelijkheid: bijvoorbeeld ontbrekende toegang tot historische meetgegevens.

Accepteer dit overzicht wanneer je kunt uitleggen waarom taak A vóór taak B komt. Een lang document met veel meldingen is daarvoor onvoldoende. Voor de onderzoeksopzet sluit een SEO-audit aan; voor de afweging tussen doelen en werkzaamheden helpt een SEO-strategie.

2. Inhoudsplan met een eigenaar per pagina

Invoer: klantvragen, bestaande pagina’s, zoekonderzoek en gecontroleerde feiten over het aanbod. Bronhouder: de persoon die verantwoordelijk is voor de dienst- of productinformatie. Uitvoerder: de schrijver of redacteur, met een benoemde inhoudelijke beoordelaar.

Bewijs: per pagina een lezersvraag, beoogde beslissing, benodigde feiten en keuze voor aanpassen, samenvoegen of nieuw schrijven. Onderhoud: een eigenaar die veranderingen in assortiment, voorwaarden of dienstverlening doorgeeft. Open afhankelijkheid: bijvoorbeeld een nog niet bevestigde productspecificatie.

Een bruikbaar plan voorkomt dat twee pagina’s dezelfde vraag vrijwel identiek beantwoorden. Het beschrijft ook welke bestaande pagina naar de nieuwe uitleg verwijst. Werk dat waar nodig uit met een plan voor interne links. De oplevering is pas uitvoerbaar als de schrijver weet welke informatie nog moet worden opgehaald.

3. Technisch uitvoeringsticket met eigen tests

Invoer: een reproduceerbaar probleem, betrokken URL’s, systeeminformatie en een voormeting. Bronhouder: de beheerder van website, thema, applicatie of hosting. Uitvoerder: een ontwikkelaar of beheerder met de benodigde rechten.

Bewijs: het uitvoeringsticket bevat verwacht gedrag, wijzigingsomvang en tests voor zowel de fout als mogelijke neveneffecten. Onderhoud: vastleggen welke component de instelling beheert en wanneer opnieuw moet worden getest. Open afhankelijkheid: bijvoorbeeld toestemming om een template te wijzigen of beschikbaarheid van een testomgeving.

De specialist hoeft niet persoonlijk elke programmeertaal te beheersen. Wel moet duidelijk zijn wie de vertaalslag naar implementatie maakt en wie controleert of het probleem is opgelost. Verdere technische onderzoeksgebieden staan bij technische SEO.

4. Afgebakend onderzoek naar AI-zoekantwoorden

Invoer: een beperkte set echte beslisvragen, relevante pagina’s en het product waarin je wilt observeren. Bronhouder: de ondernemer voor klantcontext en de onderzoeker voor de vastgelegde waarnemingen. Uitvoerder: degene die de afgesproken vragen onder beschreven omstandigheden onderzoekt.

Bewijs: bewaarde antwoorden met datum, modus, bronlinks en inhoudelijke beoordeling. Onderhoud: alleen herhalen op afgesproken momenten of bij een concrete wijziging. Open afhankelijkheid: bijvoorbeeld onbekende personalisatie of een productmodus die niet voor ieder account beschikbaar is.

Dit onderzoek kan onduidelijke informatie of onjuiste antwoorden zichtbaar maken. Het bewijst niet hoe vaak alle potentiële klanten jouw merk zien. Spreek daarom vooraf af welke beslissing het onderzoek ondersteunt, bijvoorbeeld of een belangrijke keuzevoorwaarde op je website duidelijker moet worden uitgelegd.

5. Meetoverzicht met definities en beperkingen

Invoer: beschikbare meetbronnen, ingestelde gebeurtenissen en de vragen waarop je antwoord wilt. Bronhouder: de accounteigenaar en degene die de meetinrichting beheert. Uitvoerder: de specialist of analist die gegevens controleert en rapporteert.

Bewijs: een overzicht met definities, filters, perioden en eventuele meetbreuken. Een aanvraag telt bijvoorbeeld pas als aanvraag wanneer duidelijk is welke gebeurtenis daarvoor wordt gebruikt. Onderhoud: de definities en werking opnieuw controleren na wijzigingen aan formulieren of toestemming. Open afhankelijkheid: ontbrekende historie, onvoldoende toestemming of een nog niet geteste gebeurtenis.

Maak onderscheid tussen zoekzichtbaarheid, websitegebruik en bedrijfsuitkomsten. Die gegevens kunnen samen helpen bij een besluit, maar vormen niet automatisch een sluitende toeschrijving aan SEO. Een SEO-rapportage hoort die grenzen zichtbaar te houden.

6. Release- en wijzigingscontrole

Invoer: de geplande wijziging, betrokken paginatypen, voormeting en beoogde versie. Bronhouder: de releaseverantwoordelijke. Uitvoerder: degene die publiceert, met een benoemde tester voor de controle achteraf.

Bewijs: een ingevulde voor-en-na-controle van de relevante pagina’s, inclusief actieve omgeving en eventuele afwijkingen. Onderhoud: hergebruik de kaart bij volgende wijzigingen en pas de testselectie aan de omvang aan. Open afhankelijkheid: bijvoorbeeld een externe cache, een nog niet beschikbare publicatie of een ontbrekende terugzetprocedure.

Een release kan technisch slagen terwijl belangrijke tekst of meetcode verdwijnt. Daarom eindigt deze oplevering niet bij de melding dat de publicatie is gelukt. Ze eindigt bij een vastgelegde beoordeling van de publiek zichtbare versie.

Fictief voorbeeld: een verkeerde canonical onderzoeken en herstellen

Onderstaand voorbeeld is volledig fictief. Het laat zien hoe je een opdracht en de controle ervan kunt afbakenen. De aantallen zijn uitsluitend bedoeld om de testdekking door te rekenen; ze zeggen niets over verwacht zoekverkeer of commerciële resultaten.

Een verhuurbedrijf heeft acht zelfstandig bedoelde dienstenpagina’s. In de eerste steekproef verwijzen de canonicals van twee pagina’s naar de algemene dienstenpagina. Dat is aanleiding voor verder onderzoek, geen bewijs dat alle acht fout staan. De onderzoeker vergelijkt inhoud, URL-varianten, interne links en de template-instelling. Daaruit blijkt in dit voorbeeld dat elke dienstenpagina een afzonderlijk aanbod beschrijft en dat een gedeelde templatewaarde de verkeerde canonical veroorzaakt.

• Ticket: vervang de vaste canonicalwaarde uitsluitend in het betreffende dienstentemplate door de vastgestelde voorkeurs-URL per pagina.
• Bronhouder: de websitebeheerder levert de lijst met acht bedoelde URL’s en bevestigt welke varianten bestaan.
• Uitvoerder: de ontwikkelaar past de template aan in de testomgeving.
• Verwacht gedrag: iedere betrokken pagina bevat één canonical naar haar bedoelde, bereikbare voorkeurs-URL.
• Uitgesloten wijziging: andere templates, redirects en inhoud blijven buiten dit ticket, tenzij de diagnose een aanvullende opdracht noodzakelijk maakt.
• Afhankelijkheid: de beheerder moet de voorkeurs-URL’s bevestigen voordat implementatie begint.
• Terugzetten: de releaseverantwoordelijke bewaart de vorige versie en beslist bij een ongewenst neveneffect over herstel.

De eigen tests controleren alle acht dienstenpagina’s en vier controlepagina’s uit andere templates. Voor iedere pagina worden de HTTP-status, het aantal canonicals en de waarde ervan gecontroleerd. Dat zijn twaalf pagina’s maal drie controles: 36 vastgelegde controlepunten. De acht betrokken pagina’s worden daarnaast in een echte browser bekeken om te controleren of de inhoud normaal verschijnt.

Stel dat 35 controlepunten slagen en één dienstenpagina naar een omleidende URL verwijst. Dan is het ticket nog niet geaccepteerd. De uitvoerder corrigeert die waarde en herhaalt de betrokken controles. De breuk 35 gedeeld door 36 beschrijft uitsluitend de afgevinkte controlepunten; hij is geen SEO-score.

Na publicatie worden dezelfde URL’s op de actieve website gecontroleerd. Daarna kan afzonderlijk worden gevolgd welke canonical Google selecteert. De technische implementatie kun je direct beoordelen; verwerking door een zoekmachine volgt een eigen tempo. Een canonical is een signaal en dwingt Google niet om jouw voorkeur in iedere situatie over te nemen.

Kies een hulpmiddel pas nadat de onderzoeksvraag vaststaat

Een lange lijst abonnementen zegt weinig over de kwaliteit van een opdracht. Vraag per hulpmiddel welke waarneming nodig is, hoe de uitkomst wordt gecontroleerd en welke beperking erbij hoort. Leg ook de toegangsrechten vast: wie mag bekijken, wijzigen, exporteren en gebruikers toevoegen?

Core Web Vitals helpen specifieke gebruiksproblemen onderzoeken. Controleer daarnaast de echte bezoekerstaak, zoals een uitvoering kiezen of een formulier invullen. Een goede meetwaarde laat op zichzelf niet zien of de informatie klopt of die taak lukt.

Laat vooraf bevestigen wie eventuele licentiekosten draagt en welke limieten gelden voor crawls, exports of gemonitorde vragen. Gebruik waar mogelijk persoonlijke accounts met passende rechten. Spreek ook af hoe toegang eindigt en welke exports je behoudt. Een screenshot zonder periode, filters en herhaalbare onderzoeksvraag is onvoldoende bewijs voor een belangrijke beslissing.

Voor zoekprestaties beschrijft de documentatie van Search Console onder meer klikken, vertoningen, CTR en gemiddelde positie. Beoordeel veranderingen binnen dezelfde afbakening. Een vergelijking van alle apparaten met alleen mobiel in een volgende periode kan een misleidend beeld geven.

Vraag implementatiebewijs voor schema en rendering

Begin bij de zichtbare informatie en het concrete probleem. Ontbreekt essentiële tekst in de geleverde HTML, verschijnt die pas na interactie of klopt productinformatie in de markup niet? Onderzoek eerst welke component dat veroorzaakt en of de relevante zoekmachine de inhoud kan verwerken. Kies daarna een ingreep.

Handmatig toegevoegde code en een plugin kunnen beide geschikt zijn. Het implementatiebewijs moet laten zien dat de oplossing bij de website past: relevante JSON-LD is geldig, beschrijft de zichtbare feiten en wordt niet tegengesproken door een tweede gegevensblok uit een thema of andere plugin. Meerdere blokken zijn niet automatisch fout; tegenstrijdige entiteiten en dubbele onjuiste gegevens verdienen wel onderzoek.

Controleer de oorspronkelijke HTML, de weergave in een echte browser en verschillende pagina’s uit de betrokken template. Test ook lege of afwijkende velden. Bij een meertalige website controleer je waar relevant of taalverwijzingen naar de juiste tegenhangers wijzen. Een geslaagde test op één voorbeeldpagina bewijst niet dat elk product of iedere taalversie goed staat.

Server-side rendering is een mogelijke technische keuze als de diagnose daarvoor aanleiding geeft. Het is geen standaardvoorwaarde voor iedere SEO-opdracht. Beschrijf welk probleem de wijziging moet oplossen, welke onderhoudslast ontstaat en hoe je dezelfde inhoud en functies daarna controleert.

Google ondersteunt en adviseert onder voorwaarden JSON-LD, maar geldige gestructureerde gegevens garanderen geen rich result of AI-vermelding. Google heeft FAQ-rich-results per 7 mei 2026 beëindigd, zoals vermeld in de documentatie-updates. Een zichtbare FAQ blijft bruikbaar om vragen te beantwoorden; beloof daarvoor geen uitgebreid zoekresultaat.

Gebruik logbewijs alleen voor wat het werkelijk aantoont

Logonderzoek kan helpen wanneer je wilt weten welke verzoeken een server ontvangt en welke antwoorden die geeft. Controleer eerst welke velden beschikbaar zijn. Niet ieder hostinglog bevat bruikbare IP-adressen, volledige URL’s, responstijden of gegevens van alle tussenliggende caches.

Spreek een representatieve periode af die past bij de vraag. Onderzoek je een storing rond een release, neem dan gegevens vóór en na die wijziging mee. Onderzoek je terugkerend crawlgedrag, houd dan rekening met publicatieritme en tijdelijke incidenten. Noteer ontbrekende dagen en onderdelen van de infrastructuur die buiten beeld blijven.

Een user-agent met de naam van een zoekrobot bewijst de crawleridentiteit niet. Die tekst kan worden nagebootst. Voor Google beschrijft de verificatie van crawlerverzoeken controle via gepubliceerde IP-reeksen of reverse-DNS gevolgd door overeenkomende forward-DNS. Is die verificatie niet mogelijk, label de identiteit dan als onbevestigd.

Bewaar bij bruikbaar logbewijs de periode, verificatiemethode, URL, statuscode en beperking. Een bevestigd serververzoek bewijst toegang tot die URL op dat moment. Het bewijst geen indexering, modeltraining of vermelding in een antwoord. Gebruik Search Console en een externe crawl als aanvullende bronnen voor hun eigen onderzoeksvragen.

Maak van ieder logonderzoek ook geen crawlbudgetproject. Googles uitleg over crawlbudget richt zich op grote of vaak veranderende websites; veel kleinere websites hebben geen afzonderlijk traject nodig. Weinig verkeer is bovendien geen bewijs dat een nuttige pagina moet verdwijnen. Diagnose gaat vooraf aan verwijderen, blokkeren of aanpassen.

Controleer de actieve omgeving met een releasewerkkaart

Gebruik deze releasewerkkaart bij wijzigingen aan een thema, template, plugin of belangrijk paginatype. Noteer eerst het domein, de actieve omgeving, de huidige versie, de geplande versie en de rollbackeigenaar. Leg vast wie mag besluiten om terug te zetten en hoe die persoon de vorige versie kan herstellen.

Maak verschil tussen een bewuste inhoudelijke wijziging en onbedoeld templateverlies. Als een verouderde alinea volgens het inhoudsplan is verwijderd, hoeft die niet terug. Als alle keuze-informatie verdwijnt doordat een contentveld niet meer wordt getoond, is dat een afwijking die onderzocht moet worden.

Controleer de werkelijk publieke versie. Een datum in een deployoverzicht of een HTTP 200 zegt op zichzelf niet dat de bedoelde websiteversie zichtbaar is. De releasewerkkaart helpt je beslissen tussen accepteren, gericht herstellen of terugzetten. Ze voorspelt geen rankingeffect en vervangt geen latere meting.

Behandel Bing en AI-producten als afzonderlijke zoekomgevingen

Bing is een eigen zoekomgeving. Een waarneming in Bing onderbouwt wat daar onder de vastgelegde omstandigheden zichtbaar was. Ze bewijst niet automatisch dat hetzelfde merk of dezelfde bron in ChatGPT verschijnt. Noteer bij iedere conclusie de platformscope: het product, de functie, de periode en de gebruikte bewijsbron.

Ook binnen AI-producten verschillen de rollen van bots. De OpenAI-documentatie over bots onderscheidt OAI-SearchBot voor ChatGPT search en GPTBot voor het crawlen van inhoud die mogelijk voor modeltraining wordt gebruikt. ChatGPT-User doet door gebruikers gestarte verzoeken en is geen algemene instelling voor opname in zoekresultaten. Daarbij kan robots.txt anders uitwerken dan bij automatisch crawlen.

Onderzoek daarom eerst welk gebruik je wilt toestaan of beperken. Pas daarna de relevante instellingen aan en controleer de configuratie. Toegang toestaan garandeert geen verschijning. Een llms-bestand is evenmin een universeel toegangsbewijs voor alle AI-producten.

Voor Google AI Overviews en AI Mode gelden volgens Googles documentatie over AI-functies de gewone SEO-vereisten. Er is geen speciaal AI-bestand of aanvullend schema vereist. Ondersteunende pagina’s moeten geïndexeerd zijn en een snippet kunnen tonen, zonder garantie op opname. De betreffende prestaties vallen binnen Web in Search Console; presenteer dat niet als een schoon afzonderlijk AI-rapport.

Google-Extended betreft andere vormen van gebruik en is niet de knop voor zichtbaarheid in Google Search. Pas de uitleg van Google ook niet zonder bewijs toe op een ander platform. Voor de afweging of onderzoek zinvol is, kun je verder lezen over AI en SEO.

Onderzoek AI-antwoorden met een beperkte vraagsetkaart

Kies vragen die aansluiten bij echte aankoopbeslissingen. Een vraag als ‘Welke leverancier is de beste?’ geeft zonder context weinig houvast. Een concretere vraag vermeldt toepassing, beperking en keuzecriterium. Bijvoorbeeld: welke informatie heeft iemand nodig om te bepalen of een product buiten kan blijven staan?

Gebruik onderstaande vraagsetkaart als statisch invulblad. Ze voert geen meting uit. Je vult zelf de waarnemingen in of spreekt af wie dat doet. Kies het aantal vragen en herhalingen op basis van het onderzoeksdoel, niet op basis van een voorgeschreven maandelijks volume.

• Doel: welke beslissing moet dit onderzoek ondersteunen?
• Vraag en context: welke exacte tekst, taal en relevante gebruikssituatie worden onderzocht?
• Product en modus: waar is de vraag gesteld en was zoeken ingeschakeld?
• Datum en herhaling: wanneer is de waarneming gedaan en hoe vaak onder beschreven omstandigheden?
• Merk: wordt de naam genoemd, en in welke context?
• Bronlink: staat er een controleerbare link, en ondersteunt die het antwoord?
• Nuttigheid: kan de lezer met het antwoord de bedoelde keuze maken?
• Beperking: welke factoren, zoals personalisatie of modusverschillen, zijn niet beheerst?

Controleer het antwoord los van de merkvermelding

De antwoordcontrole bestaat uit vier vragen. Past het antwoord bij de context? Zijn de voorwaarden en uitzonderingen genoemd? Ondersteunt de gelinkte bron de concrete bewering? Welke informatie ontbreekt nog om een besluit te nemen?

Een merkvermelding kan samengaan met een onbruikbaar antwoord. Andersom kan een antwoord zonder jouw merk wel laten zien dat een klantvraag voldoende wordt behandeld. Houd merk, bronlink en nuttigheid daarom apart. Voeg ze niet zonder onderbouwing samen tot één vermeende zichtbaarheidsscore.

Als je website de ontbrekende voorwaarde nergens uitlegt, kan dat aanleiding zijn om de pagina te verbeteren. Controleer daarna eerst of de nieuwe uitleg feitelijk klopt en begrijpelijk is. Een eventuele herhaling van de vraagset blijft een steekproef. Ze bewijst geen stabiele plaats in alle toekomstige antwoorden.

Bespreek aanbiedersbewijs voordat je een keuze maakt

Vraag bij een portfolio of case naar de beginsituatie en de eigen rol van de aanbieder. Wie onderzocht, schreef, bouwde en testte? Welke onderdelen deed de klant of een ander bureau? Daarmee voorkom je dat je een gezamenlijke uitkomst volledig toeschrijft aan één persoon.

Goed aanbiedersbewijs maakt minstens één concrete oplevering bespreekbaar. Denk aan een geanonimiseerd ticket met acceptatiecriteria, een onderbouwd inhoudsbesluit of een meetoverzicht met duidelijke grenzen. Vraag of de aanbieder toestemming heeft om het materiaal te delen. Vertrouwelijke klantgegevens zijn geen noodzakelijk onderdeel van een overtuigende toelichting.

Gebruik bij openbare claims een verifieerbare publieke bron. Controleer of de genoemde pagina, publicatie of bijdrage bestaat en daadwerkelijk ondersteunt wat wordt beweerd. Een interview kan laten zien hoe iemand redeneert. Het bewijst niet dat die persoon bij jouw website een vergelijkbaar resultaat zal behalen.

• Welke beginsituatie maakte deze opdracht nodig?
• Wat heeft de aanbieder aantoonbaar zelf opgeleverd?
• Welke andere veranderingen vonden in dezelfde periode plaats?
• Waar eindigt de meting en begint de interpretatie?
• Welk onderdeel is vergelijkbaar met jouw platform, team en probleem?

Let ook op de reactie op onzekerheid. Een aanbieder die ontbrekende informatie benoemt en een passende controlevraag stelt, geeft je iets toetsbaars. Een belofte zonder toegang tot je website of meetgegevens maakt de uitvoering juist moeilijk te beoordelen.

Gebruik het werkblad om een uitvoerbare opdracht te kiezen

Zet bovenaan je werkblad één echte klantvraag en maximaal enkele pagina’s die die vraag moeten beantwoorden. Schrijf daaronder wat je nu waarneemt, welke bron dat ondersteunt en welke informatie ontbreekt. Vul vervolgens de vier verantwoordelijkheden in en kies de passende opleveringscontracten.

Beoordeel de opdracht daarna met deze beslismatrix. De uitkomst is een voorstel voor de volgende stap, geen automatische prioriteitsscore. Bij meerdere knelpunten kijk je eerst welke afhankelijkheid het andere werk blokkeert.

Bewaar onopgeloste punten onderaan met een eigenaar en een vervolgbesluit. ‘Wacht op klant’ is te vaag. ‘Productverantwoordelijke bevestigt voor welke toepassingen dit materiaal geschikt is’ maakt duidelijk wat nodig is. Zo ondersteunt het werkblad keuzes over onderzoek, uitvoering, uitstel of het verkleinen van de opdracht.

Veelgestelde vragen bij het kiezen van een SEO-specialist

Welke taken mag ik van een SEO-specialist verwachten?

Verwacht onderzoek naar zoekvragen, pagina’s en technische obstakels, gevolgd door onderbouwde keuzes en controleerbare opleveringen. Schrijven, bouwen en testen horen alleen bij de opdracht als dat is afgesproken. Leg per taak vast wie uitvoert en wie accepteert.

Hoe weet ik of ik advies of uitvoering nodig heb?

Heb je een intern team dat wijzigingen kan uitvoeren, dan kan gericht onderzoek met uitvoerbare instructies voldoende zijn. Ontbreken tijd of vaardigheden, neem de uitvoering expliciet op in de opdracht. Controleer ook wie toegang regelt en wie het werk achteraf test.

Moet een specialist bepaalde SEO-tools gebruiken?

De onderzoeksvraag bepaalt welke hulpmiddelen nodig zijn. Search Console, een crawler of meetgegevens kunnen passend zijn, maar geen vaste gereedschapslijst bewijst kwaliteit. Vraag welke gegevens het hulpmiddel levert, welke beperkingen gelden en wie eventuele kosten bevestigt.

Hoe toets ik technische kennis zonder zelf ontwikkelaar te zijn?

Vraag om een voorbeeld met diagnose, voorgestelde wijziging en acceptatietests. Laat uitleggen hoe de uitvoerder controleert dat het probleem is opgelost en andere pagina’s blijven werken. Een concreet ticket met begrijpelijk bewijs geeft meer houvast dan alleen een lijst technische termen.

Heeft mijn website naast SEO ook AI-onderzoek nodig?

Alleen als er een concrete vraag of beslissing ligt waarvoor dat onderzoek nuttig is. Gewone vindbaarheid en duidelijke informatie blijven relevant. Een beperkte observatie in een AI-product kan aanvullend helpen, maar is geen verplichte taak voor iedere website en geeft geen garantie op vermeldingen.

Wat moet er in de kostenscope staan?

De kostenscope beschrijft welke pagina’s, onderzoeken, schrijfwerkzaamheden, technische wijzigingen en controles zijn inbegrepen. Benoem ook licenties, interne inzet, onderhoud en open afhankelijkheden. Laat aanvullende werkzaamheden eerst specificeren, zodat je opdrachten inhoudelijk kunt vergelijken zonder alleen naar een totaalbedrag te kijken.

Wanneer kan ik beoordelen of de samenwerking goed loopt?

Plan een beoordelingsmoment zodra de eerste afgesproken oplevering klaar is. Dan kun je brongebruik, uitvoerbaarheid en acceptatiebewijs al toetsen. Zoekeffect vraagt een aparte beoordeling met voldoende vergelijkbare gegevens; daarvoor bestaat geen vaste termijn die voor iedere website geldt.

Stuur Niblah je websitevraag en beschikbare capaciteit

Niblah biedt webdesign, WordPress, Shopify en SEO. Maak je aanvraag concreet door niet alleen ‘meer vindbaarheid’ te noemen, maar ook welke klantvraag jouw website beter moet beantwoorden. Daarmee kun je bespreken wie onderzoekt, schrijft, bouwt en test.

Neem in je bericht je domein op, de relevante paginatypen en enkele voorbeeld-URL’s. Beschrijf belangrijke veranderingen, zoals een nieuw thema, aangepast assortiment of eerdere verhuizing van pagina’s. Vermeld vervolgens de beschikbare capaciteit van je team en welke bronnen ontbreken, bijvoorbeeld zoekgegevens, technische documentatie of bevestigde productinformatie. Deel geen wachtwoorden in het formulier.

Gebruik het contactformulier van Niblah en voeg je ingevulde vierverantwoordelijkhedenblad toe aan je bericht, of vat de open rollen daarin samen. Vraag om de eerste noodzakelijke oplevering af te bakenen, inclusief uitvoerder, afhankelijkheden en het bewijs waarmee je die oplevering kunt beoordelen.