Post-mortem
Daling van het verkeer na een core update: schrijf de post-mortem
Iedereen stelt hetzelfde om 8 uur: is het Google, zijn wij het, of is de tracking het probleem? Een post-mortem geeft antwoord in die volgorde en vermijdt gissen.
Begin met de tijdlijn, niet met de theorie
Een daling heeft een startdatum. Vind deze voordat je een enkel forumdraadje leest over een verkeringsdaling na een core update.
Google bevestigde core updates in maart 2024, augustus 2024, december 2024, maart 2025 en juni 2025, en elke update werd over ongeveer twee weken uitgerold. Een daling op dag drie van een rollout is dus nog niet het eindbeeld. Leg je eigen changelog over die data: releases, migraties, template-aanpassingen, robots.txt-wijzigingen.
Als er niets bij jou is veranderd en je Search Console-grafiek buigt binnen een rollout-venster, heb je een verdachte. Als jouw deploy de dag ervoor plaatsvond, heb je een sterkere kandidaat. In beide gevallen verdient de verkeringsdaling na de core update-week een geschreven tijdlijn. Schrijf het op.
Oorzaken gerangschikt op hoe snel je ze kunt uitsluiten
| Verdachte | Hoe controleren | Tijd om uit te sluiten |
|---|---|---|
| Tracking kapot | Vergelijk GA4 met Search Console-kliks voor dezelfde pagina's; een gap die in één nacht ontstond, is de aanwijzing | 10 minuten |
| Indexering of sitemap | Search Console pagina-indexeringsrapport, plus een site: spot check op de gedaalde URLs | 20 minuten |
| Technische release | Diff robots.txt, canonicals, statuscodes en redirects tegen de crawl van vorige week | 1 uur |
| Links verloren of gewonnen | Diff twee refdomains snapshots; zie verloren links | 30 minuten |
| Cannibalization | Twee van jouw URLs die van plaats wisselen voor dezelfde query in het prestatierapport | 1 uur |
| SERP-verandering | Open de live resultaten: AI Overview, forumdraadjes, listicles van grote merken waar jij normaal gesproken stond | 30 minuten |
| Kwaliteitsbeoordeling | Wat overblijft als elke andere regel duidelijk is | Dagen tot weken |
Link-evidence: één vergelijking
Haal verwijzende domeinen op voor de gedaalde site op twee data en print wat vertrokken is en wat nieuw is. De index vernieuwt zich ongeveer maandelijks, dus kies snapshots aan weerszijden van de update.
import json
old = {r['domain'] for r in json.load(open('2026-09-01.json'))['rows']}
new = {r['domain'] for r in json.load(open('2026-10-01.json'))['rows']}
print('lost :', len(old - new))
print('gained:', len(new - old))
print('sample lost:', sorted(old - new)[:20])
# Field names ('rows', 'domain') vary by action: print one response first.
Voorbeeld van een write-up (hypothetische cijfers)
Dit is een verzonnen voorbeeld, geen echte klant. Het toont de toon die we zouden nastreven.
Impact. Organische kliks daalden met 38% over negen dagen voor een fictief receptensite met 140 pagina's. Detectie. Een weekelijkse Search Console-export kruiste een 25% week-op-week alert. Oorzaak. Verwijzende domeinen bewogen van 410 naar 402, wat links uitsluit als belangrijkste driver. Twee pagina's wisselden van ranking voor dezelfde query, wat cannibalization is.
Actiepunten. Voeg de twee pagina's samen met een 301, update interne links, controleer opnieuw over vier weken. Geen disavow. Geen herschrijving van de hele site.
Meet- en indexeringsfouten die op een update lijken
Sommige dalingen zijn helemaal geen rankings. Tracking is een veelvoorkomende verdachte. Een kapotte tag, een veranderd property of een sitemap die kleiner is geworden, kan er precies uitzien als een core update in de grafieken. Een verkeringsdaling na core update timing kan ze allemaal verbergen, dus controleer die eerst.
De snelste test is om je analytics te vergelijken met Search Console voor dezelfde pagina's en dagen. Als de gap in één nacht ontstond, behandel het dan als een meetfout tot het tegendeel bewezen is.
Indexeringsfouten volgen dezelfde logica. Pagina's die uit de index verdwijnen, zijn een ander probleem dan pagina's die geïndexeerd blijven en in de resultaten zakken.
Wat als de kliks in één nacht naar nul daalden?
Controleer eerst het Search Console property. Een veranderd protocol, een nieuw property of verloren verificatie kan de data splitsen, zodat het oude property niets toont terwijl de nieuwe property het verkeer vasthoudt. Kijk pas daarna naar de pagina's zelf.
Waarom zouden pagina's na een update niet meer geïndexeerd worden?
Haal het indexeringsrapport op voor de betrokken URLs. Rankings kunnen zakken voor een pagina die geïndexeerd blijft. Een pagina die uit de index verdwijnt, heeft een andere oorzaak, vaak een robots-directive, een canonical-verandering of een noindex die met een release werd geïmplementeerd.
Kan een kapotte sitemap de daling veroorzaken?
Dat kan, als de sitemap plotseling slechts een klein deel van je URLs opsomt. Een korte sitemap is goedkoop op te lossen, maar Google vindt pagina's nog steeds via interne links, dus behandel het als één verdachte onder meerdere, niet als het vonnis. Vergelijk het URL-aantal met je echte pagina-aantal.
Onze positie
Schrijf de site niet in week één om
Core updates beoordelen kwaliteit over weken. Verander wat je bewezen kapot kunt maken, en wacht tot de rollout voorbij is voordat je aan content raakt.
- Los meet- en technische fouten onmiddellijk op.
- Voeg gecannibaliseerde pagina's samen zodra je bewijs hebt.
- Laat contentstrategie met rust tot de rollout voorbij is.
Wat je in het document moet schrijven
Zes koppen zijn genoeg: impact, tijdlijn, detectie, oorzaak, wat we hebben uitgesloten, actiepunten. De lijst met uitgesloten oorzaken is het deel waar toekomstige jij je voor zal bedanken.
Houd het bewijs naast de bewering. Een regel zoals "links uitgesloten, 402 vs 410 verwijzende domeinen" overleeft een sceptische manager beter dan "links zagen er goed uit".
Als het antwoord links blijkt te zijn, stoppen de alert rules for rivals en het weekly diff recepte je de volgende keer voor verrassingen.
De eerste week nadat een rollout begint
- 1
Bevries contentaanpassingen
Schrijf pagina's niet om terwijl de rollout loopt. Aanpassingen die middenin gebeuren, maken het voor-en-na-beeld troebel dat je later nodig zult hebben.
- 2
Log elke release
Schrijf elke deploy, template-aanpassing, redirect en robots.txt-wijziging op met de datum, zodat de tijdlijn echte entries bevat in plaats van herinneringen.
- 3
Voer de meetchecks uit
Vergelijk analytics met Search Console, controleer daarna het indexeringsrapport voor de gedaalde URLs. Beide checks passen binnen een half uur.
- 4
Open de case met de tijdlijn
Begin de post-mortem met de data die je hebt, zelfs als de oorzaak nog open is. Een gedeeltelijk document is makkelijker af te maken dan een leeg document.
- 5
Stel een reviewdatum in
Kies een datum nadat de rollout voorbij is en beoordeel het bewijs dan, niet op de dag dat de grafiek buigt.
De zaak aan het leiderschap uitleggen dat het probleem technisch is
Leiderschap leest vaak een verkeringsdaling als een contentvonnis. Dat is een logische reactie, en ook de reactie die de meeste weken kost als de fout een kapotte template of een ontbrekende tag is.
Breng de tijdlijn en de oorzakentabel mee, niet een theorie. Een tabel met een tijd om elke verdachte uit te sluiten, laat een manager zien dat het team door een lijst werkt, niet gist.
Wees eerlijk over wat de tabel niet kan bewijzen. Als een kwaliteitsbeoordeling nog open staat, zeg dat dan, en geef aan wat je mening zou veranderen.
Hoe toon ik aan dat het een dev-probleem is en geen content?
Wijs naar een gedateerde verandering die overeenkomt met het begin van de daling, zoals een templaterelease of een robots-wijziging. Een fout die je kunt reproduceren, met de URL en de header die veranderde, weegt zwaarder dan elke grafiek met gemiddelden.
Wat zeg ik als het helemaal niet technisch is?
Zeg dat de links-, indexering- en trackingchecks schoon zijn, en dat de resterende verdachte kwaliteitsbeoordeling is. Dat antwoord is langzamer en minder bevredigend, maar het is accuraat, en het vertelt het team waar contentwerk zich op moet richten.
Schrijf het herstel op, niet alleen de daling
Een post-mortem is niet klaar als het verkeer terugkomt. De tweede helft van de write-up registreert wat er veranderd is, wanneer het veranderd is en welke verdachten je definitief hebt gesloten.
Bekijk het document opnieuw na de volgende core update. Een patroon dat zich herhaalt over rollouts vertelt je meer over je site dan elke enkele daling.
Houd de lijst met uitgesloten oorzaken gescheiden van de oorzaken. Toekomstige lezers vragen eerst wat er is uitgesloten, en een ontbrekende lijst stuurt ze terug naar het begin.
Wat telt als herstel?
Definieer het voordat je kijkt. Een terugkeer naar het oude niveau van kliks is één definitie, en een terugkeer van de pagina's die het meest belangrijk waren, is een andere. Kies er één, schrijf het op en rapporteer erop, in plaats van de lat te verleggen als de grafiek beweegt.
Hoe lang moet de review wachten?
Lang genoeg voor de rollout om te sluiten en voor twee normale weken aan data. Herstel komt meestal langzaam, dus een vroege review vindt vooral ruis, terwijl een latere review een kans heeft om het antwoord te vinden.
Vragen die we na elke update horen
Kan ik herstellen van een core update-daling?
Vaak gedeeltelijk, zelden in één nacht. Herstel heeft meestal een latere update nodig om de site opnieuw te beoordelen, dus verwacht maanden, geen dagen. Niemand kan het beloven. Wat je wel kunt doen, is echte fouten verwijderen en pagina's blijven publiceren die het waard zijn om te citeren.
Waarom hielden rankings stand terwijl het verkeer daalde?
De resultatenpagina veranderde rondom jou. AI Overviews, forumdraadjes en shopping blocks kunnen dezelfde positie lager op het scherm duwen. Vergelijk de click-through rate voor dezelfde queries voor en na, niet alleen de gemiddelde positie.
Veroorzaken verloren backlinks een daling na een update?
Soms wel, en Rankift kan je niet vertellen welke update wat deed. Een linkverlies dat groot genoeg is om te tellen, toont zich als een duidelijke daling in verwijzende domeinen tussen twee snapshots. Kleine churn van een paar procent verklaart zelden een 30% verkeringsdaling.
Hoe lang moet ik wachten voordat ik handel?
Totdat Google de rollout als voltooid markeert op zijn statusdashboard, tenzij je een duidelijke technische fout vindt. Los fouten direct op, maar houd contentaanpassingen tegen. Bewerken tijdens een rollout maakt het bewijs dat je later nodig hebt, troebel.
