Fai un redirect 301 senza plugin scrivendo la regola direttamente a livello di server: nel file .htaccess su Apache, nella configurazione di Nginx, o tra le regole di un CDN come Cloudflare. La differenza rispetto a un plugin è dove la regola viene eseguita. A livello di server il redirect si risolve prima che WordPress venga caricato, mentre un plugin tiene le regole nel database e le controlla a ogni richiesta, dopo aver avviato WordPress. Per pochi redirect un plugin va benissimo; per molti, o quando cambi piattaforma, le regole server-side sono più stabili e veloci. In tutti i casi, ogni regola deve essere un 301 a salto singolo verso la pagina giusta. WPBuildAI genera la mappa dei redirect pronta per .htaccess, Nginx o il CDN.
Dove vivono i redirect senza plugin
Senza plugin, un redirect vive in uno di tre posti, tutti a monte di WordPress. Il primo è la configurazione del web server: .htaccess su Apache, o un blocco nella config di Nginx. Il secondo è il CDN, per esempio le regole di redirect di Cloudflare, che agiscono al bordo della rete, ancora prima del server. Il terzo, in pratica meno comune, è una regola a livello di hosting gestito. Il filo comune è che il redirect viene servito prima che il codice di WordPress entri in gioco, ed è proprio questo a renderlo leggero.
.htaccess su Apache
Su un server Apache, i redirect si scrivono nel file .htaccess, alla radice del sito. Una riga del tipo Redirect 301 vecchio-percorso nuovo-URL, o una regola di rewrite per i pattern, indica al server di rispondere subito con un 301 quando arriva la vecchia URL. Il vantaggio è che non serve alcun plugin e la regola agisce prima di WordPress. L’attenzione va alla sintassi e all’ordine delle regole, perché un errore in .htaccess può influire su tutto il sito; conviene perciò partire da una mappa pulita e testare.
La configurazione su Nginx
Su Nginx non esiste .htaccess: i redirect si mettono nel file di configurazione del server, di solito con una direttiva return 301 o una rewrite all’interno del blocco del sito. La logica è la stessa di Apache, cambia solo la sintassi. Poiché la config di Nginx spesso richiede accesso al server e un riavvio, è comune preparare l’elenco completo dei redirect e applicarlo in una volta, invece di aggiungerli uno a uno. Anche qui il redirect si risolve prima di WordPress, quindi non pesa sull’applicazione.
A livello di CDN
Se usi un CDN come Cloudflare, puoi gestire i redirect al bordo, con le sue regole di redirect di massa. Il vantaggio è che la richiesta viene reindirizzata ancora prima di raggiungere il tuo server, il che è il punto più veloce possibile. È un’ottima soluzione per grandi insiemi di redirect, perché scarica del tutto sia WordPress sia il server di origine. Carichi un elenco vecchio-nuovo e il CDN lo applica. Per un sito con migliaia di redirect, questa via tiene tutto fuori dall’applicazione.
Perché è più veloce di un plugin
Il motivo della velocità è semplice: meno lavoro per richiesta. Un plugin di redirect avvia WordPress, si carica e interroga il database per confrontare l’URL con le sue regole, tutto prima di rispondere. Una regola server-side risponde con il 301 senza avviare nulla di tutto questo. Su pochi redirect la differenza è invisibile, ma su migliaia incide sul Time to First Byte, che entra nei Core Web Vitals descritti su web.dev. Il Web Almanac 2024 (HTTP Archive) ricorda quanto WordPress già fa a ogni richiesta, e un plugin di redirect carico aggiunge altro.
Regole per redirect corretti
Spostare i redirect sul server non deve comprometterne la correttezza. Valgono le stesse regole di sempre: ogni redirect è un 301 permanente, si risolve in un solo salto verso la pagina giusta, e non punta tutto alla home, che Google legge come soft 404, secondo la documentazione sui redirect. Evita catene e loop, il problema dietro un errore di troppi redirect, e non esagerare col numero, come spiega quanti redirect sono troppi. Dopo aver caricato le regole, verifica un campione, come in verificare i redirect 301.
Passo per passo
- Inventaria gli URL e costruisci la mappa vecchio-nuovo.
- Scegli il punto: .htaccess (Apache), config Nginx, o CDN.
- Genera le regole nel formato giusto per quel punto.
- Applica l’elenco in una volta, non una regola alla volta.
- Verifica che i redirect si risolvano in un salto.
- Tieni il file sotto controllo di versione e monitora i 404.
Esempio: spostare una sezione
Prendiamo un sito che sposta una sezione, cambiando centinaia di URL, e che vuole evitare un plugin pesante. Si costruisce la mappa vecchio-nuovo e la si esporta come regole per Nginx, dato che il sito gira su quel server. Le regole vengono caricate nella config in una volta, e i redirect ora si risolvono prima di WordPress. Si verifica che un campione risponda con un 301 a salto singolo verso la pagina corretta, conforme alla guida sullo spostamento con modifiche agli URL. Il Time to First Byte resta basso e i redirect funzionano come con un plugin, ma senza il suo peso.
Errori da evitare
- Usare un plugin per migliaia di redirect, appesantendo ogni richiesta.
- Sbagliare la sintassi di .htaccess, con effetti su tutto il sito.
- Puntare i redirect alla home invece che alla pagina giusta.
- Creare catene o loop di redirect spostandoli sul server.
- Non verificare che le regole del server si risolvano in un salto.
Cosa ricordare
Fai un redirect 301 senza plugin scrivendo la regola a livello di server: .htaccess su Apache, config di Nginx, o regole del CDN. Lì si risolve prima che WordPress si carichi, quindi è più veloce di un plugin che controlla il database a ogni richiesta. Per pochi redirect un plugin va bene; per molti, o in una migrazione, il server è la scelta giusta. Mantieni ogni regola un 301 a salto singolo verso la pagina corretta, evita catene e loop, e verifica un campione. WPBuildAI genera la mappa dei redirect pronta per .htaccess, Nginx o il CDN. Invia l’indirizzo del tuo sito per un’analisi gratuita.
Senza affiliazione con WordPress, Lovable, Webflow, Shopify, Wix o Squarespace.