Core Web Vitals og Latens: Får hurtigere sider flere AI-citationer?

Core Web Vitals og Latens: Får hurtigere sider flere citationer fra kunstig intelligens?

Introduktion

En hurtig hjemmeside er lettere for folk at bruge. Den kan også være lettere for søgemaskiner og kunstig intelligens-systemer at hente, gengive og forstå.

Men en vigtig skelnen bliver ofte overset:

En hurtigere side kan forbedre crawling og tilgængeligheden af indhold. Det betyder ikke, at hastighed alene får et kunstig intelligens-system til at citere siden.

Pr. 2. august 2026 angiver Google, at stabile serverresponstider og lavere latens kan øge et websites crawlkapacitet. Google angiver også, at deres søgefunktioner med kunstig intelligens bruger de samme grundlæggende søge- og indekseringssystemer som traditionel søgning og ikke kræver særlig AI-markup eller hastighedsoptimeringer. (developers.google.com)

Denne artikel præsenterer en evidensbaseret testplan frem for at hævde, at et gennemført eksperiment allerede er udført. Ingen website, sidesæt, serverlog eller citeringsdata blev leveret. Målet er at definere en kontrolleret undersøgelse, der kan måle:

1. Hvorvidt lavere time to first byte øger crawlingfrekvensen.
2. Hvorvidt lavere Largest Contentful Paint forbedrer opdagelse eller indeksering.
3. Hvorvidt lavere Cumulative Layout Shift påvirker crawling eller hentning via kunstig intelligens.
4. Hvorvidt præstationsforbedringer øger den hastighed, hvormed sider synligt citeres af søgesystemer med kunstig intelligens.

Det korte svar

Lavere time to first byte kan forbedre crawling under de rette betingelser

Googles nuværende crawling-dokumentation siger, at dets crawlkapacitetsgrænse kan stige, når et website har stabile eller forbedrede responstider, inklusive time to first byte. Hvis responstiderne stiger, eller hvis et website returnerer for mange serverfejl eller rate-limit-svar, kan Google reducere crawlingen. (developers.google.com)

Hurtigere responstid garanterer dog ikke mere crawling. Crawling-efterspørgslen afhænger også af faktorer som:

• Hvor ofte websitet ændrer sig.
• Hvor populært websitet og dets sider er.
• Hvorvidt indholdet er brugbart og unikt.
• Hvor mange duplikerede eller lavværdi-URL'er der eksisterer.
• Hvorvidt opdaterede URL'er er inkluderet i sitemaps.

Dette betyder, at lavere latens bør have den stærkeste effekt på store, ofte opdaterede eller serverbegrænsede websites, ikke nødvendigvis på et lille website med begrænset nyt indhold.

Lavere Largest Contentful Paint kan hjælpe indirekte

Largest Contentful Paint måler, hvornår det primære synlige indhold vises for en bruger. Google angiver også, at både serverresponstid og den tid, der kræves for at gengive sider og indlejrede ressourcer, kan påvirke crawlingeffektiviteten. (developers.google.com)

Den sandsynlige sammenhæng er indirekte:

Lavere latens → hurtigere ressourcelevering → mere effektiv gengivelse eller hentning → færre crawl-timeouter eller ufuldstændige hentninger.

Effekten bør være stærkest, når vigtigt indhold afhænger af:

• Langsom JavaScript.
• Store billeder.
• Gengivelsesblokerende typografiark (stylesheets).
• Klient-side gengivelse.
• Tunge indlejrede ressourcer.

En hurtig Largest Contentful Paint-score i sig selv er sandsynligvis ikke et direkte signal for citation fra kunstig intelligens.

Lavere Cumulative Layout Shift har sandsynligvis ringe direkte crawling-effekt

Cumulative Layout Shift måler uventet bevægelse af synligt indhold. Det er primært en brugeroplevelsesmetrik. Almindelige årsager inkluderer billeder uden dimensioner, dynamisk indsatte annoncer, indlejret indhold og webfonter. (web.dev)

En crawler oplever ikke et layoutskift på samme måde som en menneskelig besøgende. Derfor er en direkte sammenhæng mellem lavere Cumulative Layout Shift og mere crawling usandsynlig.

Der kan være en indirekte sammenhæng, når et stort layoutskift skyldes:

• Indhold indsat sent via JavaScript.
• Vigtig tekst skjult, indtil scripts kører.
• Billeder eller indlejringer, der forsinker sideopbygning.
• Ustabile skabeloner, der producerer forskelligt indhold under forskellige hentninger.

I disse tilfælde er det reelle problem ikke layoutskift-scoren. Det reelle problem er, at siden kan være svær at behandle eller kan afsløre vigtigt indhold for sent.

Hurtigere sider citeres ikke automatisk oftere

Google siger, at sider, der vises i kunstig intelligens-funktioner, først skal indekseres og være kvalificerede til at vises i normale søgeresultater med et snippet. Google siger også, at der ikke er yderligere tekniske krav eller særlige AI-optimeringer for dens AI-oversigter og AI-tilstand. (developers.google.com)

OpenAI angiver ligeledes, at ChatGPT's søgerangeringer afhænger af flere faktorer, og at det er vigtigt at tillade dens søgecrawler, OAI-SearchBot, for inklusion. Det angives ikke, at lavere Core Web Vitals direkte øger sandsynligheden for citation. (help.openai.com)

Dette antyder en firetrinsmodel:

1. Opdagelse — Får systemet kendskab til, at URL'en eksisterer?
2. Hentning og behandling — Kan systemet hente og forstå siden?
3. Indeksering og hentning — Vælges siden til en specifik forespørgsel?
4. Citationsudvælgelse — Vises siden som en synlig kilde i svaret?

Sidehastighed kan påvirke de to første trin. Det er ikke etableret som en direkte årsag til det fjerde trin.

Nyere forskning viser også, at systemer med kunstig intelligens kan læse mange relevante sider, men kun citere nogle af dem. Med andre ord er hentning og citation separate begivenheder. (cambridge.org)

Hvad skal testes?

Undersøgelsen bør teste to forskellige spørgsmål frem for at behandle "kunstig intelligens-synlighed" som én metrik.

Spørgsmål 1: Påvirker ydeevne crawling?

Primære resultater:

• Tid fra udgivelse til første crawleranmodning.
• Antal crawleranmodninger pr. side pr. dag.
• Tid mellem succesfulde rekrawls.
• Antal sider crawlet pr. 1.000 publicerede sider.
• Procentdel af succesfulde hentninger.
• Frekvens af serverfejl og rate-limit-svar.
• Tid fra udgivelse til indeksering.

Spørgsmål 2: Påvirker ydeevne udvælgelse af citationer?

Primære resultater:

• Procentdel af testede forespørgsler, der producerer en synlig citation.
• Citeringsfrekvens pr. kvalificeret side.
• Citeringsandel inden for en forespørgsel.
• Procentdel af hentede sider, der bliver synlige citationer.
• Citeringsvedholdenhed over tid.
• Citeringsfrekvens pr. system med kunstig intelligens.

Disse resultater skal adskilles efter udbyder. En Google AI-oversigt, et ChatGPT-søgeresultat, et Microsoft Copilot-svar, et Perplexity-svar og et Claude-søgesvar kan bruge forskellige indekser, crawlere, rangeringssystemer og opdateringsplaner.

Eksperimentelt design

1. Opbyg et kontrolleret sidesæt

Brug et sidesæt, der er stort nok til at producere meningsfulde crawler- og citeringsdata.

Et praktisk startdesign ville inkludere:

• 240 til 800 sider.
• Mindst 20 sider pr. sideskabelon.
• Tre til fem indholdskategorier.
• En blanding af tidløse og regelmæssigt opdaterede sider.
• Et lige antal sider i hver behandlingsgruppe.

Hver side bør have:

• Lignende HTML-struktur.
• Lignende indholdslængde.
• Det samme publiceringssystem.
• Det samme interne linkmønster.
• De samme kanoniske regler.
• Den samme sitemap-behandling.
• De samme robots.txt-tilladelser.
• Et unikt, brugbart emne.

Opret ikke hundredvis af tynde eller næsten-duplikerede sider kun til eksperimentet. Googles retningslinjer advarer om, at duplikerede URL'er og URL'er af lav værdi kan spilde crawl-ressourcer og reducere et websites effektivitet. (developers.google.com)

Et matchet-par-design er nyttigt. For eksempel, par sider med lignende:

• Indholdslængde.
• Emneefterspørgsel.
• Opdateringsfrekvens.
• Antal interne links.
• Antal eksterne links.
• Historisk trafik.
• Søgerangeringsposition.

Placer derefter én side fra hvert par i kontrolgruppen og den anden i en behandlingsgruppe.

2. Brug et faktorielt behandlingsdesign

De primære præstationsbehandlinger bør testes uafhængigt og sammen.

Dette skaber et kontrolleret eksperiment for de tre ønskede optimeringer:

• HTTP/3.
• Edge caching via indholdsleveringsnetværk (CDN).
• Billedkomprimering.

Behandlingen af layoutstabilitet er nødvendig, fordi de tre første optimeringer ikke pålideligt isolerer Cumulative Layout Shift. Billedkomprimering kan sænke Largest Contentful Paint uden overhovedet at ændre layoutstabiliteten.

Hvorfor HTTP/3 kræver sin egen måling

HTTP/3 bruger QUIC-transportprotokollen og tilbyder uafhængige streams, som kan undgå head-of-line-blokering på transportniveau, der findes i HTTP/2 over TCP. Dets fordele afhænger af, om klienten eller crawleren faktisk forhandler HTTP/3. (rfc-editor.org)

Registrer derfor den forhandlede protokol for hver anmodning:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

Antag ikke, at aktivering af HTTP/3 betyder, at enhver crawler bruger det. Hvis Googlebot, OAI-SearchBot eller en anden crawler fortsætter med at bruge HTTP/2, kan HTTP/3 ikke påvirke denne crawlers anmodninger.

Hvorfor edge caching bør testes omhyggeligt

Et Content Delivery Network (CDN) kan reducere time to first byte ved at servere indhold tættere på anmoderen. Det kan også reducere antallet af anmodninger, der når originserveren. (web.dev)

Test mindst tre cachetilstande:

1. Kold cache — Edgen skal kontakte origin.
2. Varm cache — Edgen serverer siden uden at kontakte origin.
3. Revalideret cache — Edgen eller crawleren bruger en ETag- eller Last-Modified-værdi og modtager et 304 Not Modified-svar.

Google anbefaler specifikt effektiv HTTP caching og understøtter brugen af 304 Not Modified-svar for at reducere unødvendig behandling og båndbredde. (developers.google.com)

Tillad ikke caching at servere forældet eller forkert indhold til crawlere. Registrer:

• Cache hit eller miss.
• Cachealder.
• Edge-lokation.
• Origin-responstid.
• Indholdsversion.
• Statuskode.
• Valideringsheadere.

Hvorfor billedkomprimering bør bindes til Largest Contentful Paint

WebP og AVIF giver generelt bedre komprimering end ældre billedformater. Mindre billeder kan reducere overførselstid og kan forbedre Largest Contentful Paint, når billedet er Largest Contentful Paint-elementet. (web.dev)

Testen bør anvende:

• De samme billeddimensioner.
• Det samme visuelle kvalitetsmål.
• Responsive srcset-billeder.
• Et moderne format med en passende fallback.
• Eksplicitte width- og height-værdier.
• Ingen lazy loading for Largest Contentful Paint-billedet.
• En billed-URL synlig i den oprindelige HTML.

Billedkomprimering alene forbedrer muligvis ikke Largest Contentful Paint, hvis den virkelige forsinkelse stammer fra JavaScript eller sen ressourceopdagelse. Googles præstationsvejledning bemærker, at reduktion af billeddownloadtid simpelthen kan flytte forsinkelsen til en anden del af siden, hvis Largest Contentful Paint-elementet afsløres sent. (web.dev)

3. Kør testen længe nok

En kort test kan overse effekterne af crawl-planlægning og indeksopdatering.

Et praktisk design er:

• To ugers basislinjemåling.
• Seks til tolv ugers behandlingsmåling.
• En afsluttende reversal- eller crossover-periode, hvis muligt.

Ved en crossover-test skiftes behandlingerne mellem matchede sidegrupper. Hvis præstationseffekten forsvinder, når behandlingen fjernes, er resultatet stærkere end en simpel før-og-efter-sammenligning.

Core Web Vitals feltdata bør evalueres over en passende periode. Chrome User Experience Report bruger en rullende 28-dages aggregering, så den er ikke designet til at vise øjeblikkelige ændringer efter en udrulning. (developer.chrome.com)

4. Mål den komplette crawler-population

Behandl ikke al automatiseret trafik som én gruppe.

Adskil som minimum:

Søge-crawlere

• Googlebot.
• Bingbot.

Søge-crawlere med kunstig intelligens

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Brugeranmodede fetchere

• Perplexity-User.
• Claude-User.
• ChatGPT bruger-fetchere, hvor identificerbare.

Trænings-crawlere

• GPTBot.
• ClaudeBot.
• Google-Extended kontroller.

Trænings-crawlere bør ikke bruges som en proxy for citationer fra søgninger med kunstig intelligens. Anthropic, OpenAI og Google skelner mellem crawlere, der bruges til træning, søgning eller brugeranmodet hentning. Google angiver også, at Google-Extended ikke påvirker inklusion eller rangering i Google Søgning. (help.openai.com)

Perplexity skelner ligeledes mellem PerplexityBot, der understøtter søgeindeksering, og Perplexity-User, der kan hente en side som svar på en brugeranmodning. (docs.perplexity.ai)

Verificer crawler-identitet ved hjælp af publicerede IP-intervaller eller omvendt DNS, hvor udbyderen understøtter det. User-agent-strenge kan kopieres af uafhængige crawlere. Google advarer specifikt om, at Googlebot user-agent-strenge kan spoofes. (developers.google.com)

Metrikker der skal indsamles

Ydeevnemetrikker

Indsaml både laboratorie- og real-user data:

• Time to first byte.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Total sidevægt.
• Indledende HTML-størrelse.
• Billedoverførselsstørrelse.
• Antal anmodninger.
• Tid brugt på serverbehandling.
• Tid brugt på at vente på Largest Contentful Paint-ressourcen.
• HTTP-protokol.
• Cachestatus.

Google anbefaler et omtrentligt time to first byte-mål på 800 millisekunder eller mindre, men time to first byte er ikke i sig selv en Core Web Vital. (web.dev)

De nuværende "gode" tærskler for Core Web Vitals ved 75. percentil er:

• Largest Contentful Paint: 2,5 sekunder eller mindre.
• Cumulative Layout Shift: 0,1 eller mindre.
• Interaction to Next Paint: 200 millisekunder eller mindre. (web.dev)

Crawl-metrikker

For hver verificeret crawleranmodning registreres:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

Beregn:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

Citeringsmetrikker for kunstig intelligens

Brug et fast sæt forespørgsler på tværs af hver platform. Forespørgselssættet bør inkludere:

• Direkte faktuelle spørgsmål.
• Sammenligningsspørgsmål.
• "Bedste" eller anbefalingsspørgsmål.
• Friskhedsfølsomme spørgsmål.
• Spørgsmål, hvor den testede side er det stærkeste svar.
• Spørgsmål, hvor den testede side er relevant, men ikke dominerende.

For hver forespørgsel registreres:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

Gentag forespørgsler, da svar fra kunstig intelligens kan variere. Brug en fast tidsplan, f.eks. tre gange om ugen, og registrer ændringer i motoren eller modellen.

Microsoft Bing Webmaster Tools tilbyder nu en AI-præstationsrapport, der viser citerede sider, grundlæggende forespørgsler og citeringsudviklinger på tværs af understøttede Microsoft AI-oplevelser. Microsoft advarer om, at dataene er aggregerede, samplede og observationelle; det kan ikke bevise, at en bestemt sideændring forårsagede en citeringsændring. (bing.com)

Google begyndte også at udrulle dedikerede rapporter om generativ AI-ydeevne i Search Console i juni 2026. Rapporterne var oprindeligt kun tilgængelige for en delmængde af websites, så adgangen kan variere. (developers.google.com)

Statistisk analyse

Crawlingfrekvens

Brug en mixed-effects tællemodel, f.eks. en negativ binomial model:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

Side- og crawler-effekterne er vigtige, fordi nogle sider naturligt får mere opmærksomhed end andre, og forskellige crawlere har forskellige tidsplaner.

Opdagelse og indeksering

Brug overlevelsesanalyse for:

• Tid fra udgivelse til første hentning.
• Tid fra udgivelse til første indeks.
• Tid fra opdatering til recrawl.

Nøglens resultat er ikke blot, om en side til sidst blev crawlet. Det er, om behandlingen reducerede den tid, det tog for siden at blive fundet og behandlet.

Udvælgelse af citationer fra kunstig intelligens

Brug en hierarkisk logistisk model:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

Kør to separate modeller:

1. Hentningsmodel — Blev siden hentet eller vist som en kandidat?
2. Citationsmodel — Hvis hentet, blev siden da synligt citeret?

Denne skelnen er afgørende. En præstationsforbedring, der øger crawling, men ikke hentning, er ikke en AI-citationseffekt. En præstationsforbedring, der øger hentning, men ikke citationer, antyder, at siden overvejes, men taber under kildeudvælgelsen.

Forventede resultater

Dette er arbejdshypoteser, ikke hævdede eksperimentelle resultater.

Hypotese 1: Time to first byte vil have den tydeligste crawl-effekt

Forvent en positiv sammenhæng mellem lavere time to first byte og crawl-kapacitet, når:

• Websitet har mange sider.
• Sider ændrer sig ofte.
• Originserveren er langsom eller overbelastet.
• Websitet returnerer 5xx- eller 429-svar.
• Crawleren bruger betydelig tid på at vente på svar.

Forvent ringe målbar effekt på et lille website med lav crawl-efterspørgsel.

Hypotese 2: Largest Contentful Paint vil have betydning via gengivelse og ressourcelevering

Forvent, at lavere Largest Contentful Paint vil hjælpe, når:

• Siden afhænger af browsergengivelse.
• Vigtigt indhold er bag JavaScript.
• Store billeder eller stylesheets er nødvendige for indeksering.
• Crawleren henter mange sideressourcer.
• Den langsommere behandling producerer timeouter eller ufuldstændig gengivelse.

Forvent en svag sammenhæng, når sidens vigtige tekst allerede er til stede i den indledende HTML.

Hypotese 3: Cumulative Layout Shift vil have ringe direkte effekt

Forvent ingen meningsfuld direkte sammenhæng mellem Cumulative Layout Shift og crawlfrekvens eller citeringsfrekvens efter kontrol for sidestruktur og JavaScript-adfærd.

Hvis Cumulative Layout Shift ser ud til at forudsige citationer, undersøg da, om det fungerer som en proxy for:

• Klient-side gengivelse.
• Sen indholdsindsættelse.
• Ustabile annoncer.
• Skjult eller forsinket tekst.
• Dårligt struktureret HTML.

Hypotese 4: Hastighed alene vil ikke producere flere citationer fra kunstig intelligens

De stærkeste forudsigere for udvælgelse af citationer vil sandsynligvis fortsat være:

• Relevans for forespørgslen.
• Indholdskvalitet.
• Klare svar.
• Friskhed.
• Autoritet og tillid.
• Kvalifikation til søgeindeks.
• Hentningsrang.
• Hvorvidt siden direkte understøtter den fremsatte påstand.

Googles vejledning understreger brugbart, pålideligt og menneskecentreret indhold og siger, at søgefunktioner med kunstig intelligens bygger på de eksisterende søge- og indekseringssystemer. (developers.google.com)

Et præstationsbudget tunet for hentning via kunstig intelligens

Følgende er et foreslået driftsbudget. Det er ikke en publiceret rangeringsformel for kunstig intelligens.

Googles nuværende dokumentation siger, at Googlebot henter de første 2 megabyte af en understøttet fil og henter eksterne scripts og stylesheets separat. Den anbefaler også at placere vigtige metadata og strukturerede data tidligt i HTML'en. (developers.google.com)

Implementeringsanbefalinger

HTTP/3

Brug HTTP/3, når det understøttes af hostingudbyderen og content delivery network.

Mål:

• HTTP/3 forhandlingsfrekvens.
• HTTP/2 fallback-frekvens.
• Forbindelsesoprettelsestid.
• Time to first byte.
• Ydeevne efter geografisk region.
• Ydeevne efter crawler.

Behandl ikke HTTP/3 som en garanteret søge- eller AI-optimering. Det er en transportforbedring, der kun kan hjælpe klienter, der bruger den.

Content Delivery Network Edge Caching

For offentlige, ikke-personaliserede sider:

• Indstil klare Cache-Control-regler.
• Brug langvarig caching for versionerede statiske aktiver.
• Brug kort, men nyttig caching for ofte opdateret HTML.
• Undgå cachefragmentering fra unødvendige forespørgselsparametre.
• Bevar kanoniske URL'er.
• Understøt ETag og Last-Modified.
• Test kolde, varme og revaliderede cachetilstande.
• Bekræft, at crawleranmodninger modtager det samme vigtige indhold som menneskelige anmodninger.

Et content delivery network bør reducere latens uden at skabe forældede, inkonsistente eller bot-specifikke sideversioner.

Billedkomprimering

For billeder:

• Brug AVIF eller WebP, når den visuelle kvalitet er acceptabel.
• Tilbyd responsive billedstørrelser.
• Server ikke et desktop-størrelse billede til en lille mobilskærm.
• Lazy-load ikke Largest Contentful Paint-billedet.
• Inkluder billeddimensioner.
• Placer Largest Contentful Paint-billedet i den indledende HTML.
• Brug fetchpriority="high" kun når det er passende.
• Hold vigtige forklaringer i tekst i stedet for kun at indlejre dem i billeder.

Billedkomprimering er mest værdifuld, når billedet er Largest Contentful Paint-elementet. Det vil ikke reparere en side, hvis primære forsinkelse skyldes servergengivelse eller JavaScript-udførelse. (web.dev)

Layoutstabilitet

For at sænke Cumulative Layout Shift:

• Indstil bredde- og højdeattributter på billeder.
• Reserver plads til annoncer.
• Reserver plads til indlejret video og socialt indhold.
• Undgå at indsætte bannere over eksisterende tekst.
• Brug stabile fontindlæsningsstrategier.
• Undgå at erstatte store blokke af servergengivet indhold efter sideindlæsning.

Disse ændringer forbedrer brugeroplevelsen, selvom de ikke har nogen målbar effekt på crawling eller citationer. (web.dev)

Værktøjer og overvågning

Ydeevneværktøjer

Brug:

• Chrome User Experience Report for Core Web Vitals fra rigtige brugere.
• Chrome User Experience Report API (application programming interface) for automatiseret feltdataopsamling.
• PageSpeed Insights for laboratorieaudits og feltdata.
• Lighthouse for gentagelige laboratorietests.
• Lighthouse Continuous Integration for pull-request præstationsbudgetter.
• WebPageTest for multi-lokationstests, cachetilstande og protokol-sammenligninger.
• Chrome DevTools for Largest Contentful Paint og layoutskift-fejlfinding.
• web-vitals JavaScript-biblioteket for real-user overvågning.

Chrome User Experience Report API leverer aggregerede feltdata på side- og origins-niveau, herunder Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint og eksperimentel time to first byte. (developer.chrome.com)

Lighthouse Continuous Integration kan køre præstationskontroller ved hver kodeændring og fejle builds, når budgetter overskrides. (github.com)

Crawler-overvågning

Brug serverlogs, edge-logs og et lille sæt syntetiske prober.

Eksempel på probe:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

Kør den samme test med:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• En normal browser user-agent.

Testen bør verificere:

• Statuskode.
• Robots-tilladelse.
• Svarheadere.
• HTML-indhold.
• HTTP-version.
• Cachetilstand.
• Responstid.
• Hvorvidt vigtig tekst er til stede uden JavaScript.

Søge- og indekseringsovervågning

Brug:

• Google Search Console crawl-statistikker.
• Google Search Console sideindekseringsrapporter.
• Google Search Console URL-inspektion.
• Google Search Console sitemap-data.
• Google Search Console generativ kunstig intelligens-rapporter, når tilgængelige.
• Bing Webmaster Tools crawl-anmodninger og indekserede sider.
• Bing Webmaster Tools AI-ydeevne.
• Daglige sitemap- og lastmod-tjek.

Search Console API kan hente ydeevnedata efter side, forespørgsel, dato, enhed og søgeudseende, underlagt dets datagrænser. (developers.google.com)

Citerings-overvågning

Opret et citeringspanel indeholdende 50 til 200 stabile forespørgsler pr. emne. Kør panelet efter en fast tidsplan og registrer:

• Hvorvidt platformen søgte.
• Hvilke kilder der optrådte.
• Hvorvidt den testede URL blev citeret.
• Citeringsrækkefølge.
• Svarets dato og tid.
• Hvorvidt siden ændrede sig.
• Hvorvidt modellen eller søgeoplevelsen ændrede sig.

Sammenlign ikke citeringsantal fra forskellige systemer, som om de var ækvivalente. Microsoft angiver, at citeringsaktivitet ikke er en rangeringsscore, autoritetsscore, trafikmåling eller kvalitetsscore. (bing.com)

Advarselsregler

Opret alarmer for:

• Time to first byte stiger med mere end 25 procent.
• Largest Contentful Paint bevæger sig over 2,5 sekunder ved 75. percentil.
• Cumulative Layout Shift bevæger sig over 0,1.
• En vedvarende stigning i 5xx- eller 429-svar.
• Et fald i crawlerens succesrate.
• En robots.txt-ændring.
• En sitemap-fejl.
• Et pludseligt fald i indekserede sider.
• Et pludseligt fald i AI-citationer på tværs af flere platforme.
• En ændring i citeringsvolumen, der kun påvirker én platform.

Et fald i citationer, der påvirker én platform, kan skyldes en model-, indeks-, forespørgsels- eller produktændring snarere end et problem med sideydeevnen. Microsoft advarer udtrykkeligt om, at citationstendenser er observationelle og kan ændre sig på grund af indholdsopdateringer, brugerbehov og system- eller modelændringer. (bing.com)

Endelig konklusion

Den mest forsvarlige konklusion er:

Hurtigere sider kan forbedre crawl-effektiviteten, især når serverlatens, ressourcestørrelse, fejl eller gengivelsesforsinkelser er begrænsende faktorer. Men der er i øjeblikket ingen stærke beviser for, at lavere Core Web Vitals direkte får AI-systemer til at vælge en side som en citation.

Den forventede kausale kæde er:

text Lower latency → better server capacity → fewer failed or delayed fetches → faster discovery and processing → improved chance of being indexed and retrieved → possible increase in citations

Det sidste skridt forbliver usikkert, fordi udvælgelse af citationer afhænger af relevans, kvalitet, friskhed, autoritet, forespørgselsintention, hentningsrang og adfærden for hvert system med kunstig intelligens.

For de fleste websites er den korrekte præstationsstrategi derfor ikke at "optimere for AI-citationer" isoleret. Den er:

1. Hold vigtigt indhold tilgængeligt i den indledende HTML.
2. Hold time to first byte stabil.
3. Brug edge caching for offentligt indhold.
4. Komprimer og prioriter vigtige billeder.
5. Forhindre layoutskift.
6. Returner pålidelige statuskoder.
7. Hold sitemaps og interne links opdaterede.
8. Tillad de korrekte søge-crawlere.
9. Mål crawling, indeksering, hentning og citation som separate stadier.

Denne tilgang producerer et hurtigere website for mennesker, et sundere website for søge-crawlere og et testbart grundlag for at forstå AI-synlighed.