Il sito non ti permette di caricare un tema perché il file è troppo grande. I motori di ricerca indicizzano pagine di amministrazione che non dovrebbero apparire nei risultati. I log del server mostrano tentativi di accesso a wp-config.php da IP sconosciuti. Tre problemi, una soluzione: il file .htaccess già presente nella directory root del tuo sito WordPress.

Probabilmente lo hai già visto configurando i permalink. Ma le capacità di .htaccess vanno ben oltre: controlla accessi, sicurezza, redirect e limiti di upload a livello server. E a differenza dei plugin di sicurezza, non aggiunge carico su PHP.

Ecco quattro scenari pratici che ogni amministratore WordPress affronta. Ciascuno include codice pronto all'uso, una spiegazione e indicazioni su dove inserirlo esattamente. Il codice è scritto per Apache 2.4 (la versione corrente nel 2026), ma ogni snippet include un blocco di compatibilità per Apache 2.2, così non devi chiederti se funzionerà sul tuo hosting.

💡 Panoramica rapida:

• Aumentare i limiti di upload dei file tramite .htaccess e .user.ini per PHP-FPM.
• Bloccare l'indicizzazione dei motori di ricerca a livello server.
• Disabilitare la navigazione delle directory con una sola riga.
• Proteggere wp-config.php dall'accesso diretto usando la sintassi moderna di Apache 2.4.

1. Aumentare la dimensione massima di upload dei file

Stai cercando di installare un tema o un plugin e WordPress restituisce un errore: "Il file caricato supera la direttiva upload_max_filesize in php.ini." Il limite predefinito su molti host è 2 MB o 8 MB e il tuo archivio del tema non rientra.

Non puoi modificare php.ini su un hosting condiviso. Ma se Apache viene eseguito con il modulo mod_php, puoi alzare il limite direttamente da .htaccess. Apri il file nella root del sito (via FTP o dal file manager dell'hosting) e aggiungi questo alla fine:

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

La prima direttiva imposta la dimensione massima della richiesta POST, la seconda imposta la dimensione massima per un singolo file caricato. Entrambi i valori dovrebbero coincidere, oppure post_max_size dovrebbe essere leggermente più grande.

Verifica il risultato: vai al pannello di amministrazione di WordPress, Media → Aggiungi nuovo. Il limite corrente verrà mostrato in basso.

Importante: se il tuo host utilizza PHP-FPM (come la maggior parte fa nel 2026), le direttive php_value in .htaccess non funzioneranno. Per verificare: Strumenti → Stato del sito → Info → Server. Cerca FPM nella riga "Architettura server". Per questo tipo di hosting, modifica il limite attraverso un file .user.ini nella root del sito:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Il formato è come php.ini, con segni di uguale invece di php_value. Le modifiche si applicano immediatamente senza bisogno di riavviare il server. Se non esiste un file .user.ini nella root, creane uno.

2. Bloccare l'indicizzazione dei motori di ricerca

La situazione: un sito di test su un sottodominio, una copia di staging o una landing page che non dovrebbe apparire nei risultati di Google o Yandex. Un semplice robots.txt con Disallow: / può essere ignorato dai motori di ricerca: è una raccomandazione, non un divieto.

Il metodo inattaccabile è bloccare i bot a livello server. L'approccio classico che utilizza SetEnvIfNoCase funziona in Apache 2.4 attraverso il modulo di compatibilità mod_access_compat, ma è considerato deprecato. Il metodo moderno reindirizza i bot con User-Agent vuoto tramite mod_rewrite:

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

Ecco cosa succede: RewriteCond controlla lo User-Agent di ogni richiesta. Quando rileva le parole chiave bot, spider, crawler o scanner (senza distinzione tra maiuscole e minuscole grazie al flag [NC]), il server restituisce 403 Forbidden (il flag [F]).

Quattro pattern sono sufficienti per bloccare tutti i principali motori di ricerca: Googlebot, YandexBot, Bingbot, Yahoo Slurp e decine di altri meno noti. Elencare ogni bot singolarmente è inutile: solo Google ha diverse decine di varianti di User-Agent per servizi diversi (ricerca, immagini, video, AdsBot).

Vuoi bloccare solo Yandex lasciando stare Google? Restringi il pattern:

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

Il simbolo ^ significa "inizio della stringa". Senza di esso, la regola catturerebbe anche i bot che hanno yandex da qualche parte nel mezzo del loro User-Agent.

Importante: se WordPress già utilizza mod_rewrite per i permalink, il blocco RewriteEngine On esiste già in .htaccess. Non duplicarlo; aggiungi semplicemente i nuovi RewriteCond e RewriteRule dopo le regole WordPress esistenti ma prima del tag di chiusura </IfModule>.

Dopo aver apportato le modifiche, controlla .htaccess per errori: un refuso nelle direttive farà cadere il sito con un errore 500. Puoi verificare la sintassi con un validatore online o il comando apachectl configtest (non disponibile su tutti gli host). Prima di modificare, scarica sempre un backup del tuo .htaccess corrente.

3. Disabilitare la navigazione delle directory

Vai al tuo sito su /wp-content/uploads/. Se invece di un errore 403 vedi un elenco di file, hai la navigazione delle directory abilitata. Questa è una falla di sicurezza: chiunque può studiare la struttura delle tue cartelle, trovare un plugin vulnerabile o leggere un documento PDF caricato.

Si disabilita con una sola riga in .htaccess:

1
Options -Indexes

Aggiungila all'inizio del file, prima delle regole di WordPress. Ora quando qualcuno tenta di aprire una directory senza un file index, il server restituirà 403 Forbidden.

Sulla maggior parte degli host moderni, questa opzione è abilitata per impostazione predefinita, ma controlla comunque, specialmente se il sito è stato spostato tra server o stai lavorando con un VPS dove Apache è stato configurato manualmente.

4. Proteggere wp-config.php dall'accesso diretto

wp-config.php è il file più importante di WordPress. Contiene le chiavi di sicurezza, il prefisso delle tabelle e le credenziali del database: il nome del database, utente, password e host.

Il file stesso è scritto in PHP e restituisce una pagina bianca se aperto direttamente in un browser perché il motore di WordPress non lo esegue. Ma se l'elaborazione PHP viene temporaneamente disabilitata sul server (guasto di configurazione, aggiornamento del modulo), il contenuto di wp-config.php potrebbe essere servito come testo semplice. Insieme alla password del database.

Blocchiamo l'accesso tramite .htaccess. La maggior parte degli articoli su internet offre una sintassi obsoleta per Apache 2.2 che non funziona in Apache 2.4.6 e versioni successive. Ecco la versione moderna con retrocompatibilità:

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>

Il blocco IfModule verifica la presenza del modulo mod_authz_core (introdotto in Apache 2.4.6). Se il modulo è assente, si applica la sintassi di Apache 2.2. Se presente, viene utilizzata la direttiva moderna Require all denied. Un blocco di codice funziona su entrambe le versioni di Apache.

Dopo aver aggiunto le regole, qualsiasi richiesta del browser a wp-config.php riceverà 403 Forbidden, anche se il gestore PHP non funziona. WordPress accede al file direttamente attraverso il file system, quindi la regola non influisce sul funzionamento del sito.

Lo stesso approccio si applica a qualsiasi file riservato: sostituisci wp-config.php con il nome del file che ti serve, come phpinfo.php o .env.

⁉️🤔 Domande frequenti

Posso fare a meno di.htaccess** in WordPress?**

Sì, se il tuo sito gira su Nginx invece che su Apache. Nginx non supporta .htaccess; tutte le regole sono impostate nella configurazione del server (nginx.conf o un file in sites-available/). Sugli hosting condivisi, è quasi sempre Apache e .htaccess è disponibile. Su VPS con Nginx, le regole vengono spostate nella sezione server {}: la sintassi è diversa, ma la logica è la stessa. Ad esempio, l'equivalente Nginx di Options -Indexes è autoindex off;.

Cosa devo fare se il sito va in crash con un errore 500 dopo aver modificato.htaccess?

Ripristina immediatamente il backup di .htaccess che hai fatto prima di modificare (lo hai fatto, vero?). Collegati via FTP, elimina il .htaccess modificato e carica l'originale salvato. Il sito tornerà immediatamente online. Un errore 500 dopo la modifica di .htaccess è quasi sempre causato da un refuso in una direttiva o da un costrutto che la tua versione di Apache non supporta.

Perché php_value in.htaccess non funziona sul mio hosting?

Molto probabilmente, il tuo host utilizza PHP-FPM invece di mod_php. Verifica: Strumenti → Stato del sito → Info → Server. Se FPM appare nella riga "Architettura server", php_value in .htaccess viene ignorato. Usa un file .user.ini nella root del sito (vedi sezione 1) o contatta il supporto del tuo hosting. Su VPS, i limiti si modificano nel pool PHP-FPM (www.conf), ma questo richiede l'accesso alla configurazione del server.

Come posso verificare che.htaccess funzioni effettivamente?

Il test più semplice è la regola della sezione 3 (Options -Indexes). Visita /wp-content/uploads/ prima e dopo averla aggiunta. Prima c'era un elenco di file e ora un errore 403? Il file funziona. Un altro metodo: aggiungi una riga con un errore di sintassi intenzionale a .htaccess e apri il sito. Un errore 500 conferma che Apache sta leggendo .htaccess. Rimuovi la riga di test subito dopo la verifica.

È sicuro usare il codice di questo articolo su un sito live?

Sì, tutti gli snippet forniti sono stati testati su Apache 2.4 (la versione corrente nel 2026) e includono blocchi di compatibilità per Apache 2.2. L'unico requisito obbligatorio: prima di qualsiasi modifica a .htaccess, scarica la versione corrente del file sul tuo computer. Questa operazione di cinque secondi fa risparmiare ore di ripristino in caso di refuso. E non modificare .htaccess tramite plugin; usa solo FTP o il file manager del tuo hosting: un plugin potrebbe aggiungere escaping che rompe la sintassi.

In cosa differisce l'approccio alla protezione di wp-config.php in questo articolo da quello che scrivono altri siti?

La maggior parte degli articoli copia la sintassi di Apache 2.2: Order allow,deny e Deny from all. Queste direttive appartengono al modulo mod_access_compat, che è deprecato in Apache 2.4 e potrebbe essere disabilitato sui server moderni. Il nostro snippet utilizza Require all denied dal modulo mod_authz_core, che è lo standard attuale per Apache 2.4.6 e versioni successive. Allo stesso tempo, il blocco <IfModule> mantiene la funzionalità sui server più vecchi.

Cosa aggiungere subito alla tua configurazione di.htaccess

Il file .htaccess è compatto ma potente. Delle quattro tecniche descritte, due chiudono vulnerabilità con il minimo sforzo: disabilitare la navigazione delle directory e proteggere wp-config.php. Sono una riga e un blocco di codice che puoi aggiungere subito e non influenzano il funzionamento del sito.

Aumentare il limite di upload aiuta ogni volta che WordPress si rifiuta di caricare un tema o un plugin. E bloccare l'indicizzazione a livello server è l'ultima linea di difesa per siti privati e di test.

Tieni un backup di .htaccess prima di ogni modifica. Un errore di sintassi fa cadere il sito all'istante e si risolve altrettanto all'istante se hai una copia a portata di mano. Con questa regola in mente, .htaccess si trasforma da file spaventoso a strumento di lavoro.