File .htaccess predefinito di WordPress: cosa contiene e come ripristinarlo

Il file .htaccess predefinito di WordPress è il breve blocco RewriteEngine che il software scrive nel .htaccess alla radice del tuo sito perché permalink come /2026/10/nome-articolo/ si risolvano invece di dare 404. Ha questo aspetto:

# 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

Questo è il blocco esatto, riprodotto dalla guida ufficiale di WordPress su Apache HTTP Server e dalla logica di rewrite documentata nella pagina HelpHub sui permalink. Se il tuo RewriteBase non è / — ad esempio perché WordPress è installato in una sottocartella — corrisponderà invece a quel percorso, ed è altrettanto normale e generato da WordPress stesso.

I punti chiave

• WordPress genera questo blocco automaticamente, solo su Apache e LiteSpeed, quando il file è scrivibile e salvi Impostazioni > Permalink.
• Se il file manca o è danneggiato, tutti i permalink tranne la home restituiscono 404, perché solo la home si può trovare senza le regole di rewrite.
• Qualsiasi cosa tu o un plugin aggiungiate deve stare sopra # BEGIN WordPress, mai dentro i marcatori — WordPress sovrascrive tutto ciò che sta in mezzo a ogni salvataggio dei permalink.

Serve ricostruire il file con il tuo percorso reale e qualche regola in più? Il generatore .htaccess per WordPress ne assembla uno corretto direttamente nel browser.

Cosa fa ogni riga

RewriteEngine On attiva il modulo mod_rewrite di Apache per questa directory; senza questa riga tutto il resto è inerte.

RewriteBase / dice ad Apache che i percorsi riscritti sono relativi alla radice del sito. WordPress lo imposta in base a dove vive realmente il sito — un’installazione in una sottocartella riceve RewriteBase /blog/, non /.

RewriteRule ^index\.php$ - [L] è una guardia senza effetto: se la richiesta è già index.php, il rewrite si interrompe e la richiesta passa inalterata.

Le due righe RewriteCond sono la logica vera e propria. %{REQUEST_FILENAME} !-f e !-d chiedono “questa richiesta NON corrisponde a un file reale, e NON corrisponde a una cartella reale?”. Entrambe devono essere vere perché la regola finale scatti — così un’immagine reale, un file CSS o un PDF caricato vengono serviti direttamente e non toccano mai il routing di WordPress.

RewriteRule . /index.php [L] è ciò che fa funzionare i permalink: tutto ciò che è sopravvissuto alle due condizioni precedenti — cioè non è un file o una cartella reale — viene mandato a index.php, e il routing proprio di WordPress (WP_Query, tag di rewrite) decide a quale articolo, pagina o archivio quell’URL si riferisca davvero.

Quando WordPress ricrea questo file, e quando no

WordPress cerca di scrivere .htaccess da solo ogni volta che apri Impostazioni > Permalink e clicchi Salva le modifiche, anche se non è cambiato nulla a schermo. Quel salvataggio attiva flush_rewrite_rules(), che tenta di aprire .htaccess in scrittura e inserire il blocco attuale tra i marcatori.

Questo tentativo fallisce silenziosamente, lasciando il file mancante o non aggiornato, quando:

• Il file o la sua cartella padre non sono scrivibili dall’utente con cui gira PHP. Su molti hosting condivisi PHP gira con un utente di sistema diverso da quello che ha caricato i file via FTP, quindi permessi che sembrano corretti in un client FTP bloccano comunque la scrittura di WordPress.
• Sei su nginx. .htaccess è un meccanismo esclusivo di Apache e LiteSpeed (la documentazione di Apache su AllowOverride spiega perché: nginx non ha un file di configurazione per directory che rilegge a ogni richiesta). L’equivalente su nginx è una direttiva try_files nel blocco server, modificabile solo da chi ha accesso al server; WordPress non può mai scriverla per te.
• AllowOverride è impostato su None per la directory del tuo sito nella configurazione principale di Apache. È l’impostazione che permette a un .htaccess di sovrascrivere qualcosa; la documentazione Apache è esplicita: con AllowOverride None “i file .htaccess vengono completamente ignorati” — WordPress può scrivere un file perfetto e resterà senza effetto finché questa impostazione non viene cambiata a livello di server.
• Il file è stato cancellato o non è mai esistito e qualcosa nel salvataggio non ha attivato una rigenerazione — il motivo più comune è che i permalink avevano già la stessa struttura, quindi WordPress non ha visto nessun cambiamento da riscrivere.

Come ripristinarlo a mano

Se articoli e pagine danno 404 mentre la home continua a funzionare, è la firma tipica di un .htaccess mancante o rotto. Risolvilo in due passaggi.

1. Prova prima la soluzione a un click. Vai su Impostazioni > Permalink nella bacheca di WordPress e clicca Salva le modifiche senza cambiare nulla. Se il file è scrivibile, questo da solo lo rigenera e hai finito.

2. Se non basta, crea il file a mano. Collegati via FTP/SFTP o il file manager del tuo host, vai nella cartella dove è installato WordPress (quella che contiene wp-config.php) e verifica se .htaccess esiste — è un file nascosto, alcuni file manager lo nascondono di default; attiva “mostra file nascosti”.

• Se manca, crea un nuovo file chiamato esattamente .htaccess (niente .txt, niente prima del punto).
• Incolla il blocco predefinito qui sopra, adattando RewriteBase se WordPress vive in una sottocartella.
• Salva e ricarica il permalink di un articolo per confermare che funzioni.

Se continua a dare 404 dopo questo, la causa si è spostata da “manca .htaccess” a “viene ignorato .htaccess” — chiedi al tuo host informazioni su AllowOverride, perché un file corretto in una directory dove Apache ha l’ordine di ignorarlo si comporta esattamente come l’assenza del file.

Le tue regole contro il blocco di WordPress

Un plugin o una modifica manuale possono aggiungere regole proprie — redirect, protezione hotlink, header di cache. È un blocco distinto e separato da quello generato da WordPress, e i due non dovrebbero mai sovrapporsi:

# Regole aggiunte da te o da un plugin — SOPRA i marcatori di WordPress
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # esempio: protezione hotlink, regole di cache, ecc.
</FilesMatch>

# 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

Qualsiasi cosa sia collocata tra # BEGIN WordPress e # END WordPress viene eliminata silenziosamente la prossima volta che qualcuno salva la schermata Permalink, perché WordPress tratta tutto quel tratto come proprio e lo riscrive da capo. È la causa più comune di “la mia regola personalizzata è scomparsa” — non è mai stata rimossa di proposito, si trovava semplicemente in un blocco che WordPress considera suo. Per i redirect in particolare, vedi regole di redirect .htaccess di WordPress fatte bene per sapere dove devono stare e come evitare i loop.

È anche la causa più comune di un 500 Internal Server Error improvviso subito dopo aver modificato il file: una regola copiata da un forum scritto per una versione diversa di Apache (sintassi Order/Deny della 2.2 mischiata con la sintassi Require della 2.4) rompe il parsing di tutto il file, incluso il blocco WordPress sottostante, e va giù l’intero sito — non solo la parte che hai toccato.

Oltre il blocco predefinito

Il blocco predefinito gestisce solo il routing dei permalink. Se vuoi anche blindare l’accesso ai file sensibili o aggiungere il pugno di regole .htaccess che riducono davvero la superficie di attacco — bloccare l’esecuzione PHP in /uploads, negare richieste dirette a wp-config.php — guarda le regole di sicurezza .htaccess di WordPress che aiutano davvero. E se i permalink danno 404 per un altro motivo — struttura permalink sbagliata, un livello di cache che serve regole vecchie, conflitti multisito in sottodirectory — i permalink di WordPress che non funzionano ripassa le altre cause.

Domande frequenti

Cos’è il file .htaccess predefinito di WordPress? È il blocco RewriteEngine che WordPress scrive tra # BEGIN WordPress e # END WordPress perché i permalink si risolvano verso index.php invece di dare 404.

Qual è il codice esatto del .htaccess predefinito di WordPress? RewriteEngine On, RewriteBase /, una regola di passaggio per index.php, due condizioni che verificano che la richiesta non sia un file o una cartella reali, e una regola finale che manda tutto il resto a index.php. Il blocco completo è riportato all’inizio di questa guida.

Perché tutti i miei articoli danno 404 tranne la home? La home si può trovare senza nessuna regola di rewrite; ogni altro permalink ne ha bisogno. Un .htaccess mancante o danneggiato su Apache produce esattamente questo schema.

WordPress ricrea .htaccess automaticamente? Solo se il file è scrivibile — risalvare Impostazioni > Permalink lo attiva. Se il file non è scrivibile, manca su un host che non lo autogenera, o AllowOverride è disattivato, WordPress non può risolverlo per te e devi creare o correggere il file a mano.

Perché nginx non ha un file .htaccess di WordPress? .htaccess funziona solo su Apache e LiteSpeed. nginx non ha un file di configurazione per directory e ignora completamente .htaccess; lo stesso routing si scrive come regola try_files nel blocco server di nginx.

Perché il mio .htaccess si è rotto dopo aver salvato i permalink? Una regola personalizzata è stata messa dentro i marcatori # BEGIN WordPress / # END WordPress invece che sopra, e WordPress ha sovrascritto tutto quel tratto al salvataggio successivo dei permalink.

---

Ricostruisci un .htaccess pulito e corretto — blocco permalink predefinito più le regole di sicurezza o redirect che ti servono davvero — con il generatore .htaccess per WordPress gratuito.