Oppsummering
Kontrollen av HTTP-headere ber om enhver nettadresse, følger omdirigeringene og viser endelig statuskode, alle svarheaderne, en sikkerhetsscore basert på sju sikkerhetsheadere, og caching- og komprimeringsheaderne. Se først på statuskoden og eventuell X-Robots-Tag, for en header kan fjerne en side fra indeksen selv når HTML-en ser perfekt ut, deretter på caching og komprimering, og til slutt på sikkerhet.
Vil du vite mer? Spør
En kontroll av HTTP-headere viser hva serveren din sier før siden i det hele tatt begynner: statuskoden, cachereglene, sikkerhetspolicyene og noen ganger instrukser for indeksering. Disse headerne er usynlige i sidekildekoden, men Google leser dem. Enhver regel du kan legge i en robots-metatag, for eksempel noindex, kan også sendes som en X-Robots-Tag-header, og det er måten å styre filer uten HTML på, som PDF-filer eller bilder (Google Search Central, robots-metatag og X-Robots-Tag). Når en side faller ut av Google og HTML-en viser ingenting galt, er headerne neste sted å se.
Hva viser kontrollen av HTTP-headere?
Skriv inn en nettadresse. Verktøyet ber om den, følger omdirigeringene til den endelige adressen og returnerer en rapport i fire deler.
| Del av rapporten | Hva den inneholder |
|---|---|
| Nøkkeltall | Endelig HTTP-statuskode, antall sikkerhetsheadere til stede av 7, totalt antall headere, navn på server |
| Sikkerhetsheadere | Til stede eller mangler, med verdien og alvorlighetsgraden til hver |
| Cache og ytelse | Cache-Control, Expires, ETag, Last-Modified, Age, Vary, Content-Encoding og Content-Type |
| Alle headere | Hver header som returneres, i alfabetisk rekkefølge, vises på forespørsel |
Tre kontroller per dag er gratis, etter en rask anti-bot-verifisering. Rapporten viser svaret for den endelige adressen. For å se hvert ledd i en omdirigeringskjede, bruk omdirigeringssjekkeren.
Hvilke headere påvirker SEO?
Fire typer headere endrer hvordan søkemotorer crawler og indekserer en adresse. Finn dem i den fullstendige listen over headere.
| Header | Eksempel | Effekt på Google |
|---|---|---|
| Statuskode | 200, 301, 404, 503 | Et 2xx-svar kan indekseres. Google følger opptil 10 omdirigeringsledd (Google, HTTP-statuskoder) |
| X-Robots-Tag | X-Robots-Tag: noindex | Samme regler som robots-metatagen, brukt på alle filtyper |
| Link, rel="canonical" | Link: <https://example.com/page>; rel="canonical" | Erklærer den foretrukne adressen, nyttig for PDF-filer |
| Link, rel="alternate" hreflang | Link: <https://example.com/de/>; rel="alternate"; hreflang="de" | Erklærer språkversjoner, én av tre likeverdige metoder |
To advarsler fra Googles dokumentasjon. For kanoniske adresser velger du enten HTML-lenkeelementet eller HTTP-headeren: å bruke begge «er mer utsatt for feil», for eksempel når de peker til ulike adresser (Google, samle dupliserte adresser). For hreflang er HTML, HTTP-headere og sitemaps likeverdige, og headere er nyttige for filer som ikke er HTML (Google, lokaliserte versjoner). Sjekk HTML-siden med kontrollen av kanoniske adresser og generatoren for hreflang.
Hvordan beregnes sikkerhetsscoren?
Sikkerhetsscore = sikkerhetsheadere til stede ÷ 7 × 100. Hver header teller likt, uansett alvorlighetsgrad. Ringen blir grønn fra 70%, gul fra 40%, og rød under det.
| Header | Alvorlighet | Hva den gjør |
|---|---|---|
| Strict-Transport-Security (HSTS) | Høy | Forteller nettlesere å bare bruke HTTPS for denne vertsmaskinen |
| Content-Security-Policy | Høy | Begrenser hvilke skript, stiler og ressurser en side får laste |
| X-Content-Type-Options | Middels | Hindrer nettlesere i å gjette filtypen («nosniff») |
| X-Frame-Options | Middels | Hindrer andre nettsteder i å ramme inn sidene dine |
| Referrer-Policy | Middels | Styrer hva adressene dine avslører for nettstedene du lenker til |
| Permissions-Policy | Middels | Slår av nettleserfunksjoner du ikke bruker, som kameraet |
| X-XSS-Protection | Lav | Eldre filter, nå utdatert |
Scoren sjekker tilstedeværelse, ikke kvalitet: en Content-Security-Policy som tillater alt, teller som til stede. Og ikke jakt på det siste poenget: MDN markerer X-XSS-Protection som utdatert og anbefaler å ikke bruke den i nye prosjekter (MDN, X-XSS-Protection). Et godt sikret moderne nettsted kan med vilje ligge på 86% (6 av 7). OWASP Secure Headers Project dokumenterer de anbefalte verdiene for hver header (OWASP Secure Headers Project).
Hvordan påvirker caching- og komprimeringsheaderne hastigheten?
De avgjør hvor mye en tilbakevendende besøkende laster ned på nytt, og hvor tung hver respons er.
- Cache-Control setter reglene. «max-age=N» holder et svar friskt i N sekunder. «no-cache» tillater lagring, men krever sjekk mot serveren før hver gjenbruk. «no-store» forbyr lagring (MDN, Cache-Control).
- ETag og Last-Modified lar nettleseren spørre om en fil har endret seg, og få et kort svar i stedet for hele filen når den ikke har endret seg.
- Age viser hvor lenge et CDN har beholdt svaret: en verdi betyr at det kom fra en cache.
- Vary lister opp forespørselsheaderne som endrer svaret, for eksempel Accept-Encoding.
- Content-Encoding viser komprimeringen: gzip, br (Brotli) eller zstd. En HTML-side uten komprimering laster ned flere ganger mer enn nødvendig.
Et vanlig mønster: statiske filer med versjonerte navn får en lang max-age, ofte med «immutable». HTML får en kort max-age eller «no-cache», slik at oppdateringer vises med en gang. Mål effekten på hele siden med sjekkeren for sidestørrelse.
Hvordan ser et sunt svar ut?
Her er et typisk sett med headere for en HTML-side som kan indekseres, er fornuftig cachet, komprimert og sikret, med det hver linje forteller deg.
| Header som returneres | Tolkning |
|---|---|
| HTTP-status 200 | Siden svarer normalt og kan indekseres |
| Content-Type: text/html; charset=utf-8 | En HTML-side med en erklært tegnkoding |
| Content-Encoding: br | Komprimert med Brotli |
| Cache-Control: max-age=300 | Cachet i fem minutter, så oppdateringer vises raskt |
| Vary: Accept-Encoding | Cacher holder komprimerte og ukomprimerte versjoner atskilt |
| Strict-Transport-Security: max-age=31536000 | Bare HTTPS i ett år |
| Ingen X-Robots-Tag | Ingen skjult indekseringsbegrensning |
Ser du «X-Robots-Tag: noindex» på en side du vil ha med i Google, eller en 302 der du forventet en 301, fiks det før alt annet.
Når bør du kontrollere headerne dine?
- En side forsvant fra Google og HTML-en ser fin ut: se etter en X-Robots-Tag, og bekreft deretter med sjekkeren for indekserbarhet.
- Etter en migrering, en CDN-endring eller en ny hostingplan, når regler for omdirigering, cache og sikkerhet skrives om i bulk.
- Etter at en staging-side går live, siden en generell «noindex»-header satt på testserveren ofte overlever flyttingen.
- Før en ytelsesøkt, for å se hva som er cachet, hva som er komprimert, og hva som er verken eller.
- For PDF-filer og bilder du vil ha indeksert, eller holdt utenfor, siden headere er den eneste måten å gi dem instrukser på.
Hva er begrensningene ved kontrollen?
Verktøyet ser det egen forespørselen får. Noen servere svarer ulikt avhengig av besøkende: en brannmur kan blokkere ukjente roboter, et CDN kan variere etter land, og noen nettsteder gir søkemotorroboter et annet svar. Hvis resultatet overrasker deg, sammenlign det med URL-inspeksjonsverktøyet i Google Search Console, som viser hva Googlebot fikk. Rapporten viser også bare svaret for den endelige adressen. Mellomliggende omdirigeringer hører til omdirigeringssjekkeren.
Hvordan holder du headerne riktige på hele nettstedet?
Kontroller maler, ikke enkeltsider. Headere settes vanligvis én gang i konfigurasjonen av serveren, CDN-et eller rammeverket, så én feil regel påvirker tusenvis av adresser. Etter hver infrastrukturendring kontrollerer du én adresse av hver type: forside, artikkel, produkt, PDF og bilde.
For en bredere teknisk gjennomgang, kjør revisjonen av SEO på siden, og se ordlisteoppføringen vår om teknisk SEO-revisjon. For å følge effekten av rettelsene dine på trafikk og AI-svar, bruk Sorank GEO- og SEO-dashbordet, eller spør Sorank SEO-chatten hva en header betyr for nettstedet ditt.
Statuskode, X-Robots-Tag, kanonisk adresse, deretter cache og sikkerhet: det er rekkefølgen som beskytter rangeringene dine først. Kontroller nøkkeladressene dine med verktøyet over, og se deretter Sorank-planene for å overvåke nettstedet ditt på autopilot.
