403 Forbidden: Hva betyr feilen, og hvordan fikser du den?

403 Forbidden betyr at serveren har forstått forespørselen, men nekter å vise siden. Som besøkende kan du sjelden gjøre noe annet enn å laste siden på nytt, tømme hurtigbufferen eller slå av VPN. Som eier skyldes feilen nesten alltid filrettigheter, en .htaccess-regel, manglende indeksfil eller en brannmur som blokkerer feil trafikk.

Hva betyr 403 Forbidden?

403 Forbidden er en HTTP-statuskode som betyr at serveren har mottatt og forstått forespørselen, men ikke vil utføre den. Siden eller filen finnes, men du har ikke lov til å se den. Slik står det i HTTP-standarden RFC 9110, avsnitt 15.5.4, som er den gjeldende definisjonen av statuskodene.

Forskjellen fra 401 er viktig for feilsøkingen. Ifølge MDN sin oversikt over statuskoder kjenner serveren allerede til hvem klienten er ved en 403, i motsetning til ved 401. Det hjelper altså ikke å logge inn på nytt, for tilgangen er nektet med vilje eller fordi noe er satt opp feil. Feilen kan vises som «403 Forbidden», «Access Denied», «You don't have permission to access this resource» eller som en egen feilside fra Cloudflare eller webhotellet.

Er det din feil eller nettstedets?

Treffer du en 403 på en nettside du ikke eier, ligger feilen nesten alltid hos nettstedet. Du kan prøve noen raske ting, men du kan ikke rette selve årsaken. Eier du nettstedet, ligger både årsaken og løsningen hos deg eller leverandøren din.

Hvis du er besøkende

• Sjekk adressen. Mange servere svarer med 403 når du åpner en mappe i stedet for en side, for eksempel /bilder/ uten filnavn.
• Last siden på nytt med Ctrl+Shift+R (Cmd+Shift+R på Mac), eller prøv et privat vindu. Da utelukker du gamle informasjonskapsler og hurtigbuffer.
• Slå av VPN eller proxy. Brannmurer blokkerer ofte IP-adresser fra VPN-tjenester og fra enkelte land.
• Fungerer det på mobilnettet, men ikke på jobbnettet, er det trolig IP-adressen deres som er blokkert. Gi beskjed til nettstedet.

Hvis du eier nettstedet

Start med å finne ut hvem som får feilen. Rammer den alle besøkende, ligger årsaken som regel på serveren, for eksempel i rettigheter, .htaccess eller en indeksfil. Rammer den bare noen, som enkelte land, Googlebot eller kunder bak et bestemt nett, er det nesten alltid en brannmur eller et sikkerhetstillegg som blokkerer dem. Den forskjellen alene kan spare deg for en time med feilsøking.

Hva er de vanligste årsakene til 403-feil?

De fleste 403-feil skyldes én av seks ting: feil filrettigheter, en feil i .htaccess, manglende indeksfil, en brannmur som blokkerer for mye, et sikkerhetstillegg, eller at Googlebot er blokkert uten at noen har ment det. Tabellen viser hva hver årsak typisk fører til, og hvor du retter den.

Én årsak overrasker mange: Apache-servere svarer med 403 når noen ber om en mappe som ikke har en indeksfil, så lenge mappevisning er slått av. Det skjer ofte etter at nettstedet er flyttet til et nytt webhotell, hvis index.php ikke ble med eller serveren leter etter et annet filnavn. Feilmeldingen sier «Forbidden», men det som faktisk har skjedd, er at en fil mangler.

Hvordan fikser du en 403-feil på din egen nettside?

Gå gjennom årsakene fra den raskeste og tryggeste til den mest inngripende. Ta alltid en sikkerhetskopi før du endrer filer på serveren. Rekkefølgen under er den vi selv bruker, fordi de fem første stegene løser de fleste tilfellene uten at du trenger å røre koden.

Feilsøking steg for steg

• 1) Finn ut hvem som rammes. Test fra mobilnett, fra et annet nett og med URL-inspeksjon i Google Search Console. Får bare Googlebot 403, hopper du rett til steg 5.
• 2) Tenk etter hva som ble endret sist. En oppdatering, et nytt tillegg, flytting til ny server eller en ny DNS-innstilling er nesten alltid utløseren.
• 3) Sjekk .htaccess. Gi filen nytt navn (for eksempel .htaccess-gammel) og last siden på nytt. Virker den nå, ligger feilen i en regel. I WordPress lager du en ny, ren fil ved å lagre permalenkene på nytt under Innstillinger.
• 4) Kontroller filrettighetene: 644 for filer og 755 for mapper. Sett aldri 777 for å «få det til å virke». Det åpner for angrep.
• 5) Gå gjennom brannmurloggen hos Cloudflare eller webhotellet. Finn forespørselen som ble blokkert, og se hvilken regel som slo til. Slå av land-sperrer og robotfiltre midlertidig hvis du er i tvil.
• 6) Slå av sikkerhetstillegg ett om gangen. Kommer du ikke inn i wp-admin, gir du tilleggets mappe under wp-content/plugins nytt navn via SFTP.
• 7) Sjekk at indeksfilen finnes i rotmappen, og at domenet peker til riktig mappe på serveren.
• 8) Får du fortsatt feil, ber du webhotellet om feilloggen (error_log) for tidspunktet. Der står den eksakte årsaken, og den tar ofte bare minutter å finne for supporten.

Riktige filrettigheter i WordPress

WordPress sin egen dokumentasjon om filrettigheter anbefaler 755 for mapper og 644 for filer. For wp-config.php, som inneholder passordet til databasen, er strengere verdier som 440 eller 400 vanlige, men hva som fungerer, avhenger av hvordan webhotellet kjører PHP. Blir siden hvit eller gir 403 etter at du har strammet inn, går du tilbake til 640 eller 600 og spør webhotellet. Har noen satt 777 på mapper fordi «det løste problemet», bør du se på det som et varsel om sikkerheten. Les gjennom hva du gjør hvis WordPress er hacket for å sjekke at ingen har utnyttet det.

Cloudflare og brannmurer

Brannmurer er den årsaken til 403 vi ser vokse mest. Robotfiltre, land-sperrer og strenge WAF-regler stopper ofte reelle kunder og søkemotorer i tillegg til angrepstrafikken. Det vi ser oftest, er bedrifter som har sperret all trafikk fra utlandet for å «stoppe spam», og dermed også stoppet Googlebot, som i hovedsak henter sider fra amerikanske IP-adresser. Vi fraråder land-sperrer på et offentlig nettsted. Sperr heller wp-login.php og wp-admin enn hele nettstedet.

Hva gjør 403 med Google og AI-svar i søk?

En 403 som Googlebot får, fører over tid til at siden fjernes fra Google. Ifølge Googles dokumentasjon om statuskoder indekserer ikke Google nettadresser som svarer med en 4xx-kode, og adresser som allerede ligger i indeksen, blir fjernet. Google behandler alle 4xx-koder unntatt 429 likt, som om innholdet ikke finnes.

Det gjelder også AI-svarene. AI Overviews og AI-modus i Google bygger på det Google har kunnet hente og indeksere. En side som svarer med 403 til Googlebot, kan derfor ikke siteres i AI-svarene heller. Mange slår i tillegg på blokkering av AI-roboter hos Cloudflare uten å vite hvilke roboter som rammes. Bestem deg bevisst for hvilke roboter du vil sperre ute, og test etterpå med URL-inspeksjon. Se også våre tips om søkemotoroptimalisering.

Fallgruven med robots.txt

Svarer robots.txt-filen med 403, skjer det motsatte av det mange tror. Googles tolkning av robots.txt-standarden sier at alle 4xx-feil unntatt 429 behandles som om det ikke finnes noen gyldig robots.txt. Da antar Google at det ikke er noen begrensninger. Har du sperret ute administrasjonsområder, testmiljøer eller filtersider i robots.txt, kan en 403 på selve filen gjøre at Google begynner å hente alt sammen. Åpne dittdomene.no/robots.txt og sjekk at filen svarer med 200.

Bruk aldri 403 til å bremse Googlebot

Google skriver i samme dokumentasjon at du ikke skal bruke 401 eller 403 for å begrense hvor ofte Google henter sider, fordi 4xx-koder unntatt 429 ikke har noen effekt på hentefrekvensen. Er serveren overbelastet, gir du heller 503 eller 429 i noen timer. Da forstår Google at dette er midlertidig, og sidene beholder plassen i indeksen. Dette er særlig viktig for nettbutikker med mange filtersider. Les mer om søkemotoroptimalisering i WordPress.

403, 401, 404 eller 429: hvilken kode skal du bruke?

Bruk 403 når innholdet finnes og brukeren skal vite det, men ikke har tilgang. Bruk 404 når du vil skjule at innholdet finnes. Bruk 429 eller 503 når serveren trenger pause. RFC 9110 åpner uttrykkelig for at serveren kan svare med 404 i stedet for 403 for å skjule at en side finnes.

Hvorfor dukker 403 opp etter flytting eller redesign?

Flytting til nytt webhotell, ny plattform eller nytt design er den vanligste enkeltgrunnen til 403-feil vi ser. Rettighetene følger ikke alltid med når filene kopieres. .htaccess-regler fra den gamle serveren passer ikke på den nye. Brannmuren hos den nye leverandøren har andre standardinnstillinger. Og gamle nettadresser som skulle fått 301-omdirigering, gir 403 i stedet.

Ved plattformbytter med korrekt 301-plan beholder Box sine kunder normalt 90–98 % av organisk trafikk gjennom migreringen.

Det forutsetter at omdirigeringene faktisk når fram. Svarer de gamle adressene med 403, ser Google en sperret side i stedet for en omdirigering, og trafikken forsvinner. Vårt råd er å hente ut alle gamle adresser før flyttingen og kjøre dem gjennom en statussjekk rett etter at du har byttet. Se hvordan du planlegger redesign av nettsiden, og bruk et verktøy for å sjekke nettsider for feilkoder.

Hva koster det å få rettet en 403-feil?

Feil i rettigheter, .htaccess eller en indeksfil tar normalt kort tid å rette når årsaken er funnet. Feilsøking i brannmurregler, et hacket nettsted eller en flytting som har gått galt, tar mer tid. Prisen avhenger av timeprisen til leverandøren og av om nettstedet har en driftsavtale. Mange webhotell hjelper gratis med serverfeil som rettigheter og feillogger. Er feilen i et tillegg eller et tema, faller den som regel utenfor det webhotellet dekker.

Det dyreste er sjelden selve rettingen, men hvor lenge feilen får stå. En 403 på produktsider eller kontaktskjemaer betyr tapte henvendelser fra første dag, og sider som blir fjernet fra Google, må hentes og indekseres på nytt. Har du ingen fast avtale, bør du vurdere drift av nettsiden eller vedlikehold av WordPress, der oppetid og feilkoder overvåkes. Se også hva en nettside koster totalt.

Når en 403 ikke er riktig svar fra serveren

403 er riktig når du med vilje sperrer noe som finnes, men ikke når du bruker koden til å skjule, slette eller bremse. Fire situasjoner går igjen der 403 gjør mer skade enn nytte:

• Slettede sider: Bruk 404 eller 410, eller en 301-omdirigering til den nærmeste relevante siden. Med 403 ser det ut som om siden finnes, men er sperret.
• Sensitive adresser som ikke skal avsløres, som gamle sikkerhetskopier eller testmiljøer: 404 avslører mindre enn 403, som bekrefter at noe ligger der.
• Midlertidig overbelastning eller vedlikehold: 503 eller 429, aldri 403.
• Innhold som bare skal være skjult for Google, men åpent for brukerne: Bruk noindex. En 403 stenger også ute kunder som kommer fra delte lenker.

Bruker du en ferdig nettsidebygger som Wix eller Squarespace, har du sjelden tilgang til rettigheter eller .htaccess. Da er det leverandørens support som må rette feilen. Har du egen WordPress-installasjon, ligger ansvaret hos deg eller nettsideleverandøren din. Lurer du på om det er på tide med en mer robust løsning, kan du se hvordan vi bygger og drifter nettsider for bedrifter.