Sito con www o senza www: la guida completa

Sembra una domanda di altri tempi, e invece torna puntuale a ogni nuovo progetto: meglio pubblicare il sito con www oppure senza? La risposta breve è che per i motori di ricerca e per le persone non fa alcuna differenza: entrambe le forme sono URL perfettamente validi. La risposta lunga — quella che evita anni di indirizzi doppi, redirect a catena e cookie che sfuggono al controllo — è la vera ragione di questa guida. La sostanza non è «quale forma», ma una sola forma, dichiarata e difesa.

Cosa cambia davvero tra le due forme

Sul piano visivo, nulla. Sul piano tecnico, tre differenze concrete. Primo, il DNS: l'apex del dominio (il nome senza nulla davanti) non può contenere un record CNAME canonico, quindi chi usa CDN o piattaforme che si collegano via CNAME deve appoggiarsi al cosiddetto flattening, oggi diffuso ma un tempo fonte di grattacapi; con www il CNAME è nativo. Secondo, i cookie: un cookie impostato sull'apex viene inviato a tutti i sottodomini, tecnici compresi; con www i sottodomini di servizio restano isolati, un dettaglio che pesa quando il progetto cresce. Terzo, i certificati: un wildcard per *.esempio.it copre www ma non copre l'apex, quindi serviranno entrambe le SAN. Per il posizionamento, ripetiamolo, non esiste una forma premiata: esiste solo la coerenza.

La regola d'oro: una sola versione canonica

Google tratta esempio.it e www.esempio.it come due URL diversi. Se entrambi rispondono con stato 200 e contenuto identico, avete creato una duplicazione: i segnali si dividono, gli anchor si spargono, gli strumenti segnalano pagine duplicate. Il protocollo in cinque mosse:

• scegliere una forma e scriverla nel documento di progetto, il primo giorno;
• configurare un redirect permanente 301 dall'altra forma verso quella scelta;
• usare la forma scelta in tutti i link interni, nella sitemap, nei tag canonical;
• verificare in Search Console le proprietà per entrambe le versioni (e per http e https);
• impostare un canonical auto-riferito su ogni pagina, come conferma esplicita.

Il redirect 301, in pratica

Con Apache, nel virtual host della forma da ritirare:

<VirtualHost *:443>
    ServerName esempio.it
    Redirect permanent / https://www.esempio.it/
</VirtualHost>

Con Nginx, un server block dedicato:

server {
    listen 443 ssl;
    server_name esempio.it;
    return 301 https://www.esempio.it$request_uri;
}

Chi pubblica su reti edge può fare lo stesso con una regola di redirect a livello di zona: corrispondenza dell'host, redirect 301, preservazione del percorso e della query string. L'obiettivo è sempre uno solo: un singolo salto, senza catene.

Gli errori classici da evitare

• Catene di redirect: http:// che salta a https://, che salta ad apex, che salta a www. Ogni hop costa latenza su mobile e diluisce il segnale: dallo stato iniziale alla forma finale in un solo passaggio.
• Canonical bugiardi: la pagina canonica che punta alla forma opposta a quella servita confonde più di quanto non risolva.
• Sitemap miste: elenchi che contengono sia gli URL con sia quelli senza www, oltre a quelli in http.
• Link interni «quasi giusti»: puntano alla forma che poi viene reindirizzata. Funziona, ma ogni click paga un salto inutile.

Cosa conviene scegliere oggi

Per progetti ampi, con sottodomini tecnici, CDN dedicate e team che lavorano sul DNS, la forma www resta la più comoda: isola i cookie, semplifica il CNAME, scala senza ripensamenti. Per domini brevi, progetti editoriali o brand che vivono sull'essenzialità del nome, l'apex è legittimo e pulito. La nostra scelta qui è dichiarata apertamente: questo sito risponde in forma canonica su www.ondiz.net, e la forma senza www reindirizza permanentemente. Se volete approfondire il versante prestazioni, la guida all'uso di una rete edge e della compressione e quella sui punteggi di velocità completano il quadro; per la parte gestionale dei browser in azienda c'è il confronto tra Chrome e Firefox.