1,200 26/03/2026 07/04/2026 8 min

Il sintomo era chiaro: in Search Console cresceva il report “Pagina con reindirizzamento” e, nello stesso periodo, il file di log mostrava un crawler che rimbalzava tra due URL quasi identici. Le visite organiche calavano piano, ma il problema vero era un altro: Google sprecava richieste su URL duplicati invece di consolidare quelli buoni.

In questi casi non conviene partire dal CMS. Conviene partire dal server, dai log e da una sola domanda: quale URL deve essere l’unica versione canonica? Da lì si risolve il resto, passo passo.

Prerequisiti

Serve accesso a:

  • Apache con mod_rewrite attivo o configurazione virtual host modificabile.
  • SSH sul server, oppure pannello hosting con accesso ai file di configurazione.
  • Google Search Console per leggere il report di indicizzazione.
  • Un editor per file come vim, nano o il file manager del pannello.

Note: se usi Plesk, vai in Siti Web e Domini → Impostazioni Apache e nginx. Se usi cPanel, controlla Domains → Redirects e il file .htaccess.

Warning: prima di cambiare redirect o canonical, salva una copia del file di configurazione e del .htaccess. Un errore qui può creare loop o bloccare il sito.

Step 1: identifica il sintomo nei log e in Search Console

Il primo passo è verificare se il problema è reale e ripetibile. Nel report di Search Console cerca questi segnali:

  • Pagina con reindirizzamento
  • Pagina duplicata, Google ha scelto una pagina canonica diversa da quella utente
  • Esclusa da tag “noindex” se il noindex è finito dove non doveva

Dal server, filtra i log per il bot di Google e per gli URL sospetti.

grep -E 'Googlebot|/blog/|/blog' /var/log/apache2/access.log | tail -n 50
# Output:
# 66.249.66.1 - - [26/Mar/2026:12:10:31 +0000] "GET /blog HTTP/1.1" 302 412 "-" "Googlebot/2.1"
# 66.249.66.1 - - [26/Mar/2026:12:10:32 +0000] "GET /blog/ HTTP/1.1" 200 18422 "-" "Googlebot/2.1"

Qui il sintomo è evidente. Google visita /blog, riceve un 302 e poi arriva su /blog/. Se il comportamento si ripete su molte URL, il crawl budget si spreca.

Step 2: scegli una sola versione canonica

Devi decidere una regola unica. Esempi tipici:

  • https://example.com/ come versione finale.
  • Con o senza www, ma solo una.
  • Con slash finale per le directory, se il sito lo usa in modo coerente.

Il motivo è semplice. Se il server risponde in modo diverso a seconda della forma dell’URL, i bot vedono duplicati. Anche gli utenti possono finire su percorsi diversi per la stessa pagina.

Nel pannello del CMS spesso trovi il campo Indirizzo del sito o URL canonico. Vai lì solo per verificare che il dominio impostato sia corretto. Poi correggi il server, non il contrario.

Note: in WordPress controlla Impostazioni → Generali. In Drupal cerca Configuration → System → Basic site settings. In questi casi il CMS deve riflettere il dominio scelto, non inventarne uno nuovo.

Step 3: sostituisci il 302 con un 301 pulito

Un 302 dice “spostamento temporaneo”. Per SEO tecnico quasi sempre è la scelta sbagliata se il cambio è stabile. Usa un 301 per consolidare segnali e link.

Nel virtual host Apache, una regola semplice per forzare HTTPS e dominio senza www può essere questa:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

# Output: ogni richiesta su HTTP o su www viene portata a https://example.com con codice 301.

Se lavori da pannello, cerca la sezione Redirect o Reindirizzamenti. Imposta il tipo su Permanente (301). Poi verifica che il pannello non stia aggiungendo un secondo redirect via CMS o plugin.

Warning: non concatenare più regole che puntano a destinazioni diverse. Un redirect da HTTP a HTTPS e un altro da www a non-www devono finire nella stessa destinazione finale, in un solo salto.

Step 4: correggi il canonical nella pagina, non solo nel server

Il redirect non basta. Se il tag canonical punta a un URL diverso, Google riceve segnali contraddittori. Il risultato è spesso questo: la pagina è raggiungibile in una forma, ma dichiarata canonica in un’altra.

Nel sorgente HTML verifica la presenza di una sola riga coerente:

<link rel="canonical" href="https://example.com/blog/seo-tecnico/" />

# Output: il canonical coincide con l’URL finale servito dal 301.

Se il CMS genera canonical dinamici, controlla questi punti:

  • la base URL del sito è corretta;
  • il plugin SEO non sta forzando uno slug vecchio;
  • categorie, tag e pagine archivio non puntano tutti alla home.

Note: in molti siti il canonical errato nasce da un plugin SEO dopo una migrazione. In quel caso non servono regole extra sul server. Serve correggere la sorgente del tag.

Step 5: riduci il crawl budget con regole su URL inutili

Il crawl budget diventa un problema quando il bot consuma molte richieste su URL che non portano valore. Tipici responsabili:

  • parametri di tracking come ?utm=;
  • filtri interni con combinazioni infinite;
  • versioni con e senza slash;
  • archivi data inutili;
  • ricerche interne indicizzabili per errore.

Su Apache puoi normalizzare alcuni parametri senza toccare il CMS. Esempio semplice: togli i parametri di tracking e ridirigi alla stessa pagina pulita.

RewriteCond %{QUERY_STRING} (^|&)utm_[^=]+=[^&]+ [NC]
RewriteRule ^ %{REQUEST_URI}? [R=301,L]

# Output: gli URL con parametri utm_* vengono ripuliti e reindirizzati alla versione senza query string.

Non abusare di questa tecnica. Va bene per parametri di marketing, non per parametri funzionali come paginazione o filtri importanti.

Se hai accesso a Google Search Console, usa anche il report Statistiche di scansione. Cerca picchi di richieste su URL inutili. Se il numero cresce, il crawler sta lavorando male. Se cala dopo le correzioni, hai ridotto lo spreco.

Step 6: verifica che non esistano catene di redirect

Una catena lunga rallenta il bot e peggiora l’esperienza utente. L’obiettivo è sempre: un URL vecchio → un URL finale.

Controlla la catena con curl:

curl -I -L https://www.example.com/blog
# Output:
# HTTP/2 301
# location: https://example.com/blog/
# HTTP/2 200

Se vedi tre o quattro passaggi, hai trovato un problema. Spesso la catena nasce da una somma di regole: CDN, web server, CMS e plugin SEO.

Fix rapido: elimina il redirect più basso nella catena, di solito quello nel CMS, e lascia una sola regola sul server o sul bilanciatore.

Step 7: allinea sitemap e link interni

La sitemap deve contenere solo URL canonici e finali. Se elenca indirizzi vecchi, Google continua a visitarli e a sprecare risorse.

Controlla la sitemap dal browser:

  • deve usare https;
  • deve riportare il dominio scelto;
  • non deve includere parametri;
  • non deve elencare URL che fanno 301.

Se la sitemap viene generata da WordPress, vai in SEO plugin → Sitemap e rigenera il file. Se è generata dal server o da un task, aggiorna la sorgente e svuota la cache.

Note: i link interni hanno più peso del canonical in molti siti piccoli. Se nel menu o nei breadcrumb compare la vecchia versione, correggi subito i template.

Verifica finale

Quando la correzione è fatta, fai quattro controlli rapidi:

  1. l’URL vecchio risponde con 301 verso quello giusto;
  2. l’URL finale risponde con 200;
  3. il tag canonical coincide con l’URL finale;
  4. la sitemap elenca solo URL canonici.

Puoi confermare con questo comando:

curl -sI https://example.com/blog | sed -n '1,5p'
# Output:
# HTTP/2 200
# content-type: text/html; charset=UTF-8

Se vuoi una verifica più completa, usa URL Inspection in Search Console e richiedi l’indicizzazione della pagina corretta. Non farlo prima di aver sistemato il redirect e il canonical.

Troubleshooting

1) “Too many redirects”

Causa: due regole si rimandano a vicenda, spesso tra www e non-www o tra HTTP e HTTPS.

Fix:

curl -IL https://www.example.com/ | head -n 20
# Output:
# HTTP/2 301
# location: https://example.com/
# HTTP/2 200

Se il comando mostra più di un 301, elimina una delle regole e lascia una sola destinazione finale.

2) “Submitted URL marked ‘noindex’”

Causa: il canonical o il template include un meta noindex su pagine che vuoi indicizzare.

Fix:

grep -R "noindex" /var/www/html/ -n | head
# Output:
# /var/www/html/wp-content/themes/site/header.php:42:<meta name="robots" content="noindex,follow">

Rimuovi il meta dal template o dal plugin SEO, poi rigenera cache e sitemap.

3) “Duplicate, Google chose different canonical than user”

Causa: il canonical HTML punta a una URL diversa da quella servita dal redirect o dai link interni.

Fix:

curl -s https://example.com/pagina/ | grep -i canonical
# Output:
# <link rel="canonical" href="https://example.com/pagina" />

Allinea lo slash finale tra server, template e sitemap. Poi invalida la cache del CMS o del reverse proxy se presente.

Conclusione

Un problema SEO lato server raramente nasce da un solo errore. Di solito è la somma di redirect, canonical e link interni incoerenti.

Se parti dai log e chiudi il cerchio con Search Console, trovi il punto esatto dove il crawler perde tempo. Il prossimo passo concreto è controllare una sola URL sospetta, dall’accesso al canonical, senza cambiare altro.

Nota pratica: se vuoi ridurre davvero il crawl budget, misura prima e dopo. Senza numeri, il fix sembra giusto ma resta solo un’impressione.