Runbook voor reactie op algoritme-update

Een reactie op een algoritme-update is een incidentonderzoek, geen bewerkingssprint. De eerste regel is eenvoudig: bevestig dat de daling echt is en van jou is voordat je reageert. “Echt” betekent dat de daling aanhoudt in volledige, vergelijkbare data. “Van jou” betekent dat het de zoekzichtbaarheid van jouw site weerspiegelt, niet een kapotte meting, verminderde vraag, een gewijzigde resultaatweergave of een update die je pagina’s niet heeft geraakt.

Checklist: Reactie op algoritme-update. Tijdsbox: 60–90 minuten voor triage op dag één; 2–4 uur voor segmentatie in de eerste week; een formeel actie-of-wacht-besluit na zeven volledige dagen, tenzij een geverifieerde technische fout onmiddellijke reparatie vereist. Eigenaar: de SEO-lead is eigenaar van het incident en beslissingslogboek; een analist valideert de data; engineering is eigenaar van technische fouten; content-eigenaren keuren paginawijzigingen goed.

Gebruik dit runbook wanneer een materiële daling in zoekresultaten samenvalt met een bevestigde of vermoedelijke Google-algoritme-update , dat wil zeggen een wijziging in Google’s rankingsystemen. Het is ook geschikt wanneer geen update is bevestigd maar veel URL’s tegelijk bewegen en de oorzaak onduidelijk is.

Waarom deze fase, en waarom hier

Deze checklist verbruikt de gedateerde basismeting , publicatie-annotaties, paginaeigenarenkaart, template-inventaris, intentieclassificatie, analysedata, Search Console-data en conversiedefinities die eerder in het proces zijn vastgesteld. Zonder die invoer kan een team zien dat een lijn bewoog, maar niet vaststellen wat er veranderde, waar het veranderde of of het belangrijk is voor het bedrijf.

De volgorde is belangrijk omdat meetfouten en sitefouten algoritmeverliezen kunnen nabootsen. Een toestemmingswijziging kan analytics-sessies verwijderen. Een implementatie kan noindex toevoegen, de verkeerde canonical kiezen of interne links verbergen. Seizoensinvloeden kunnen zoekopdrachten verminderen terwijl rankings stabiel blijven. Diagnosticeer die gevallen voordat je de daling toeschrijft aan een extern systeem.

Het uitvoeren van herstel vóór segmentatie veroorzaakt een tweede probleem: toeschrijving verdwijnt. Als het team titels herschrijft, templates herstructureert, pagina’s verwijdert en interne links wijzigt in dezelfde week, heeft elk later herstel of elke daling meerdere aannemelijke oorzaken. De reactie moet daarom gaan van verificatie, naar patroonisolaite, naar een geregistreerd actie-of-wacht-besluit, en pas daarna naar een gecontroleerde interventie.

Invoer en uitvoer

Het beslissingsregistratie is het contract met de volgende stap. “Google heeft iets veranderd” is geen opleverbaar resultaat; een begrensd patroon, een expliciet besluit en bewijs dat een andere beoordelaar kan inspecteren zijn dat wel.

De checklist

1. Bevestig dat de daling echt is en van jou is

Wat: verifieer het verlies over onafhankelijke metingen voordat je een oorzaak toewijst. Waarom: onvolledige rapportage, trackingfouten, weekenden, seizoensinvloeden, nieuwscycli en veranderende vraag kunnen een overtuigend vals alarm creëren. Organisch verkeer betekent onbetaalde bezoeken uit zoekresultaten; het kan dalen zelfs als rankings dat niet doen. Hoe: gebruik volledige dagen, vergelijk gelijke weekdag-uitgelijnde perioden, controleer Search Console-klikken en -vertoningen tegen analytics-sessies en -conversies, inspecteer jaar-op-jaar-context waar seizoensinvloeden bestaan, en noteer de laatste datum waarop elke bron is gefinaliseerd. Tool: zoekprestatiedata, analytics, conversierapportage, uptimelogs en de publicatiekalender. Gereed wanneer: ten minste twee onafhankelijke signalen overeenkomen in richting, de laatste drie volledige dagen onder de geselecteerde basislijn blijven, actualiteit van data is vastgelegd en de brief vermeldt of het verlies zichtbaarheid, vraag, tracking, conversie of een mengeling betreft.

2. Sluit oorzaken uit die jij beheerst

Wat: test op site-, tracking-, beveiligings- en indexeringsfouten. Waarom: een geverifieerd defect verdient onmiddellijke reparatie, terwijl wachten op een update om te voltooien vermijdbaar verlies zou verlengen. Indexeerbaarheid is het vermogen van een pagina om te worden opgenomen in de index van een zoekmachine. Hoe: inspecteer getroffen en niet-getroffen URL’s op responsstatus, robots-instructies, canonical, rendering, interne links, sitemapaanwezigheid, meldingen van handmatige acties en analytics-gebeurtenissen; stem elke wijziging af op het publicatietijdstip. Tool: URL-inspectie, server- en implementatielogs, crawleroutput, analytics-debugger, uptimemonitor en wijzigingsregistratie. Gereed wanneer: elke kandidaat-fout is doorstaan, weerlegd of toegewezen met een eigenaar; elke fout die overeenkomt met het begin is gelabeld als nu repareren en gescheiden van algoritme-hypothesen.

3. Segmenteer op map, template en intentie

Wat: bouw een impactmatrix in plaats van het sitebrede gemiddelde te beoordelen. Waarom: een breed totaal kan het daadwerkelijke patroon verbergen: productpagina’s kunnen dalen terwijl handleidingen groeien, één template kan mobiele klikken verliezen, of informatieve zoekopdrachten kunnen verschuiven terwijl merkgebonden vraag stabiel blijft. Zoekintentie is de taak die iemand wil voltooien met een zoekopdracht. Hoe: bereken voor-na-veranderingen voor klikken, vertoningen, positie, conversies en getroffen URL’s; groepeer eerst op map, dan op template, primaire intentie, apparaat, land, queryklasse en bedrijfsrol. Neem stabiele of stijgende groepen op als controles. Gebruik gewogen absolute totalen naast percentages, zodat tien verloren klikken op een klein segment niet zwaarder wegen dan tienduizend verloren klikken op een groot segment. Tool: map-, pagina-, query-, URL-mover- en keyword-mover-rapporten plus een spreadsheet of analysedocument. Gereed wanneer: de matrix ten minste 95% van de zoekklikken dekt, getroffen en controlesegmenten toont, laag-volume groepen als niet-conclusief registreert en het smalste herhaalbare patroon noemt dat door de data wordt ondersteund.

4. Inspecteer representatieve winnaars en verliezers

Wat: beoordeel pagina’s en zoekopdrachten die elk getroffen en controlesegment het beste vertegenwoordigen. Waarom: totalen lokaliseren de schade maar verklaren deze niet. Een zoekresultatenpagina kan klassieke vermeldingen vervangen door winkeleenheden, lokale resultaten, video of AI-antwoorden; die wijziging kan klikken verminderen zonder een corrigeerbaar pagina-defect te tonen. Hoe: selecteer ten minste vijf hoog-impact verliezers en vijf stabiele of stijgende controles wanneer het segment voldoende URL’s bevat. Vergelijk intentiebevrediging, originaliteit, bewijs, auteurschap, commerciële lading, updategeschiedenis, interne routering, snippetwijzigingen en concurrerende resultaatformaten. Leg observaties vast als hypothesen, niet als ranking-factorclaims. Tool: live resultaatbeoordeling, paginarender, bronregistratie, concurrentpagina’s, zoekdata en contentinventaris. Gereed wanneer: elke hypothese voorbeelden aanhaalt uit verliezers en controles, tegenstrijdig bewijs wordt behouden en geen aanbeveling op slechts één pagina of één zoekopdracht alleen rust.

5. Bevries paniekbewerkingen in week één

Wat: verbied brede, speculatieve wijzigingen terwijl de diagnose doorgaat. Waarom: massale titelherschrijvingen, wijzigingen van publicatiedatum, paginadeletie, sitebrede woordenaantallen, template-herontwerpen en linkschommeling veranderen meerdere variabelen tegelijk. Ze kunnen pagina’s beschadigen die niet waren getroffen en elke latere beweging ontoerekenbaar maken. Hoe: creëer een wijzigingsvenster van zeven volledige dagen vanaf het waargenomen begin. Sta alleen geverifieerde reparaties, juridische of feitelijke correcties, beveiligingswerk en reeds goedgekeurde lanceringen toe waarvan uitstel groter risico met zich meebrengt; annoteer elke uitzondering. Bewaar kopieën van huidige pagina’s en exports. Tool: publicatiekalender, CMS-machtigingen, incidentlogboek en annotatiesysteem. Gereed wanneer: de reikwijdte, start, einde, goedkeurder en uitzonderingen van de bevriezing zichtbaar zijn voor uitgevers en engineers; nul niet-geregistreerde SEO-experimenten worden uitgevoerd binnen het venster.

6. Kies actie, wacht of nu repareren

Wat: neem een besluit op een genoemd controlepunt. Waarom: eindeloze observatie laat echte defecten onbehandeld, terwijl reflexmatig handelen onzekerheid omzet in ongecontroleerde verandering. Hoe: kies nu repareren voor een gereproduceerde technische of meetfout; kies actie wanneer een materieel verlies aanhoudt, concentreert in een coherent segment en een pagina- of systeemzwakte zowel verliezers als controles verklaart; kies wacht wanneer uitrol, datalag, seizoensinvloeden, laag volume of tegenstrijdige segmenten een verdedigbare oorzaak verhinderen. Leg de afgewezen alternatieven en het bewijs dat het besluit zou veranderen vast. Tool: incidentbrief, impactmatrix, representatieve beoordeling, bedrijfsrisicobeoordeling en goedkeurder. Gereed wanneer: het verslag één besluit, vertrouwensniveau, eigenaar, beoordelingsdatum, bewijslinken en een trigger voor heropening bevat.

7. Voer één gecontroleerde interventie uit

Wat: vertaal een actie-besluit in een begrensde reparatie of experiment. Waarom: één hypothese en één coherente wijzigingsset behouden de kans om te leren; gelijktijdige sitebrede wijzigingen doen dat niet. Hoe: definieer het getroffen cohort, onaangetaste vergelijkingsgroep waar praktisch, precieze zwakte, beoogde lezersverbetering, verwachte metriek, observatievenster, acceptatiedrempel en terugdraairoute. Gebruik voor vervallen pagina’s de contentverversingschecklist in plaats van datums te wijzigen of copy blind uit te breiden. Tool: actiebrief, pagina-inventaris, CMS, QA-registratie, release-eigenaar en annotaties. Gereed wanneer: elke gewijzigde URL overeenkomt met het gediagnosticeerde patroon, de interventie QA heeft doorstaan, controles ongewijzigd blijven of afwijkingen zijn geregistreerd en de release-annotatie vermeldt wat moet bewegen en tegen wanneer.

8. Meet, documenteer en sluit af of iterereer

Wat: evalueer de interventie los van het updateverhaal. Waarom: herstel na een release is associatie, geen bewijs dat de release het veroorzaakte; de update kan nog steeds worden uitgerold, concurrenten kunnen veranderen en vraag kan terugkeren. Hoe: vergelijk het aangegeven nametingvenster met de bevroren basislijn, behoud dezelfde segmentatie, inspecteer controles en conversies en leg verstorende factoren vast. Classificeer de uitkomst als positief, neutraal, negatief of niet-conclusief. Tool: annotatieresultaten, mover-rapporten, analytics, conversierapportage en het incidentverslag. Gereed wanneer: werkelijke versus verwachte resultaten zijn bijgevoegd, vertrouwen en beperkingen zijn vermeld, de eigenaar kiest voor afsluiten, observatie verlengen, terugdraaien of een nieuwe begrensde hypothese uitvoeren, en de volgende beoordelingsdatum is vastgesteld.

Tools in AmICited

AmICited maakt de diagnose reproduceerbaar door perioden, segmenten en interventies te bewaren. Het bewijst niet wat een algoritme beloont; gebruik de rapporten om patronen te lokaliseren en beslissingen te testen.

1. Open Organic Rank met het Organic Rank-rapport om vraag, gemiddelde positie en klikken over verbonden zoekkanalen te vergelijken. Gebruik het om te beslissen of het incident breed of kanaalspecifiek is.
2. Open URL-positiewijzigingen met URL-positiewijzigingen om de pagina’s te identificeren die het verlies veroorzaken, perioden te vergelijken en beweging uit te splitsen naar apparaat en sectie.
3. Open Keyword-positiewijzigingen met Keyword-positiewijzigingen om gewijzigde query-rankings te scheiden van verloren vraag en intentie-niveau patronen te vinden.
4. Open Google Zoekmappen met Google Zoekmappen om van de hele site in te zoomen op de mappen waar klikken of vertoningen veranderden.
5. Gebruik Google Zoekpagina’s met Google Zoekpagina’s en Google Zoekopdrachten met Google Zoekopdrachten om representatieve URL’s en de exacte zoekopdrachten die ze dienden te valideren.
6. Open Annotatieresultaten met Annotatieresultaten om de interventie, verwachting, controlepunt en resultaat vast te leggen. Beschouw een beoordeelde uitkomst als bewijs van associatie, niet als bewijs van causaliteit.

Beslissingsregels

Dit zijn standaard incidentbeheersingsregels, geen claims over hoe Google pagina’s beoordeelt. Hun doel is zowel overreactie op ruis als inactiviteit tijdens een materiële storing te voorkomen. Vervang ze alleen door een gedocumenteerde drempelwaarde gebaseerd op de gevestigde volatiliteit en het bedrijfsrisico van de site.

Percentages alleen zijn onvoldoende. Een daling van 50% van twee klikken naar één is operationeel niet gelijk aan een daling van 15% met duizenden bezoeken. Behoud altijd absoluut volume, conversieblootstelling en vertrouwen naast de relatieve verandering.

Opleverbaar: het algoritme-update incidentpakket

Overhandig één gedateerde map of incidentregistratie, niet een dia met “core-update-impact”. Het bevat:

1. Een incidentbrief van één pagina met begin, ernst, vermoedelijke update, actualiteit van data, bedrijfsrisico, eigenaar en huidig besluit.
2. Bevroren exports of rapporterlinks voor basislijn- en incidentperioden, inclusief filters en tijdzone.
3. Een impactmatrix per map, template, intentie, apparaat, land, pagina en query, met getroffen en controlecohorten.
4. Een oorzaak-uitsluitingslogboek met betrekking tot meting, vraag, releases, crawlen, indexeren, rendering, beveiliging en wijzigingen in resultaatweergave.
5. Representatieve verliezer- en controlebeoordelingen, met ondersteunend en tegenstrijdig bewijs voor elke hypothese.
6. Het actie/wacht/reparatie-besluit, afgewezen alternatieven, goedkeurder, volgende beoordelingsdatum en bewijs dat het incident zou heropenen.
7. Voor een interventie: het exacte URL-cohort, wijzigingsspecificatie, QA-registratie, terugdraairoute, release-annotatie, controlepunt en eindresultaat.

Gebruik een machine-leesbare tabel voor de impactmatrix en een mens-leesbare samenvatting voor het besluit. Het pakket is compleet wanneer een andere analist het getroffen patroon kan reproduceren zonder te vragen welke filters zijn gebruikt, en een uitgever precies kan zien wat is goedgekeurd zonder een grafiek te interpreteren.

Wat er misgaat

De update wordt de verklaring voor alles

Een aankondiging en een verkeersdaling vinden vlak bij elkaar plaats, waardoor het team stopt met het testen van alternatieven. De oplossing is het bijhouden van een uitsluitingslogboek en het vereisen van corroboratie. Timing vestigt een hypothese, niet het eigendom van het verlies.

Sitegemiddelden verbergen tegenovergestelde bewegingen

Handleidingen winnen terwijl categoriepagina’s verliezen, maar een vlak totaal doet het voorval er onschuldig uitzien. Of één grote map daalt en laat elke template er zwak uitzien. Segmenteer dezelfde data op map, template, intentie, apparaat en land, en behoud stabiele groepen als controles.

Week-één bewerkingen vernietigen toeschrijving

Teams herschrijven pagina’s omdat actie veiliger voelt dan wachten. Een herstel kan vervolgens niet worden gescheiden van uitrolvoltooiing, vraag, concurrentiewijzigingen of de bewerkingen zelf. Bevries speculatief werk gedurende zeven volledige dagen en annoteer elke uitzondering.

Percentageveranderingen overdrijven kleine steekproeven

Een laag-volume groep daalt van vier klikken naar twee en wordt de top “verliezer” met 50%. Koppel relatieve verandering altijd aan absolute klikken, vertoningen, aantal getroffen URL’s en bedrijfswaarde. Markeer dunne segmenten als richtinggevend.

Controles worden gekozen na het resultaat

Als stabiele pagina’s pas worden geselecteerd nadat is gezien welke stabiel bleven, vleit de vergelijking de voorkeursverklaring. Verklaar controles logica vóór de interventie: dezelfde template maar andere intentie, dezelfde intentie maar andere template, of onaangetast land/apparaat binnen hetzelfde cohort.

Meerdere fixes worden als één pakket geleverd

Titels, bodytekst, navigatie, schema en templates veranderen samen. Zelfs een positieve uitkomst leert weinig. Splits oorzaken in afzonderlijke interventies waar operationeel mogelijk; wanneer ze niet kunnen worden gescheiden, leg het pakket vast en verlaag het toeschrijvingsvertrouwen.

Herstel wordt gerapporteerd als bewijs

De metriek verbetert na een release, dus wordt de actie als causaal verklaard. Rapporteer de volgorde nauwkeurig: de wijziging werd gevolgd door herstel, controles gedroegen zich op een vermelde manier en bekende verstorende factoren blijven bestaan. Die taal is nuttiger dan zekerheid die het bewijs niet kan ondersteunen.

Volgende fase

Een geverifieerde technische fout gaat onmiddellijk naar de engineering-eigenaar, met het getroffen cohort en hertestconditie bijgevoegd. Een gediagnosticeerd paginakwaliteitsprobleem gaat naar de contentverversingsworkflow. Een niet-conclusief incident keert terug naar observatie met een genoemde beoordelingsdatum in plaats van in een onbepaalde achterstand te belanden.

De lopende fase continu verversen en itereren heeft vier dingen nodig van dit runbook: het getroffen cohort, de aanvaarde of afgewezen hypothese, de actie- en annotatieregistratie en de volgende meetdatum. Het gebruikt die uitvoer om werk te prioriteren zonder elke rankingfluctuatie als verval te behandelen.

FAQ

De incidenteigenaar moet de FAQ-antwoorden uit de frontmatter publiceren in de FAQ-component van de pagina en ze afgestemd houden op de bovenstaande beslissingsregels. Het leidende principe blijft hetzelfde bij elk antwoord: verifieer, segmenteer, besluit, wijzig één begrensd systeem en meet.

Reageer met bewijs, niet met urgentie

Open het Organic Rank-rapport , bevries de vergelijkingsdatums en maak de eerste incidentbrief voordat je een pagina wijzigt. De snelste nuttige reactie is een besluit dat het team later kan uitleggen.

[Read 100 lines (lines 101-200 of 201 total). 1 lines remaining from offset 200.]