Contact

SEO en developers laten samenwerken: zo komt je fix wél live

door | okt 21, 2026 | SEO | 0 Reacties

SEO-specialist en ontwikkelaar bespreken URL-keuzes

Samenwerken met developers lukt pas als SEO meepraat vóór er gebouwd wordt, in de taal van het dev-team: korte tickets met een duidelijke reden, een score voor impact en moeite, en een vast gezicht binnen het team dat SEO bewaakt. Een lijst van 80 issues mailen werkt niet. Die belandt in de backlog en komt er niet meer uit. In dit artikel lees je hoe je de samenwerking opzet, hoe een goed SEO-ticket eruitziet, hoe je prioriteert en wanneer je beter iets anders kunt doen.

Nebber
Maak SEO-fixes werkbaar voor developers
Nebber combineert technische SEO-optimalisatie met samenwerking met webprofessionals om de organische zichtbaarheid van je website te verbeteren.

Bekijk Nebber

TL;DR

  • Sluit aan bij de backlog refinement, niet pas bij de sprint planning. Dan liggen de keuzes al vast.
  • Schrijf tickets met één probleem, één reden, één acceptatiecriterium. Geen dump van 50 losse issues.
  • Geef elk ticket een score van 1 tot 5 voor impact en voor moeite. Hoge impact en lage moeite gaat altijd eerst.
  • Controleer de ruwe HTML, niet wat je eigen browser laat zien. Daar kijkt Google naar.
  • Kweek één SEO-champion in het dev-team. Dan hoef je niet elk ticket zelf na te lopen.

Inhoudsopgave

Waarom SEO-tickets in de backlog blijven liggen

Het probleem is bijna nooit onwil. Een developer heeft een volle sprint, een product owner die features wil zien en een lijst bugs die klanten merken. Dan komt er een SEO-rapport binnen met 120 pagina’s aan bevindingen uit een crawler. Zonder context. Zonder volgorde. Dat is als een kraan die lekt in een huis waar al het water tot de enkels staat: niemand weet welke kraan eerst dicht moet, dus pakt niemand er een.

Marketingfacts beschrijft dit patroon helder: losse technische issues zonder context worden genegeerd, en tickets zonder prioriteit blijven eindeloos in de backlog staan. De oplossing is geen langere lijst. Het is een kortere.

Er spelen drie oorzaken:

  1. Verschillende doelen. Developers worden afgerekend op stabiliteit, snelheid van opleveren en zo min mogelijk bugs. SEO wordt afgerekend op verkeer en omzet uit Google. Als je niet uitlegt hoe jouw ticket bijdraagt aan iets waar het dev-team om geeft, verliest het van elk ander ticket.
  2. Verschillende taal. “De canonical klopt niet” zegt een developer weinig als je niet zegt welke URL, welke tag, wat er nu staat en wat er moet staan.
  3. Verkeerd moment. SEO komt vaak pas in beeld na de lancering. Dan moet er iets gesloopt worden dat net af is. Dat kost twee keer.

Search Engine Journal noemt de silo’s tussen marketing en development als kern van het probleem. Hun advies: organiseer sessies waarin beide kanten elkaars werk leren kennen, bijvoorbeeld een gezamenlijke hackathon. Zo zie je waar het in elkaars proces knelt. SEO is dan geen klus die je over de schutting gooit, maar werk dat je samen doet.

Zit aan tafel voordat de eerste regel code er staat

Het belangrijkste moment in een sprint is niet de planning. Het is de refinement. Daar wordt besproken hoe iets gebouwd gaat worden, welke URL-structuur een nieuwe sectie krijgt, of een pagina server-side of in de browser wordt opgebouwd en welke filters indexeerbaar worden.

Sitebulb raadt aan om juist bij die backlog refinement aanwezig te zijn. Wie pas bij de sprint planning aanschuift, staat te dweilen terwijl het bad al overloopt: de architectuur is gekozen, de schattingen zijn gemaakt, en jouw opmerking betekent extra werk.

Wat je in de refinement doet:

  • Vraag per user story: verandert dit iets aan URL’s, templates, interne links of rendering? Zo nee, dan ben je klaar. Zo ja, dan schrijf je de SEO-eisen er direct bij.
  • Leg eisen vast als acceptatiecriteria. “De pagina geeft een 200-statuscode, heeft een self-referencing canonical en de producttitel staat in de eerste HTML-response.” Dat is toetsbaar. “Moet SEO-vriendelijk zijn” niet.
  • Spreek af wie het test. Een criterium dat niemand controleert, bestaat niet.

Dit kost je een uur per sprint. Het scheelt je weken herstelwerk na een migratie of relaunch. Een gemiste redirectregel bij een migratie kan maanden verkeer kosten. Een uur vergaderen kost een uur.

Zo schrijf je een SEO-ticket dat een developer oppakt

Een goed ticket is een opdracht die een developer kan uitvoeren zonder jou te bellen. Gebruik voor elk ticket dezelfde opbouw:

  1. Titel in één zin. Wat er mis is en waar. “Productpagina’s sturen canonical naar categorie in plaats van naar zichzelf.”
  2. Waarom. In één of twee zinnen, in gewone taal. “Google indexeert daardoor de categorie en niet het product. Die 1.400 productpagina’s verschijnen nu niet in de zoekresultaten.”
  3. Huidige situatie. Een voorbeeld-URL, de huidige code en een screenshot of de output van een crawl.
  4. Gewenste situatie. Exact wat er moet staan, liefst als codevoorbeeld.
  5. Scope. Welk template of welke pagina’s. Eén template fixen is iets anders dan 30 losse pagina’s aanpassen.
  6. Acceptatiecriteria. Hoe je samen vaststelt dat het klaar is.
  7. Impact en moeite. Een score van 1 tot 5 voor beide, met een korte onderbouwing.

Een voorbeeld, zoals het in Jira of een vergelijkbaar systeem kan staan:

Titel: Filterpagina’s met meer dan één filter zijn indexeerbaar
Waarom: De crawl vindt 23.000 filtercombinaties tegenover 1.100 echte categorie- en productpagina’s. Google besteedt zijn tijd aan pagina’s die niemand zoekt.
Gewenst: Combinaties van twee of meer filters krijgen noindex, follow. Enkele filters blijven indexeerbaar.
Acceptatie: /schoenen?kleur=rood is indexeerbaar, /schoenen?kleur=rood&maat=42 geeft noindex.
Impact: 4. Moeite: 2.

Eén probleem per ticket. Hoort bij één probleem een wijziging in twee templates, dan zijn dat twee subtaken onder één ticket. Zo kan een developer het oppakken, afronden en sluiten. Dat geeft voortgang die het team ziet. Wil je de technische kant per onderwerp uitgewerkt zien, lees dan onze technische SEO-checklist voor developers.

Prioriteren met impact en moeite

Niet elk issue is een ticket waard. Een crawler meldt ook ontbrekende alt-teksten op een privacypagina. Dat is geen prioriteit. De score voor impact en moeite helpt je om die keuze hard te maken, zodat het geen gevoelskwestie wordt.

Marketingfacts werkt met een schaal van 1 tot 5 voor beide: impact gaat over omzet, rankings en gebruikerservaring, moeite over ontwikkeltijd en technische complexiteit. Zet je tickets daarna in vier vakken:

Impact Moeite Wat je doet Voorbeeld
Hoog (4-5) Laag (1-2) Direct inplannen, deze sprint Noindex staat per ongeluk op een template
Hoog (4-5) Hoog (4-5) Opknippen en op de roadmap zetten Overstap van client-side naar server-side rendering
Laag (1-2) Laag (1-2) Meenemen als er ruimte is Meta-descriptions op weinig bezochte pagina’s
Laag (1-2) Hoog (4-5) Niet doen Volledige herbouw van een sectie met weinig verkeer

Het laatste vak is het lastigste. Je moet durven zeggen dat iets niet gebeurt. Dat geeft vertrouwen. Een developer die merkt dat jij zelf schrapt, neemt jouw prioriteit 5 serieuzer.

Werk in batches. Lever per sprint drie tot vijf tickets aan, niet vijftig. Dan blokkeer je de sprint niet en zie je na twee weken resultaat. Hoe je zo’n reeks tickets omzet in een plan voor een heel jaar, lees je in ons stappenplan voor een SEO-roadmap opstellen.

Kijk naar wat Google ziet, niet naar je browser

Veel discussies tussen SEO en development gaan mis op één punt: je kijkt niet naar hetzelfde. Een developer opent de site in Chrome en ziet een volle pagina. Google ziet soms iets anders.

Google legt in zijn documentatie uit dat JavaScript-pagina’s in drie fases worden verwerkt: crawlen, renderen en indexeren. Het renderen gebeurt niet altijd meteen. Content die pas in de browser wordt opgebouwd, is daardoor niet direct zichtbaar voor de zoekmachine.

Illustratie van het crawlen, renderen en indexeren

Een praktische gids op DEV Community zet het scherp neer: wie alleen naar het DOM in de eigen browser kijkt, ziet een vertekend beeld. Controleer de ruwe HTML met curl of via “bron weergeven”. Staan je titel, je hoofdtekst, je interne links en je gestructureerde data daar niet in, dan is het huis van buiten af dichtgetimmerd, ook al is het binnen netjes ingericht.

Een korte check die je samen met een developer in vijf minuten doet:

  1. curl -A "Googlebot" https://jouwsite.nl/pagina en zoek naar de H1 en de eerste alinea.
  2. Vergelijk met de URL-inspectie in Google Search Console (de gerenderde HTML).
  3. Zoek de interne links op: staan ze als gewone <a href> in de HTML, of pas na een klik?

Dat werkt beter dan een discussie. Je laat het zien.

Hetzelfde geldt voor snelheid. Gebruik de grenzen die Google zelf hanteert. Volgens web.dev is een score “goed” bij deze waarden, gemeten op het 75e percentiel van echte bezoekers:

Meting Wat het meet Goed
Largest Contentful Paint (LCP) Hoe snel de grootste inhoud zichtbaar is Tot 2,5 seconde
Interaction to Next Paint (INP) Hoe snel de pagina reageert op een klik of tik Tot 200 milliseconden
Cumulative Layout Shift (CLS) Hoeveel de pagina verspringt tijdens het laden Tot 0,1

Een getal in een ticket (“LCP op mobiele productpagina’s is 4,1 seconde, doel is 2,5”) werkt beter dan “de site is traag”. Maar snelheid is niet alles. Een snelle pagina die niet geïndexeerd wordt, levert niets op. Waarom we Core Web Vitals een plek geven maar niet bovenaan elke lijst zetten, lees je in ons artikel over Core Web Vitals en SEO.

Kweek een SEO-champion in het dev-team

Je kunt niet bij elke stand-up, elke refinement en elke code review zitten. Dat hoeft ook niet. Sitebulb adviseert om binnen het dev-team een SEO-champion te vinden: vaak een front-end developer die al om performance geeft. Geef die persoon de data en de kennis. Dan bewaakt hij of zij de indexeerbaarheid in het dagelijkse werk.

Hoe je dat aanpakt:

  • Kies iemand die het al leuk vindt. Aanwijzen werkt slecht. Zoek wie in de code review al opmerkingen maakt over laadtijd of semantische HTML.
  • Geef toegang tot de data. Search Console, de crawl-rapporten, een dashboard. Iemand die ziet dat een release 300 pagina’s uit de index heeft gegooid, wordt vanzelf voorzichtiger.
  • Maak het zichtbaar. Laat de champion in de sprint review vertellen wat een SEO-fix heeft opgeleverd. Met een getal.
  • Leg regels vast. Een korte lijst met dingen die nooit zonder overleg veranderen: robots.txt, canonicals, redirects, URL-structuur.

Dat laatste is in feite SEO-governance: afspraken over wie wat mag wijzigen. Wil je weten hoe je dat inricht, lees dan wat SEO-governance is en waarom je het nodig hebt. En voor de data: met een SEO-dashboard van drie tabbladen heeft het hele team hetzelfde beeld.

Wie stuurt de implementatie?

Deze vraag komt in elk project terug. Search Engine Journal bespreekt de rolverdeling tussen SEO, developers en IT en komt uit op samenwerking richting een gedeeld doel, niet op één winnaar. In de praktijk werkt deze verdeling goed:

Rol Verantwoordelijk voor Niet verantwoordelijk voor
SEO-specialist Wat er moet gebeuren en waarom, prioriteit, controle na livegang Hoe het technisch gebouwd wordt
Developer Hoe het gebouwd wordt, schatting van moeite, kwaliteit van de code Welke pagina’s in Google moeten staan
Product owner Plek in de sprint, afweging tegen andere features De technische SEO-eisen zelf
Management Budget en draagvlak, doelen op omzet Losse tickets

De SEO-specialist bepaalt het wat, de developer het hoe. Zeg je als SEO hoe iets technisch moet, dan loop je het risico dat je een slechtere oplossing afdwingt dan de developer zelf zou kiezen. Beschrijf het gewenste resultaat en laat de weg open.

Management heeft een eigen rol. Zonder draagvlak daar verliest SEO elke afweging tegen een nieuwe feature. Dat draagvlak krijg je met een prognose: “deze vijf tickets kosten samen 6 dagen ontwikkeltijd en raken pagina’s die nu 40% van het organische verkeer trekken.” Dat is een gesprek dat een directeur kan voeren. Wie dit projectmatig wil regelen, vindt meer in ons artikel over SEO-projectmanagement.

Wanneer dit niet de beste aanpak is

Een vaste samenwerking met refinements, scores en een champion is niet altijd nodig. Soms is het te zwaar.

  • Kleine site, geen eigen dev-team. Heb je een WordPress-site van 40 pagina’s en een bureau dat af en toe iets aanpast? Dan is een sprintproces overkill. Eén goed geschreven lijst met vijf punten per kwartaal is genoeg.
  • De basis is stuk. Staat de hele site op noindex of is een migratie mislukt? Dan geen batches en geen scores. Eén ticket, prioriteit 5, vandaag. Brand eerst blussen, daarna de verbouwing plannen.
  • Geen tijd bij development, punt. Als het dev-team voor 100% vastzit aan een relaunch, krijg je er niets tussen. Gebruik die tijd om de SEO-eisen voor de nieuwe site vast te leggen. Dat is dan je belangrijkste werk.

Onze kijk op SEO en development

Wij zien het elke keer weer: het SEO-advies is niet het probleem. De uitvoering wel. Een audit van 90 pagina’s die niemand oppakt, levert nul bezoekers op. Daarom werken we direct samen met de developers, copywriters en linkbuilders die het werk moeten doen. We zitten aan tafel, schrijven de tickets in de vorm die het team gewend is en controleren na livegang of het werkt.

Ons uitgangspunt is simpel. Elke aanbeveling moet een developer morgen kunnen oppakken. Kan dat niet, dan is het nog geen aanbeveling maar een idee. En we schrappen hard. Liever drie fixes die live staan dan dertig die in de backlog liggen.

De tweede helft van het werk zit bij management. Een developer wil een helder ticket, een directeur wil weten wat het oplevert. Daarom koppelen we elk blok werk aan een prognose en een rapportage waar een beslissing uit volgt. Dan krijgt SEO ruimte in de sprint, omdat iedereen ziet waarom.

Samenwerken met developers is geen kwestie van vriendelijk vragen. Het is een kwestie van hun werk makkelijker maken.

— Ramon

Hulp bij de samenwerking met je dev-team

Ligt er een stapel SEO-issues en weet je niet welke eerst moet? Met een technische audit krijg je geen lange lijst, maar tickets met een score voor impact en moeite die je team direct kan oppakken. Wil je dat iemand de samenwerking met development tijdelijk trekt, refinements bijwoont en de voortgang bewaakt? Dan is interim SEO-management een optie. Neem contact op, dan kijken we samen wat past.

Veelgestelde vragen

Moet een SEO-specialist zelf kunnen programmeren?

Nee, maar je moet code kunnen lezen. Je moet de ruwe HTML kunnen controleren, een statuscode kunnen opzoeken en begrijpen wat server-side en client-side rendering betekent. Zonder die basis kun je geen ticket schrijven dat een developer serieus neemt.

Hoeveel SEO-tickets lever je per sprint aan?

Houd het bij drie tot vijf per sprint van twee weken. Zo blokkeer je het dev-team niet en zie je snel resultaat. Meer tickets betekent meestal dat ze langer blijven liggen.

Hoe overtuig je een dev-team dat SEO prioriteit heeft?

Met getallen en een duidelijke reden per ticket. Laat zien hoeveel pagina’s of hoeveel verkeer een fix raakt, en hoeveel ontwikkeltijd het kost. Laat daarna na livegang zien wat het heeft opgeleverd.

Wat doe je als een developer het niet eens is met je ticket?

Bespreek het. Vaak kent de developer een betere oplossing voor hetzelfde doel. Houd vast aan het gewenste resultaat en laat de technische invulling bij het team.

Bronnen

Aanbevelingen