www ou sans www : quel choix pour le SEO ?

Non, choisir d'écrire www.exemple.fr plutôt que exemple.fr ne vous fera ni gagner ni perdre de positions sur Google. Le moteur traite les deux adresses comme deux hôtes distincts, sans préférer l'un ou l'autre, et ne donne aucun bonus à la forme "moderne" ou à la forme "classique". La question mérite pourtant mieux qu'un haussement d'épaules, parce que ce choix a des conséquences techniques bien réelles : le DNS, les cookies, les certificats, le CDN.

Le vrai risque SEO ne se trouve pas dans le choix lui-même, mais dans l'absence de choix. Un site qui répond en 200 sur les deux versions se retrouve avec deux copies complètes de chaque page, des signaux de liens dispersés et des rapports Search Console qui se contredisent. Cet article explique comment trancher selon vos contraintes, comment verrouiller la version retenue avec une redirection 301 et comment déclarer le tout correctement dans Search Console.

Ce que Google fait vraiment des deux versions

Techniquement, exemple.fr et www.exemple.fr sont deux noms d'hôte différents. Rien n'oblige un serveur à servir le même contenu sur les deux, et rien n'oblige Google à considérer qu'il s'agit du même site. Quand les deux adresses renvoient les mêmes pages, le moteur les regroupe dans la pratique par un mécanisme de canonicalisation : il regarde les redirections, les balises canoniques, les sitemaps et les liens internes, puis choisit une URL de référence pour chaque contenu.

Ce regroupement fonctionne souvent, mais vous le laissez alors entre les mains d'un algorithme. Il peut retenir la version que vous n'aviez pas en tête, hésiter d'une page à l'autre, ou changer d'avis après une modification du site. Les deux formes ne sont jamais pénalisées pour autant : il n'existe pas de sanction spécifique liée au www, et la documentation de Google présente les deux comme parfaitement acceptables, à condition que vous restiez cohérent.

Il faut aussi écarter une idée reçue. Une partie de la littérature ancienne conseillait d'ajouter le www parce que les internautes "s'attendent" à le voir. Aujourd'hui, les navigateurs masquent souvent le préfixe dans la barre d'adresse, et les gens arrivent par la recherche, les favoris, les réseaux sociaux ou des applications. L'argument de l'habitude ne pèse plus grand-chose, et il n'a de toute façon jamais été un facteur de classement.

Les vraies différences : DNS, cookies et infrastructure

Si le SEO est neutre, l'infrastructure ne l'est pas. La première contrainte est le DNS. Un nom de domaine racine, appelé aussi apex ou domaine nu (exemple.fr), doit porter des enregistrements SOA et NS, et les règles du DNS interdisent qu'un enregistrement CNAME cohabite avec d'autres enregistrements sur le même nom. Concrètement, vous ne pouvez pas faire pointer l'apex vers un service tiers avec un simple CNAME, alors que vous le pouvez sans difficulté pour www.

Cela compte dès que votre site est hébergé chez un prestataire qui vous donne un nom d'hôte à cibler plutôt qu'une adresse IP fixe : plateforme d'e-commerce, hébergeur de sites statiques, répartiteur de charge d'un fournisseur cloud. Beaucoup de services de DNS proposent des parades, sous des noms variables selon l'éditeur (aplatissement de CNAME, ALIAS, ANAME), mais elles ne sont pas universelles. Si votre fournisseur DNS ne les gère pas, le sous-domaine www est le chemin le plus simple et le plus robuste.

La deuxième contrainte concerne les cookies. Un cookie posé par exemple.fr avec un attribut Domain est envoyé à tous les sous-domaines, y compris ceux qui n'en ont pas besoin. Si vous servez vos images ou vos scripts depuis static.exemple.fr, chaque requête embarquera alors ces cookies, ce qui alourdit les en-têtes et expose des cookies de session à des hôtes qui n'ont rien à en faire. Avec www.exemple.fr comme site principal, vous pouvez restreindre les cookies à ce seul hôte et garder les autres sous-domaines "propres".

Cet argument s'est affaibli avec HTTP/2 et la compression des en-têtes, et il ne s'applique que si vous posez effectivement des cookies avec un domaine large. Il reste pertinent pour les sites qui hébergent plusieurs applications sous le même domaine, ou qui ont des exigences de sécurité strictes.

• Sans www : adresse plus courte, image plus moderne, mais apex soumis aux limites du DNS et cookies plus largement diffusés si vous les configurez au niveau du domaine.
• Avec www : CNAME possible vers un CDN ou un hébergeur, cookies plus facilement isolés, bascule de serveur plus souple, mais une adresse un peu plus longue à communiquer.
• Dans les deux cas : le SEO est identique, à condition qu'une seule version réponde.

Comment choisir : cinq critères pratiques

Puisque Google ne tranche pas pour vous, appuyez-vous sur des critères concrets. Le premier est votre hébergement : si la documentation de votre fournisseur recommande un CNAME vers un nom d'hôte, le www s'impose presque de lui-même, sauf si vous disposez d'un mécanisme d'alias sur l'apex. Le deuxième est votre architecture : un domaine qui porte déjà plusieurs sous-domaines (blog, application, espace client) gagne à avoir un site principal sur un hôte bien identifié.

Le troisième critère est l'existant. Si votre site est en ligne depuis des années et que la majorité des liens entrants, des mentions et des partages pointent vers une version, conservez-la. Les redirections 301 transmettent l'essentiel des signaux, mais toute migration comporte un risque d'erreur et une période de recalcul. Changer de version pour une simple préférence esthétique est rarement rentable.

Le quatrième critère est la communication : sur une carte de visite, une affiche ou une annonce radio, exemple.fr est plus court et plus facile à retenir. Le cinquième est la cohérence avec vos adresses électroniques et vos autres supports. Le nom de domaine des courriels n'est pas concerné par le choix du www, mais une marque qui écrit partout exemple.fr a intérêt à ce que le site réponde sur cette forme.

Pour un nouveau projet sans contrainte, les deux options se défendent. Retenez celle qui vous donne le plus de souplesse d'hébergement, puis figez ce choix dans tous vos outils.

La vraie règle : une seule version qui répond en 200

Quelle que soit la forme retenue, chaque contenu doit exister à une seule adresse. Pour y parvenir, il faut combiner plusieurs mécanismes, qui se renforcent mutuellement. Le plus important est la redirection 301 : la version non retenue renvoie vers la version retenue, sur toutes les URL, pas seulement la page d'accueil. Une redirection qui envoie www.exemple.fr/blog/article vers l'accueil est une erreur fréquente et coûteuse, car elle détruit la correspondance page à page.

La redirection doit aussi tenir compte du protocole. Il existe en réalité quatre variantes d'un même site : http://exemple.fr, http://www.exemple.fr, https://exemple.fr et https://www.exemple.fr. Trois d'entre elles doivent rediriger vers la quatrième en un seul saut. Un enchaînement du type http sans www, puis http avec www, puis https avec www fait perdre du temps aux visiteurs, consomme du budget d'exploration et multiplie les occasions de boucle.

Les autres signaux doivent ensuite aller dans le même sens. La balise canonique de chaque page pointe vers l'URL finale, avec le bon hôte. Le sitemap XML ne liste que des URL de la version retenue. Les liens internes, les liens hreflang, les données structurées, les images Open Graph et les flux utilisent tous le même hôte. Quand ces signaux se contredisent, Google doit arbitrer, et vous perdez le contrôle du résultat.

• Redirection 301 de la version écartée vers la version retenue, page par page.
• Redirection de http vers https dans le même saut, sans étape intermédiaire.
• Balise canonique auto-référencée sur l'hôte retenu.
• Sitemap XML et liens internes uniquement sur l'hôte retenu.
• Certificat HTTPS valide pour les deux noms, afin que la redirection fonctionne sans alerte de sécurité.

Mettre en place la redirection sans se tromper

Le point de départ est le certificat. Une redirection depuis https://www.exemple.fr vers https://exemple.fr suppose que le serveur puisse d'abord établir la connexion sécurisée sur l'hôte écarté. Si le certificat ne couvre que l'apex, les visiteurs qui tapent le www voient un avertissement avant même d'atteindre la redirection, et les robots peuvent abandonner. Faites donc émettre un certificat qui couvre les deux noms, ce que permettent les autorités de certification courantes, y compris gratuites.

Côté serveur, le principe est le même partout : un bloc de configuration pour l'hôte écarté, qui renvoie un code 301 vers l'hôte retenu en conservant le chemin et les paramètres de l'URL. Sous Apache, on le fait par une règle de réécriture dans le fichier de configuration ou dans le fichier .htaccess. Sous Nginx, un bloc de serveur dédié avec une directive de retour 301 suffit. Sur un hébergement mutualisé ou une plateforme de site, il existe souvent un réglage dans l'interface, qui évite de toucher aux fichiers.

Un exemple de raisonnement : vous choisissez la version sans www en HTTPS. Vous écrivez une règle qui dit "si l'hôte est www.exemple.fr, répondre 301 vers https://exemple.fr suivi du chemin demandé", et une seconde règle qui dit "si le protocole est http, répondre 301 vers l'adresse https sans www". Testez ensuite les quatre variantes, avec un chemin profond et des paramètres, pas seulement la racine.

Pour vérifier, un outil en ligne de commande qui affiche les en-têtes de réponse suffit : vous devez voir un seul code 301, puis un 200 sur l'URL finale. Les outils de crawl donnent aussi une vue d'ensemble, en listant toutes les chaînes de redirection du site. Si vous voyez deux 301 consécutifs, reprenez les règles pour les fusionner.

Search Console : déclarer une propriété de domaine

Search Console propose deux types de propriétés. La propriété de préfixe d'URL ne couvre qu'une adresse exacte : https://www.exemple.fr/ et https://exemple.fr/ sont donc deux propriétés différentes, et il faut en créer une pour chaque variante à surveiller. La propriété de domaine, elle, agrège toutes les variantes : http et https, avec et sans www, et tous les sous-domaines. Sa vérification se fait par un enregistrement TXT dans la zone DNS.

Pour le sujet qui nous occupe, la propriété de domaine est le bon réflexe. Elle rassemble dans un seul rapport les performances, les erreurs d'exploration et l'indexation de toutes les versions, ce qui permet de constater qu'une ancienne variante continue de recevoir des impressions ou d'être explorée. C'est aussi la meilleure façon de surveiller une migration, puisque vous voyez l'hôte écarté se vider pendant que l'hôte retenu monte en charge.

La propriété de domaine ne remplace pas la vigilance : elle ne choisit rien à votre place. Certains rapports, comme l'inspection d'URL, restent liés à une adresse précise. Conservez une propriété de préfixe d'URL sur l'hôte retenu si vous voulez des vérifications ciblées, et laissez la propriété de domaine servir de filet de sécurité. Vous n'avez plus à déclarer de "domaine préféré" : l'ancien réglage de ce nom a disparu de l'outil, et les redirections ainsi que les balises canoniques font désormais ce travail.

Dernier point : si vous avez déjà des propriétés de préfixe d'URL sur les anciennes variantes, ne les supprimez pas le jour de la redirection. Elles vous serviront à observer la transition, et à repérer les pages restées accessibles par erreur.

Les erreurs qui coûtent cher

La plus répandue est de laisser les deux versions en ligne "parce que la canonique s'en occupe". Une balise canonique est une indication, pas une instruction : Google peut l'ignorer si d'autres signaux la contredisent. Elle ne règle pas non plus le problème pour les visiteurs, qui restent répartis entre deux adresses, ni pour les outils d'analyse, qui comptent deux sites.

La deuxième est la redirection temporaire. Un code 302 ou 307 dit "cette adresse reviendra", et laisse planer le doute sur la version à retenir. Pour une règle permanente, utilisez 301 ou 308. La troisième est d'oublier les sous-domaines génériques : si votre DNS accepte n'importe quel sous-domaine et que le serveur y répond, vous pouvez vous retrouver avec des copies du site sur des hôtes que personne n'avait prévus.

La quatrième concerne les environnements de préproduction et les hôtes techniques. Une adresse de test ou l'hôte d'origine d'un CDN, indexés par accident, créent un troisième ou un quatrième jeu de doublons. Le même principe vaut pour eux : authentification, noindex ou redirection vers l'hôte public. La cinquième est d'activer HSTS avec l'option qui inclut les sous-domaines avant d'avoir vérifié que tous les sous-domaines sont bien accessibles en HTTPS, ce qui peut les rendre inutilisables dans les navigateurs qui ont mémorisé la consigne.

Enfin, n'oubliez pas les ressources extérieures à votre site : profils sociaux, annuaires, fiches d'établissement, campagnes de liens. Mettez à jour ce que vous maîtrisez pour pointer vers l'hôte retenu. La redirection rattrapera le reste, mais un lien direct évite un détour inutile et limite la dépendance à la redirection.

Changer de version sur un site déjà en ligne

Passer du www au sans www, ou l'inverse, est une migration d'URL comme une autre, en plus simple puisque les chemins ne changent pas. Préparez la liste des règles de redirection, le nouveau sitemap, les balises canoniques et les liens internes, puis déployez l'ensemble en une seule fois. Les redirections doivent rester en place durablement : c'est une règle de configuration, pas un pansement temporaire, et les supprimer au bout de quelques mois ferait réapparaître les anciennes adresses.

Après la bascule, surveillez trois choses. D'abord les rapports d'indexation et d'exploration de la propriété de domaine, pour vérifier que l'hôte retenu prend bien le relais. Ensuite les journaux du serveur, pour voir si les robots suivent les 301 sans erreur. Enfin les performances organiques, en comparant sur plusieurs semaines les pages de destination regroupées par hôte. Des fluctuations légères sont normales pendant le recalcul, mais une chute durable doit vous pousser à rechercher une chaîne de redirection, un blocage ou une canonique erronée.

Pensez aussi aux outils connexes : propriétés d'analyse, balises de suivi, domaines autorisés dans les formulaires de connexion tierce, configurations CORS, politiques de sécurité du contenu. Un changement d'hôte peut casser ce qui dépendait de l'ancienne adresse sans que le SEO y soit pour quelque chose, et ces pannes se découvrent rarement d'elles-mêmes.