Redirect 301 in .htaccess durante una migrazione di dominio

Quando un team cerca .htaccess redirect 301, di solito il problema iniziale è molto concreto:

• una vecchia URL deve puntare a una nuova
• HTTP deve passare a HTTPS
• un vecchio dominio deve spostarsi in modo permanente

Per poche regole .htaccess può ancora andare bene. Il problema arriva quando la stessa logica viene stirata fino a coprire tutta una migrazione di dominio.

La risposta pratica è spesso questa:

• per pochi 301 stabili, .htaccess può bastare
• per migrazioni di dominio, rebrand, relaunch o redirect map grandi, .htaccess diventa facilmente un punto di fragilità

Se il progetto è già in corso, tieni aperta anche la website migration redirect checklist. Qui ci concentriamo sul punto di partenza classico: i 301 in .htaccess.

La risposta rapida

Una regola semplice può essere:

Redirect 301 /pagina-vecchia https://www.esempio.it/pagina-nuova

E uno spostamento di dominio completo con conservazione del path finisce spesso in mod_rewrite:

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

Questo però risponde solo alla sintassi. La vera domanda è:

[!TIP] State ancora gestendo poche regole, o state già gestendo un workflow di migrazione che richiede validazione, ownership e rollback?

Quando .htaccess è ancora adatto

Di solito resta praticabile quando:

• i redirect sono pochi
• Apache è l’unico layer attivo
• nessun CDN, proxy o middleware sta riscrivendo traffico
• la logica dei path è semplice
• l’ownership è chiara

Dove inizia a rompersi

1. Esistono più layer di redirect

Nella realtà i redirect possono arrivare da:

• .htaccess
• plugin CMS
• Nginx o load balancer
• Cloudflare
• middleware applicativo

La migrazione allora diventa:

http://dominio-vecchio.it/prodotto-a
  -> https://dominio-vecchio.it/prodotto-a
  -> https://www.dominio-vecchio.it/prodotto-a
  -> https://www.dominio-nuovo.it/shop/prodotto-a

Magari funziona ancora, ma la struttura è già scadente.

2. Path e query diventano opachi

Molti team testano solo la homepage. Più tardi scoprono che deep link, docs o UTM non arrivano bene.

3. Le wildcard non bastano più

Una regola tipo:

/blog/* -> /articoli/*

sembra ordinata finché:

• alcune categorie vengono fuse
• certi prodotti spariscono
• alcune pagine richiedono eccezioni

Da lì servono:

• mapping espliciti
• priorità
• validazione
• una redirect map rivedibile

4. Le modifiche sono difficili da auditare

Un merge in un file di configurazione non è una traccia di migrazione.

Molto presto il team vuole sapere:

• chi ha cambiato cosa
• quali regole sono nuove
• quali sono state rimosse
• dove ci sono conflitti
• come si fa rollback

.htaccess da sola non aiuta molto.

Errori frequenti

Separare host, HTTPS e destinazione finale in più hop

Cattivo:

http://dominio-vecchio.it/docs/api
  -> https://dominio-vecchio.it/docs/api
  -> https://www.dominio-vecchio.it/docs/api
  -> https://www.dominio-nuovo.it/docs/api

Meglio:

http://dominio-vecchio.it/docs/api
  -> https://www.dominio-nuovo.it/docs/api

Validare la homepage ma dimenticare le URL importanti

La home sembra a posto, ma prodotti, articoli, docs e URL storiche non lo sono.

Perdere i parametri

Se il tracking dipende da email, QR, paid social o link partner, perdere gli utm_ trasforma la migrazione in un problema sia SEO sia di reporting.

Lasciare la vera redirect map fuori dal layer live

Se la verità del progetto vive in un foglio e le regole attive vivono in file server, aumentano i punti ciechi.

Quando passare a un altro workflow

Questo momento arriva di solito quando:

• hai centinaia o migliaia di URL
• più team o agenzie cambiano le regole
• ti serve import CSV
• i conflitti vanno validati prima del go-live
• il rollback deve essere chiaro
• non vuoi più deployare l’origine per ogni modifica

A quel punto UrlEdge diventa utile:

• bulk URL management per redirect map grandi
• redirect management per ownership e rollout
• permanent 301 redirects per migrazioni durature

Conclusione

La domanda vera non è se .htaccess sia buona o cattiva.

La domanda vera è:

La tua migrazione è ancora abbastanza piccola da stare in poche regole manuali, oppure è già un progetto di routing con dipendenze SEO, campaign e multi-team?

Se è la seconda, lo snippet non è più la soluzione completa.