Htaccess Redirect: guida pratica ai redirect 301

Cinque migrazioni su sei che analizo hanno lo stesso problema: i redirect ci sono, ma sono configurati in modo da disperdere autorità invece di trasferirla. Non è un errore di pigrizia. È un errore di metodo: si imposta il redirect, si verifica che “funzioni” nel browser, e si chiude il capitolo. Ma il browser non è Google. Quello che vedi nel browser e quello che passa davvero in termini di PageRank sono due cose diverse.

Il file .htaccess è lo strumento più diretto che hai per gestire i redirect lato server su Apache. Non passa per WordPress, non dipende da plugin, non introduce strati intermedi. La regola viene letta prima ancora che il CMS si accenda, e questo fa una differenza concreta in termini di velocità e affidabilità.

In questo articolo ti spiego come scrivere i redirect nel file .htaccess senza rompere il sito, quale tipo di redirect scegliere in ogni situazione e come verificare che il valore SEO si stia trasferendo davvero dove vuoi.

Ti mostro anche gli errori più comuni che vedo nei siti dopo una migrazione, con una checklist di verifica da usare prima di pubblicare qualsiasi modifica.

Cos’è un redirect 301 e cosa significa per il SEO?

Un redirect 301 htaccess è un reindirizzamento permanente che trasferisce il valore SEO (link equity) dalla vecchia URL alla nuova, segnalando a Google di aggiornare il proprio indice. Google dichiara esplicitamente che il 301 trasferisce la maggior parte del PageRank, rendendolo il tipo di redirect corretto in qualsiasi migrazione o ristrutturazione del sito.

In pratica: se una pagina ha accumulato link nel tempo e la sposti, il 301 dice ai motori di ricerca “quella pagina non esiste più qui, esiste là, porta tutto con te.” Senza redirect, quel valore svanisce. Non si riduce gradualmente: svanisce, e non torna.

Cos’è il file .htaccess e a cosa serve per i redirect

Il file .htaccess è un file di configurazione che Apache legge ad ogni richiesta HTTP prima di servire qualsiasi contenuto. Si trova nella root del sito (o in sottodirectory specifiche) ed è invisibile per impostazione predefinita nei file manager standard, perché inizia con un punto.

La differenza rispetto ai plugin WordPress è sostanziale. Un plugin come Redirection o Yoast gestisce i redirect a livello applicativo: PHP si avvia, WordPress si carica, il plugin intercetta la richiesta, e solo allora scatta il redirect. Con .htaccess, il redirect avviene prima che PHP entri in gioco. Meno risorse, meno latenza, meno cose che possono andare storte.

Per chi arriva da WordPress: se usi Apache (la stragrande maggioranza degli hosting condivisi), il file .htaccess esiste già. WordPress lo usa per gestire i permalink. Puoi modificarlo, ma l’ordine delle direttive conta.

Redirect 301 e 302: quale scegliere e perché conta per la SEO

La scelta tra 301 e 302 non è solo tecnica: è una dichiarazione d’intento verso Google. Il 301 dice “questa pagina si è spostata per sempre.” Il 302 dice “questa pagina è temporaneamente altrove, torna a cercare qui tra un po’.”

Google tratta i due redirect in modo diverso. Con il 301, aggiorna l’indice e trasferisce il PageRank. Con il 302, mantiene la pagina originale nell’indice e non consolida l’autorità sulla nuova URL. Usare un 302 dove serve un 301 è uno degli errori più costosi in una migrazione, proprio perché i risultati negativi si vedono in ritardo.

Quando usare il redirect 301 htaccess

Il 301 è la scelta corretta in tutti i casi in cui la destinazione è permanente. I scenari più comuni sono:

  • Cambio dominio: tutto il sito si sposta da un dominio all’altro (es. da vecchiodominio.it a nuovodominio.it)
  • Migrazione URL: una pagina viene rinominata o ristrutturata (es. da /blog/post-titolo a /articoli/post-titolo)
  • Rimozione www: redirect da www.dominio.it a dominio.it per consolidare la versione canonica
  • Pagine eliminate: prodotti fuori catalogo, articoli rimossi, sezioni dismesse che puntano alla categoria più pertinente
  • HTTP verso HTTPS: dopo l’installazione del certificato SSL

Quando il redirect 302 è la scelta giusta

Il 302 ha senso in tre situazioni specifiche: A/B test su una variante di pagina, manutenzione programmata breve (il sito tornerà identico entro poche ore), promozioni stagionali su URL dedicate che ricompariranno.

Attenzione all’abuso del 302. Ho visto siti dove ogni redirect era un 302 “per sicurezza”, con l’idea di poter tornare indietro in futuro. Il risultato era un sito con zero consolidamento dell’autorità e pagine duplicate nell’indice. Se non hai una ragione specifica per usare il 302, usa il 301.

Sintassi .htaccess redirect: come scrivere le regole correttamente

Esistono due approcci principali per i redirect in .htaccess: la direttiva Redirect (semplice, leggibile, senza mod_rewrite) e RewriteRule (potente, condizionale, richiede mod_rewrite attivo). La scelta dipende dalla complessità del redirect che devi gestire.

Approccio Quando usarlo Richiede mod_rewrite
Redirect Redirect singoli, URL esatte No
RewriteRule Pattern, condizioni, HTTPS, www

Redirect singolo URL con la direttiva Redirect

Per spostare una singola pagina da un URL a un altro, la sintassi è questa:

# Redirect permanente da /vecchia-pagina a /nuova-pagina
Redirect 301 /vecchia-pagina https://dominio.it/nuova-pagina

Riga per riga: Redirect è la direttiva. 301 è il codice HTTP (usa 302 per temporaneo). /vecchia-pagina è il percorso relativo della vecchia URL, che inizia sempre con /. https://dominio.it/nuova-pagina è la destinazione assoluta.

Nota importante: questo approccio funziona per URL esatte. Se la vecchia pagina aveva parametri o varianti, non le intercetta.

Redirect avanzato con RewriteEngine e RewriteRule

Per redirect condizionali, da HTTP a HTTPS e da www a non-www, serve mod_rewrite. Prima di tutto, verificane l’attivazione:

RewriteEngine On

Redirect da HTTP a HTTPS:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

RewriteCond è la condizione: “se HTTPS è disattivo.” RewriteRule si applica solo se la condizione è vera. [L,R=301] significa: ultima regola da applicare (L) e redirect 301 (R=301).

Redirect da www a non-www:

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

Sostituisci dominio.it con il tuo dominio reale. Il $1 riprende il percorso originale, così /prodotti/scarpe diventa https://dominio.it/prodotti/scarpe senza perdere la struttura.

Posso usare il file .htaccess su WordPress?

Sì. WordPress su server Apache usa già il file .htaccess per gestire i permalink. Quando apri il file, troverai un blocco simile a questo:

# 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

Le tue regole personalizzate vanno inserite sopra il blocco # BEGIN WordPress. Se le inserisci dopo, WordPress potrebbe sovrascriverle al prossimo aggiornamento delle impostazioni dei permalink. Sopra il blocco, sopravvivono.

Quanti redirect sono troppi? Impatto sulla velocità del sito

Ogni redirect aggiunge una richiesta HTTP e aumenta il tempo di caricamento. Google consiglia di mantenere le catene di redirect al minimo, idealmente zero hop intermedi. Una catena di 3 o più redirect può aumentare il TTFB di centinaia di millisecondi, con impatto diretto sui Core Web Vitals.

Il problema delle catene emerge spesso dopo migrazioni successive: il sito è passato da HTTP a HTTPS, poi da www a non-www, poi da un dominio a un altro. Ogni passaggio ha aggiunto un redirect senza rimuovere quello precedente. Il risultato è una catena A → B → C → D che si potrebbe risolvere con A → D.

L’ordine che seguo quando sistemo un sito con catene di redirect: prima mappo tutte le catene esistenti con un crawler (Screaming Frog o Sitebulb), poi collasso ogni catena in un redirect diretto, poi verifico che nessuna URL esterna punti a hop intermedi.

Errori comuni nei redirect .htaccess e come evitarli

Gli errori che vedo più spesso non sono errori di sintassi: sono errori di logica. Prima di pubblicare qualsiasi modifica al .htaccess, usa questa checklist:

  • Loop di redirect: la URL di destinazione punta di nuovo alla sorgente. Succede spesso con redirect HTTP→HTTPS mal configurati su hosting con SSL gestito a livello server.
  • mod_rewrite non attivo: RewriteEngine On non funziona se il modulo non è abilitato. Il server restituisce un errore 500. Verifica con l’hosting o aggiungi Options +FollowSymLinks prima delle regole.
  • Conflitti con WordPress: le regole personalizzate inserite dopo # END WordPress possono essere sovrascritte. Mettile sempre prima.
  • Percorsi assoluti invece di relativi: nella direttiva Redirect, il vecchio percorso deve essere relativo (/vecchia-pagina), la destinazione deve essere assoluta (https://dominio.it/nuova-pagina).
  • Mancanza di backup: prima di modificare .htaccess, scarica sempre una copia. Un errore di sintassi può rendere il sito irraggiungibile con un 500 secco.

Come verificare che il redirect 301 funzioni correttamente

Verificare che un redirect “funzioni” nel browser non basta. Il browser segue i redirect automaticamente e mostra la destinazione finale senza dirti quanti hop hai attraversato.

Gli strumenti che uso per verificare i redirect in modo affidabile sono tre:

  • Browser DevTools (Network tab): apri la scheda Network, abilita “Preserve log”, digita la vecchia URL. Vedrai ogni richiesta HTTP con il codice di risposta. Un 301 seguito da un 200 è corretto. Un 301 seguito da un altro 301 è una catena da risolvere.
  • Redirect Checker online (come httpstatus.io o redirect-checker.org): incolla la URL e ti mostra l’intera catena di redirect con tutti i codici HTTP.
  • Google Search Console: dopo una migrazione, vai su “Copertura” e monitora le URL che Google sta ancora cercando di scansionare. Se vedi le vecchie URL segnalate come “reindirizzate”, il 301 è stato recepito. Se le vedi ancora come “non trovate”, il redirect non sta funzionando lato Google.

In Search Console, la sezione “Ispezione URL” ti permette di inserire la vecchia URL e vedere cosa vede Google: qual è la versione canonica, se c’è un redirect attivo, se la pagina è stata indicizzata. È il modo più diretto per capire se l’autorità si sta trasferendo davvero.

I redirect non sono un dettaglio tecnico da delegare o verificare una sola volta. Sono il meccanismo con cui l’autorità che hai costruito nel tempo sopravvive a qualsiasi cambiamento strutturale del sito. Un 301 mal configurato non fa solo perdere ranking: fa perdere il lavoro di mesi, talvolta di anni, senza che il sito mostri subito un segnale chiaro. Il danno si accumula in silenzio. Questo è il motivo per cui non chiudo mai una migrazione senza una verifica sistematica delle catene, dei codici reali lato server e di ciò che Google Search Console effettivamente registra. Il browser non è una fonte attendibile. I dati lo sono.

Hai bisogno di una consulenza SEO per gestire una migrazione o sistemare i redirect del tuo sito? Contattami e analizziamo insieme la situazione.

Se quello che hai letto ti risuona, fammi sapere su cosa stai lavorando.

Contattami







    Autore

    Adriana Longhitanohttps://adrianalonghitano.it

    Adriana Longhitano

    SEO Specialist con oltre 8 anni di esperienza. Progetto strategie di visibilità organica per aziende e professionisti che vogliono essere trovati — su Google e nei sistemi AI. Specializzata in GEO (Generative Engine Optimization), SEO tecnica e architettura dell’informazione.

    Adriana Longhitano
    Torna in alto

    Se quello che hai letto ti risuona, allora ha senso parlarne.

    Contattami