Con o senza www: quale versione scegliere e unificarle

Per Google non esiste una versione di dominio migliore: www.esempio.it e esempio.it possono posizionarsi ugualmente bene. Quello che conta è sceglierne una sola e far sì che tutto il resto, cioè redirect, canonical, sitemap e link interni, punti in modo coerente a quella. Il problema non è la scelta, è lasciare entrambe le versioni raggiungibili e rispondere con un 200 su ciascuna.

In questo articolo vediamo perché le due versioni sono tecnicamente host diversi, con quali criteri scegliere quella preferita, come configurare il redirect in modo pulito (in un solo salto, insieme a HTTPS) e come trattare nello stesso modo le varianti con e senza slash finale. Chiudiamo con i controlli da fare in Search Console e con gli errori che si incontrano più spesso nelle migrazioni.

Perché www e non-www sono due siti diversi

Un nome host è tutto ciò che sta tra lo schema e il percorso dell'URL. Per il protocollo HTTP, www.esempio.it ed esempio.it sono due host distinti: possono avere record DNS diversi, server diversi, certificati diversi e contenuti diversi. Il fatto che quasi tutti i siti li facciano rispondere allo stesso modo è una convenzione, non una regola. Google, quindi, non dà per scontato che siano la stessa cosa: li tratta come URL diversi finché non trova segnali che glielo dicano.

Se entrambe le versioni restituiscono la stessa pagina con stato 200, ti ritrovi con duplicati esatti su tutto il sito. Google di solito riesce a raggruppare i duplicati e a scegliere un URL canonico da solo, ma lo fa con le sue euristiche, non con le tue preferenze. Le conseguenze pratiche sono concrete: il link che un sito esterno punta a una versione e quello che ne punta un'altra non si sommano in modo pulito, nei report compaiono URL che non volevi vedere, il crawl budget viene speso due volte sulle stesse pagine e la versione mostrata nei risultati può cambiare da una pagina all'altra.

Le combinazioni da tenere sotto controllo non sono due ma quattro, perché si sommano al protocollo: http://esempio.it, http://www.esempio.it, https://esempio.it e https://www.esempio.it. Una sola di queste deve rispondere con 200. Le altre tre devono reindirizzare in modo permanente alla prima. È un errore comune sistemare il protocollo e dimenticare l'host, o viceversa.

Quale versione scegliere: i criteri che contano davvero

Dal punto di vista del posizionamento la scelta è neutra. Google non premia il www né la sua assenza, e nessun test serio ha mai mostrato il contrario; chi sostiene il contrario di solito confonde la scelta con la presenza o meno di redirect corretti. Conviene quindi decidere sulla base di considerazioni tecniche e pratiche, e poi non tornarci più sopra.

Ci sono però motivi concreti per cui il www può essere la scelta più robusta, soprattutto per siti grandi o con infrastrutture complesse. Il dominio nudo, detto anche apex, ha un limite nel DNS: su un apex non puoi mettere un record CNAME, perché convive con i record SOA e NS. Se il sito sta dietro una CDN o una piattaforma che ti chiede di puntare un CNAME, il www è la strada naturale. Molti provider risolvono il problema con record ALIAS o con il cosiddetto CNAME flattening, ma è una funzione del provider, non dello standard DNS. Un altro aspetto è quello dei cookie: un cookie impostato sul dominio nudo viene inviato anche a tutti i sottodomini, mentre un cookie impostato su www resta confinato a quell'host, il che può essere utile se servi risorse statiche da un sottodominio separato.

D'altra parte la versione senza www è più corta, più facile da scrivere su una locandina o in un biglietto da visita e oggi sembra più moderna a molti utenti. Per un sito piccolo, con hosting tradizionale e nessun requisito di CDN, non c'è alcuna controindicazione. In sintesi: se i backlink e i link interni puntano già a una versione, tienila; se la CDN richiede un CNAME, scegli www; altrimenti scegli la forma che il tuo team sa mantenere.

Il redirect 301: una sola regola, un solo salto

Il modo più solido per unificare le versioni è un redirect permanente 301 lato server dalla versione non preferita a quella preferita. Il 301 comunica a Google che la risorsa si è spostata in modo definitivo e che i segnali associati al vecchio URL vanno trasferiti al nuovo. Il meccanismo dei redirect in generale ha il suo approfondimento dedicato; qui ci interessa l'aspetto specifico: la regola deve essere scritta in modo che ogni richiesta arrivi alla destinazione finale in un solo passaggio.

Il caso tipico in cui si sbaglia è la catena. Un utente richiede http://esempio.it/pagina; una regola lo porta su https://esempio.it/pagina; una seconda regola lo porta su https://www.esempio.it/pagina. Sono due redirect in sequenza, e ogni salto aggiunge latenza e rischio. Con due o tre regole scritte in momenti diversi da persone diverse si arriva facilmente a quattro o cinque salti. La regola corretta porta direttamente all'URL finale, cioè https con l'host preferito, qualunque sia la combinazione di partenza.

Su Apache, con mod_rewrite attivo e ipotizzando www come host preferito, il blocco in .htaccess assomiglia a questo: RewriteEngine On, poi una RewriteCond che controlla se l'host non è esattamente www.esempio.it oppure se HTTPS è disattivato, e infine una RewriteRule che rimanda a https://www.esempio.it/ seguito dal percorso richiesto, con i flag R=301 e L. Su Nginx si usa invece un blocco server dedicato per le combinazioni da scartare, con una direttiva return 301 verso https://www.esempio.it seguita dalle variabili request_uri, e un blocco server separato per la versione buona. Molte piattaforme gestite, come le CDN, i pannelli degli hosting e i builder, offrono un'opzione equivalente a livello di configurazione: usala se c'è, ma controlla comunque il risultato con una richiesta reale.

Due dettagli spesso dimenticati. Il primo: il redirect deve conservare il percorso e i parametri della query, non mandare tutto alla home. Un redirect che scarica ogni URL sulla home è trattato come un soft 404 e distrugge i segnali pagina per pagina. Il secondo: il certificato TLS deve coprire tutte le combinazioni di host che redirigono. Se il certificato è emesso solo per www.esempio.it, chi digita https://esempio.it vede un errore di sicurezza prima ancora di raggiungere il redirect, e Google non può seguire una redirezione che non riesce a stabilire. Serve un certificato con entrambi i nomi, oppure un wildcard.

Canonical, sitemap e link interni devono dire la stessa cosa

Il redirect è il segnale più forte, ma non è l'unico e non deve restare da solo. Il tag rel canonical di ogni pagina dovrebbe contenere l'URL assoluto con protocollo, host preferito e percorso esatto. Il canonical è un suggerimento, non un ordine, e Google lo valuta insieme agli altri segnali: se il tag dice una cosa e il redirect un'altra, il sistema deve decidere da sé quale credere. Un canonical scritto come percorso relativo, o generato dinamicamente dall'host della richiesta, è una trappola classica: se qualcuno riesce a raggiungere una pagina sull'host sbagliato, il canonical si auto-riferisce a quello sbagliato e conferma il duplicato invece di risolverlo. Il valore dell'host va scritto nella configurazione dell'applicazione, non letto dalla richiesta.

Lo stesso vale per la sitemap XML, che deve elencare esclusivamente URL nella forma preferita. Una sitemap con URL che poi redirigono manda un messaggio contraddittorio e fa sprecare scansioni. Vale anche per i link interni: se il menu punta a https://esempio.it/servizi ma il sito vive su www, ogni clic interno passa da un redirect. Non è un danno grave, ma è un difetto facile da evitare con una ricerca e sostituzione sul database o sui template, e rende più nitidi i segnali.

Non dimenticare gli altri posti in cui compare l'host. Le annotazioni hreflang devono usare gli URL preferiti e devono essere reciproche. I dati strutturati con proprietà come url, sameAs o mainEntityOfPage devono riportare la forma canonica. Il file robots.txt va servito dall'host preferito, e le direttive Sitemap al suo interno devono puntare a URL assoluti nella forma corretta. Anche i link presenti nelle email transazionali, nei profili social, in Google Business Profile e nelle firme vanno allineati: non sono tutti segnali di ranking, ma ogni link esterno che punta alla versione sbagliata è un redirect in più da attraversare.

Lo slash finale: la stessa logica applicata al percorso

Il problema dello slash finale è gemello di quello del www. Per il server, /guida e /guida/ sono URL diversi. Nella tradizione dei web server, un URL che termina con slash indica una directory e uno senza slash un file, ma con i CMS moderni e i percorsi riscritti la distinzione non ha più un significato fisico: è solo una scelta. Google tratta le due forme come URL distinti per le pagine interne, quindi se il sito risponde con 200 a entrambe hai di nuovo un duplicato.

C'è un'eccezione utile da conoscere: per la radice del dominio la questione non si pone, perché https://www.esempio.it e https://www.esempio.it/ sono lo stesso URL, dato che la richiesta HTTP per la radice contiene sempre lo slash e i browser lo aggiungono da soli. Lo slash finale conta solo dal primo livello di percorso in poi, e lì va scelta una convenzione.

Quale scegliere? Anche qui il ranking è indifferente. Conviene seguire quello che il CMS genera in modo nativo: WordPress, per esempio, usa di default lo slash finale sui permalink, altre piattaforme fanno il contrario. Combattere la convenzione del sistema con regole manuali aumenta il rischio di loop di redirect. Quello che conta è applicare la regola in modo uniforme e fare in modo che la versione non scelta risponda con un 301 verso quella scelta, mantenendo query e percorso.

Attenzione ai file. Gli URL che terminano con un'estensione, come .pdf, .jpg, .xml o .css, non devono ricevere lo slash finale, altrimenti il file non si trova più e si produce un errore o un redirect inutile. Le regole generiche che aggiungono lo slash a tutto vanno quindi scritte con una condizione che escluda i percorsi che corrispondono a file esistenti. Lo stesso per gli endpoint di API e per le risorse dinamiche, dove lo slash può cambiare il significato della richiesta.

Search Console: proprietà di dominio o prefisso URL

In Search Console esistono due tipi di proprietà, e la scelta incide su come vedi i dati delle varianti. La proprietà di dominio aggrega tutti i protocolli e tutti i sottodomini, quindi include http, https, www e non-www in un unico report. Richiede la verifica tramite un record DNS. La proprietà con prefisso URL, invece, riguarda una sola combinazione esatta di protocollo e host: se la crei per https://esempio.it e il sito vive su www, non vedrai quasi nulla.

Non esiste più, in Search Console, l'impostazione del dominio preferito che un tempo permetteva di dichiarare la versione con o senza www. Lo strumento è stato dismesso, e l'unica via per comunicare la preferenza è quella dei segnali sul sito stesso: redirect, canonical, sitemap e link interni. Nel rapporto di indicizzazione, lo stato Duplicata: Google ha scelto una pagina canonica diversa da quella dell'utente è il campanello che indica che i segnali non sono ancora coerenti. Lo strumento Controllo URL mostra sia il canonical dichiarato dall'utente sia quello selezionato da Google: se divergono sulla tua versione preferita, controlla redirect e tag prima di toccare altro.

Come verificare che l'unificazione funzioni

Dopo aver configurato le regole, testa a mano tutte le combinazioni. Da terminale basta una richiesta con curl e l'opzione per mostrare solo le intestazioni, seguita dall'opzione per non seguire i redirect, in modo da vedere ogni salto separatamente. Per ciascuno dei quattro URL di partenza, e per una pagina interna con e senza slash, devi osservare esattamente un 301 con una intestazione Location che punta alla destinazione finale, e la destinazione finale deve rispondere 200. Se vedi due 301 in fila, hai una catena da accorciare.

Gli errori ricorrenti nelle migrazioni sono pochi:

• Redirect temporaneo al posto di quello permanente: un 302 lasciato per errore dal pannello dell'hosting indica a Google che lo spostamento non è definitivo.
• Loop di redirect: una regola dell'applicazione e una regola della CDN che si contraddicono sulla versione preferita producono un ciclo infinito e il sito diventa irraggiungibile.
• Record DNS mancante: se non esiste un record per la versione che deve solo redirigere, l'host non risponde affatto e il redirect non parte.
• Certificato incompleto: copre solo una delle due versioni, e le visite sull'altra mostrano un avviso prima del redirect.
• Canonical dinamico costruito dall'host della richiesta, che conferma il duplicato invece di risolverlo.