Kort fortalt
Google opdaterede tre Indexing API-sider 16. oktober 2026, og kvotesiden oplyser nu konkrete tal: 200 publish-kald pr. projekt pr. dag, 180 getMetadata-kald pr. minut og 380 kald pr. minut på tværs af alle endpoints, med nulstilling ved midnat Pacific-tid. Væk er afsnittet om en startkvote til test og afsnittet om at ansøge om adgang. Tilbage står sætningen på siden Using the Indexing API, dateret samme dag: API'et må kun bruges til sider med JobPosting eller BroadcastEvent i et VideoObject. Kvoten tælles pr. URL, så en batch på 100 URL'er koster 100 kald — batching sparer requests, ikke kvote. Jeg målte 17. oktober fire af mine egne artikler, og ingen af dem er en af de to tilladte sidetyper: der gik mellem 3 timer 42 minutter og 6 timer 35 minutter fra publicering til Googles seneste crawl. Crawltiden er Googles eget tal fra URL Inspection API, og crawl er ikke det samme som indeksering.
Dokumentationsændringen 16. oktober 2026 giver dig ikke lov til at pinge Google om almindelige sider — den oplyser kvoten højt, mens adgangskravet står uændret. Google tog ansøgningsafsnittet og startkvoten ud af Indexing API's kvoteside, og den slags oprydning ser ud som en åbning. På nabosiden, med samme dato i bunden, står stadig at API'et kun må bruges til sider med JobPosting eller BroadcastEvent i et VideoObject.
Hvad der blev ændret 16. oktober
Googles ændringslog for søgedokumentationen har én linje den 16. oktober 2026: kvotesiden for Indexing API er opdateret, så den afspejler de nuværende kvotegrænser og processen, og en forældet formular er fjernet. Tre sider bærer datoen Last updated 2026-10-16 UTC: quickstart, Using the Indexing API og Quota and pricing.
Det, der forsvandt, var ifølge Search Engine Roundtables gennemgang tre ting: afsnittet om en startkvote til onboarding og test, afsnittet om at ansøge om adgang til brug med JobPosting og BroadcastEvent, og en passage i quickstart, der anbefalede API'et frem for sitemaps til kortlivede sider.
Det, der kom til, er tal. Kvotesiden oplyser nu 200 publish-kald pr. projekt pr. dag — og de 200 dækker både URL_UPDATED og URL_DELETED — 180 getMetadata-kald pr. minut pr. projekt og 380 kald pr. minut på tværs af alle endpoints. Kvoten nulstilles ved midnat Pacific-tid, og en ændret kvote kan være op til 24 timer om at virke. Prisen er nul.
Sætningen, der ikke blev rørt
På siden om at bruge API'et, med præcis samme dato i bunden, står adgangskravet uændret: API'et må kun bruges til at crawle sider med enten JobPosting eller BroadcastEvent indlejret i et VideoObject. Samme sætning står i quickstart. Det er to sidetyper, ikke to eksempler.
Og kvoten er strammere, end tallet 200 lyder. Kvoten tælles pr. URL, ikke pr. HTTP-request: samler du 100 URL'er i én batch, koster det 100 af dine 200. Googles spampolitik gælder for alt, der sendes gennem API'et, og dokumentationen nævner inddraget adgang som konsekvens ved misbrug — inklusive forsøg på at omgå kvoten.
Så hvis din interesse i ændringen var, at godkendelsesformularen er væk: formularen var aldrig det, der holdt dig ude. Kravet til sidetypen var, og det står der stadig.
Hvad en helt almindelig artikel koster i ventetid
Jeg kan ikke bruge API'et på mine egne artikler. Ingen af dem er en jobannonce eller et livestream-event. Så jeg målte, hvad den kanal, alle har, egentlig leverer: 17. oktober 2026 spurgte jeg Search Consoles URL Inspection API om de fire nyeste artikler på dette site og sammenholdt Googles lastCrawlTime med mit eget publiceringstidspunkt.
Alle fire stod som Submitted and indexed med verdict PASS. Spændet var 3 timer 42 minutter til 6 timer 35 minutter, og gennemsnittet 5 timer 10 minutter. Én detalje er værd at bemærke: to af artiklerne har nøjagtigt samme crawltid, 2026-10-15 09:29:11Z, ned til sekundet. Google hentede dem i samme gennemløb. Det er en kø, der tømmes i portioner, ikke en kanal, der reagerer på enkeltsider.
Forbeholdene hører med, og de er ikke små. Crawltiden er Googles eget tal, ikke min måling. Crawl er ikke indeksering — det sker et stykke efter. Og mine artikler er linket fra forsiden, som bliver crawlet ofte; et site uden den slags interne vej til nye sider vil se andre tal. Jeg har også kun fire datapunkter fra ét domæne.
De rapporter, der ikke stemmer med dokumentationen
Søgefolk, der testede efter ændringen, får ikke samme billede som dokumentationen. Search Engine Roundtable refererer to: Alexander Chukovski oplyser, at en ny service-konto stadig får en startkvote på 200, altså ingen reel ændring, og Nick LeRoy, at et kald gav HTTP 200 tilbage, men at getMetadata derefter svarede 404 på den samme URL.
Det er andenhånds og enkeltstående tests, så det er ikke et bevis for noget. Men retningen er den samme som i dokumentationen: siderne beskriver nu kvoten, ikke en adgangsproces — og der er intet i ændringen, der tyder på, at API'et har fået flere opgaver.
Rækkefølgen, der faktisk flytter noget
Hvis din side ikke er en af de to typer, er arbejdet det samme som før 16. oktober. Strukturen, jeg kører efter, har tre led og ét målepunkt — ingen af dem kræver et API-kald til indeksering.
Første led er, at sitemappet bliver regenereret ved hver udgivelse, uden at nogen husker det. Andet led er, at den nye side får et link fra en side, Google i forvejen henter ofte — på dette site er det forsiden, og det er den eneste grund til, at tallene ovenfor er timer og ikke dage. Tredje led er tålmodighed med det, der ligger efter crawlet: Google har selv sat tal på kæden fra crawl til servering, og crawlet er det billigste led i den.
Målepunktet er URL Inspection API'et, ikke et rank tracker-dashboard. Det svarer på coverageState, lastCrawlTime og hvilken canonical Google valgte — tre felter, der tilsammen siger, om problemet er opdagelse, hentning eller valg af URL. Det er tre forskellige problemer med tre forskellige løsninger, og ingen af dem løses af et notifikations-API.
Oprydning er ikke adgang
Det er en god ændring. En formular, der ikke længere betjener noget, hører ikke i dokumentationen, og konkrete tal er bedre end en vag startkvote. Men ændringen rører ikke det ene krav, der afgør, om API'et er til dig, og det krav stod uændret på nabosiden samme dag.
Den praktiske pointe er kedelig: hvis du ikke driver en jobportal eller sender livestreams, har du aldrig haft adgang til API'et, og du har heller ikke manglet det. Mine fire artikler blev hentet på under syv timer gennem den kanal, alle har. Det dyre ved indeksering ligger ikke i at få Google besked — det ligger i alt det, der kommer bagefter.