SEO-governance betekent dat je vastlegt wie over SEO beslist, wie het werk uitvoert en wie controleert of het goed live staat. Zonder die afspraken kan je SEO-specialist nog zo goed zijn, en blijven zijn aanbevelingen toch in een backlog liggen of sneuvelen ze bij de volgende release. Met governance krijgt elke wijziging een eigenaar, een goedkeurder en een controle achteraf. Dat is minder spannend dan een nieuwe contentcampagne, maar het levert meestal meer op. In dit artikel lees je hoe je dat inricht: rollen, beslisrechten, prioritering, standaarden en een invoerplan van 90 dagen.

Nebber
Laat SEO-advies beter landen
Nebber combineert 19 jaar SEO-ervaring met technische optimalisatie en samenwerking met webprofessionals om de organische zichtbaarheid van je website te verbeteren.

Bekijk SEO-expertise

Kort samengevat

  • SEO-management gaat over het dagelijkse werk. SEO-governance gaat over de regels: wie mag wat beslissen en wie controleert dat.
  • Leg per type wijziging vast wie aanvraagt, wie goedkeurt, wie uitvoert en wie het resultaat controleert. Een RACI-tabel van één pagina is genoeg.
  • Laat elk technisch SEO-verzoek dezelfde route volgen: gespecificeerd, geticket, geprioriteerd, live gezet en geverifieerd.
  • Standaarden werken alleen als ze verplicht zijn en in de workflow zitten vóór er iets live gaat. Een richtlijn in een gedeelde map leest niemand.
  • Heb je één website, één marketeer en één developer? Dan is een zware governancestructuur niet de beste keuze. Een wekelijks overleg van 30 minuten doet dan hetzelfde werk.

Inhoudsopgave

Wat SEO-governance is, en wat het niet is

Search Engine Land omschrijft SEO-governance als het communiceren, monitoren en controleren van SEO-processen en -systemen. Het doel is dat SEO overal op dezelfde manier wordt toegepast en beter aansluit op processen die al bestaan.

Het verschil met SEO-management is simpel. Management is het werk zelf: keywordonderzoek, pagina’s optimaliseren, interne links leggen, technische fouten oplossen. Governance is het huishoudreglement van het huis waarin dat werk gebeurt. Wie mag de meterkast openen? Wie mag een muur weghalen? Wie kijkt na of het nog veilig is?

Een voorbeeld. Je SEO-specialist ontdekt dat 1.200 productpagina’s een verkeerde canonical hebben. Management is: de fout vinden en de oplossing beschrijven. Governance is: weten bij wie dat ticket landt, wie beslist dat het vóór de nieuwe filterfunctie gaat, en wie twee weken later controleert of Google de juiste versie indexeert. Ontbreekt dat tweede deel, dan blijft het eerste deel een rapport.

Governance is dus geen extra laag bureaucratie. Het is het verschil tussen advies en resultaat.

Wil je eerst de basis scherp hebben, lees dan ook ons stuk over wat SEO-governance is en waarom je het nodig hebt.

Waarom SEO zonder afspraken lekt

SEO raakt bijna elk team. Marketing schrijft de teksten, developers bouwen de templates, IT beheert de servers, de productowner bepaalt de roadmap en de directie het budget. Search Engine Land wijst erop dat bij grotere organisaties silo-teams en tegenstrijdige prioriteiten het lastig maken om SEO in het hele bedrijf op één lijn te krijgen.

In de praktijk zie je drie patronen:

  1. De stille sloop. Een developer past een template aan voor een nieuwe huisstijl. De H1 wordt een afbeelding, de breadcrumbs verdwijnen. Niemand heeft SEO gevraagd, want niemand wist dat het moest. Drie weken later daalt het verkeer op 400 categoriepagina’s.
  2. De eeuwige backlog. SEO levert 35 aanbevelingen op. Er is geen afspraak over wie ze weegt tegen andere tickets. Na een half jaar staan er 31 nog open.
  3. Twee kapiteins. Marketing wil een nieuwe blogsectie op een subdomein, de SEO-specialist wil een submap. Er is niemand die de knoop doorhakt. Dus wint wie het hardst roept.

In alle drie de gevallen ben je aan het dweilen met de kraan open. Je herstelt elke maand wat er de maand ervoor kapot is gegaan. Die rekening loopt op: elke fout die na livegang wordt ontdekt kost een tweede sprint, terwijl een check vóór livegang vaak een kwartier kost.

De oplossing is niet harder dweilen. Kraan dicht. Altijd.

Wie is eigenaar van SEO?

Begin met één naam. Niet een team, niet een afdeling, één persoon die eindverantwoordelijk is voor de SEO-strategie en de prioriteiten. Zonder die persoon heeft elk team een mening en niemand een besluit.

Waar die persoon in de organisatie hangt, maakt uit. Search Engine Journal adviseert SEO onder e-commerce of marketing te plaatsen en niet onder IT, met een technische SEO-rol die formeel samenwerkt met IT. De reden is logisch: SEO gaat uiteindelijk over omzet en vindbaarheid, niet over serverbeheer. Maar zonder een vaste lijn naar IT komt er niets live.

Een werkbare rolverdeling ziet er zo uit:

Rol Verantwoordelijk voor Beslist over
SEO-lead Strategie, prioriteiten, standaarden, rapportage Volgorde van SEO-werk, wat wel en niet SEO-proof is
Marketing / content Teksten, contentkalender, interne links in content Onderwerpen en tone of voice, binnen de SEO-standaarden
Development / webteam Templates, techniek, performance, releases Technische uitvoering en planning in sprints
IT / hosting Servers, redirects op serverniveau, beveiliging Infrastructuur en toegang
Productowner Roadmap van de website Weging van SEO-tickets tegen andere tickets
Directie Budget en doelen Escalaties en keuzes met grote impact, zoals een migratie

De lastigste relatie is bijna altijd die tussen SEO en development. Daar gaat het mis als een SEO-verzoek als losse mail binnenkomt in plaats van als duidelijk ticket. Hoe je dat oplost, lees je in SEO en developers laten samenwerken. Voor de contentkant werkt hetzelfde principe: een copywriter die vooraf weet wat de zoekintentie is, levert de eerste keer goed op. Zie SEO en copywriters laten samenwerken.

Beslisrechten: één RACI per type wijziging

Een RACI-tabel legt per taak vier rollen vast:

  • Responsible: wie het werk uitvoert.
  • Accountable: wie eindverantwoordelijk is en tekent. Altijd één persoon.
  • Consulted: wie vooraf om advies wordt gevraagd.
  • Informed: wie achteraf op de hoogte wordt gebracht.

Maak die tabel niet per project, maar per type wijziging. Dan hoef je niet bij elk ticket opnieuw te vergaderen over wie wat doet.

Type wijziging Responsible Accountable Consulted Informed
Nieuwe pagina of artikel Copywriter Contentmanager SEO-lead Webteam
URL-wijziging of redirect Developer SEO-lead IT Marketing
Template-aanpassing Developer Productowner SEO-lead Marketing
Robots.txt, noindex, canonicals Developer SEO-lead Productowner IT
Migratie of nieuw CMS Projectteam Directie SEO-lead, IT Hele organisatie
Nieuwe taal of land Marketing Directie SEO-lead, development Lokale teams

Let op twee dingen. Bij alles wat de indexering raakt, zoals robots.txt, noindex en canonicals, is de SEO-lead accountable. Eén verkeerde regel in robots.txt kan in een dag een hele site uit beeld halen. Dat leg je niet bij iemand die SEO alleen van horen zeggen kent.

En bij template-aanpassingen is SEO consulted, niet informed. Het verschil is één woord, maar het betekent dat SEO vóór de bouw meekijkt en niet pas als het verkeer al weg is.

Spreek ook een beslistermijn af. Bijvoorbeeld: een SEO-advies op een ticket komt binnen 3 werkdagen, anders gaat het ticket door zonder SEO-check. Dan wordt SEO nooit de flessenhals.

Prioriteren op impact, inspanning en risico

De meeste bedrijven hebben geen tekort aan SEO-ideeën. Ze hebben een tekort aan developmenttijd. Daarom moet elke aanbeveling een score krijgen voordat hij de backlog in gaat.

Gebruik vier criteria:

  1. Impact: hoeveel pagina’s of hoeveel omzet raakt het? Een fix op 1 template die 2.000 productpagina’s verbetert, wint van 20 losse blogaanpassingen.
  2. Inspanning: hoeveel uur development, content of IT kost het?
  3. Goedkeuringskosten: hoeveel mensen moeten tekenen? Een wijziging die juridische goedkeuring nodig heeft, duurt altijd langer.
  4. Risico: wat gaat er mis als het fout gaat, en kun je het terugdraaien?

Een eenvoudig rekenvoorbeeld. Geef impact en inspanning een score van 1 tot 5. Deel impact door inspanning. Een fix met impact 5 en inspanning 1 scoort 5. Een fix met impact 3 en inspanning 3 scoort 1. De eerste gaat deze sprint mee, de tweede volgend kwartaal. Risico gebruik je als rem: bij een hoog risico komt er altijd een testomgeving en een terugdraaiplan bij.

Dit klinkt als papierwerk. Het is het omgekeerde. Met een score hoef je niet elke week opnieuw te onderhandelen met de productowner, want de cijfers liggen op tafel. Wil je dit vertalen naar een planning per kwartaal, dan helpt ons stappenplan voor een SEO-roadmap opstellen.

Van verzoek tot verificatie: een vaste route

Een SEO-verzoek dat als losse mail binnenkomt, is een fles in de zee. Misschien spoelt hij aan. Geef elk technisch verzoek daarom dezelfde route:

  1. Gespecificeerd. De SEO-lead beschrijft het probleem en de oplossing, met bewijs: welke URL’s, welke data, welk effect verwacht je.
  2. Geticket. Het verzoek komt in hetzelfde ticketsysteem als alle andere werk. Geen apart SEO-lijstje in een spreadsheet.
  3. Geprioriteerd. Het ticket krijgt een score en een plek in de sprint.
  4. Live gezet. De developer bouwt en zet het live, eerst op een testomgeving als het risico hoog is.
  5. Geverifieerd. De SEO-lead controleert of het werkt zoals bedoeld. Pas dan is het ticket af.

Stap 5 wordt het vaakst overgeslagen. Juist daar gaat het mis. Een redirect die naar de verkeerde pagina wijst, is formeel “opgeleverd”. Het verkeer is toch weg.

Zet in elk ticket minimaal: het bewijs, de scope, de acceptatiecriteria, hoe je het controleert, het risico, hoe je het terugdraait, de eigenaar en de goedkeurder. Acht velden. Met minder velden krijg je vragen terug, en elke vraag kost een dag.

Hoe je dit als project laat draaien, met vaste overlegmomenten en rapportage, lees je in SEO-projectmanagement: de aanpak die wél wordt uitgevoerd.

Standaarden die je vastlegt

Governance zonder standaarden is een scheidsrechter zonder spelregels. Search Engine Journal stelt dat een SEO Center of Excellence pas werkt als naleving van standaarden verplicht is en die standaarden in de workflow zitten voordat iets live gaat. Een PDF met richtlijnen die niemand opent, telt niet.

Leg minimaal drie soorten standaarden vast.

Technische standaarden. Hoe ziet een URL eruit? Wanneer gebruik je een canonical? Welke statuscode krijgt een verwijderd product? Hoe snel moet een template laden? Maak er een checklist van die de developer bij elke release afvinkt. Een startpunt vind je in onze technische checklist voor developers.

Contentstandaarden. Google zegt in de SEO Starter Guide dat aantrekkelijke en nuttige content waarschijnlijk meer invloed heeft op je zichtbaarheid dan de andere aanbevelingen in de gids. In de richtlijnen over content die primair voor mensen is gemaakt noemt Google een bestaande doelgroep, aantoonbare eerstehands expertise, een duidelijk doel en een bevredigend antwoord. Content die vooral wordt gemaakt om te ranken, ziet Google als waarschuwingssignaal. Vertaal dat naar een briefing die elke schrijver gebruikt: voor wie is dit, welke vraag beantwoorden we, welke expert levert de kennis.

Dat geldt ook als je AI inzet. Wie werkt met AI-blogging en contentplanning heeft dezelfde standaard nodig, en eigenlijk nog strenger: meer output betekent meer kans dat een tekst zonder echte expertise live gaat. Hetzelfde geldt voor andere formats, zoals een videocontentstrategie voor marketeers: één doel per video, één platform, en een duidelijke eigenaar.

Release-standaarden. Welke wijzigingen mogen nooit live zonder SEO-check? Maak die lijst kort, bijvoorbeeld vijf punten: URL’s, redirects, robots.txt en meta robots, canonicals, hreflang. Kort betekent dat mensen hem onthouden.

Drie categorieën SEO-standaarden voor teams

Meten: laat zien dat de afspraken werken

Governance moet zichzelf bewijzen, anders sneuvelt het bij de eerste bezuiniging. Meet daarom niet alleen rankings en verkeer, maar ook het proces zelf.

Meetpunt Wat het laat zien Voorbeeld van een doel
Doorlooptijd SEO-ticket Hoe snel advies live staat Van 90 naar 30 dagen
Percentage geverifieerde tickets Of stap 5 echt gebeurt 100%
SEO-fouten na release Of de checks vóór livegang werken Elk kwartaal minder
Openstaande SEO-tickets ouder dan 6 maanden Of de prioritering eerlijk is Maximaal 5
Organisch verkeer en omzet per paginatype Het resultaat voor de business Per kwartaal gerapporteerd

Rapporteer dit aan de directie in hun taal: omzet, leads en risico. Een rapport met 40 grafieken over posities leest niemand. Een rapport met 3 cijfers en een forecast wel. Welke acties het meeste verkeer opleveren zodra de afspraken staan, lees je in organisch verkeer verhogen.

Invoeren in 90 dagen

Je hoeft niet alles tegelijk te regelen. Dit is een realistisch tempo voor een middelgroot bedrijf.

Dag 1 tot 30: inventariseren.

  • Wijs de SEO-lead aan en zet de naam op papier.
  • Breng in kaart wie nu aan de website werkt: teams, bureaus, freelancers.
  • Laat een technische audit doen, zodat je weet welke problemen er nu al liggen.
  • Verzamel alle open SEO-aanbevelingen in één lijst.

Dag 31 tot 60: afspreken.

  • Maak de RACI-tabel per type wijziging en laat de directie tekenen.
  • Leg de ticketroute en de acht verplichte velden vast.
  • Schrijf de vijf release-checks en de contentbriefing.
  • Scoor de open aanbevelingen op impact, inspanning en risico.

Dag 61 tot 90: draaien.

  • Laat de eerste sprint met SEO-tickets volgens de nieuwe route lopen.
  • Meet de doorlooptijd en het aantal geverifieerde tickets.
  • Bespreek na 90 dagen wat werkt en wat niet, en pas aan.

Werk je in meerdere landen of talen, voeg dan lokale teams pas toe als de route in het eerste land werkt. Start klein, zoals we ook beschrijven in onze internationale SEO-strategie.

Veelgemaakte fouten

  • Een commissie in plaats van een eigenaar. Vijf mensen die samen verantwoordelijk zijn, betekent dat niemand verantwoordelijk is.
  • SEO onder IT hangen zonder businessdoel. Dan wordt SEO een lijst technische tickets zonder relatie met omzet.
  • Standaarden schrijven en niet afdwingen. Een regel zonder controle is een suggestie.
  • Geen verificatie. “Opgeleverd” is niet hetzelfde als “werkt”.
  • Alles tegelijk willen. Wie in maand 1 een framework van 40 pagina’s uitrolt, heeft in maand 3 een framework dat niemand gebruikt.
  • Governance zonder budget. Als er geen developmenttijd voor SEO is gereserveerd, is elke afspraak een lege belofte. Reserveer een vast deel van elke sprint, bijvoorbeeld 10 tot 20 procent.

Wanneer zware governance niet de beste keuze is

Niet elk bedrijf heeft een RACI-tabel nodig. Heb je één website, één marketeer en een externe developer die je elke week spreekt? Dan is een formele structuur overkill. Je verliest meer tijd aan het bijhouden van de tabel dan aan het oplossen van problemen.

In dat geval volstaan drie afspraken: één persoon beslist over SEO, de developer meldt vooraf elke wijziging aan URL’s of templates, en er is een wekelijks overleg van 30 minuten. Klaar.

Governance gaat lonen zodra er meer dan twee teams of bureaus aan de site werken, je in meerdere landen actief bent, of je een migratie plant. Dan is het geen luxe meer. Dan is het brandverzekering.

Onze kijk op SEO-governance

We zien in de praktijk vaak hetzelfde beeld. Een bedrijf heeft een goede SEO-strategie, een audit van 60 pagina’s en een team dat wil. Toch gebeurt er weinig. Het probleem zit dan zelden in de kennis. Het zit in de route van advies naar livegang.

Daarom kijken we bij governance eerst naar de samenwerking met de mensen die het werk doen: copywriters, webdevelopers en linkbuilders. Een advies dat de developer niet kan bouwen, is geen advies. We schrijven tickets die een developer direct kan oppakken en we controleren daarna zelf of het werkt.

De tweede pijler is draagvlak bij het management. Een directie tekent niet voor “betere SEO”. Ze tekent voor een forecast: als we deze 5 fixes dit kwartaal doen, verwachten we zoveel extra verkeer op deze paginatypes. Actiegerichte rapportages maken van SEO een investering in plaats van een kostenpost.

En we zijn eerlijk als governance niet de oplossing is. Soms heb je geen framework nodig, maar gewoon iemand die drie maanden de regie pakt.

— Ramon

Hulp bij het inrichten van SEO-governance

Wil je dat je SEO-advies niet meer blijft liggen, maar echt live komt? Nebber helpt bedrijven met een technische audit als startpunt, een SEO-strategie met heldere prioriteiten en, als er intern niemand de regie heeft, interim SEO-management. Daarbij werken we direct samen met je developers, copywriters en linkbuilders, zodat verbeteringen snel worden doorgevoerd.

Nebber

Bekijk wat een technische audit inhoudt, of lees welke taken een interim SEO-manager van je kan overnemen. Liever direct overleggen? Neem contact op via Nebber.

Veelgestelde vragen

Wat is het verschil tussen SEO-governance en SEO-management?

SEO-management is het dagelijkse werk, zoals keywordonderzoek, content optimaliseren en technische fouten oplossen. SEO-governance legt vast wie daarover beslist, wie het uitvoert en wie controleert of het werkt. Management zonder governance levert rapporten op die niet worden uitgevoerd.

Wie moet eindverantwoordelijk zijn voor SEO in een bedrijf?

Eén persoon, de SEO-lead, die bij voorkeur onder marketing of e-commerce valt. Die persoon heeft een formele lijn naar development en IT. Bij grote beslissingen, zoals een migratie, ligt de eindverantwoordelijkheid bij de directie, met de SEO-lead als vaste adviseur.

Heeft een mkb-bedrijf SEO-governance nodig?

Een lichte vorm wel, een zware structuur meestal niet. Werk je met één marketeer en één developer, dan volstaan een vaste beslisser, een meldplicht voor wijzigingen aan URL’s en templates, en een kort wekelijks overleg. Zodra meerdere teams of bureaus aan de site werken, loont een RACI-tabel.

Hoe lang duurt het om SEO-governance in te voeren?

Reken op ongeveer 90 dagen voor een werkende basis: een maand inventariseren, een maand afspraken maken en een maand draaien en bijsturen. Daarna pas je de afspraken elk kwartaal aan op basis van doorlooptijd en fouten na releases.

Kan een externe SEO-specialist de governance inrichten?

Ja. Een externe specialist of interim SEO-manager kan de rollen, de ticketroute en de standaarden opzetten en de eerste maanden de regie voeren. Belangrijk is dat er daarna intern een eigenaar is die het overneemt, anders verdwijnt de structuur zodra de opdracht stopt.

Bronnen

Aanbevelingen