Nettstedet lar deg ikke laste opp et tema fordi filen er for stor. Søkemotorer indekserer adminsider som ikke skal vises i resultatene. Serverloggene viser tilgangsforsøk til wp-config.php fra ukjente IP-adresser. Tre problemer, én løsning: .htaccess-filen som allerede ligger i rotmappen til WordPress-nettstedet ditt.

Du har sannsynligvis sett den da du satte opp pene permalenker. Men .htaccess-mulighetene strekker seg langt utover det: den styrer tilgang, sikkerhet, omdirigeringer og opplastingsgrenser på servernivå. Og i motsetning til sikkerhetsplugins, legger den ingen belastning på PHP.

Nedenfor finner du fire praktiske scenarioer hver WordPress-administrator møter. Hvert scenario inkluderer klar-til-bruk-kode, en forklaring og veiledning om nøyaktig hvor den skal settes inn. Koden er skrevet for Apache 2.4 (gjeldende versjon per 2026), men hver kodebit inkluderer en kompatibilitetsblokk for Apache 2.2, slik at du slipper å lure på om den vil fungere på din hosting.

💡 Rask oversikt:

• Øk filopplastingsgrenser gjennom .htaccess og .user.ini for PHP-FPM.
• Blokker søkemotorindeksering på servernivå.
• Deaktiver mappegjennomgang med én enkelt linje.
• Beskytt wp-config.php mot direkte tilgang ved hjelp av moderne Apache 2.4-syntaks.

1. Øke maksimal filopplastingsstørrelse

Du prøver å installere et tema eller en plugin, og WordPress kaster en feilmelding: «The uploaded file exceeds the upload_max_filesize directive in php.ini.» Standardgrensen hos mange hoster er 2 MB eller 8 MB, og temaarkivet ditt får ikke plass.

Du kan ikke redigere php.ini på delt hosting. Men hvis Apache kjører med mod_php-modulen, kan du øke grensen direkte fra .htaccess. Åpne filen i nettstedets rotmappe (via FTP eller vertens filbehandler) og legg til dette på slutten:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

Det første direktivet angir maksimal størrelse på POST-forespørselen, det andre angir maksimal størrelse for én enkelt opplastet fil. Begge verdiene bør være like, eller så bør post_max_size være litt større.

Sjekk resultatet: gå til WordPress-administrasjonspanelet, Media → Legg til ny. Gjeldende grense vises nederst.

Viktig: hvis verten din bruker PHP-FPM (noe de fleste gjør i 2026), vil ikke php_value-direktivene i .htaccess fungere. For å sjekke: Verktøy → Nettstedshelse → Info → Server. Se etter FPM på linjen «Serverarkitektur». For slik hosting endrer du grensen via en .user.ini-fil i nettstedets rotmappe:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Formatet er som php.ini, med likhetstegn i stedet for php_value. Endringer trer i kraft umiddelbart uten at serveren må startes på nytt. Hvis det ikke finnes noen .user.ini-fil i rotmappen, opprett en.

2. Blokkere søkemotorindeksering

Situasjonen: et testsite på et underdomene, en staging-kopi eller en landingsside som ikke skal vises i Google- eller Yandex-resultater. En enkel robots.txt med Disallow: / kan ignoreres av søkemotorer: det er en anbefaling, ikke et forbud.

Den vanntette metoden er å blokkere roboter på servernivå. Den klassiske tilnærmingen med SetEnvIfNoCase fungerer i Apache 2.4 via kompatibilitetsmodulen mod_access_compat, men den regnes som utdatert. Den moderne metoden omdirigerer roboter med tom User-Agent gjennom mod_rewrite:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Her er hva som skjer: RewriteCond sjekker User-Agent for hver forespørsel. Når den oppdager nøkkelordene bot, spider, crawler eller scanner (uavhengig av store/små bokstaver på grunn av [NC]-flagget), returnerer serveren 403 Forbidden ([F]-flagget).

Fire mønstre er nok til å blokkere alle store søkemotorer: Googlebot, YandexBot, Bingbot, Yahoo Slurp og dusinvis av mindre kjente. Å liste hver enkelt bot individuelt er meningsløst: Google alene har flere dusin User-Agent-variasjoner for ulike tjenester (søk, bilder, video, AdsBot).

Vil du bare blokkere Yandex og la Google være i fred? Smaln inn mønsteret:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

Symbolet ^ betyr «starten av strengen». Uten det ville regelen også fanget opp roboter som har yandex et sted midt i User-Agenten sin.

Viktig: hvis WordPress allerede bruker mod_rewrite for pene permalenker, finnes RewriteEngine On-blokken allerede i .htaccess. Ikke dupliser den; bare legg til de nye RewriteCond og RewriteRule etter de eksisterende WordPress-reglene, men før den avsluttende </IfModule>-taggen.

Etter at du har gjort endringer, sjekk .htaccess for feil: en skrivefeil i direktivene vil ta ned nettstedet med en 500-feil. Du kan bekrefte syntaksen med en online validator eller kommandoen apachectl configtest (ikke tilgjengelig hos alle hoster). Før du redigerer, last alltid ned en sikkerhetskopi av din nåværende .htaccess.

3. Deaktivere mappegjennomgang

Gå til nettstedet ditt på /wp-content/uploads/. Hvis du ser en filliste i stedet for en 403-feil, har du mappegjennomgang aktivert. Dette er et sikkerhetshull: hvem som helst kan studere mappestrukturen din, finne en sårbar plugin eller lese et opplastet PDF-dokument.

Det deaktiveres med én enkelt linje i .htaccess:

1
Options -Indexes

Legg den til i begynnelsen av filen, før WordPress-reglene. Nå vil serveren returnere 403 Forbidden når noen prøver å åpne en mappe uten en indeksfil.

Hos de fleste moderne hostene er dette alternativet aktivert som standard, men sjekk likevel, spesielt hvis nettstedet har flyttet mellom servere eller du jobber med en VPS der Apache ble konfigurert manuelt.

4. Beskytte wp-config.php mot direkte tilgang

wp-config.php er den viktigste WordPress-filen. Den inneholder sikkerhetsnøkler, tabellprefikset og databaselegitimasjon: databasenavn, bruker, passord og vert.

Selve filen er skrevet i PHP og returnerer en blank side når den åpnes direkte i en nettleser, fordi WordPress-motoren ikke kjører den. Men hvis PHP-prosessering er midlertidig deaktivert på serveren (konfigurasjonsfeil, moduloppdatering), kan innholdet i wp-config.php bli servert som ren tekst. Sammen med databasepassordet.

Vi blokkerer tilgang via .htaccess. De fleste artikler på internett tilbyr utdatert Apache 2.2-syntaks som ikke fungerer i Apache 2.4.6 og høyere. Her er den moderne versjonen med bakoverkompatibilitet:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

IfModule-blokken sjekker tilstedeværelsen av mod_authz_core-modulen (introdusert i Apache 2.4.6). Hvis modulen er fraværende, gjelder Apache 2.2-syntaks. Hvis den er til stede, brukes det moderne direktivet Require all denied. Én kodeblokk fungerer på begge Apache-versjoner.

Etter at du har lagt til reglene, vil enhver nettleserforespørsel til wp-config.php motta 403 Forbidden, selv om PHP-behandleren ikke fungerer. WordPress får tilgang til filen direkte gjennom filsystemet, så regelen påvirker ikke nettstedets drift.

Samme tilnærming gjelder for enhver konfidensiell fil: bytt ut wp-config.php med filnavnet du trenger, for eksempel phpinfo.php eller .env.

⁉️🤔 Ofte stilte spørsmål

Kan jeg klare meg uten.htaccess** i WordPress i det hele tatt?**

Ja, hvis nettstedet ditt kjører på Nginx i stedet for Apache. Nginx støtter ikke .htaccess; alle regler settes i serverkonfigurasjonen (nginx.conf eller en fil i sites-available/). På delt hosting er det nesten alltid Apache, og .htaccess er tilgjengelig. På VPS med Nginx flyttes regler til server {}-seksjonen: syntaksen er annerledes, men logikken er den samme. For eksempel er Nginx-ekvivalenten til Options -Indexes autoindex off;.

Hva bør jeg gjøre hvis nettstedet krasjer med en 500-feil etter endring av.htaccess?

Gjenopprett umiddelbart sikkerhetskopien av .htaccess som du tok før redigering (du tok en, ikke sant?). Koble til via FTP, slett den endrede .htaccess og last opp den lagrede originalen. Nettstedet vil være tilbake umiddelbart. En 500-feil etter redigering av .htaccess skyldes nesten alltid en skrivefeil i et direktiv eller en konstruksjon som din versjon av Apache ikke støtter.

Hvorfor fungerer ikke php_value i.htaccess på min hosting?

Mest sannsynlig bruker verten din PHP-FPM i stedet for mod_php. Sjekk: Verktøy → Nettstedshelse → Info → Server. Hvis FPM vises på linjen «Serverarkitektur», ignoreres php_value i .htaccess. Bruk en .user.ini-fil i nettstedets rotmappe (se avsnitt 1) eller kontakt vertens support. På VPS endres grenser i PHP-FPM-poolen (www.conf), men dette krever tilgang til serverkonfigurasjon.

Hvordan bekrefter jeg at.htaccess faktisk fungerer?

Den enkleste testen er regelen fra avsnitt 3 (Options -Indexes). Besøk /wp-content/uploads/ før og etter at du legger den til. Var det en filliste før, og nå en 403-feil? Filen fungerer. En annen metode: legg til en linje med en bevisst syntaksfeil i .htaccess og åpne nettstedet. En 500-feil bekrefter at Apache leser .htaccess. Fjern testlinjen umiddelbart etter kontroll.

Er det trygt å bruke koden fra denne artikkelen på et live-nettsted?

Ja, alle kodebitene som er gitt, er testet på Apache 2.4 (gjeldende versjon per 2026) og inkluderer kompatibilitetsblokker for Apache 2.2. Det eneste obligatoriske kravet: før enhver .htaccess-redigering, last ned gjeldende versjon av filen til datamaskinen din. Denne operasjonen på fem sekunder sparer timer med gjenoppretting i tilfelle en skrivefeil. Og ikke rediger .htaccess gjennom plugins; bruk kun FTP eller vertens filbehandler: en plugin kan legge til escaping som ødelegger syntaksen.

Hvordan skiller tilnærmingen til å beskytte wp-config.php i denne artikkelen seg fra det andre nettsteder skriver?

De fleste artikler kopierer Apache 2.2-syntaks: Order allow,deny og Deny from all. Disse direktivene tilhører mod_access_compat-modulen, som er utdatert i Apache 2.4 og kan være deaktivert på moderne servere. Vår kodebit bruker Require all denied fra mod_authz_core-modulen, som er gjeldende standard for Apache 2.4.6 og høyere. Samtidig opprettholder <IfModule>-blokken funksjonalitet på eldre servere.

Hva du bør legge til i din.htaccess-konfigurasjon akkurat nå

Filen .htaccess er kompakt, men kraftfull. Av de fire beskrevne teknikkene lukker to sårbarheter med minimal innsats: deaktivering av mappegjennomgang og beskyttelse av wp-config.php. Det er én linje og én kodeblokk du kan legge til akkurat nå, og de påvirker ikke nettstedets drift.

Å øke opplastingsgrensen hjelper hver gang WordPress nekter å laste opp et tema eller en plugin. Og blokkering av indeksering på servernivå er den siste forsvarslinjen for private nettsteder og testsider.

Ta en sikkerhetskopi av .htaccess før hver redigering. En syntaksfeil tar ned nettstedet umiddelbart, og det fikses like umiddelbart hvis du har en kopi for hånden. Med denne regelen i bakhodet forvandles .htaccess fra en skummel fil til et praktisk verktøy.