1,210 26/03/2026 07/04/2026 13 min

HTACCESS WordPress: guida completa

Il file .htaccess è uno degli strumenti più utili per chi gestisce un sito WordPress su server Apache o LiteSpeed. Serve per riscrivere gli URL, impostare redirect, proteggere directory, migliorare la cache e applicare regole di sicurezza senza intervenire sul core di WordPress. È un file potente, ma va usato con attenzione: una sola riga errata può bloccare il sito con errore 500.

In questa guida trovi una struttura completa e pratica: dalla configurazione standard di WordPress fino alle regole più usate per sicurezza, performance, redirect e multisite. L’obiettivo è darti una base solida, riutilizzabile e facilmente adattabile al tuo hosting.

Prima di modificare .htaccess

Prima di fare qualsiasi modifica, salva sempre una copia del file originale. Se il sito usa cPanel, Plesk, FastPanel o un file manager del hosting, il metodo più semplice è scaricare o duplicare il file prima di editarlo. Se lavori da SSH, fai un backup con un nome diverso.

cp .htaccess .htaccess.bak

Se il sito va in errore dopo una modifica, ripristinare il backup è quasi sempre il modo più rapido per tornare online.

Struttura base di WordPress

La configurazione minima e corretta di WordPress su Apache è questa. È il punto di partenza da cui costruire il resto.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Queste regole fanno sì che gli URL “amichevoli” di WordPress funzionino correttamente. Se usi permalink personalizzati, questo blocco è indispensabile. In generale WordPress lo riscrive automaticamente, ma può essere utile sapere cosa contiene e come ripristinarlo manualmente.

Regole fondamentali: cosa fanno

Per capire davvero il file .htaccess, conviene conoscere le direttive più comuni.

  • RewriteEngine On: abilita il motore di riscrittura.
  • RewriteBase /: indica la base delle regole, utile soprattutto nella root del sito.
  • RewriteRule: definisce la regola di riscrittura o redirect.
  • RewriteCond: impone una condizione prima di applicare la regola.
  • [L]: stop processing, cioè non eseguire altre regole dopo questa.
  • [R=301]: redirect permanente.
  • [R=302]: redirect temporaneo.
  • [NC]: case-insensitive, non distingue maiuscole e minuscole.

Molti problemi nascono da regole duplicate o dall’ordine sbagliato. In Apache, infatti, l’ordine conta moltissimo: una regola posta sopra può impedire a quelle sotto di funzionare.

Redirect 301: da HTTP a HTTPS

Uno degli usi più frequenti è forzare il sito in HTTPS. Se il certificato SSL è già installato e il sito risponde correttamente in HTTPS, questa è una delle prime regole da applicare.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Se il sito è dietro proxy o CDN, il controllo di HTTPS può cambiare. In alcuni casi il server vede la connessione come HTTP anche se il browser usa HTTPS. In quel caso bisogna adattare la regola alla configurazione del provider.

Redirect www o non-www

È buona pratica scegliere una sola versione canonica del dominio: con www oppure senza www. Questo aiuta SEO, coerenza dei link e gestione dei cookie.

Da non-www a www:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^tuodominio\.it$ [NC]
RewriteRule ^(.*)$ https://www.tuodominio.it/$1 [L,R=301]
</IfModule>

Da www a non-www:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.tuodominio\.it$ [NC]
RewriteRule ^(.*)$ https://tuodominio.it/$1 [L,R=301]
</IfModule>

Evita di usare entrambe le versioni contemporaneamente: si rischiano catene di redirect o loop infiniti.

Redirect da una vecchia pagina a una nuova

Quando cambi struttura URL o elimini contenuti, il redirect 301 è fondamentale per non perdere traffico e link esterni.

Redirect 301 /vecchia-pagina/ https://tuodominio.it/nuova-pagina/

Se la vecchia pagina ha una struttura complessa, puoi usare una riscrittura più flessibile:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^vecchia-sezione/(.*)$ /nuova-sezione/$1 [R=301,L]
</IfModule>

Usa il 301 per cambi permanenti. Il 302 va bene solo per test o spostamenti temporanei.

Proteggere il file wp-config.php

Il file wp-config.php contiene credenziali e chiavi sensibili. Se il server lo consente, puoi aggiungere questa regola per impedirne l’accesso via web:

<files wp-config.php>
order allow,deny
deny from all
</files>

Su Apache 2.4 alcuni hosting preferiscono una sintassi più moderna:

<Files wp-config.php>
Require all denied
</Files>

Se una delle due varianti non funziona, dipende dalla versione di Apache e dalla politica del provider. In caso di dubbio, verifica prima in staging.

Bloccare l’accesso a file sensibili

Puoi limitare anche altri file che non dovrebbero essere esposti pubblicamente.

<FilesMatch "(readme\.html|license\.txt|wp-config\.php|error_log)">
Require all denied
</FilesMatch>

Questa regola può essere utile, ma va valutata con attenzione: alcuni plugin o procedure di supporto potrebbero usare file come readme.html. Se il tuo hosting ha sistemi di diagnostica o aggiornamento che li leggono, meglio testare prima.

Limitare l’accesso a .htaccess

Il file .htaccess non deve mai essere scaricabile da browser. Di norma Apache lo impedisce già, ma una regola esplicita non fa male.

<Files .htaccess>
Require all denied
</Files>

Se il tuo ambiente usa una sintassi più vecchia, puoi trovare anche:

<Files .htaccess>
deny from all
</Files>

Disabilitare directory listing

Se una cartella non ha un index file, Apache potrebbe mostrare l’elenco dei file. Questo è sconsigliato per motivi di sicurezza e privacy.

Options -Indexes

È una delle regole più semplici e più utili. In molti casi conviene inserirla all’inizio del file, prima del blocco WordPress.

Bloccare hotlink delle immagini

L’hotlink avviene quando altri siti caricano direttamente le tue immagini, consumando banda e risorse del server. Puoi limitarlo così:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?tuodominio\.it/ [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC,L]
</IfModule>

Se usi CDN, social preview o servizi esterni, questa regola va adattata per non bloccare richieste legittime.

Protezione base contro accessi indesiderati

Puoi anche negare l’accesso a directory specifiche, ad esempio a cartelle di backup, upload temporanei o archivi sensibili.

<Directory "/percorso/della/cartella">
Require all denied
</Directory>

Attenzione: questa direttiva di solito non si usa dentro .htaccess su hosting condivisi, perché spesso è permessa solo nei file di configurazione del server. Se ricevi errore 500, probabilmente il provider non consente questa direttiva in quel contesto.

Cache browser per migliorare le prestazioni

Una delle ottimizzazioni più comuni è dire al browser di memorizzare temporaneamente file statici come immagini, CSS e JS.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 year"
</IfModule>

Questa regola migliora il caricamento per i visitatori abituali e riduce richieste ripetute. Verifica però che il tuo tema o plugin non cambi spesso file con lo stesso nome senza versioning, altrimenti la cache può mostrare asset vecchi.

Compressione Gzip o Brotli

Se il server lo supporta, puoi abilitare la compressione delle risorse testuali per ridurre il peso trasferito.

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/json image/svg+xml
</IfModule>

Su alcuni ambienti è già attiva a livello server o CDN. In quel caso duplicarla nel file .htaccess non porta vantaggi e, in rari casi, può creare conflitti. Meglio verificare con gli strumenti del browser o con un test HTTP.

Impostare headers di sicurezza

Molti webmaster aggiungono header di sicurezza direttamente in .htaccess quando non hanno accesso alla configurazione globale del server.

<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

Questi header aiutano a ridurre alcuni vettori di rischio. Non sostituiscono un hardening completo, ma sono una buona base. Se il sito usa embed esterni o iframe, X-Frame-Options va valutato con attenzione.

Bloccare file e cartelle di WordPress

Alcune cartelle o file non devono essere esposti all’indicizzazione o all’accesso diretto. Un esempio utile è bloccare la navigazione nelle directory sensibili.

Options -Indexes
<FilesMatch "^(readme\.html|license\.txt)$">
Require all denied
</FilesMatch>

Ricorda che i plugin di sicurezza spesso fanno già questo lavoro. Se ne usi più di uno, evita di duplicare regole simili senza controllo, perché potresti rendere più difficile la manutenzione.

Regole per WordPress in sottocartella

Se WordPress è installato in una sottocartella, ad esempio /blog, la struttura cambia. In questi casi il file .htaccess deve essere coerente con il percorso reale.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>

Se WordPress è nella sottocartella ma il dominio principale punta altrove, la configurazione va studiata con attenzione per evitare conflitti con altri applicativi presenti nello stesso hosting.

WordPress multisite: configurazione base

Per una rete WordPress multisite, il file .htaccess cambia leggermente. La configurazione dipende dal fatto che il network usi sottodirectory o sottodomini.

Esempio tipico per multisite in sottodirectory:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

La multisite è uno dei casi in cui è più facile rompere gli URL con una piccola modifica. Se gestisci un network, salva sempre il file prima di toccarlo e fai un test di login, navigazione e upload media.

Proteggere wp-login.php e wp-admin

Limitare l’accesso al backend può ridurre tentativi di brute force. Una soluzione semplice è consentire l’accesso solo da IP fidati.

<Files wp-login.php>
Require ip 1.2.3.4
</Files>

Oppure, per bloccare l’accesso a wp-admin tranne alcune condizioni:

<FilesMatch "^(wp-login\.php|wp-admin)$">
Require ip 1.2.3.4
</FilesMatch>

Questa è una misura efficace, ma va usata con cautela: se cambi rete o IP, potresti bloccarti fuori dal pannello. È meglio applicarla solo se hai un IP stabile o un accesso di emergenza alternativo.

Bloccare XML-RPC se non serve

Il file xmlrpc.php è spesso usato da app esterne o vecchi servizi, ma può essere un bersaglio per attacchi brute force. Se non ti serve, puoi bloccarlo:

<Files xmlrpc.php>
Require all denied
</Files>

Se invece usi app mobile, Jetpack o integrazioni che dipendono da XML-RPC, non bloccarlo senza test. In quel caso è meglio limitarne l’uso con un plugin di sicurezza o con regole più selettive.

Regole anti errore 404 e canonical

Le regole canoniche aiutano a mantenere consistenza negli URL e a evitare duplicati. La parte più importante, però, resta la scelta di una sola versione del dominio e della corretta struttura permalink in WordPress.

Una regola utile è forzare il trailing slash solo quando coerente con la configurazione del sito. WordPress di norma lo gestisce già, ma su siti con rewrite personalizzati può essere necessario intervenire.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+[^/])$ /$1/ [R=301,L]
</IfModule>

Attenzione: questa regola non è universale. Su alcuni siti può creare redirect indesiderati su file, endpoint API o URL particolari. Testala sempre prima in staging.

Regole per bloccare bot indesiderati

In caso di scraping aggressivo o crawling eccessivo, puoi intervenire con regole basate su user agent. È una difesa parziale, non assoluta, ma può aiutare in situazioni semplici.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^.*(AhrefsBot|SemrushBot|MJ12bot).*$ [NC]
RewriteRule .* - [F,L]
</IfModule>

Questa regola non è una soluzione di sicurezza completa, perché gli user agent possono essere falsificati. Per un controllo migliore conviene usare firewall, rate limiting o servizi di protezione esterni.

Gestione degli errori personalizzati

Puoi definire pagine di errore personalizzate per migliorare esperienza utente e branding.

ErrorDocument 404 /404.html
ErrorDocument 403 /403.html
ErrorDocument 500 /500.html

Assicurati che le pagine esistano davvero e che non generino a loro volta altri errori. Una pagina di errore ben fatta deve essere semplice, leggera e sempre raggiungibile.

Regole complete consigliate per molti siti WordPress

Se vuoi una base pratica e abbastanza sicura per un sito WordPress standard su Apache, puoi partire da questa struttura, adattando dominio e certificato SSL.

Options -Indexes

<IfModule mod_rewrite.c>
RewriteEngine On

# Forza HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Forza non-www: sostituisci con www se preferisci questa versione
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

# WordPress
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

<Files wp-config.php>
Require all denied
</Files>

<Files xmlrpc.php>
Require all denied
</Files>

Questa configurazione è solo un esempio di partenza. Va adattata al tuo hosting, al tuo dominio canonico e ai plugin installati. Se il sito usa CDN, reverse proxy o cache server-side, alcune regole potrebbero essere già gestite altrove.

Come capire se .htaccess è la causa di un problema

Se il sito mostra errore 500, redirect infiniti o pagine non raggiungibili, il file .htaccess è uno dei primi elementi da controllare. Il metodo più rapido è rinominarlo temporaneamente e testare il sito.

mv .htaccess .htaccess.off

Se il sito torna online, il problema è quasi certamente in una regola del file. A quel punto puoi ricrearlo partendo dalla struttura base di WordPress e reinserire le personalizzazioni una alla volta.

Buone pratiche operative

Per lavorare bene con .htaccess, segui alcune regole semplici:

  • fai sempre un backup prima di modificare;
  • cambia una sola cosa per volta;
  • testa subito il sito dopo ogni modifica;
  • evita di copiare blocchi trovati online senza capirne l’effetto;
  • se usi plugin di cache o sicurezza, controlla che non riscrivano lo stesso file.

Molti problemi non derivano da Apache in sé, ma da sovrapposizioni tra plugin, regole personalizzate, CDN e configurazioni del provider. Una gestione ordinata del file riduce tantissimo il rischio di downtime.

Conclusione

Il file .htaccess resta uno strumento essenziale per WordPress, soprattutto su hosting condivisi o ambienti dove non hai accesso alla configurazione globale del server. Con poche regole ben scritte puoi migliorare SEO, sicurezza e prestazioni, oltre a gestire redirect e compatibilità con strutture URL complesse.

La chiave è sempre la stessa: partire dalla base di WordPress, aggiungere solo ciò che serve, e verificare ogni modifica. Se vuoi una configurazione avanzata, è meglio costruirla in modo progressivo piuttosto che incollare un blocco enorme non testato.

Se necessario, puoi usare questa guida come template e adattarla al tuo sito, al tuo dominio e al tipo di server che stai usando.