Webbplatsen låter dig inte ladda upp ett tema eftersom filen är för stor. Sökmotorer indexerar adminsidor som inte borde visas i resultaten. Serverloggarna visar åtkomstförsök till wp-config.php från okända IP-adresser. Tre problem, en lösning: .htaccess-filen som redan ligger i din WordPress-sajts rotkatalog.

Du har förmodligen sett den när du ställde in snygga permalänkar. Men .htaccess-funktionerna sträcker sig långt utöver det: den styr åtkomst, säkerhet, omdirigeringar och uppladdningsgränser på servernivå. Och till skillnad från säkerhetsplugins belastar den inte PHP.

Här är fyra praktiska scenarier som varje WordPress-administratör ställs inför. Varje scenario innehåller färdig kod, en förklaring och vägledning om exakt var den ska infogas. Koden är skriven för Apache 2.4 (den aktuella versionen från och med 2026), men varje kodsnutt innehåller ett kompatibilitetsblock för Apache 2.2 så att du slipper undra om det fungerar på ditt webbhotell.

💡 Snabb översikt:

• Öka filuppladdningsgränser via .htaccess och .user.ini för PHP-FPM.
• Blockera sökmotorindexering på servernivå.
• Inaktivera katalogvisning med en enda rad.
• Skydda wp-config.php från direkt åtkomst med modern Apache 2.4-syntax.

1. Öka maximal filuppladdningsstorlek

Du försöker installera ett tema eller en plugin, och WordPress ger ett felmeddelande: "Den uppladdade filen överskrider upload_max_filesize-direktivet i php.ini." Standardgränsen på många webbhotell är 2 MB eller 8 MB, och ditt temaarkiv får inte plats.

Du kan inte redigera php.ini på delade webbhotell. Men om Apache körs med mod_php-modulen kan du höja gränsen direkt från .htaccess. Öppna filen i din sajts rotkatalog (via FTP eller ditt webbhotells filhanterare) och lägg till detta i slutet:

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

Det första direktivet anger maximal storlek för POST-förfrågningar, det andra anger maximal storlek för en enskild uppladdad fil. Båda värdena bör matcha, eller så bör post_max_size vara något större.

Kontrollera resultatet: gå till WordPress adminpanel, Media → Lägg till ny. Den aktuella gränsen visas längst ner.

Viktigt: om ditt webbhotell använder PHP-FPM (vilket de flesta gör 2026) kommer php_value-direktiven i .htaccess inte att fungera. För att kontrollera: Verktyg → Webbplatshälsa → Info → Server. Leta efter FPM på raden "Serverarkitektur". För sådana webbhotell ändrar du gränsen via en .user.ini-fil i sajtens rotkatalog:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Formatet är som php.ini, med likhetstecken istället för php_value. Ändringar tillämpas omedelbart utan att servern behöver startas om. Om det inte finns någon .user.ini-fil i rotkatalogen, skapa en.

2. Blockera sökmotorindexering

Situationen: en testsajt på en underdomän, en staging-kopia eller en landningssida som inte bör visas i Google- eller Yandex-resultat. En enkel robots.txt med Disallow: / kan ignoreras av sökmotorer: det är en rekommendation, inte ett förbud.

Den vattentäta metoden är att blockera bottar på servernivå. Den klassiska metoden med SetEnvIfNoCase fungerar i Apache 2.4 via kompatibilitetsmodulen mod_access_compat, men den anses vara föråldrad. Den moderna metoden omdirigerar bottar med en tom User-Agent via mod_rewrite:

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

Här är vad som händer: RewriteCond kontrollerar User-Agent för varje förfrågan. När den upptäcker nyckelorden bot, spider, crawler eller scanner (skiftlägesokänsligt tack vare [NC]-flaggan) returnerar servern 403 Forbidden ([F]-flaggan).

Fyra mönster räcker för att blockera alla större sökmotorer: Googlebot, YandexBot, Bingbot, Yahoo Slurp och dussintals mindre kända. Att lista varje bot individuellt är meningslöst: enbart Google har flera dussin User-Agent-varianter för olika tjänster (sök, bilder, video, AdsBot).

Vill du bara blockera Yandex men lämna Google ifred? Begränsa mönstret:

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

Symbolen ^ betyder "början av strängen". Utan den skulle regeln också fånga bottar som har yandex någonstans i mitten av sin User-Agent.

Viktigt: om WordPress redan använder mod_rewrite för snygga permalänkar finns RewriteEngine On-blocket redan i .htaccess. Duplicera det inte; lägg bara till de nya RewriteCond och RewriteRule efter de befintliga WordPress-reglerna men före den avslutande </IfModule>-taggen.

Efter ändringar, kontrollera .htaccess för fel: ett stavfel i direktiven kommer att fälla sajten med ett 500-fel. Du kan verifiera syntaxen med en onlinevalidator eller kommandot apachectl configtest (inte tillgängligt på alla webbhotell). Innan du redigerar, ladda alltid ner en säkerhetskopia av din nuvarande .htaccess.

3. Inaktivera katalogvisning

Gå till din sajt på /wp-content/uploads/. Om du istället för ett 403-fel ser en fillista har du katalogvisning aktiverat. Detta är ett säkerhetshål: vem som helst kan studera din mappstruktur, hitta en sårbar plugin eller läsa ett uppladdat PDF-dokument.

Det inaktiveras med en enda rad i .htaccess:

1
Options -Indexes

Lägg till den i början av filen, före WordPress-reglerna. När någon nu försöker öppna en katalog utan en indexfil kommer servern att returnera 403 Forbidden.

På de flesta moderna webbhotell är detta alternativ aktiverat som standard, men kontrollera ändå, särskilt om sajten har flyttats mellan servrar eller om du arbetar med en VPS där Apache konfigurerades manuellt.

4. Skydda wp-config.php från direkt åtkomst

wp-config.php är den viktigaste WordPress-filen. Den innehåller säkerhetsnycklar, tabellprefixet och databasuppgifter: databasnamn, användare, lösenord och värd.

Själva filen är skriven i PHP och returnerar en tom sida när den öppnas direkt i en webbläsare eftersom WordPress-motorn inte kör den. Men om PHP-bearbetning tillfälligt är inaktiverad på servern (konfigurationsfel, moduluppdatering) kan innehållet i wp-config.php serveras som ren text. Tillsammans med databaslösenordet.

Vi blockerar åtkomst via .htaccess. De flesta artiklar på internet erbjuder föråldrad Apache 2.2-syntax som inte fungerar i Apache 2.4.6 och högre. Här är den moderna versionen med bakåtkompatibilitet:

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-blocket kontrollerar förekomsten av modulen mod_authz_core (introducerad i Apache 2.4.6). Om modulen saknas tillämpas Apache 2.2-syntax. Om den finns används det moderna direktivet Require all denied. Ett kodblock fungerar på båda Apache-versionerna.

Efter att ha lagt till reglerna kommer varje webbläsarförfrågan till wp-config.php att få 403 Forbidden, även om PHP-hanteraren inte fungerar. WordPress kommer åt filen direkt via filsystemet, så regeln påverkar inte sajtens drift.

Samma tillvägagångssätt gäller för alla konfidentiella filer: ersätt wp-config.php med det filnamn du behöver, till exempel phpinfo.php eller .env.

⁉️🤔 Vanliga frågor

Kan jag klara mig utan.htaccess** i WordPress överhuvudtaget?**

Ja, om din sajt körs på Nginx istället för Apache. Nginx stöder inte .htaccess; alla regler ställs in i serverkonfigurationen (nginx.conf eller en fil i sites-available/). På delade webbhotell är det nästan alltid Apache, och .htaccess är tillgängligt. På VPS med Nginx flyttas regler till server {}-sektionen: syntaxen är annorlunda, men logiken är densamma. Till exempel är Nginx-motsvarigheten till Options -Indexes autoindex off;.

Vad ska jag göra om sajten kraschar med ett 500-fel efter att ha ändrat.htaccess?

Återställ omedelbart säkerhetskopian av .htaccess som du gjorde innan redigeringen (du gjorde väl en?). Anslut via FTP, ta bort den modifierade .htaccess och ladda upp den sparade originalfilen. Sajten kommer tillbaka direkt. Ett 500-fel efter redigering av .htaccess orsakas nästan alltid av ett stavfel i ett direktiv eller en konstruktion som din version av Apache inte stöder.

Varför fungerar inte php_value i.htaccess på mitt webbhotell?

Troligtvis använder ditt webbhotell PHP-FPM istället för mod_php. Kontrollera: Verktyg → Webbplatshälsa → Info → Server. Om FPM visas på raden "Serverarkitektur" ignoreras php_value i .htaccess. Använd en .user.ini-fil i sajtens rotkatalog (se avsnitt 1) eller kontakta ditt webbhotells support. På VPS ändras gränser i PHP-FPM-poolen (www.conf), men detta kräver åtkomst till serverkonfigurationen.

Hur verifierar jag att.htaccess faktiskt fungerar?

Det enklaste testet är regeln från avsnitt 3 (Options -Indexes). Besök /wp-content/uploads/ före och efter att du lagt till den. Fanns det en fillista tidigare, och nu ett 403-fel? Filen fungerar. En annan metod: lägg till en rad med ett avsiktligt syntaxfel i .htaccess och öppna sajten. Ett 500-fel bekräftar att Apache läser .htaccess. Ta bort testraden omedelbart efter kontrollen.

Är det säkert att använda koden från denna artikel på en live-sajt?

Ja, alla medföljande kodsnuttar har testats på Apache 2.4 (den aktuella versionen från och med 2026) och innehåller kompatibilitetsblock för Apache 2.2. Det enda obligatoriska kravet: innan någon .htaccess-redigering, ladda ner den aktuella versionen av filen till din dator. Denna femsekundersoperation sparar timmar av återställning vid ett stavfel. Och redigera inte .htaccess via plugins; använd endast FTP eller ditt webbhotells filhanterare: en plugin kan lägga till escaping som förstör syntaxen.

Hur skiljer sig tillvägagångssättet för att skydda wp-config.php i denna artikel från vad andra sajter skriver?

De flesta artiklar kopierar Apache 2.2-syntax: Order allow,deny och Deny from all. Dessa direktiv tillhör modulen mod_access_compat, som är föråldrad i Apache 2.4 och kan vara inaktiverad på moderna servrar. Vår kodsnutt använder Require all denied från modulen mod_authz_core, vilket är den aktuella standarden för Apache 2.4.6 och högre. Samtidigt bibehåller <IfModule>-blocket funktionalitet på äldre servrar.

Vad du ska lägga till i din.htaccess-konfiguration just nu

Filen .htaccess är kompakt men kraftfull. Av de fyra beskrivna teknikerna täpper två till sårbarheter med minimal ansträngning: inaktivering av katalogvisning och skydd av wp-config.php. Det är en rad och ett kodblock du kan lägga till just nu, och de påverkar inte sajtens drift.

Att öka uppladdningsgränsen hjälper varje gång WordPress vägrar ladda upp ett tema eller en plugin. Och att blockera indexering på servernivå är den sista försvarslinjen för privata sajter och testsajter.

Ha en säkerhetskopia av .htaccess före varje redigering. Ett syntaxfel fäller sajten omedelbart, och det åtgärdas lika omedelbart om du har en kopia till hands. Med denna regel i åtanke förvandlas .htaccess från en skrämmande fil till ett fungerande verktyg.