Een SEO-backlog beheer je met vier dingen: elk ticket heeft een meetbaar doel, elk ticket krijgt een score, je hebt een vast ritme om te schonen en te kiezen, en na elke release controleer je of het werkte. Mist er één, dan wordt je backlog een zolder vol dozen. Alles staat er, niemand weet wat erin zit, en wat je zoekt vind je nooit terug. In dit artikel lees je hoe je een backlog opzet, hoe je prioriteert zonder eindeloze discussie, en wanneer een backlog juist níét het juiste middel is.

Nebber
Maak SEO-werk gericht op resultaat
Nebber helpt bedrijven met holistische SEO, van technische optimalisatie tot praktische adviezen die organische zichtbaarheid verbeteren.

Bekijk Nebber

Kort samengevat

  • Een backlog is een wachtkamer voor ideeën, geen plan. Alleen wat wint, schuift door naar je roadmap.
  • Elk ticket heeft minimaal zeven velden: probleem, URL’s, bewijs, gewenste uitkomst, eigenaar, inspanning en de controle na livegang.
  • Prioriteer met een score (impact × waarde × zekerheid, gedeeld door inspanning × risico) in plaats van met de luidste stem in het overleg.
  • Plan drie vaste momenten: wekelijks triage, maandelijks herprioriteren, per kwartaal opruimen.
  • Een ticket is pas klaar als een nieuwe crawl of meting bewijst dat het probleem weg is. Niet als de developer het op ‘done’ zet.

Inhoudsopgave

Wat een SEO-backlog is, en wat niet

Een backlog is de lijst met alles wat je ooit zou kunnen doen. Bevindingen uit een audit, contentkansen, verzoeken van sales, een developer die een redirectketen heeft gezien. Alles komt erin.

Een roadmap is iets anders. Daarin staat alleen wat je dit kwartaal of dit jaar echt gaat doen, met een reden erbij. Search Engine Land beschrijft het zo: elke regel op je roadmap hoort te vertellen waarom hij belangrijk is, wat hij moet opleveren en wat er gebeurt als hij een kwartaal later komt.

De fout die we het vaakst zien: bedrijven gebruiken de backlog als roadmap. Dan werkt iedereen van boven naar beneden de lijst af. Het team is druk, de rapportage staat vol ‘afgeronde taken’, en het organisch verkeer blijft gelijk. Dat is een tuinslang aanzetten terwijl de regenton lekt. Er stroomt water, maar de bak wordt niet voller.

Het verschil in één tabel:

Backlog Roadmap
Doel Alles verzamelen Kiezen wat je doet
Inhoud Ideeën, bugs, kansen, verzoeken Alleen de initiatieven die winnen
Omvang Mag groot zijn Klein en haalbaar
Wie kijkt erin Het SEO- en webteam Management en stakeholders
Maatstaf Score op impact en inspanning Meetbaar doel per initiatief

Wil je weten hoe je van die gekozen items een plan maakt dat management tekent? Lees dan hoe je een SEO-roadmap opstelt. Dit artikel gaat over de stap ervoor: de backlog zelf.

Een backlog opzetten: de velden die elk ticket nodig heeft

Begin niet met een tool. Jira, Trello, Asana, Monday of een gedeeld spreadsheet: het maakt weinig uit. Wat wel uitmaakt is wat er in elk ticket staat. Een ticket zonder duidelijke uitkomst is een kraan die je half dichtdraait. Het druppelt minder, maar het lek is er nog.

Dit zijn de velden die nooit mogen ontbreken:

Veld Wat erin staat Voorbeeld
Probleem Wat er mis is, in één zin 340 productpagina’s hebben een canonical naar de categoriepagina
URL’s De pagina’s of het patroon /product/*?kleur=
Bewijs Waar je het zag Crawlexport van 12 oktober, rapport ‘Pagina-indexering’ in Search Console
Gewenste uitkomst Wat er na de fix waar moet zijn Elke productpagina verwijst naar zichzelf en wordt geïndexeerd
Eigenaar Eén naam, geen team De front-end developer
Inspanning In dagen of punten 2 dagen
Controle na livegang Hoe je bewijst dat het klaar is Nieuwe crawl binnen 7 dagen, indexering na 4 weken

De voorbeelden in de tabel zijn verzonnen om het format te laten zien. Het format zelf is wat telt.

Drie velden worden het vaakst vergeten.

De eigenaar. ‘Marketing’ is geen eigenaar. ‘Development’ ook niet. Als drie mensen verantwoordelijk zijn, is niemand het. Eén naam per ticket.

Het bewijs. Zonder bewijs wordt elk overleg een mening tegen een mening. Met een screenshot uit Search Console of een crawlexport is de discussie in twee minuten klaar.

De controle na livegang. Dit is het belangrijkste veld. Hier spreek je vooraf af wanneer iets klaar is. Niet ‘de code staat live’, maar ‘de crawl laat nul fouten zien op dit patroon’. Zonder deze afspraak sta je te dweilen met de kraan open: je lost hetzelfde probleem elk half jaar opnieuw op.

Werk je met developers die tickets oppakken? Schrijf het ticket dan in hun taal: wat er technisch moet veranderen, niet alleen waarom het voor SEO goed is. Onze technische SEO-checklist voor developers helpt om die vertaling te maken. Gaat een ticket naar een copywriter, dan gelden andere velden. Die staan in de SEO-briefing voor een copywriter.

Categorieën in je backlog

Geef elk ticket een label. Vier is genoeg:

  1. Techniek: indexering, crawlbaarheid, snelheid, redirects, structured data.
  2. Content: nieuwe pagina’s, bestaande pagina’s verbeteren, samenvoegen of verwijderen.
  3. Interne structuur: menu, interne links, URL-opbouw, categorieën.
  4. Autoriteit: linkbuilding, digitale PR, vermeldingen.

Met labels zie je in één oogopslag of je backlog uit balans is. Staan er 80 technische tickets en 3 contenttickets? Dan is je backlog waarschijnlijk gevuld door één audit en niet door je zoekvraag.

Prioriteren: scoren in plaats van schreeuwen

Zonder scoremodel wint de luidste stem. De directeur wil een pagina over een nieuw product, sales wil een landingspagina voor een beurs, de developer wil eerst de oude redirects opruimen. Iedereen heeft een punt. Niemand heeft een getal.

Een gangbare formule:

Prioriteit = (SEO-impact × businesswaarde × zekerheid) ÷ (inspanning × risico)

Geef elke factor een score van 1 tot 5:

  • SEO-impact: hoeveel pagina’s of hoeveel zoekvolume raakt het?
  • Businesswaarde: gaat het om pagina’s die omzet of leads opleveren, of om een blog die niemand leest?
  • Zekerheid: hoe zeker weet je dat de fix werkt? Een kapotte canonical is 5. ‘Misschien helpt een langere tekst’ is 2.
  • Inspanning: hoeveel tijd kost het? 1 is een uur, 5 is een sprint of meer.
  • Risico: kan het iets kapotmaken? Een migratie van URL’s is 5. Een metatitel aanpassen is 1.

Een rekenvoorbeeld

Stel, je hebt vier tickets. De cijfers zijn een voorbeeld, geen benchmark.

Ticket Impact Waarde Zekerheid Inspanning Risico Score
Canonicals productpagina’s herstellen 5 5 5 2 2 31,3
Interne links naar categoriepagina’s 3 4 4 1 1 48,0
Blog over branchetrends schrijven 2 2 2 2 1 4,0
Volledige URL-structuur ombouwen 4 4 3 5 5 1,9

Zie wat er gebeurt. Het ticket met de minste glans, interne links aanpassen, staat bovenaan. Het grote project dat in elk overleg terugkomt, de URL-structuur ombouwen, staat onderaan. Niet omdat het slecht is, maar omdat het veel kost en veel kan breken. Moet die URL-structuur toch veranderen? Lees dan eerst wat je aan je URL-structuur vandaag nog aanpast zonder alles om te gooien.

De score is geen wet. Het is een startpunt voor het gesprek. Maar het gesprek gaat nu over ‘waarom geef jij zekerheid een 4?’ en niet meer over wie de meeste invloed heeft.

Wil je zien hoe andere teams zo’n plan in de tijd zetten? Dit voorbeeld van een SEO-plan voor 30 tot 90 dagen voor kleine bedrijven laat zien hoe je de eerste weken vult met werk dat snel iets oplevert, en het zware werk later inplant. De tekst is in het Pools, maar de opbouw is goed te volgen.

Een rekenvoorbeeld — overview diagram

Wat er níét in je top tien hoort

Google zegt in de eigen SEO-starthandleiding dat er geen geheimen zijn die je automatisch bovenaan zetten. Tickets die proberen ‘het algoritme te slim af te zijn’ horen dus onderaan of eruit. Denk aan een trucje met trefwoordherhaling, of een lijst nieuwe pagina’s die alleen een plaatsnaam verschillen. Als een ticket niet helpt om de zoekvraag beter te beantwoorden of de site gezonder te maken, kost het alleen tijd.

Het ritme: drie vaste momenten

Een backlog zonder onderhoud groeit dicht als een sloot zonder baggeraar. Na een jaar staan er 400 tickets in, waarvan de helft niet meer klopt. Dit ritme voorkomt dat:

  1. Wekelijks, 30 minuten: triage. Nieuwe tickets beoordelen. Zijn alle zeven velden ingevuld? Zo niet, terug naar de indiener. Krijgt het een score? Dan de backlog in. Is het een dubbel? Samenvoegen.
  2. Maandelijks, 60 minuten: herprioriteren. De top twintig opnieuw scoren. Is er iets veranderd in de business? Is een ticket door een andere fix al opgelost? Kies wat naar de volgende sprint gaat.
  3. Per kwartaal, een halve dag: opruimen. Elk ticket ouder dan zes maanden dat nog onderaan staat: weg. Het komt wel terug als het echt belangrijk is. En de winnaars van dit kwartaal schuiven door naar de roadmap.

Die laatste stap voelt voor veel teams als weggooien van werk. Dat is het niet. Een ticket dat zes maanden onderaan staat, heeft zijn kans gehad. Weg ermee. Geen spijt.

Wie bewaakt dit ritme? Dat is de vraag die de meeste backlogs laat mislukken. Als SEO bij iemand ‘erbij’ ligt, valt het overleg als eerste weg bij drukte. In SEO-projectmanagement lees je wat die rol doet en wanneer je er iemand voor aanneemt. En als je wilt vastleggen wie welke beslissing mag nemen, bijvoorbeeld wie een URL mag wijzigen, dan is SEO-governance de volgende stap.

Na de release: meten of het werkte

Hier verliezen de meeste teams het spoor. Het ticket gaat naar ‘done’, iedereen gaat door, en niemand kijkt terug. Dan weet je na een jaar niet welke 10 van de 60 fixes het verschil maakten.

Hoe lang je wacht

Google schrijft in de SEO-starthandleiding dat sommige wijzigingen binnen een paar uur effect hebben en andere pas na enkele maanden. Het advies is om in het algemeen een paar weken te wachten voordat je beoordeelt of iets werkte. Plan de controle dus in het ticket zelf: een technische check direct na livegang, een beoordeling van verkeer en posities na enkele weken.

Waar je meet

Search Console is je eerste meetpunt. Daar zie je of pagina’s geïndexeerd worden, voor welke zoekopdrachten je getoond wordt en hoe vaak er geklikt wordt. Leg in elk ticket vast welk rapport je gebruikt en wat de uitgangswaarde was. Zonder nulmeting is elke stijging een gevoel.

Voor technische tickets rond snelheid kijk je naar Core Web Vitals. Een goede uitleg van wat Core Web Vitals meten en hoe je ze verbetert helpt je om vooraf te bepalen welke waarde ‘klaar’ betekent. Let wel: snelheid is een factor, niet de enige. Een backlog met twintig snelheidstickets en geen contentwerk is een fort met dikke muren en geen voorraad. Lees ook waarom snelheid telt, maar niet als enige factor.

Let op met je analytics

Meet je met een analytics-tool naast Search Console, kijk dan of je meetopzet past binnen de regels. Volgens de Rijksoverheid moeten websites toestemming vragen voor cookies, maar geldt dat niet voor cookies die niet privacygevoelig zijn, zoals bepaalde analytische cookies. Twijfel je of jouw instellingen onder die uitzondering vallen, leg het dan voor aan je privacy-jurist of functionaris gegevensbescherming voordat je een meetticket afsluit. Wil je beter begrijpen wat een bezoekersstatistiek wel en niet laat zien, dan geeft deze uitleg over bezoekersstatistieken een helder beeld van de basis. Dat is relevant omdat een tool die minder meet, ook minder laat zien van het effect van je tickets.

Terugkoppelen naar de score

De meting heeft nog één doel. Leg na elke beoordeling vast of je zekerheidsscore klopte. Gaf je een ticket een 5 voor zekerheid en gebeurde er niets? Dan scoor je vergelijkbare tickets voortaan lager. Na een paar maanden wordt je scoremodel zo steeds scherper.

Wanneer een backlog niet de beste keuze is

Niet elke situatie vraagt om een backlog met scoremodel en vast ritme.

Je site heeft 15 pagina’s. Dan heb je geen backlog nodig maar een lijstje van vijf acties. Een scoremodel op vijf tickets is een kanon om een mug te raken.

Er is een acuut probleem. Is je verkeer na een migratie met de helft gezakt? Dan ga je niet scoren. Dan blus je eerst de brand. Het scoremodel komt daarna weer.

Niemand kan tickets uitvoeren. Een backlog zonder developer of copywriter die het werk oppakt, is een boodschappenlijst zonder winkel. Regel eerst de capaciteit, dan de lijst.

Je weet nog niet wat er mis is. Een backlog vullen zonder analyse levert een lijst op met losse ideeën. Begin dan met een technische audit en bouw de backlog op uit de bevindingen.

Zo kijken wij ertegen aan

We zien bij bijna elke nieuwe opdracht hetzelfde. Er ligt een backlog van honderden regels. Een deel komt uit een audit van twee jaar geleden, een deel uit wensen van verschillende afdelingen. Het team werkt hard, maar het organisch verkeer groeit niet. De reden is bijna altijd dezelfde: er wordt gemeten in afgeronde taken, niet in resultaat.

Onze aanpak is daarom eenvoudig. Eerst halen we de backlog leeg tot wat bewijsbaar impact heeft. Daarna werken we direct samen met de developers, copywriters en linkbuilders die het werk uitvoeren, zodat een fix niet weken in een wachtrij staat. En we rapporteren aan management in forecasts: wat levert dit kwartaal op als deze vijf tickets live gaan? Dat creëert draagvlak. Een directeur tekent sneller voor een verwachte uitkomst dan voor een lijst met technische termen.

Wat we niet doen: elke bevinding uit een audit als ticket inschieten. Een audit met 200 punten waarvan je er 20 uitvoert, is beter dan een backlog met 200 tickets waarvan er niets live gaat. Minder lijst, meer resultaat.

— Ramon

Hulp bij je SEO-backlog

Loopt je backlog vol en zie je niet welke tickets het verschil maken? Dan kan een frisse blik helpen. Met een technische scan zie je snel waar de grootste lekken zitten. Wil je dat iemand de backlog, het ritme en de afstemming met je webteam voor een periode overneemt, dan past interim SEO-management beter. Daarbij zetten we de backlog op, scoren we samen met jouw team en zorgen we dat de winnaars echt live gaan.

Veelgestelde vragen

Hoe groot mag een SEO-backlog zijn?

Er is geen vast maximum, maar alles boven de 100 open tickets wordt lastig te overzien. Belangrijker is hoeveel tickets een score en een eigenaar hebben. Ruim per kwartaal op wat langer dan zes maanden onderaan staat.

Welke tool gebruik je voor een SEO-backlog?

De tool die je developers al gebruiken. Staat SEO in een apart spreadsheet, dan wordt het werk niet opgepakt. Zet de SEO-tickets in hetzelfde systeem als de rest van het webwerk, met een eigen label.

Hoe vaak moet je de backlog herprioriteren?

Een maandelijks moment van een uur is voor de meeste teams genoeg. Daarnaast doe je wekelijks een korte triage voor nieuwe tickets. Bij grote veranderingen, zoals een migratie of een nieuw product, prioriteer je direct opnieuw.

Wanneer is een SEO-ticket echt afgerond?

Als de controle die je vooraf hebt afgesproken laat zien dat het probleem weg is. Bijvoorbeeld een nieuwe crawl zonder fouten op dat patroon, of indexering in Search Console na enkele weken. ‘Code staat live’ is niet hetzelfde als klaar.

Wat is het verschil tussen een SEO-backlog en een SEO-roadmap?

De backlog bevat alles wat je zou kunnen doen, met een score per item. De roadmap bevat alleen wat je gaat doen, met een doel en een planning. Items schuiven van de backlog naar de roadmap zodra ze winnen op score en er capaciteit is.

Bronnen

Aanbevelingen