Pour le référencement, un site avec ou sans www ne fait pas de différence : le domaine nu reste la meilleure option d'un site vitrine ou d'un blog qui veut une adresse web courte, le www la solution d'un site internet branché sur un réseau de diffusion ou entouré de sous-domaines. Une fois le nom de domaine choisi, l'autre version redirige vers lui en 301.
- Domaine nu (monsite.org)
- Nom plus court à dicter et à imprimer, idéale pour un site simple hébergé sur un seul serveur.
- Sous-domaine www (www.monsite.org)
- Plus souple côté DNS : accepte un CNAME vers un CDN et isole les cookies des autres sous-domaines.
- Règle commune
- Une seule adresse canonique, l'autre en redirection permanente, un certificat qui couvre les deux noms.
Pourquoi certaines adresses web commencent encore par www
Le préfixe www vient des débuts du World Wide Web : une organisation qui possédait un nom de domaine y nommait chaque machine selon son rôle, ftp pour le serveur de fichiers, mail pour la messagerie, www pour le serveur web. Taper www.monsite.org revenait à viser la machine qui publiait les pages. Aucune norme n'a jamais imposé ce préfixe : c'est une convention de nommage, devenue un réflexe chez les internautes. Le premier serveur du Web, au CERN, centre de recherche où Tim Berners-Lee a créé le protocole HTTP et le langage HTML, répondait d'ailleurs sous le nom info.cern.ch, sans www.
Le nom d'hôte www était donc une simple étiquette : le protocole ne l'exige pas, et un texte HTML était tout aussi accessible sur l'apex que sur un sous-domaine. La lecture de l'URL par le navigateur ne change pas selon la présence du préfixe.
Aujourd'hui, un seul serveur répond le plus souvent aux deux noms, et la plupart des navigateurs masquent le www dans la barre d'adresse. Pour le visiteur, exemple.fr et www.exemple.fr désignent le même site. Pour le DNS, en revanche, ce sont deux noms distincts : le premier est le sommet de la zone, appelé apex ou domaine nu, le second un sous-domaine comme un autre. Cette différence technique, invisible à l'écran, explique tout le reste du comparatif.
Domaine nu ou www : le comparatif critère par critère
Le domaine nu et le www se départagent sur quatre critères techniques et un critère d'usage. Aucun ne touche au classement dans les moteurs de recherche ; tous touchent à la gestion quotidienne du site et à son évolution.
| Critère | Domaine nu | www |
|---|---|---|
| Enregistrement DNS | A ou AAAA obligatoire, CNAME interdit à l'apex | CNAME accepté, pratique pour un CDN |
| Cookies | Peuvent partir vers tous les sous-domaines | Restent séparés d'un sous-domaine statique |
| Certificat TLS | Doit aussi couvrir www | Doit aussi couvrir le domaine nu |
| Lisibilité | Nom court, facile à dicter | Reconnue d'emblée comme un site internet |
| Référencement | Aucun en soi | Aucun en soi |
L'interdiction du CNAME à l'apex vient des RFC 1034 et 1912 : le sommet de la zone porte déjà les enregistrements SOA et NS, qu'un alias ne peut pas côtoyer. Certains fournisseurs DNS contournent la règle par un mécanisme d'aplatissement (ALIAS, ANAME ou CNAME flattening), mais cet outil n'existe pas chez tous les registraires. Le certificat, lui, doit couvrir les deux noms, même celui qui ne sert qu'à rediriger, sinon le navigateur affiche une alerte avant de suivre la redirection ; la question du certificat SSL à double nom détaille ce réglage.
Quelle variante retenir selon le profil du site
Le choix entre domaine nu et www se tranche sur l'architecture prévue du site, pas sur une préférence esthétique. Trois profils couvrent la grande majorité des cas.
Site vitrine, blog ou petit WordPress
Un site vitrine ou un blog hébergé sur un seul serveur mutualisé gagne à prendre le domaine nu : le nom est plus court sur une carte de visite, dans une signature d'e-mail ou au bas d'un article de blog, et aucune contrainte DNS ne pèse sur lui. L'hébergeur fournit une IP à poser en enregistrement A, le www redirige vers l'apex, et la configuration s'arrête là. Une agence de communication digitale qui livre un site vitrine à un artisan retient d'ailleurs plutôt cette version, plus lisible sur les supports imprimés et dans le marketing digital local.
Boutique ou plateforme derrière un CDN
Une boutique en ligne ou une plateforme qui passe par un réseau de diffusion de contenu a intérêt à garder le www. Le CDN fournit généralement un nom à cibler en CNAME, ce que seul un sous-domaine accepte sans artifice ; changer de prestataire revient alors à modifier une ligne de la zone. Ce raisonnement vaut pour un site qui sert ses images, sa vidéo, ses scripts ou ses fichiers produit depuis un sous-domaine statique. L'intégration d'un module de paiement, d'un outil d'emailing ou d'une ressource externe passe elle aussi plutôt par un sous-domaine, et chaque intégration de ce type se gère mieux quand le site public vit déjà en www.
Application avec plusieurs sous-domaines
Une application qui répartit ses éléments sur app., api. ou espace client. sous le même nom de domaine profite aussi du www. Des cookies déposés sur le domaine nu peuvent être transmis à tous ces sous-domaines, ce qui alourdit chaque requête et mélange des sessions qui devraient rester étanches. Un site public en www garde ses données de session à part, et chaque fonctionnalité de l'application reste isolée ; cette séparation simplifie aussi le support technique quand une fonctionnalité tombe en panne.
Le www a-t-il un impact SEO ?
Le www n'a aucun effet sur le référencement en lui-même : Google traite exemple.fr et www.exemple.fr comme deux URL différentes, sans préférence pour l'une ou l'autre. Le risque vient de l'absence de choix. Si les deux variantes répondent avec le même contenu, le moteur de recherche voit deux copies du site, répartit les liens entrants entre elles et choisit seul celle qu'il affiche : c'est le duplicate content technique le plus courant. Le problème ne se voit pas à l'œil nu, mais il se mesure : une recherche site: sur chaque variante montre néanmoins vite si les deux sont indexées.
La documentation Google Search Central sur la consolidation des URL en double classe la redirection parmi les signaux forts pour désigner l'adresse canonique. Elle se complète par une balise link rel="canonical" cohérente sur chaque page et un plan du site qui ne liste que le domaine canonique. Dans Google Search Console, une propriété de domaine regroupe les deux variantes et l'extension https dans un seul rapport, utile pour suivre la recherche organique sans jongler entre plusieurs propriétés. Cette aide au suivi ne remplace pas la redirection : elle permet seulement de vérifier, au niveau du domaine entier, que la mise en place a produit l'effet attendu.
Domaine nu et www : les cas limites avant de trancher
Les adresses e-mail changent-elles avec le choix du www ?
Les adresses e-mail ne changent pas : le courrier dépend des enregistrements MX du domaine, pas de la variante retenue pour le site web. Une boîte contact@monsite.org continue de fonctionner, que le site soit servi en www ou sur l'apex.
Faut-il garder la variante secondaire dans la zone DNS ?
La variante secondaire doit rester dans la zone DNS et continuer à répondre, faute de quoi la redirection ne peut pas fonctionner. La supprimer casserait tous les anciens liens qui pointent vers elle, y compris ceux des annuaires et des réseaux sociaux.
Peut-on utiliser le www et le domaine nu ensemble ?
Le www et le domaine nu peuvent coexister techniquement, mais un seul doit servir les pages ; l'autre se contente d'une redirection permanente vers lui. Servir les deux à l'identique crée deux sites aux yeux de Google.
Mettre en place la redirection 301 sur le serveur
La redirection 301 se pose sur le serveur web, au plus près de la requête. Sur Apache, quelques lignes dans le fichier htaccess à la racine suffisent. Cet exemple envoie toutes les requêtes vers https://www.exemple.fr en conservant le chemin demandé :
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC,OR]
RewriteCond %{HTTPS} off
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [R=301,L]Sous Nginx, un bloc server dédié aux noms secondaires fait un travail identique :
server {
listen 443 ssl;
server_name exemple.fr;
return 301 https://www.exemple.fr$request_uri;
}Sauvegarder le .htaccess existant avant d'y toucher évite de bloquer tout le site sur une faute de frappe : une erreur de syntaxe produit une erreur 500 générale, et ce fichier sert aussi à configurer des pages d'erreur 404 et 500 personnalisées. Un CMS garde souvent sa propre URL de référence dans ses réglages : sous WordPress, l'adresse du site et l'adresse WordPress doivent reprendre exactement le nom retenu, sinon CMS et serveur se renvoient la requête en boucle. La bascule vers HTTPS sur WordPress suit d'ailleurs la même logique de réglages.
Changer de variante sur un site déjà référencé
Passer du domaine nu au www, ou l'inverse, se fait sans perte durable si la redirection est permanente, page à page, et jamais vers l'accueil seul. Google recalcule l'adresse canonique au fil de son exploration ; le temps nécessaire varie selon la taille du site et la fréquence de passage du robot, et l'utilisation d'un plan du site à jour l'accélère.
- Vérifier que le certificat couvre déjà les deux noms.
- Changer l'URL de référence du CMS, puis poser la redirection serveur.
- Mettre à jour les liens internes écrits en dur, le plan du site et les balises canoniques.
- Contrôler quelques URL profondes avec curl -I pour lire le code 301 et l'en-tête Location.
- Suivre dans la Search Console la migration des pages indexées vers la nouvelle version.
Les autres réglages de domaine, de DNS et de messagerie se trouvent dans la rubrique services internet et hébergement.
Sources : documentation Google Search Central sur la consolidation des URL en double et les URL canoniques, RFC 1034 et RFC 1912 de l'IETF pour la règle du CNAME, documentation Apache HTTP Server 2.4 (mod_rewrite), documentation Nginx, MDN Web Docs sur le choix entre www et domaine nu.
