Kort fortalt
Googles augustopdatering mod spam blev udsendt 18. august 2026 kl. 09:27 PDT og var færdigudrullet 21. august kl. 01:49 — 2 døgn og 16 timer, mod knap 20 timer i marts og omkring 48 timer i juni. Den gjaldt globalt og på alle sprog, dansk inklusive, og Google oplyste ikke, hvad den rammer. I samme uge lå Search Consoles performancerapporter med en logningsfejl fra 13. august, som Google selv kalder ren logning uden sammenhæng med synlighed, og som først var rettet omkring 20. august. En sammenligning af de 28 dage før og efter lægger derfor et for lavt datasæt op mod et udrulningsvindue. Det første døgn, tallene kan bære, er 22. august.
Målingen af augustopdateringen skal starte 22. august 2026 — ikke 18. — og den skal tælle forespørgsler, ikke placeringer. Udrulningen løb fra 18. til 21. august, og ugen før den lå Search Console med en logningsfejl, så både før- og eftertallene er utroværdige i standardopsætningen. Det, der adskiller et spamhit fra en core-opdatering, er formen på tabet: hele sæt af forespørgsler forsvinder i stedet for at glide nedad.
Hvad der faktisk skete 18.–21. august
Google udsendte augustopdateringen mod spam den 18. august 2026 kl. 09:27 PDT og meldte den færdigudrullet 21. august kl. 01:49 PDT. Statusnoten på Googles Search Status Dashboard siger, at den gælder globalt og på alle sprog. Der er ingen undtagelse for dansk, og der er heller ingen liste over, hvad den rammer — Google har alene beskrevet det som en spamopdatering, der køres igen. Det var årets tredje efter 24. marts og 24. juni.
Udrulningsvinduet er blevet længere for hver gang: knap 20 timer i marts, omkring 48 timer i juni, 2 døgn og 16 timer i august. PPC Land har tidsstemplerne for alle tre. Det siger ikke noget om, hvor hårdt en opdatering rammer; Google kobler aldrig de to ting, og der er ingen grund til at gøre det for dem. Det siger noget om, hvor længe dine tal er i bevægelse — og det er den del, der afgør, hvilken periode du kan sammenligne med.
To ting forurener din sammenligningsperiode
Standardgrebet efter en opdatering er 28 dage før mod 28 dage efter i Search Console. I august giver det et forkert svar to gange.
Den første fejl ligger i før-perioden. Fra 13. august faldt visninger og klik i performancerapporterne, også i rapporten for generativ AI. John Mueller bekræftede offentligt, at der var tale om en logningsfejl og ikke om ændret synlighed i Search, og Googles egen side om dataafvigelser i Search Console noterer, at fejlen kun berører logningen. Tallene var tilbage omkring 20. august, og de manglende AI-tal blev bekræftet rettet 31. august. Men de dage, du sammenligner med, står stadig lavere i rapporten, end virkeligheden var.
Den anden fejl ligger i efter-perioden. 18.–21. august er selve udrulningen. Placeringerne flytter sig undervejs, så et gennemsnit hen over de fire døgn beskriver en tilstand, der ikke findes længere.
Tilbage står ét brugbart snit: en før-periode, der slutter 12. august, og en efter-periode, der starter 22. august. Vil du have 28 dage i hver, er det 16. juli til 12. august mod 22. august til 18. september. Og husk, at den danske sommerferie ligger midt i før-perioden. For de fleste B2B-sites er juli et lavpunkt i sig selv, så sammenlign hellere med de samme uger sidste år end med "de foregående 28 dage".
Tab af forespørgsler, ikke tab af placeringer
Glenn Gabe gennemgik fire ramte sites efter opdateringen i sine case studies. Tallene er værd at kigge på — ikke fordi de er dine, men fordi formen på tabet går igen. Ét site mistede placeringer for over 200.000 forespørgsler. Et Amazon-affiliatesite mistede over 14.000. Et tredje, med omkring 250.000 URL'er der viderestillede brugerne videre, mistede omkring 25.000. Det fjerde havde over 1,5 mio. indekserede URL'er, hvoraf omkring 85 % var programmatisk genereret, og faldt på tværs af hele domænet.
Forbeholdet hører med: sitene er anonymiserede, og tallene er tredjepartsestimater over synlighed, ikke udtræk fra ejernes egen Search Console. Men mønstret er det interessante. Forespørgslerne blev ikke placeret dårligere — de forsvandt.
Det er den praktiske forskel på en spamopdatering og en core-opdatering. En core-opdatering flytter dig ned ad listen, fordi noget andet nu vurderes mere relevant. En spamklassificering tager sidegruppen ud af spillet.
Derfor er gennemsnitsposition den dårligste måleenhed, du kan vælge lige nu. En side, der slet ikke længere vises for en forespørgsel, tæller ikke med i gennemsnittet. Gennemsnittet kan altså se stabilt eller ligefrem bedre ud, samtidig med at antallet af forespørgsler, du overhovedet er synlig på, er halveret.
Rækkefølgen jeg måler i
Det her er strukturen, ikke værktøjet. Den kan klares i Search Consoles brugerflade, men bliver først rigtig brugbar over API'et, fordi du skal kunne bryde tallene op efter sidegruppe.
- Lås vinduerne, før du kigger på et eneste tal. Slut før-perioden 12. august, start efter-perioden 22. august. Ellers vælger du ubevidst den periode, der bekræfter det, du allerede tror.
- Tæl unikke forespørgsler med mindst én visning i hvert vindue. Ikke klik, ikke CTR, ikke position. Det er tælleren, der afslører et spamhit.
- Del op efter mappe eller sidetype, ikke på domæneniveau. Et fald på 40 % i én skabelongenereret sektion forsvinder i et domænetal, hvor resten af sitet ligger fladt.
- Hold det op mod indekseringen. Er URL'erne stadig indekserede, men holdt op med at rangere, er det en klassificering. Er de gledet ud af indekset, er det en anden diagnose og en anden opgave.
- Brug brandsøgninger som kontrolgruppe. De påvirkes sjældent af spamklassificering, så de viser dig, hvor meget af faldet der bare er sæson eller logningsfejl.
Falder forespørgselstællingen kraftigt i én sidegruppe, mens kontrolgruppen ligger fladt, har du noget at handle på. Falder alting jævnt, kigger du sandsynligvis på ferien eller på fejlen fra 13. august.
Hvis mønstret passer
Google skriver i sine spampolitikker, at overtrædelser findes både gennem automatiserede systemer og, efter behov, gennem menneskelig gennemgang, der kan føre til en manuel handling. Det er to spor, og kun det ene skriver til dig. En spamopdatering er det automatiske spor: der kommer ingen besked i Search Console, og der er ingen genbehandlingsanmodning at sende, fordi der ikke er nogen manuel handling at få ophævet.
Derfor findes der heller ingen kort vej tilbage. Gabe sætter genopretningen til måneder, og først efter at det strukturelle er lavet om — ikke efter at et par sider er skrevet igennem. Er 85 % af dine indekserede URL'er genereret af en skabelon oven på et datasæt, er det tallet, der skal ned. Ordvalget på siderne er ikke det, der bliver klassificeret.
Byg din baseline, inden du får brug for den
Det dyre ved augustopdateringen er sjældent trafikken i sig selv. Det er, at efteråret går med at diskutere et tal, der er regnet oven på en uge, hvor Googles egen logning var i stykker — og at ingen i lokalet kan afgøre, om faldet er sandt.
Garderingen er kedelig: gem dine egne daglige udtræk fra Search Console-API'et med dato på, opdelt efter sidegruppe. Så er du uafhængig af, om rapporten stadig viser det samme om tre måneder. Tre spamopdateringer på et år, alle uden forvarsel og uden en liste over, hvad de rammer, er rigelig grund til at holde regnskabet selv.