Redirect 301 e gestione 404 in WordPress: non perdere traffico per link rotti
Ogni 404 è un visitatore che se ne va e un segnale SEO negativo. Come gestire i redirect 301 a livello di server (non con plugin), monitorare i 404 da Search Console, e perché i redirect concatenati sono peggio del 404 stesso.
Un 404 non è solo una pagina che non esiste — è un visitatore che se ne va, un link di valore che perde peso SEO, e un segnale che Google registra. Quando rifai un sito, cambi la struttura degli URL, elimini vecchie pagine o migri da una piattaforma all'altra, i 404 sono inevitabili. Quello che non è inevitabile è lasciarli lì. Ogni URL con traffico che restituisce 404 è una perdita misurabile di visite e posizionamento.
L'errore più comune che vediamo è gestire i redirect con un plugin. Non che i plugin di redirect non funzionino — funzionano. Ma aggiungono un layer PHP a ogni richiesta 404: WordPress si avvia, elabora la richiesta, scopre che la pagina non esiste, cerca il redirect nel database, e solo allora reindirizza. Su un sito con mille 404 al giorno (succede più spesso di quanto pensi, per bot e link vecchi), è un carico inutile sul server. I redirect vanno gestiti a livello di web server, prima che WordPress venga coinvolto.
Redirect 301 a livello di .htaccess (Apache)
Il redirect più efficiente è quello che il web server gestisce prima ancora di passare la richiesta a PHP. Su Apache, si fa con RedirectMatch o Redirect nel file .htaccess. La regola: redirect semplici con Redirect, redirect con pattern con RedirectMatch:
# Redirect 301 di singole pagine (vecchio URL → nuovo URL)
Redirect 301 /vecchia-pagina https://www.example.com/nuova-pagina
Redirect 301 /servizi-vecchi https://www.example.com/servizi
Redirect 301 /chi-siamo-2018 https://www.example.com/chi-siamo
# Redirect con pattern: intera directory → nuova destinazione
RedirectMatch 301 ^/blog/2018/(.*)$ https://www.example.com/blog/$1
RedirectMatch 301 ^/category/(.*)$ https://www.example.com/argomenti/$1
# Redirect da vecchio dominio a nuovo dominio (migrazone completa)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^vecchio-dominio\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.vecchio-dominio\.com$
RewriteRule ^(.*)$ https://www.nuovo-dominio.com/$1 [R=301,L]Redirect a livello di Nginx (se non sei su Apache)
Se il tuo hosting usa Nginx (sempre più hosting cloud lo fanno), .htaccess non esiste. I redirect vanno nel file di configurazione del server block. La sintassi è diversa ma il concetto è lo stesso:
# Nginx: redirect singola pagina
location = /vecchia-pagina {
return 301 https://www.example.com/nuova-pagina;
}
# Nginx: redirect con pattern (directory intera)
location ~ ^/blog/2018/(.*)$ {
return 301 https://www.example.com/blog/$1;
}
# Nginx: redirect da vecchio dominio
server {
listen 80;
server_name vecchio-dominio.com www.vecchio-dominio.com;
return 301 https://www.nuovo-dominio.com$request_uri;
}Monitorare i 404 da Search Console
Google Search Console è la fonte più autorevole per i 404 che contano davvero — quelli che Google ha trovato e che avevano traffico o link. Nel pannello Copertura, filtra per 'Escluse' e cerca '404 non trovato'. Ogni URL in quella lista è un candidato per un redirect:
# Verifica che un redirect funzioni correttamente
curl -I -L https://www.example.com/vecchia-pagina
# Output atteso:
# HTTP/2 301
# location: https://www.example.com/nuova-pagina
# HTTP/2 200
# Verifica che non ci siano redirect concatenati (chain)
curl -o /dev/null -s -w 'Redirect count: %{num_redirects}\nFinal: %{url_effective}\n' \
-L https://www.example.com/vecchia-pagina
# Se num_redirects > 1, hai una catena: A → B → C invece di A → CLa pagina 404 personalizzata (l'ultima spiaggia)
Non tutti i 404 possono essere reindiritti — alcuni URL non hanno una destinazione naturale. Per quelli, la pagina 404 personalizzata è l'ultima possibilità di trattenere il visitatore. Una buona pagina 404 non dice solo 'pagina non trovata': offre ricerca, link alle sezioni principali, e articoli correlati. WordPress usa il file 404.php del tema:
<?php
// 404.php nel tema child
get_header(); ?>
<div class="error-404">
<h1>Questa pagina non esiste (più)</h1>
<p>L'URL che cercavi potrebbe essere stato spostato o eliminato.</p>
<!-- Form di ricerca -->
<?php get_search_form(); ?>
<!-- Link alle sezioni principali -->
<nav class="error-404-nav">
<a href="/servizi">I nostri servizi</a>
<a href="/blog">Il magazine</a>
<a href="/contatti">Contattaci</a>
</nav>
<!-- Articoli recenti come suggerimento -->
<h2>Articoli recenti</h2>
<?php
$recent = new WP_Query( array(
'post_type' => 'post',
'posts_per_page' => 3,
'post_status' => 'publish',
) );
if ( $recent->have_posts() ) :
while ( $recent->have_posts() ) : $recent->the_post(); ?>
<a href="<?php the_permalink(); ?>"><?php the_title(); ?></a>
<?php endwhile;
endif;
wp_reset_postdata();
?>
</div>
<?php get_footer(); ?>I redirect e i 404 sono manutenzione, non glamour. Ma sono il tipo di manutenzione che fa la differenza tra un sito che mantiene il posizionamento e uno che lo perde silenziosamente. Ogni 404 con traffico è un piccolo salasso SEO — da solo non uccide, ma cento insieme sì. L'audit dei 404 va fatto ogni trimestre, non una volta sola e mai più.
Verifica lo stato del tuo WordPress con un check-up gratuito.
Analisi di sicurezza, prestazioni e configurazione tecnica senza impegno commerciale.
Articoli correlati
Email deliverability WordPress: perché le email di WooCommerce finiscono nello spam
Leggi
Sitemap XML WordPress: perché l'XML sitemap è ancora essenziale nel 2026
Leggi