Chromes skjulte prefetch-system: Hvad .well-known/traffic-advice betyder for dit website

Rigtig mange websites, sandsynligvis også dit, sender lige nu et signal til Chrome om at de ikke er konfigureret korrekt, uden at vide det. Det ses ved at Signalet er en 404-fejl på stien /.well-known/traffic-advice, og det sker fordi Chrome aktivt forsøger at pre-loade dit website for brugere der ser det i søgeresultaterne.

Systemet hedder Private Prefetch Proxy, det har kørt siden Chrome 103, og det er en af de mest oversete tekniske optimeringer jeg kender til. Ikke fordi det er svært at sætte op, men fordi de færreste ved det eksisterer.

Sådan fungerer Chromes prefetch

Konceptet er ret simpelt. Når en bruger søger på Google og ser dit website i resultaterne, kan Chrome allerede begynde at hente din side i baggrunden. Hvis brugeren så klikker, loader den nærmest instant fordi den allerede er hentet, ikke meget anderledes end Googles AMP projekt, de prøvede at indføre for år tilbage, hvor adoptionsraten bare ikke var god nok.

Google selv kalder det Private Prefetch Proxy, og “private” er afgørende her, for forespørgslen sendes gennem en proxy-server der skjuler brugerens identitet. Dit website ser kun at proxyen henter siden, ikke hvem der står bag. Chrome sender ingen cookies med, og der er kun begrænset info i User-Agent headeren. Så du kan ikke tracke det som et rigtigt besøg, og det tæller heller ikke som et i dine statistikker.

Det rammer primært førstegangsbesøgende og brugere der ikke har cookies på dit site. Præcis de brugere der kommer fra organisk søgning. Så forbedringen rammer der hvor det tæller mest, nemlig den allerførste oplevelse af dit website. Den nye bruger, som sandsynligvis ikke har stiftet bekendtskab med dig og dit website endnu.

Googles egne tests viser en forbedring på mellem 20% og 30% af Largest Contentful Paint (LCP) på prefetchede sider. En ret markant forbedring, på et element, der ellers kan være svær at efterleve.

Hvorfor er det relevant for SEO?

Page speed har været en ranking faktor i Google i mange år, og med Core Web Vitals er det blevet mere specifikt. LCP er en af de tre kernemålinger, og den måler hvor hurtigt det vigtigste indhold på siden vises. Hvis Chrome prefetcher din side og den dermed loader hurtigere, forbedrer det den oplevede hastighed for brugeren. Jeg har ikke set nogen dokumentation fra Google der direkte siger at prefetch-hastigheden påvirker rankings. Men vi ved at brugeroplevelse er afgørende, og en side der loader instant kontra en der tager 3 sekunder er to vidt forskellige oplevelser. Og vi ved at Chrome-data indgår i Googles forståelse af webkvalitet, det er bekræftet gennem CrUX-data.

Det interessante er at du kan give Chrome eksplicit tilladelse til at prefetche mere aggressivt. Og det gør du med en simpel fil.

.well-known/traffic-advice filen

Styringen sker med en JSON-fil du placerer på dit domæne: /.well-known/traffic-advice. Den fortæller Chrome hvor meget den må prefetche fra dit site. Tænk på den som en robots.txt, bare for Chromes prefetch-system i stedet for crawlere.

Fuld tilladelse ser sådan her ud:

[{"user_agent": "prefetch-proxy", "fraction": 1.0}]

Fraction-værdien bestemmer andelen af requests. 1.0 betyder 100%, 0.5 betyder halvdelen, og 0.3 ville være 30%. Du kan starte lavt og skrue op.

Hvis du vil slå det helt fra:

[{"user_agent": "prefetch-proxy", "disallow": true}]

Filen skal serveres med MIME-typen application/trafficadvice+json. Som er det eneste tekniske krav.

Det jeg ser i server logs

Når jeg laver tekniske audits for kunder og gennemgår server logs, ser jeg næsten altid det samme mønster: en strøm af 404-fejl på /.well-known/traffic-advice. Nogle gange er det 403-fejl fordi nginx eller Apache blokerer hele .well-known-stien. Det er Googles prefetch-proxy der prøver at få et svar, men uden held. Det er altså ikke noget du bør ignorere, Chrome prøver at fortælle dig, at den gerne vil gøre dit website hurtigere for brugerne og du returnerer tjeneste med en fejlkode.

Prefetchingen kører stadig i et vist omfang selv uden filen, for Chrome bruger den primært til at styre volume og opt-out. Men den løbende strøm af fejl er unødvendig serverbelastning, og du sender et signal om at du ikke har konfigureret dit setup korrekt.

Sådan sætter du det op

Det afhænger af din server. I nginx tilføjer du en location block:

location = /.well-known/traffic-advice {
    default_type application/trafficadvice+json;
    return 200 '[{"user_agent":"prefetch-proxy","fraction":1.0}]';
}

I Apache kan du bruge .htaccess:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^\.well-known/traffic-advice$ - [L]
</IfModule>

Med en statisk traffic-advice fil i .well-known/ mappen og korrekt MIME-type.

Til Next.js på Vercel kan du lægge filen i public/.well-known/traffic-advice og tilføje headers i next.config.js:

async headers() {
  return [{
    source: '/.well-known/traffic-advice',
    headers: [{
      key: 'Content-Type',
      value: 'application/trafficadvice+json'
    }]
  }]
}

Min anbefaling

Sæt filen op med fraction: 1.0 og glem den. Der er ingen grund til at begrænse det medmindre du har et site med så lille server-kapacitet at prefetch-trafikken rent faktisk belaster dig, og det er usandsynligt for de fleste websites.

Opsætningen tager fem minutter. Det fjerner de irriterende fejl fra dine logs, det giver hurtigere load for brugere der kommer fra søgning, og det sender de rigtige signaler til Chrome. Om det direkte påvirker rankings er svært at sige med sikkerhed, men det er en af de sjældne ting i teknisk SEO der er ren upside uden nogen downside.

Henrik Bondtofte SEO-specialist & strateg med fokus på AI og retrieval

Henrik Bondtofte er en af Danmarks mest erfarne SEO-specialister med over 20 års praktisk erfaring. Han står bag flere anerkendte fagbøger om SEO, linkbuilding og interne links og er forfatteren bag denne blog, hvor han deler sine erfaringer.

See Full Bio