Dokumentasjon

Forbedre synligheten

Ferskhet og Web Vitals

Se hvor ofte du og konkurrentene dine publiserer og oppdaterer sider, hvor raskt de siterte sidene dine laster for ekte brukere, og hvor mye hver prompts toppresultater støtter seg på ferske eller raske sider.

To faktorer på sidenivå dukker opp igjen og igjen når en konkurrents side blir sitert i stedet for din: den ble oppdatert nylig, eller den laster og reagerer raskere. AmICited måler begge, for domenet ditt og for de sporede konkurrentene dine, og plasserer dem ved siden av posisjonene AI-motorer siterer sider på. To sider under Audit dekker dem: Freshness og Web Vitals. Hver prompt får også to sensitivitetsscorer som forteller deg om ferskhet eller hastighet i det hele tatt sannsynligvis betyr noe for det spørsmålet.

Freshness#

Audit → Freshness bygges fra en daglig crawl av sitemapene dine og konkurrentenes sitemaps. Den viser hvor mange URL-er hver vert legger til, fjerner og markerer som oppdatert, slik at du kan se hvem som publiserer mer enn hvem, og hvor.

  • Sitemap churn. Én søyle per dag, segmentert etter vert: lagt til over aksen, fjernet under. Klikk på et segment for å se URL-ene. Bytt mellom Added, Removed og Net.
  • Freshness leaderboard. Én ferskhetsindeks fra 0 til 100 per vert, bygget fra fire delscorer (publiseringsrate, oppdateringsrate, aktualitet og andel foreldede) og størrelsesjustert, slik at et lite nettsted som leverer jevnt, ikke slås av et stort som ikke gjør det.
  • URLs by last update. Hvor mange URL-er hver vert sist endret innen 7, 30, 90, 180 og 360 dager, eller lenger, fra lastmod-datoer i sitemap. «No date» betyr at sitemapen ikke oppgir noen lastmod: umålt, ikke gammelt.
  • Directory comparison. Antall URL-er per stiprefiks, som et trekartdiagram du kan bore deg ned i og farge etter ferskhet (andelen daterte sider oppdatert de siste 30 dagene).
  • URL changes. Hver URL lagt til i en sitemap, fjernet fra en eller markert som oppdatert, med CSV-eksport.
  • Freshness vs citation position. Hver URL som er sitert for domenets prompts (ikke bare konkurrenters) plottet etter sidealder mot beste siteringsrangering. Sidealder kommer fra en dato siden selv oppgir (strukturerte data, sidemetadata, sidemarkup, publiseringsdato eller HTTP-header); en dato hentet bare fra sitemapen er merket som et svakt signal.

Historikken starter den dagen sporingen begynner for en vert, så 90-dagersvisningen fylles opp over tid. Re-check crawler en verts sitemaps på nytt ved behov (0,005 kreditter), høyst én gang om dagen. Sideantall per konkurrent og 30-dagers endring finnes også under Competitors → Competitor sitemaps.

Web Vitals#

Audit → Web Vitals bruker Chrome UX Report (CrUX) feltdata: hvordan ekte Chrome-brukere opplevde siden de siste 28 dagene, ved 75. persentil. Den dekker LCP (lasting av hovedinnhold), INP (responsivitet), CLS (layoutstabilitet), FCP (første innhold) og TTFB (serverrespons).

  • Competitor comparison. Hjemmesidens score og Core Web Vitals-status mot hjemmesidene til de sporede konkurrentene dine.
  • Your pages by Web Vitals. Hver side på domenet ditt som AI-motorer siterer, sortert etter hvor ofte den vises i promptkilder, slik at du fikser de viktigste sidene først.
  • Performance impact. For hvert måltall, de siterte sidene dine spredt etter hastighet mot posisjonen motorene siterer dem på, som kan filtreres etter motor, med en trendlinje. En flat linje betyr at måltallet ikke har noen reell betydning for posisjonene dine; en bratt betyr at det har det.
  • What moves your position most. Hvilket måltall som følger siteringsposisjonen din tettest. Behandle det som et hint, ikke et bevis: topp 10-data er støyende.

Refresh Web Vitals legger en ny import i kø; URL-er sjekkes på nytt gradvis, og det kan ta flere timer. CrUX har bare data for sider med nok Chrome-trafikk, så sider med lite trafikk kan vise opprinnelsens tall eller ingenting i det hele tatt.

Sensitivitetsscorer for prompts#

På siden Prompts viser kolonnene Sensitivity, for hver prompt, hvor mye Googles topp 10 støtter seg på ferske sider og på gode Core Web Vitals. Begge beregnes fra ett observert øyeblikksbilde av Google-resultatene for prompteksten. De beskriver resultatsettet, ikke hvorfor sider rangerer.

Freshness sensitivity
topp 10-sider oppdatert de siste 30 dagene ÷ topp 10-sider med en brukbar dato × 100
Web Vitals sensitivity (per måltall)
topp 10-sider med en god p75 ÷ topp 10-sider med CrUX-data for det måltallet × 100
  • «God» bruker standardbåndene: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, FCP ≤ 1,8 s, TTFB ≤ 800 ms.
  • En score trenger minst 5 brukbare sider, og minst 60 % av topp 10 må være datert (eller ha CrUX-data). Ellers forklarer cellen at dekningen er for lav til å score.

Regneeksempel#

For «best project management software» har 9 av Googles topp 10 en brukbar dato, og 7 av dem ble oppdatert de siste 30 dagene: 7 ÷ 9 × 100 = 78. Det er en prompt som krever ferskhet, og en side som sist ble rørt for et år siden, vil slite. En prompt som scorer 10, besvares av evergreen-sider; å oppdatere din vil flytte lite der.

Slik handler du på det#

  • Oppdater der ferskhetssensitiviteten er høy. Oppdater siden som bør eie prompten med reelle endringer (nye data, årets priser, nye seksjoner), hold lastmod og datoer på siden sanne, og logg det som en annotasjon.
  • Fiks hastighet på siterte sider først. Start øverst i «Your pages by Web Vitals». Treg TTFB og innhold som først vises etter tung JavaScript rammer AI-hentere mest, fordi retrieval-boter henter under stramme tidsavbrudd.
  • Følg med på konkurrentenes churn. At en konkurrent plutselig legger til hundrevis av URL-er i én katalog, er vanligvis et innholdspress rettet mot de samme promptene du sporer.

Korrelasjon, ikke årsak

Hvert diagram her viser samvariasjon. En fersk, rask side som ikke svarer på spørsmålet, blir fortsatt ikke sitert; sjekk promptdekning før du skriver om for hastighet eller aktualitet alene.

Relatert#