Search Console viste et fald på 30 %. Dagen var kun 16 timer lang

Hvad API'et svarer i dag

Search Analytics-API'et har et felt, brugerfladen ikke har: firstIncompleteDate. Googles egen dokumentation beskriver det som den første dato, hvor data stadig indsamles og behandles, og tilføjer at værdier efter den dato «kan ændre sig mærkbart». Feltet kommer kun med, når man beder om dataState: all og grupperer på dato.

Jeg kørte det samme kald på tre af mine egne properties i dag, 12. oktober 2026. Alle tre svarer det samme: firstIncompleteDate 2026-10-10. Sidste fuldt færdige dag er altså 9. oktober — tre dage tilbage i tiden. Beder man i stedet om dataState: final, stopper svaret ganske rigtigt den 9.: rækkerne for 10. og 11. oktober findes ikke. De er ikke tomme, de er ikke der.

At tre forskellige domæner med vidt forskellig trafikmængde rammer samme dato, siger at grænsen ligger i Googles behandling, ikke i det enkelte site.

Dagen der så ud til at falde 30 procent

På det største af de tre sites, en dansk forbrugerside med omkring 5.000 visninger om dagen, læser døgnrapporten sådan her: 9. oktober 4.751 visninger, 10. oktober 4.837, 11. oktober 3.333. Det sidste tal er 29,8 % under den 9.

Fire dage efter at Googles spamopdatering blev meldt færdig er det præcis det fald, man kigger efter. Og det er ikke et fald.

Timerne viser hvor grænsen går

API'et kan også levere en timeopdeling, og den har sit eget grænsefelt: firstIncompleteHour. På samme site og samme tidspunkt svarede den 2026-10-11 kl. 10:00 amerikansk vesttid.

Det giver to ting. For det første er timeserien langt friskere end døgnserien: den har færdige tal helt frem til formiddagen den 11., mens døgnrapporten har markeret hele den 10. som ufuldstændig. For det andet kan man tælle efter. Timerækkerne for den 11. oktober stopper kl. 15 — der er 16 af 24 timer. Summen af dem er 3.333 visninger, altså præcis det tal døgnrapporten viser. Døgnet er ikke faldet. Det er kortere.

Så sammenlign kun det, der kan sammenlignes. I vinduet kl. 00–09, hvor alle tre dage ligger før grænsen og er endelige, ser det sådan ud:

• 9. oktober: 2.611 visninger, 101 klik
• 10. oktober: 2.743 visninger, 112 klik
• 11. oktober: 2.565 visninger, 139 klik

Den 11. ligger 1,8 % under den 9. på visninger og 37,6 % over på klik. Det er ikke et site, der er ramt af noget. Det er en helt almindelig søndag.

Et forbehold hører med: de seks timer mellem kl. 10 og 15 den 11. oktober er selv ufuldstændige, og de læser 38,6 % lavere end de samme timer dagen før. Det er netop derfor, de ikke skal regnes med. Grænsen er ikke en anbefaling, den er en betingelse.

De pæne tal lyver også

Det her er den del, der narrer flest. En ufuldstændig dag mangler ikke sine timer jævnt fordelt — den mangler de sidste. Og for et dansk site er de sidste timer i Googles døgn nattetimerne herhjemme, fordi rapporten følger lokal tid i Californien. Et dansk «døgn» i Search Console løber fra kl. 9 til kl. 9.

De timer har en anden karakter end resten af dagen. På den 9. og 10. oktober stod de otte manglende timer for 20,4 % og 17,4 % af døgnets visninger, med en klikrate på henholdsvis 2,69 % og 4,03 % — altså klart under dagens øvrige niveau.

Når de timer mangler, flytter to metrikker sig i den flatterende retning. Klikraten for den 11. oktober står til 5,91 % mod 3,98 % den 9. Den gennemsnitlige placering står til 9,5 mod 11,0. Visninger og klik ser ud til at styrtdykke, mens klikrate og placering ser ud til at forbedre sig markant. Begge dele er den samme artefakt, læst fra hver sin ende. Det er værd at huske, næste gang en rapport leverer en uventet fremgang i klikrate på de nyeste dage.

Hvorfor det rammer netop nu

Googles spamopdatering fra september 2026 startede 24. september og kørte efter Googles eget statusdashboard 13 dage og 16 timer, altså til omkring den 8. oktober. Den 11. oktober rapporterede Search Engine Roundtable, at effektivitetsrapporten var over 64 timer bagud, senere på dagen nede på 44. Google havde på det tidspunkt ikke udtalt sig.

De to ting falder sammen, og det er hele problemet. Den uge, hvor alle åbner Search Console for at se, om de blev ramt, er den uge, hvor de nyeste dage er tyndest. Man leder efter et fald og får serveret et.

Det skal siges, at tre dage ikke i sig selv er unormalt. Googles hjælpetekst siger, at indsamlede data «normalt bør være tilgængelige om 2-3 dage». Det her er ikke et nedbrud. Det er den dokumenterede normaltilstand, læst som om den var et resultat. Googles oversigt over datafejl viser i øvrigt, hvordan det ser ud, når noget faktisk går galt: en logningsfejl 13.–17. august 2026, og i perioden 13. maj 2025 til 27. april 2026 blev visninger ikke rapporteret korrekt. Ingen af delene står på listen lige nu.

Sådan læser jeg rapporten i stedet

Rækkefølgen betyder mere end værktøjet:

1. Hent grænsen først, tallene bagefter. Ét kald med dataState: all grupperet på dato giver firstIncompleteDate. Alt fra og med den dato er arbejdsmateriale, ikke måling.
2. Lad sammenligningen slutte dagen før grænsen. Uge mod uge er kun gyldigt, når begge uger ligger helt på den færdige side. Sætter man i stedet dataState: final, afskærer API'et selv de ufuldstændige dage.
3. Brug timeopdelingen til det friske. Vil man have et tidligt signal, ligger det i timeserien med firstIncompleteHour som grænse — og sammenlignet mod de samme klokkeslæt dagen før, aldrig mod et helt døgn.
4. Afvis forklaringen, før du accepterer den. Et fald, der forsvinder når man skærer de ufuldstændige dage væk, var aldrig et fald. Et fald, der stadig står efter tre dages modning, er værd at bruge tid på.

Brugerfladen giver ikke grænsen som tal. Den stiplede linje på grafen antyder den, men den fortæller ikke, hvor mange timer der mangler i den sidste søjle — og det er netop det tal, der afgør, om man ser på et problem eller på klokken.