Core Web Vitals og Latency: Får raskere sider flere AI-siteringer?

Core Web Vitals og Latency: Får raskere sider flere kunstig intelligens-siteringer?

Introduksjon

En rask nettside er enklere for folk å bruke. Den kan også være enklere for søkemotorer og kunstig intelligens-systemer å hente, gjengi og forstå.

Men en viktig forskjell blir ofte oversett:

En raskere side kan forbedre indeksering og tilgjengelighet av innhold. Det betyr ikke at hastighet alene fører til at et kunstig intelligens-system siterer siden.

Per 2. august 2026 uttaler Google at stabile serverresponstider og lavere latenstid kan øke et nettsteds indekseringskapasitet. Google opplyser også at deres AI-søkeegenskaper bruker de samme grunnleggende søke- og indekseringssystemene som tradisjonelle søk og ikke krever spesiell AI-oppmerking eller hastighetsoptimalisering. (developers.google.com)

Denne artikkelen presenterer en evidensbasert testplan snarere enn å hevde at et fullført eksperiment allerede er utført. Ingen nettsted, sideoppsett, serverlogg eller siteringsdatasett ble levert. Målet er å definere en kontrollert studie som kan måle:

1. Hvorvidt lavere time to first byte øker indekseringsfrekvensen.
2. Hvorvidt lavere Largest Contentful Paint forbedrer oppdagelse eller indeksering.
3. Hvorvidt lavere Cumulative Layout Shift påvirker indeksering eller henting av kunstig intelligens.
4. Hvorvidt ytelsesforbedringer øker frekvensen som sider blir synlig sitert av kunstig intelligens-søkesystemer.

Det korte svaret

Lavere time to first byte kan forbedre indeksering under de rette forholdene

Googles nåværende dokumentasjon om indeksering sier at kapasitetsgrensen for indeksering kan øke når et nettsted har stabile eller forbedrede responstider, inkludert 'time to first byte'. Hvis responstidene øker, eller hvis et nettsted returnerer for mange serverfeil eller 'rate-limit'-svar, kan Google redusere indekseringen. (developers.google.com)

Imidlertid garanterer ikke raskere responstid mer indeksering. Indekseringsbehov avhenger også av faktorer som:

• Hvor ofte nettstedet endres.
• Hvor populært nettstedet og dets sider er.
• Hvorvidt innholdet er nyttig og unikt.
• Hvor mange dupliserte eller lavverdi-URL-er som eksisterer.
• Hvorvidt oppdaterte URL-er er inkludert i sitemap-filer.

Dette betyr at lavere latenstid bør ha den sterkeste effekten på store, ofte oppdaterte, eller server-begrensede nettsteder, ikke nødvendigvis på et lite nettsted med begrenset nytt innhold.

Lavere Largest Contentful Paint kan hjelpe indirekte

Largest Contentful Paint måler når hovedinnholdet blir synlig for en bruker. Google uttaler også at både serverresponstid og tiden det tar å gjengi sider og innebygde ressurser kan påvirke indekseringseffektiviteten. (developers.google.com)

Den sannsynlige sammenhengen er indirekte:

Lavere latenstid → raskere ressurslevering → mer effektiv gjengivelse eller henting → færre indekserings-timeouter eller ufullstendige hentinger.

Effekten bør være sterkest når viktig innhold avhenger av:

• Treg JavaScript.
• Store bilder.
• Gjengivelsesblokkerende stilark.
• Klient-side gjengivelse.
• Tunge innebygde ressurser.

En rask Largest Contentful Paint-score i seg selv er sannsynligvis ikke et direkte siteringssignal fra kunstig intelligens.

Lavere Cumulative Layout Shift har sannsynligvis liten direkte indekseringseffekt

Cumulative Layout Shift måler uventet bevegelse av synlig innhold. Det er primært en brukergrensesnittopplevelse-metrikk. Vanlige årsaker inkluderer bilder uten dimensjoner, dynamisk innsatte annonser, innebygd innhold og webfonter. (web.dev)

En søkerobot opplever ikke et layoutskift på samme måte som en menneskelig besøkende. Derfor er en direkte sammenheng mellom lavere Cumulative Layout Shift og mer indeksering usannsynlig.

Det kan være en indirekte sammenheng når et høyt layoutskift skyldes:

• Innhold satt inn sent av JavaScript.
• Viktig tekst skjult til skript kjører.
• Bilder eller innebygde elementer som forsinker sidekonstruksjonen.
• Ustabil maler som produserer forskjellig innhold under forskjellige hentinger.

I slike tilfeller er det virkelige problemet ikke layoutskift-scoren. Det virkelige problemet er at siden kan være vanskelig å behandle eller kan avsløre viktig innhold for sent.

Raskere sider blir ikke automatisk sitert oftere

Google sier at sider som vises i kunstig intelligens-funksjoner først må indekseres og være kvalifisert til å vises i normale søkeresultater med et utdrag. Google sier også at det ikke er noen ytterligere tekniske krav eller spesielle AI-optimaliseringer for deres AI-oversikter og AI-modus. (developers.google.com)

OpenAI uttaler tilsvarende at ChatGPTs søkerangeringer avhenger av flere faktorer, og at det er viktig å tillate søkeroboten, OAI-SearchBot, for inkludering. De uttaler ikke at lavere Core Web Vitals direkte øker siteringssannsynligheten. (help.openai.com)

Dette antyder en firetrinnsmodell:

1. Oppdagelse — Finner systemet ut at URL-en eksisterer?
2. Henting og behandling — Kan systemet hente og forstå siden?
3. Indeksering og gjenfinning — Velges siden for en bestemt søkeforespørsel?
4. Siteringsvalg — Vises siden som en synlig kilde i svaret?

Sidehastighet kan påvirke de to første trinnene. Det er ikke etablert som en direkte årsak til det fjerde trinnet.

Nyere forskning viser også at kunstig intelligens-systemer kan lese mange relevante sider, men sitere bare noen av dem. Med andre ord, gjenfinning og sitering er separate hendelser. (cambridge.org)

Hva bør testes?

Studien bør teste to forskjellige spørsmål i stedet for å behandle "AI-synlighet" som én metrikk.

Spørsmål 1: Påvirker ytelse indeksering?

Primære resultater:

• Tid fra publisering til første søkerobotanmodning.
• Antall søkerobotanmodninger per side per dag.
• Tid mellom vellykkede re-indekseringer.
• Antall sider indeksert per 1000 publiserte sider.
• Prosentandel av vellykkede hentinger.
• Frekvens av serverfeil og 'rate-limit'-svar.
• Tid fra publisering til indeksering.

Spørsmål 2: Påvirker ytelse siteringsvalg?

Primære resultater:

• Prosentandel av testede søkeforespørsler som produserer en synlig sitering.
• Siteringsrate per kvalifisert side.
• Siteringsandel innenfor en søkeforespørsel.
• Prosentandel av hentede sider som blir synlige siteringer.
• Siteringsvarighet over tid.
• Siteringsrate per AI-system.

Disse resultatene må skilles etter leverandør. En Google AI-oversikt, ChatGPT søkeresultat, Microsoft Copilot-svar, Perplexity-svar og Claude-søkerespons kan bruke forskjellige indekser, søkeroboter, rangeringssystemer og oppdateringsplaner.

Eksperimentelt design

1. Bygg et kontrollert sideoppsett

Bruk et sideoppsett som er stort nok til å produsere meningsfulle data om indeksering og sitering.

Et praktisk startdesign vil inkludere:

• 240 til 800 sider.
• Minst 20 sider per sidemal.
• Tre til fem innholdskategorier.
• En blanding av "evergreen" og regelmessig oppdaterte sider.
• Like mange sider i hver behandlingsgruppe.

Hver side bør ha:

• Lignende HTML-struktur.
• Lignende innholdslengde.
• Samme publiseringssystem.
• Samme interne lenkemønster.
• Samme kanoniske regler.
• Samme sitemap-behandling.
• Samme robots.txt-tillatelser.
• Et unikt, nyttig tema.

Ikke lag hundrevis av tynne eller nesten-dupliserte sider kun for eksperimentet. Googles veiledning advarer om at dupliserte og lavverdi-URL-er kan kaste bort indekseringsressurser og redusere nettstedets effektivitet. (developers.google.com)

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

• Innholdslengde.
• Emnets etterspørsel.
• Oppdateringsfrekvens.
• Antall interne lenker.
• Antall eksterne lenker.
• Historisk trafikk.
• Søkerangeringsposisjon.

Plasser deretter én side fra hvert par i kontrollgruppen og den andre i en behandlingsgruppe.

2. Bruk et faktoriell behandlingsdesign

Hovedytelsesbehandlingene bør testes uavhengig og sammen.

Dette skaper et kontrollert eksperiment for de tre forespurte optimaliseringene:

• HTTP/3.
• Edge-cachelagring for innholdsleveringsnettverk (CDN).
• Bildekomprimering.

Layoutstabilitetsbehandlingen er nødvendig fordi de tre første optimaliseringene ikke pålitelig isolerer Cumulative Layout Shift. Bildekomprimering kan redusere Largest Contentful Paint uten å endre layoutstabiliteten i det hele tatt.

Hvorfor HTTP/3 trenger sin egen måling

HTTP/3 bruker QUIC-transportprotokollen og gir uavhengige strømmer, noe som kan unngå transportnivå 'head-of-line blocking' funnet i HTTP/2 over TCP. Fordelene avhenger av om klienten eller søkeroboten faktisk forhandler HTTP/3. (rfc-editor.org)

Registrer derfor den forhandlede protokollen for hver forespørsel:

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

Ikke anta at aktivering av HTTP/3 betyr at hver søkerobot bruker det. Hvis Googlebot, OAI-SearchBot eller en annen søkerobot fortsetter å bruke HTTP/2, kan HTTP/3 ikke påvirke den søkerobotens forespørsler.

Hvorfor kant-cachelagring bør testes nøye

Et innholdsleveringsnettverk (CDN) kan redusere 'time to first byte' ved å levere innhold nærmere den som ber om det. Det kan også redusere antall forespørsler som når origin-serveren. (web.dev)

Test minst tre cache-tilstander:

1. Kald cache — Kanten må kontakte origin.
2. Varm cache — Kanten leverer siden uten å kontakte origin.
3. Revalidert cache — Kanten eller søkeroboten bruker en ETag eller Last-Modified-verdi og mottar et 304 Not Modified-svar.

Google anbefaler spesifikt effektiv HTTP-cachelagring og støtter bruken av 304 Not Modified-svar for å redusere unødvendig behandling og båndbredde. (developers.google.com)

Ikke la cachelagring servere utdatert eller feil innhold til søkeroboter. Registrer:

• Cache-treff eller -bom.
• Cache-alder.
• Kant-lokasjon.
• Origin-responstid.
• Innholdsversjon.
• Statuskode.
• Valideringsheadere.

Hvorfor bildekomprimering bør knyttes til Largest Contentful Paint

WebP og AVIF gir generelt bedre komprimering enn eldre bildeformater. Mindre bilder kan redusere overføringstid og kan forbedre Largest Contentful Paint når bildet er Largest Contentful Paint-elementet. (web.dev)

Testen bør bruke:

• Samme bildedimensjoner.
• Samme visuelle kvalitetsmål.
• Responsive srcset-bilder.
• Et moderne format med en passende fallback.
• Explisitte width- og height-verdier.
• Ingen "lazy loading" for Largest Contentful Paint-bildet.
• En bilde-URL synlig i den opprinnelige HTML-en.

Bildekomprimering alene forbedrer kanskje ikke Largest Contentful Paint hvis den virkelige forsinkelsen kommer fra JavaScript eller sen ressursgjenkjenning. Googles ytelsesveiledning merker seg at reduksjon av nedlastingstid for bilder ganske enkelt kan flytte forsinkelsen til en annen del av siden hvis Largest Contentful Paint-elementet avsløres sent. (web.dev)

3. Kjør testen lenge nok

En kort test kan gå glipp av effekten av indekseringsplanlegging og indeksfriskhet.

Et praktisk design er:

• To uker med grunnlinjemåling.
• Seks til tolv uker med behandlingsmåling.
• En endelig reversering eller crossover-periode hvis mulig.

For en crossover-test, bytt behandlinger mellom matchede sidegrupper. Hvis ytelseseffekten forsvinner når behandlingen fjernes, er resultatet sterkere enn en enkel før-og-etter-sammenligning.

Core Web Vitals feltdata bør evalueres over en passende periode. Chrome User Experience Report bruker en rullende 28-dagers aggregering, så den er ikke designet for å vise øyeblikkelige endringer etter en utrulling. (developer.chrome.com)

4. Mål hele søkerobotpopulasjonen

Ikke behandle all automatisert trafikk som én gruppe.

Minimum, separer:

Søkeroboter

• Googlebot.
• Bingbot.

Søkeroboter for kunstig intelligens

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

Bruker-forespurt henting

• Perplexity-User.
• Claude-User.
• ChatGPT bruker-henting der identifiserbart.

Treningsroboter

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

Treningsroboter bør ikke brukes som en proxy for siteringer fra kunstig intelligens-søk. Anthropic, OpenAI og Google skiller mellom søkeroboter som brukes til trening, søk eller bruker-forespurt henting. Google uttaler også at Google-Extended ikke påvirker inkludering eller rangering i Google Søk. (help.openai.com)

Perplexity skiller tilsvarende mellom PerplexityBot, som støtter søkeindeksering, og Perplexity-User, som kan hente en side som svar på en brukerforespørsel. (docs.perplexity.ai)

Verifiser søkerobotens identitet ved å bruke publiserte IP-områder eller omvendt DNS der leverandøren støtter det. User-agent-strenger kan kopieres av urelaterte søkeroboter. Google advarer spesifikt om at Googlebot user-agent-strenger kan forfalskes. (developers.google.com)

Metrikker som skal samles inn

Ytelsesmetrikker

Samle inn både laboratorie- og reelle brukerdata:

• Time to first byte.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Total sidevekt.
• Initial HTML-størrelse.
• Bildeoverføringsstørrelse.
• Antall forespørsler.
• Tid brukt i serverbehandling.
• Tid brukt på å vente på Largest Contentful Paint-ressursen.
• HTTP-protokoll.
• Cache-status.

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

De nåværende Core Web Vitals "gode" terskelverdiene ved 75. persentilen 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)

Indekseringsmetrikker

For hver verifiserte søkerobotanmodning, registrer:

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

Siteringsmetrikker for kunstig intelligens

Bruk et fast sett med søkeforespørsler på tvers av hver plattform. Søkesettet bør inkludere:

• Direkte faktaspørsmål.
• Sammenligningsspørsmål.
• "Beste" eller anbefalingsspørsmål.
• Ferskhetsfølsomme spørsmål.
• Spørsmål der den testede siden er det sterkeste svaret.
• Spørsmål der den testede siden er relevant, men ikke dominerende.

For hver søkeforespørsel, registrer:

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

Gjenta spørsmål fordi kunstig intelligens-svar kan variere. Bruk en fast tidsplan, for eksempel tre ganger i uken, og registrer endringer i motor eller modell.

Microsoft Bing Webmaster Tools tilbyr nå en 'Artificial Intelligence Performance'-rapport som viser siterte sider, grunnleggende spørsmål og siteringstrender på tvers av støttede Microsoft AI-opplevelser. Microsoft advarer om at dataene er aggregerte, utvalgte og observasjonsbaserte; det kan ikke bevise at en bestemt sideendring forårsaket en siteringsendring. (bing.com)

Google begynte også å rulle ut dedikerte generative AI-ytelsesrapporter i Search Console i juni 2026. Rapportene var i utgangspunktet kun tilgjengelige for et utvalg nettsteder, så tilgangen kan variere. (developers.google.com)

Statistisk analyse

Indekseringsfrekvens

Bruk en 'mixed-effects count model', for eksempel en negativ binomial modell:

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

Side- og søkeroboteffektene er viktige fordi noen sider naturlig mottar mer oppmerksomhet enn andre, og forskjellige søkeroboter har forskjellige planer.

Oppdagelse og indeksering

Bruk overlevelsesanalyse for:

• Tid fra publisering til første henting.
• Tid fra publisering til første indeks.
• Tid fra oppdatering til re-indeksering.

Hovedresultatet er ikke bare om en side til slutt ble indeksert. Det er om behandlingen reduserte tiden det tok for siden å bli funnet og behandlet.

Valg av AI-sitering

Bruk en hierarkisk logistisk modell:

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)

Kjør to separate modeller:

1. Gjenfinningsmodell — Ble siden hentet eller vist som en kandidat?
2. Siteringsmodell — Hvis hentet, ble siden synlig sitert?

Dette skillet er essensielt. En ytelsesforbedring som øker indeksering, men ikke gjenfinning, er ikke en AI-siterings effekt. En ytelsesforbedring som øker gjenfinning, men ikke siteringer, antyder at siden blir vurdert, men taper under kildevalg.

Forventede funn

Dette er arbeidshypoteser, ikke påståtte eksperimentelle resultater.

Hypotesen 1: Time to first byte vil ha den tydeligste indekseringseffekten

Forvent en positiv sammenheng mellom lavere 'time to first byte' og indekseringskapasitet når:

• Nettstedet har mange sider.
• Sider endres ofte.
• Origin-serveren er treg eller overbelastet.
• Nettstedet returnerer 5xx- eller 429-svar.
• Søkeroboten bruker betydelig tid på å vente på svar.

Forvent liten målbar effekt på et lite nettsted med lav indekseringsetterspørsel.

Hypotesen 2: Largest Contentful Paint vil være viktig gjennom gjengivelse og ressurslevering

Forvent at lavere Largest Contentful Paint vil hjelpe når:

• Siden avhenger av nettlesergjengivelse.
• Viktig innhold er bak JavaScript.
• Store bilder eller stilark er nødvendige for indeksering.
• Søkeroboten henter mange sideressurser.
• Den tregere behandlingen produserer timeouter eller ufullstendig gjengivelse.

Forvent en svak sammenheng når sidens viktige tekst allerede er til stede i den opprinnelige HTML-en.

Hypotesen 3: Cumulative Layout Shift vil ha liten direkte effekt

Forvent ingen meningsfull direkte sammenheng mellom Cumulative Layout Shift og indekseringsfrekvens eller siteringsrate etter å ha kontrollert for sidestruktur og JavaScript-atferd.

Hvis Cumulative Layout Shift ser ut til å forutsi siteringer, undersøk om det fungerer som en proxy for:

• Klient-side gjengivelse.
• Sen innholdsinnsetting.
• Ustabile annonser.
• Skjult eller forsinket tekst.
• Dårlig strukturert HTML.

Hypotesen 4: Hastighet alene vil ikke produsere flere AI-siteringer

De sterkeste prediktorene for siteringsvalg vil sannsynligvis forbli:

• Relevans for spørsmålet.
• Innholdskvalitet.
• Klare svar.
• Ferskhet.
• Autoritet og tillit.
• Søkeindekskvalifikasjon.
• Gjenfinnelsesrangering.
• Hvorvidt siden direkte støtter påstanden som fremsettes.

Googles veiledning understreker nyttig, pålitelig, menneske-først-innhold og sier at AI-søkeegenskapene er forankret i de eksisterende søke- og indekseringssystemene. (developers.google.com)

Et ytelsesbudsjett tilpasset AI-gjenfinning

Følgende er et foreslått driftsbudsjett. Det er ikke en publisert AI-rangeringsformel.

Googles nåværende dokumentasjon sier at Googlebot henter de første 2 megabytene av en støttet fil og henter eksterne skript og stilark separat. Den anbefaler også å plassere viktig metadata og strukturerte data tidlig i HTML-en. (developers.google.com)

Implementeringsanbefalinger

HTTP/3

Bruk HTTP/3 når det støttes av vertstjenesteleverandøren og Content Delivery Network.

Mål:

• HTTP/3 forhandlingsrate.
• HTTP/2 fallback-rate.
• Tilkoblingsoppsettstid.
• Time to first byte.
• Ytelse per geografisk region.
• Ytelse per søkerobot.

Ikke behandle HTTP/3 som en garantert søke- eller AI-optimalisering. Det er en transportforbedring som kun kan hjelpe klienter som bruker den.

Content Delivery Network Kant-cachelagring

For offentlige, ikke-personliggjorte sider:

• Sett klare Cache-Control-regler.
• Bruk langvarig cachelagring for versjonerte statiske ressurser.
• Bruk kort, men nyttig cachelagring for ofte oppdatert HTML.
• Unngå cache-fragmentering fra unødvendige spørringsparametere.
• Bevar kanoniske URL-er.
• Støtt ETag og Last-Modified.
• Test kalde, varme og revaliderte cache-tilstander.
• Bekreft at søkerobotanmodninger mottar det samme viktige innholdet som menneskelige forespørsler.

Et Content Delivery Network bør redusere latenstid uten å skape utdaterte, inkonsekvente eller bot-spesifikke sideversjoner.

Bildekomprimering

For bilder:

• Bruk AVIF eller WebP når visuell kvalitet er akseptabel.
• Tilby responsive bildestørrelser.
• Ikke server et skrivebords-stort bilde til en liten mobilskjerm.
• Ikke lazy-load Largest Contentful Paint-bildet.
• Inkluder bildedimensjoner.
• Plasser Largest Contentful Paint-bildet i den opprinnelige HTML-en.
• Bruk fetchpriority="high" kun når det er hensiktsmessig.
• Hold viktige forklaringer i tekst i stedet for å bare legge dem inn i bilder.

Bildekomprimering er mest verdifull når bildet er Largest Contentful Paint-elementet. Det vil ikke fikse en side der hovedforsinkelsen kommer fra servergjengivelse eller JavaScript-utførelse. (web.dev)

Layoutstabilitet

For å redusere Cumulative Layout Shift:

• Sett bredde- og høydeattributter på bilder.
• Reserver plass til annonser.
• Reserver plass til innebygd video og sosialt innhold.
• Unngå å sette inn bannere over eksisterende tekst.
• Bruk stabile skriftlastingsstrategier.
• Unngå å erstatte store blokker med server-gjengitt innhold etter sidelast.

Disse endringene forbedrer brukeropplevelsen selv om de ikke har noen målbar effekt på indeksering eller siteringer. (web.dev)

Verktøy og overvåking

Ytelsesverktøy

Bruk:

• Chrome User Experience Report for reelle bruker-Core Web Vitals.
• Chrome User Experience Report application programming interface for automatisert feltdata-innsamling.
• PageSpeed Insights for laboratorieauditer og feltdata.
• Lighthouse for repeterbare laboratorietester.
• Lighthouse Continuous Integration for pull-request ytelsesbudsjetter.
• WebPageTest for multi-lokasjonstester, cache-tilstander og protokollsammenligninger.
• Chrome DevTools for Largest Contentful Paint og layoutskift-feilsøking.
• web-vitals JavaScript-biblioteket for overvåking av reelle brukere.

Chrome User Experience Report application programming interface gir side-nivå og origin-nivå aggregerte feltdata, inkludert Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint og eksperimentell 'time to first byte'. (developer.chrome.com)

Lighthouse Continuous Integration kan kjøre ytelseskontroller på hver kodeendring og feile bygg når budsjetter overskrides. (github.com)

Overvåking av søkeroboter

Bruk serverlogger, edge-logger og et lite sett med syntetiske prober.

Eksempelprobe:

bash curl --http3 -sS -o /dev/null -D - \ -w 'status=%{http_code}
http_version=%{http_version}
namelookup=%{time_namelookup}
connect=%{time_connect}
starttransfer=%{time_starttransfer}
total=%{time_total}
size=%{size_download}
' \ -A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)' \ https://example.com/page

Kjør samme test med:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• En vanlig nettleser 'user-agent'.

Testen bør verifisere:

• Statuskode.
• Robots-tillatelse.
• Responsheadere.
• HTML-innhold.
• HTTP-versjon.
• Cache-tilstand.
• Responstid.
• Om viktig tekst er til stede uten JavaScript.

Søke- og indekseringsovervåking

Bruk:

• Google Search Console indekseringsstatistikk.
• Google Search Console sideindekseringsrapporter.
• Google Search Console URL Inspection.
• Google Search Console sitemap-data.
• Google Search Console generativ AI-rapporter når tilgjengelig.
• Bing Webmaster Tools indekseringsforespørsler og indekserte sider.
• Bing Webmaster Tools Artificial Intelligence Performance.
• Daglige sitemap- og lastmod-kontroller.

Search Console application programming interface kan hente ytelsesdata etter side, spørring, dato, enhet og søkeutseende, underlagt databegrensningene. (developers.google.com)

Siterings overvåking

Opprett et siteringspanel som inneholder 50 til 200 stabile spørringer per emne. Kjør panelet på en fast tidsplan og registrer:

• Om plattformen søkte.
• Hvilke kilder som dukket opp.
• Om den testede URL-en ble sitert.
• Siteringsrekkefølge.
• Svar dato og tid.
• Om siden endret seg.
• Om modellen eller søkeopplevelsen endret seg.

Ikke sammenlign siteringsantall fra forskjellige systemer som om de var ekvivalente. Microsoft uttaler at siteringsaktivitet ikke er en rangeringsscore, autoritetsscore, trafikk-mål eller kvalitetsscore. (bing.com)

Varslingsregler

Opprett varsler for:

• 'Time to first byte' øker med mer enn 25 prosent.
• Largest Contentful Paint beveger seg over 2,5 sekunder ved 75. persentilen.
• Cumulative Layout Shift beveger seg over 0,1.
• En vedvarende økning i 5xx- eller 429-svar.
• Et fall i søkerobotens suksessrate.
• En robots.txt-endring.
• En sitemap-feil.
• Et plutselig fall i indekserte sider.
• Et plutselig fall i AI-siteringer på tvers av flere plattformer.
• En endring i siteringsvolum som kun påvirker én plattform.

En siteringsnedgang som påvirker én plattform kan skyldes en modell-, indeks-, spørrings- eller produktendring snarere enn et sideytelsesproblem. Microsoft advarer eksplisitt om at siteringstrender er observasjonsbaserte og kan endres på grunn av innholdsoppdateringer, brukeretterspørsel og system- eller modellendringer. (bing.com)

Endelig konklusjon

Den mest forsvarlige konklusjonen er:

Raskere sider kan forbedre indekseringseffektiviteten, spesielt når serverlatenstid, ressursstørrelse, feil eller gjengivelsesforsinkelser er begrensende faktorer. Men det er foreløpig ingen sterke bevis for at lavere Core Web Vitals direkte fører til at kunstig intelligens-systemer velger en side som sitering.

Den forventede årsakskjeden er:

text Lavere latenstid → bedre serverkapasitet → færre mislykkede eller forsinkede hentinger → raskere oppdagelse og behandling → økt sjanse for å bli indeksert og gjenfunnet → mulig økning i siteringer

Det siste trinnet forblir usikkert fordi siteringsvalg avhenger av relevans, kvalitet, friskhet, autoritet, spørringens intensjon, gjenfinnelsesrangering og atferden til hvert enkelt AI-system.

For de fleste nettsteder er den riktige ytelsesstrategien derfor ikke "optimaliser for AI-siteringer" isolert. Det er:

1. Hold viktig innhold tilgjengelig i den opprinnelige HTML-en.
2. Hold 'time to first byte' stabil.
3. Bruk kant-cachelagring for offentlig innhold.
4. Komprimer og prioriter viktige bilder.
5. Forhindre layoutskift.
6. Returner pålitelige statuskoder.
7. Hold sitemap-filer og interne lenker oppdaterte.
8. Tillat de riktige søkerobotene.
9. Mål indeksering, indeksering, gjenfinning og sitering som separate stadier.

Denne tilnærmingen produserer et raskere nettsted for folk, et sunnere nettsted for søkeroboter, og et testbart grunnlag for å forstå AI-synlighet.