Hvordan Google indekserer PDF filer og hvorfor du bør erstatte dem med HTML i WordPress

#Hvordan Google gjør PDF filer om til HTML under indeksering

I episode 115 av den offisielle podcasten Search Off the Record, publisert 13. oktober 2026, forklarte Martin Splitt og John Mueller fra Search Relations teamet hos Google hvordan Google Search håndterer PDF dokumenter. I mange bedrifter og nettbutikker lever forestillingen om at det å laste opp en katalog eller en teknisk veiledning som PDF er det samme som å publisere en vanlig nettside. Episoden viser hvor formatene ligner hverandre, og hvor de ikke gjør det.

HTML er et tekstformat. En søkemotor leser HTML sekvensielt og gjenkjenner overskrifter, avsnitt, lister, strukturerte data i JSON-LD og semantiske direktiver.

Portable Document Format (PDF) ble laget for et annet formål: å bevare den nøyaktige visuelle utformingen av et dokument på utskrift og på enhver skjerm. Splitt understreker at PDF er en binær beholder: åpner du en PDF i en tekstredigerer, får du uleselige tegn, mens en HTML eller Markdown fil kan leses som den er.

Google åpner ikke PDF filer med en PDF leser. Ifølge Splitt omfatter indekseringen en komponent kalt konvertereren, som kjører rett etter rendering og rett før et dokument kan havne i indeksen. Google har konverterere for flere formater (rik tekst, dokumentfiler, Excel ark og til og med Lotus Notes dokumenter), og én av dem er PDF konvertereren. Resultatet er en HTML versjon av dokumentet, så tro mot originalen som mulig, fordi resten av nettpipelinen nesten bare jobber med HTML.

+-----------------------------------------------------------------------------------+
| Veien en PDF fil går gjennom Google Search (ifølge episode 115):                  |
| 1. Henting av filen (HTTP Content-Type: application/pdf)                          |
| 2. Rendering                                                                      |
| 3. PDF konverterer: lager en HTML representasjon av dokumentet                    |
| 4. Lenker i denne representasjonen oppdages som på enhver HTML side               |
| 5. Indeksering og rangering med de samme systemene som en HTML side               |
+-----------------------------------------------------------------------------------+

Derfor er indeksering og rangering av en PDF, med Splitts ord, stort sett lik den for ethvert annet dokument, og en PDF kan vises i AI Overviews og AI Mode. Google registrerer ikke om et dokument opprinnelig var en PDF. Den offisielle listen over indekserbare filtyper har Adobe PDF blant de støttede kodede formatene.

Mueller la til et forbehold om svært lange dokumenter: en hel bok i én PDF gir samme problem som en hel bok på én HTML side. Søkemotoren har vanskelig for å avgjøre hvilken setning som er grunnen til at dokumentet bør vises for et søk.

#Hvilke PDF filer Googlebot kan lese og når OCR svikter

Innlegget om PDF på Google Search Central bloggen, skrevet av Gary Illyes, gir grunnregelen: Google kan indeksere tekstinnholdet i en PDF på alle språk og med ulike tegnkodinger, så lenge filen ikke er passordbeskyttet eller kryptert. Er teksten innebygd som bilder, kan Google behandle disse bildene med OCR algoritmer.

I episode 115 kaller Splitt rasteriserte sider det verste problemet: dokumenter der hver side i praksis er et bilde. Da går alt tekstinnhold tapt. Mueller legger til skannede bøker som er arkivert som PDF: noen systemer kan kjøre OCR på dem, men du kan ikke stole på det.

Testen begge foreslår er enkel:

1. Åpne PDF filen.
2. Marker all tekst med Ctrl + A eller Cmd + A.
3. Lim den inn i et Google Docs dokument eller en tekstfil.
4. Dukker teksten opp, kan Google bruke den. Gjør den ikke det, ser heller ikke Google innholdet.

Splitt legger til at rasteriserte sider også er et tilgjengelighetsproblem: skjermlesere og andre hjelpemidler kan ikke lese dem, med mindre PDF generatoren bevisst har lagt inn innholdet på en tilgjengelig måte.

#Hvor stor PDF fil Googlebot laster ned

Dokumentasjonen for Googlebot oppgir to ulike grenser. For støttede filtyper henter Googlebot de første 2 MB. For en PDF henter den de første 64 MB. Grensen gjelder det dekomprimerte innholdet, ikke overføringsstørrelsen. Når grensen nås, stopper Googlebot hentingen og sender bare den delen som allerede er lastet ned, videre til indeksering.

I episoden innrømmet Splitt at han ikke husket det nøyaktige tallet for PDF, og forklarte hvorfor Google helst ikke vil låse det: grensen kan endres, og hvis utgivere begynte å publisere mye større PDF filer, kunne Google heve den for ikke å miste nyttig informasjon. Dokumentasjonen er den gjeldende kilden; tallet kan endre seg.

I praksis rammer grensen få dokumenter. En katalog full av høyoppløste bilder kan komme nær den, og da kan teksten på de siste sidene bli stående utenfor indeksen.

#Hvorfor lenker i PDF overfører PageRank mens bilder ikke rangerer

#Slik oppfører tekstlenker seg

Fordi konvertereren lager en HTML versjon, beholdes lenkene i PDF filen. Google Search Central bloggen bekrefter det: lenker i PDF filer behandles omtrent som lenker i HTML, de kan overføre PageRank og andre indekseringssignaler, og Google kan følge dem etter å ha hentet PDF filen.

• Overføring av autoritet: lenker i en PDF kan overføre PageRank til målsidene.
• Oppdagelse av nye stier: Googlebot kan følge målene den finner etter å ha hentet filen.
• Ingen nofollow: ifølge det samme innlegget er det ikke mulig å bruke nofollow lenker i et PDF dokument.

Disse lenkene har en ulempe for alle som måler resultater. På en nettside fanges klikk opp med Google Tag Manager eller sidens analyseskript. Det skriptet kjører ikke i en PDF som er åpnet i nettleserens leser, så det leseren gjør i dokumentet, havner utenfor analysen din.

#Problemet med bilder som er innebygd i PDF

På en nettside bygd med WordPress eller Astro serveres hvert bilde som en egen ressurs med egen URL, alt attributt, faste dimensjoner og moderne formater som AVIF eller WebP. Det lar Google Bilder rangere hvert bilde for seg.

I en PDF er bildene en del av selve filen. Splitt forklarte at Google vanligvis sender bilde URL-er videre til pipelinen for bildesøk, og et bilde i en PDF har ingen URL. Hans forståelse er at Google vet at det finnes et bilde, men ikke kan behandle det som et vanlig bilde for Google Bilder, selv om det kan endre seg. Innlegget fra 2011 var tydeligere: bilder i PDF filer indekseres ikke, og vil du ha dem indeksert, bør du lage HTML sider for dem.

Hvis bedriften din publiserer infografikk, arkitekturdiagrammer eller visuelle sammenligninger bare i en PDF, bør du ikke regne med trafikk fra Google Bilder.

#Hvorfor Google oppdager endringer i en oppdatert PDF sent

Mueller forklarte i episode 115 at hentefrekvensen for PDF filer ligner den for bilder. Googles systemer henter ikke en PDF på nytt med noen minutters mellomrom, fordi de antar at filen trolig ikke endres på lenge, og fordi de ikke vil hente mange store filer fra en server, noe som kunne skape problemer.

Splitt nevnte en annen forskjell: et HTML dokument er lett å redigere i et CMS, mens en generert PDF ikke kan endres uten et verktøy som Adobe Acrobat Pro; vanligvis må du ta vare på kildefilen og generere PDF filen på nytt.

Hvis du endrer en prisliste, en teknisk manual eller et regelverk ved å laste opp en ny versjon med samme navn og URL, kan utdraget Google viser og svarene i AI Overviews fortsatt bygge på den gamle versjonen ganske lenge. Google oppgir ingen tidsramme, så det finnes ikke noe pålitelig tall å gi.

#Hvordan få et oppdatert PDF dokument indeksert raskere

Muellers anbefaling er et nytt filnavn. Når Google finner en lenke til den nye URL-en, gjenkjenner den den som et nytt dokument og henter og indekserer det. I tillegg legger vi, som egen praksis og ikke som råd fra Google, inn en 301 videresending fra den gamle stien:

Versjoneringsstrategi mot utdatert innhold i indeksen:
Gammel versjon:  https://dittdomene.no/kataloger/teknisk-spesifikasjon-2025.pdf
Ny versjon:      https://dittdomene.no/kataloger/teknisk-spesifikasjon-2026-v2.pdf

Serveroppsett:
Permanent HTTP 301 svar fra den gamle stien til den nye versjonen.
Interne lenker oppdatert til den nye URL-en.

Splitt fullførte rådet med HTTP mellomlagring: vet du at en katalog endres hvert kvartal, kan du holde den i hurtigbuffer i et par måneder; endres en fil ofte, gir lang mellomlagring mindre mening.

#Hvordan styre tittel og metadata for en PDF i Google

En PDF har ikke noe HTML title element. Ifølge Google Search Central bloggen bruker Google to hovedelementer for å velge tittelen i søkeresultatene: tittelen som er lagret i filens metadata, og ankerteksten i lenker som peker til PDF filen. For å gi et tydelig signal anbefaler Google å oppdatere begge.

Splitt la til i episode 115 at du bør fylle ut metadataene i PDF filen: hvem som har skrevet den, en beskrivelse av innholdet og om mulig en lenke til hvor dokumentet opprinnelig kommer fra. Mueller foreslo et mer praktisk grep: legg en vanlig lenke til forsiden av nettstedet i toppteksten i selve PDF filen. Når Google gjør PDF filen om til HTML, beholdes lenken, og den som lander på PDF filen fra søk, har en vei tilbake til nettstedet ditt.

I en arbeidsflyt med WordPress betyr det:

1. Før du laster opp PDF filen, sjekk feltene for dokumenttittel, forfatter og beskrivelse i programmet som lager den.
2. Lenk til PDF filen fra en HTML side med beskrivende ankertekst, ikke “last ned” eller “her”.
3. Legg en synlig lenke på første side av PDF filen til HTML siden den hører til.

#Hvordan sette opp HTTP hodet Link rel canonical for PDF dokumenter

Når en organisasjon tilbyr en rapport både som nettartikkel og som nedlastbar PDF, oppstår en risiko for duplisering. Mueller beskrev et ekstra problem i episoden: en PDF er en binær klump. Laster et annet nettsted ned PDF filen din og publiserer den, ser søkemotoren to filer som er identiske byte for byte, og kanonisering blir vanskeligere enn med lignende HTML sider.

På en HTML side oppgis foretrukket versjon med elementet link rel="canonical" i head. En PDF har ikke den seksjonen. Googles dokumentasjon om dupliserte URL-er sier at hvis du kan endre serveroppsettet, kan du bruke HTTP svarhodet Link med rel="canonical", slik det er definert i RFC 5988, også for dokumenter som ikke er HTML, som PDF filer. Google presiserer at metoden bare gjelder resultater i nettsøk.

Den samme siden gir to advarsler som gjelder PDF filer. Google anbefaler ikke å bruke noindex for å hindre at en side velges som kanonisk innenfor ett nettsted, fordi det blokkerer siden helt fra søk. Og du bør ikke oppgi ulike kanoniske URL-er for samme side med ulike teknikker. For en PDF velger du derfor ett av to alternativer:

• Canonical: PDF filen er fortsatt tilgjengelig, og signalene samles på HTML siden.
• Noindex: PDF filen forsvinner fra resultatene (se neste del).

#Oppsett på Nginx servere

location ~* \.pdf$ {
    # Kanonisk lenke til HTML hovedversjonen
    add_header Link '<https://dittdomene.no/teknisk-dokumentasjon/>; rel="canonical"';
}

#Oppsett på Apache servere (.htaccess)

Med modulen mod_headers aktivert:

<FilesMatch "\.pdf$">
    Header set Link '<https://dittdomene.no/teknisk-dokumentasjon/>; rel="canonical"'
</FilesMatch>

#Oppsett i Cloudflare Pages og CDN

I Cloudflare Pages og lignende plattformer for statisk hosting legges regelen i filen _headers:

/dokumenter/*.pdf
  Link: <https://dittdomene.no/teknisk-dokumentasjon/>; rel="canonical"

En regel per filmønster peker alle PDF filer til samme side. Har hver PDF sin egen HTML side, trenger du én regel per fil eller per mappe.

#Hvordan fjerne en PDF fra Googles søkeresultater

Ifølge Google Search Central bloggen er den enkleste måten å holde en PDF utenfor søkeresultatene å sende HTTP hodet X-Robots-Tag: noindex sammen med filen. Er PDF filen allerede indeksert, faller den ut over tid; for raskere fjerning viser det samme innlegget til verktøyet for fjerning av URL-er i Search Console.

Dokumentasjonen for robots metataggen viser dette tilfellet for alle PDF filer på et nettsted, med noindex, nofollow:

<Files ~ "\.pdf$">
  Header set X-Robots-Tag "noindex, nofollow"
</Files>

location ~* \.pdf$ {
  add_header X-Robots-Tag "noindex, nofollow";
}

Vil du at Google fortsatt skal bruke lenkene i PDF filen til å oppdage sider, holder det med noindex: den samme dokumentasjonen sier at hvis du ikke angir nofollow, kan Google bruke lenkene på siden til å oppdage sidene det lenkes til.

Det finnes to andre veier, med ulik virkning:

• Passord: Splitt minner om at søkemotorer ikke kan lese en passordbeskyttet PDF. Det passer for dokumenter som ikke skal være offentlige.
• robots.txt: den hindrer Google i å hente PDF filen. Men dokumentasjonen om dupliserte URL-er advarer om at Google kan indeksere URL-er som er blokkert i robots.txt uten innholdet deres. Er målet at filen ikke skal vises, er noindex hodet riktig verktøy, og Google ser det bare hvis den kan hente filen.

#Hvordan WordPress håndterer PDF filer som lastes opp til mediebiblioteket

Når du laster opp en PDF til mediebiblioteket, lagrer WordPress filen i wp-content/uploads og oppretter et vedlegg i databasen. Selve filen leveres direkte av nettserveren (Nginx, Apache) eller CDN, uten at WordPress lastes. Denne detaljen avgjør hvor hodene settes opp.

Hooken send_headers utløses i WP::send_headers() når WordPress behandler en forespørsel. En direkte forespørsel til /wp-content/uploads/2026/10/katalog.pdf når aldri WordPress, så kode i functions.php som prøver å legge et canonical hode på den PDF filen, kjører ikke. Hodet kan bare legges til fra PHP hvis en utvidelse leverer filen gjennom WordPress, og det oppsettet har sin egen kostnad. For statiske filer settes hodet opp på serveren eller i CDN, som i delen over.

Vedlegget får også sin egen URL i WordPress: vedleggssiden. Utviklernotatet for WordPress 6.4 endret hvordan den oppfører seg:

• På nye installasjoner er vedleggssider deaktivert og videresender til filens URL.
• Valget wp_attachment_pages_enabled styrer dette: det er 0 på nye installasjoner og settes til 1 når et eksisterende nettsted oppdateres, slik at vedleggssider fungerer som før.

På et nettsted som er oppdatert fra en versjon eldre enn 6.4, kan hver opplastede PDF i tillegg til selve filen ha en tynn, indekserbar vedleggsside. Sjekk verdien med WP-CLI (wp option get wp_attachment_pages_enabled) før du bestemmer om du vil endre den.

#Farene ved automatiske PDF utvidelser i WordPress

I WordPress økosystemet er det vanlig med utvidelser som legger en knapp for PDF nedlasting på hvert innlegg. De bruker PHP biblioteker som Dompdf, TCPDF eller mPDF for å gjøre artikkelens HTML om til en PDF fil ved forespørsel.

Mueller trakk i episode 115 fram et tilfelle fra tidlige CMS, muligens Joomla, som lot deg vise hver side som PDF. Fordi Google ikke henter slike filer ofte på nytt, kunne et nettsted ende opp med det gamle innholdet indeksert som PDF og det nye som HTML side: de to versjonene konkurrerte med hverandre og var i tillegg ute av takt. Hans konklusjon: er innholdet ferskt og dynamisk og du må tilby en PDF, bør du hindre at den PDF filen indekseres.

Fra et teknisk og SEO perspektiv gir praksisen tre problemer:

1. Duplikater i hentingen: hvert innlegg får en ekstra URL med samme tekst. Robotene bruker tid på kopier i stedet for nytt innhold.
2. Serverbelastning: å lage en PDF fra stilsatt HTML i PHP er en kostbar operasjon, og ber en robot om mange nedlastinger samtidig, havner belastningen på PHP-FPM.
3. Tapt brukeropplevelse og konverteringer: rangerer PDF versjonen over HTML siden, lander besøkende i et statisk dokument uten kontaktskjema, navigasjon eller handlingsoppfordringer.

Splitt la til at de fleste nettlesere på mobil og datamaskin allerede lar brukeren lagre en side som PDF, så nettstedseieren trenger vanligvis ikke tilby den funksjonen. Et stilark for utskrift er nok:

@media print {
  header, footer, nav, aside, .sidebar, .comments, .cookie-banner {
    display: none !important;
  }
  body {
    font-size: 12pt;
    color: #000;
    background: #fff;
  }
  a[href^="http"]:after {
    content: " (" attr(href) ")";
  }
}

Med denne regelen bruker en leser som vil lagre artikkelen, utskriftsfunksjonen i nettleseren (Ctrl + P eller Cmd + P) og får en ren PDF laget på egen enhet, uten å bruke prosessorkraft på serveren din.

#Hvorfor filen llms.txt ikke bør publiseres som PDF

Forslaget llms.txt, publisert av Jeremy Howard i september 2024, definerer en Markdown fil på stien /llms.txt med kort bakgrunn, veiledning og lenker til mer detaljerte Markdown filer, for å tilby innhold som er lett for språkmodeller å behandle.

Episode 115 åpner nettopp med dette spørsmålet. Mueller spør om det gir mening å lagre llms.txt som PDF, og Splitt svarer nei: ideen med llms.txt var å gjøre innhold tilgjengelig for språkmodeller i enklest mulig form, og PDF er ikke den enkleste formen for innhold på nettet. At Google kan behandle PDF, betyr ikke at alle andre kan eller vil.

Filen llms.txt bør forbli en Markdown tekstfil i roten av nettstedet (https://dittdomene.no/llms.txt), med lenker til sider eller Markdown filer som kan leses uten konvertering.

#Når det gir mening å publisere en PDF på nettstedet

Episode 115 er ikke et innlegg mot PDF. Splitt lister opp tilfellene der han anbefaler det: når innholdet har spesielle krav til formatering, når det må se helt bestemt ut på utskrift, eller når du trenger interaktive skjemaer. Eksemplet hans er et feriested som publiserer registreringsskjemaet for gjester som PDF fordi det gjør behandlingen enklere.

Om restaurantmenyer var Mueller pragmatisk: en meny som PDF er bedre enn ingen meny på nettstedet; mellom en PDF og en vanlig side foretrekker han siden, fordi den er enklere å zoome, tilpasser seg mobilen og laster litt raskere. Kan teksten i PDF filen markeres og kopieres, kan Google bruke den i søk.

Om AI systemer la Mueller til at PDF filer fungerer hos Google, at han har sett dem sitert i andre AI systemer også, og at PDF ikke ødelegger synligheten i slike systemer. Men kan det samme innholdet ligge i HTML, blir alt litt enklere.

Splitt pekte også på to bruksproblemer på mobil: en PDF må lastes helt ned før den vises, mens en HTML side begynner å vise innhold så raskt som mulig, og mange PDF filer bryter ikke teksten om når du zoomer.

#Teknisk sammenligning av semantisk HTML og statiske PDF dokumenter

Bortsett fra dokumenter der hovedformålet er utskrift, et skjema eller en fast layout, fungerer innhold som skal rangere og holdes oppdatert bedre som HTML side.

#Tiltaksplan for å flytte PDF innhold over til HTML i WordPress

Har bedriften din dusinvis eller hundrevis av PDF filer med teknisk informasjon, produktark eller manualer, flytter en ryddig migrering til HTML sider innholdet over i formatet Google henter oftere og brukerne leser bedre på mobil.

1. Teknisk oversikt: bruk et crawlerverktøy til å liste alle .pdf filer på serveren, og sjekk dagens organiske trafikk i Google Search Console.
2. Teksttest: kjør kopier og lim inn testen på hver PDF. Rasteriserte dokumenter er de første kandidatene til HTML, fordi Google ikke ser innholdet deres i dag.
3. Omorganisering av innhold:
   • Flytt den mest verdifulle informasjonen til nye sider i WordPress eller Astro, bygd med semantiske blokker.
   • Sett opp permanente 301 videresendinger fra de gamle PDF URL-ene til de nye HTML sidene.
4. Canonical for filer som må bli: for dokumenter som fortsatt skal kunne lastes ned (skjemaer, utfyllbare maler), legg til HTTP hodet Link: <url>; rel="canonical" som peker til nettsiden som forklarer dokumentet, eller X-Robots-Tag: noindex hvis de ikke skal vises i Google. Aldri begge samtidig.
5. Metadata og lenke tilbake: fyll ut tittel, forfatter og beskrivelse i PDF filene som blir, og legg en lenke til nettstedet på første side.
6. Vedleggssider: sjekk wp_attachment_pages_enabled hvis nettstedet ble installert før WordPress 6.4.
7. Fjern automatiske generatorer: deaktiver utvidelser som masseproduserer PDF filer, og tilby et stilark for utskrift i stedet.
8. Konsekvent intern lenking: koble de nye sidene til hovedpilarene i nettstedsarkitekturen, etter rådene i vår sikkerhetsrevisjon av WordPress og våre prosjekter for WooCommerce ERP integrasjon.