WWW ou non-WWW : quel choix pour le SEO ?

TL;DR — www.example.com et example.com sont deux noms d’hôte distincts qui servent généralement le même site. Aucun des deux formats ne présente un avantage SEO intrinsèque : il faut simplement en choisir un, rediriger l’autre vers celui-ci et rester cohérent partout. Le choix dépend surtout de l’hébergement et du DNS, pas du SEO.

Ce que sont réellement www et non-www

Le www d’une adresse web est un sous-domaine, au même titre que blog.example.com ou shop.example.com. Il s’agit simplement d’une ancienne convention signifiant « voici le site web ». La version sans www, example.com, est appelée domaine nu, domaine apex ou domaine racine : trois noms pour la même chose.

Les deux versions pointent habituellement vers exactement les mêmes pages. La question n’est donc pas de savoir laquelle constitue un meilleur site, mais laquelle vous voulez faire reconnaître comme l’adresse de référence par les moteurs et les navigateurs.

Cela influence-t-il votre classement ?

Non. C’est l’une des questions les mieux établies en SEO. Depuis vingt ans, Google répète qu’il ne préfère ni www ni non-www et qu’un passage correctement réalisé de l’un à l’autre ne modifie pas le classement.

Inutile donc de chercher la version la plus « SEO-friendly » : aucune ne l’est davantage. Le vrai risque consiste à laisser les deux versions accessibles sans en désigner une, de sorte qu’une même page existe à deux adresses et que les moteurs doivent deviner laquelle afficher.

Comment procéder correctement

1. Choisissez une version — www ou non-www, les deux conviennent.
2. Redirigez l’autre vers elle avec une redirection permanente (301).
3. Alignez tous les signaux — liens internes, sitemap et balises canoniques doivent utiliser la même version.

C’est tout. Google Search Console proposait autrefois un réglage permettant d’indiquer directement cette préférence, mais Google l’a supprimé ; la version Avancé explique ce qui l’a remplacé.

L’erreur la plus fréquente

On traite souvent ce choix comme une décision SEO, alors qu’il relève surtout de la plomberie technique. Si tant de sites utilisent www, ce n’est pas pour le classement, mais à cause du fonctionnement du DNS : certaines configurations ne peuvent pas pointer le domaine nu vers la bonne destination sans mécanisme supplémentaire. Pour les détails DNS, le piège des certificats lors d’une migration et l’obsolescence du conseil sur les domaines sans cookies, passez à l’onglet Avancé.

TL;DR — www est un sous-domaine ; non-www désigne le domaine apex, nu ou racine. Google affirme depuis 2005 qu’il n’existe aucune différence de classement et John Mueller l’a réaffirmé en mars 2024 : “when the canonical URL switches, it just switches” (traduction) « lorsque l’URL canonique change, elle change simplement ». Le réglage Preferred Domain de GSC a été supprimé le 18 juin 2019. Il est remplacé par des signaux concordants : rel=canonical, un sitemap limité à la version choisie et une redirection permanente depuis l’autre version. La raison pratique de préférer www est le DNS : un CNAME ne peut pas se trouver à l’apex, qui exige donc A/AAAA, ALIAS, ANAME ou l’aplatissement CNAME. Vérifiez aussi TLS/HSTS sur le nom d’hôte source et l’attribut Domain qui règle la portée des cookies, puis oubliez l’ancien argument du domaine sans cookies.

www est un sous-domaine ; non-www est l’apex

Commençons par la définition, car elle détermine toute la suite : www est un sous-domaine, structurellement identique à blog. ou shop.. example.com est le domaine apex — également dit « nu » ou « racine » — où résident les enregistrements SOA et NS. Cette nuance paraît pointilleuse jusqu’au moment de configurer le DNS, où elle devient essentielle.

Comme www est un sous-domaine, on pourrait être tenté d’appliquer tout ce que Google dit des sous-domaines à la question du classement. Ce serait utiliser la mauvaise preuve. La formule souvent citée de Mueller selon laquelle Google traite sous-domaines et sous-répertoires “the same” (traduction) « de la même manière » répond à une autre question : où organiser des contenus réellement différents, par exemple blog.example.com ou /blog/. www et non-www présentent au contraire un contenu identique sur deux noms d’hôte : c’est un problème de canonicalisation, pas d’architecture de l’information. Les preuves directement consacrées à www suivent.

www ou non-www influence-t-il le classement ? Non.

La réponse est stable depuis presque plus longtemps que toute autre règle SEO. Dès 2005, Google présentait le sujet comme un problème d’URL dupliquées et de consolidation, non de classement. En mars 2024, John Mueller répondait au propriétaire d’un site dont la migration Cloudflare avait inversé les canoniques de www vers non-www : “This won’t cause problems with search visibility / rankings / indexing: when the canonical URL switches, it just switches. You might see a little blip, but it goes to normal very quickly.” (traduction) « Ce changement ne nuira ni à la visibilité, ni au classement, ni à l’indexation : l’URL canonique bascule simplement. Une petite variation peut apparaître, puis la situation se normalise rapidement. »

Il ajoute une réserve décisive : “The only time it would cause bigger changes is if you switch canonicals to a different domain… with a www/non-www switch it’s all within the same domain and you should be fine.” (traduction) « Le seul cas où cela provoquerait des changements plus importants serait un passage des canoniques vers un autre domaine… avec www/non-www, tout reste dans le même domaine et cela devrait bien se passer. » www et non-www appartiennent au même domaine enregistré : vous ne changez pas de domaine, vous choisissez un nom d’hôte.

Considérez donc la question du classement comme réglée — la réponse est non — et concentrez vos efforts sur le DNS et la redirection.

Soyez également précis sur le bénéfice de la cohérence : choisir un nom d’hôte et aligner les signaux supprime l’ambiguïté de duplication pour les robots. Cela ne garantit ni classement, ni trafic, ni citation dans un AI Overview ou un chatbot. Une canonicalisation correcte ne promet aucun résultat ; elle fournit simplement aux moteurs et systèmes de réponse une adresse claire plutôt que deux.

Historique : le réglage Preferred Domain de GSC

Pendant des années, Google Search Console proposait le réglage Preferred domain : on indiquait à Google s’il devait afficher la version www ou non-www. De nombreux anciens tutoriels demandent encore de l’activer, mais il n’existe plus.

Google a annoncé sa suppression dans l’article du 18 juin 2019 Bye Bye Preferred Domain setting : “As we progress with the migration to the new Search Console experience, we will be saying farewell to one of our settings: preferred domain.” (traduction) « À mesure que nous avançons dans la migration vers la nouvelle expérience Search Console, nous allons dire adieu à l’un de nos réglages : le domaine préféré. » Surtout, les anciennes configurations ont cessé d’être prises en compte : “Note that with the deprecation we will no longer use any existing Search Console preferred domain configuration.” (traduction) « Avec cette suppression, nous n’utiliserons plus aucune configuration existante de domaine préféré dans Search Console. »

Aucun nouveau bouton ne l’a remplacé : il faut désormais maintenir une combinaison de signaux concordants. Google énumère “Use rel=“canonical” link tag on HTML pages” (traduction) « Utilisez une balise de lien rel=canonical dans les pages HTML », “Use rel=“canonical” HTTP header” (traduction) « utilisez un en-tête HTTP rel=canonical », “Use a sitemap” (traduction) « utilisez un sitemap » et “Use 301 redirects for retired URLs.” (traduction) « utilisez des redirections 301 pour les URL retirées ». En pratique :

1. Une redirection 301 depuis la version écartée vers la version choisie.
2. Des balises rel=canonical pointant vers cette version.
3. Un sitemap qui ne contient que cette version ; dès 2005, Google précisait que soumettre les deux “won’t affect the indexing of your site as long as you have submitted a Sitemap for only one version.” (traduction) « n’affectera pas l’indexation du site tant que vous n’avez soumis un sitemap que pour une seule version. »

Pourquoi « un indice, pas une règle » impose la cohérence

C’est ici que l’ancien réflexe du réglage unique devient dangereux. La documentation de Google indique explicitement que “indicating a canonical preference is a hint, not a rule.” (traduction) « indiquer une préférence canonique est un indice, pas une règle ». Google pondère plusieurs facteurs — HTTP ou HTTPS, redirections, présence dans le sitemap et annotations rel=canonical — et peut choisir l’autre version si les backlinks ou liens internes la favorisent.

Voilà pourquoi la cohérence entre tous les signaux compte davantage qu’un réglage isolé. Une canonique vers non-www alors que la moitié des liens internes et le sitemap utilisent www envoie un message contradictoire. Choisissez une version et alignez tout : c’est le même principe selon lequel la cohérence prime sur l’optimisation dans les travaux d’URL et de canonicalisation.

Pourquoi tant de sites choisissent-ils www ? Le DNS.

La plupart des articles éludent cette question, alors qu’elle fournit la vraie réponse : le DNS, et non le SEO ou l’image de marque.

Un enregistrement CNAME permet de pointer facilement un nom d’hôte vers un CDN ou un hébergeur : on configure un CNAME pour www.example.com vers le nom d’hôte du fournisseur, et ce CNAME continue de fonctionner malgré ses changements d’IP. Mais la spécification DNS interdit un CNAME à l’apex de la zone. L’apex doit porter les enregistrements SOA et NS, tandis qu’un CNAME doit être le seul enregistrement de son nœud ; ces règles sont incompatibles. Un CNAME nu sur example.com est donc invalide selon les RFC 1912 et 2181, et la plupart des fournisseurs le refusent.

Pour obtenir le même comportement « pointer vers mon CDN » sur le domaine nu, il faut utiliser :

• un enregistrement A/AAAA, qui exige une IP statique souvent absente chez les CDN et hébergeurs ; ou
• un ALIAS / ANAME propre au fournisseur, ou l’aplatissement CNAME de Cloudflare, qui simulent un CNAME à l’apex en le résolvant côté serveur. Tous les fournisseurs DNS ne les proposent pas.

Cette contrainte explique très probablement pourquoi tant de plateformes utilisent www par défaut : ce nom d’hôte accepte toujours un CNAME simple. C’est une décision d’hébergement et de DNS déguisée en décision SEO.

Les cookies suivent le nom d’hôte choisi

Le choix du nom d’hôte a une autre conséquence discrète : la portée des cookies. Sans attribut Domain, un cookie est limité à l’hôte et n’est renvoyé qu’à celui qui l’a créé. Un cookie défini sur www.example.com sans Domain n’est donc pas envoyé à example.com, ni l’inverse.

Pour partager un cookie entre l’apex et ses sous-domaines, définissez explicitement Domain sur l’apex, par exemple Domain=example.com. Selon la RFC 6265, la valeur de Domain doit correspondre à l’hôte courant ou à l’un de ses parents ; on peut donc définir Domain=example.com depuis www.example.com, partager le cookie avec example.com et ses sous-domaines, puis conserver cet attribut Domain pendant la migration.

Ce point est surtout important pendant une migration. Si les cookies de session ou de préférence sont limités au nom d’hôte abandonné, leur état ne suit pas automatiquement la redirection. Avant le basculement, vérifiez leur portée et, si la continuité de session est nécessaire, définissez Domain sur l’apex ou prévoyez une nouvelle authentification explicite.

L’argument obsolète du domaine sans cookies

On conseille encore parfois de servir les fichiers statiques depuis un domaine sans cookies — souvent le domaine nu ou un sous-domaine dédié — afin d’éviter d’envoyer les cookies avec chaque requête. Ce conseil provenait de l’époque HTTP/1.1, où chaque octet d’en-tête comptait et où les navigateurs limitaient fortement les connexions parallèles par hôte.

Cette pratique est aujourd’hui largement dépassée. La compression d’en-têtes HPACK de HTTP/2 et l’usage quasi universel des CDN pour les ressources statiques en annulent l’essentiel du bénéfice ; le coût d’une connexion DNS/TLS supplémentaire est souvent supérieur à l’économie. Ne fondez pas le choix www/non-www sur cet argument.

Le piège HSTS et certificat

Voici le problème pratique qui surprend lors d’un basculement. Même si un nom d’hôte ne fait que rediriger, le navigateur doit d’abord établir une connexion TLS avec lui. Le nom d’hôte source de la redirection doit donc posséder un certificat valide. Si vous redirigez https://www.example.com vers https://example.com, la négociation a d’abord lieu avec www.example.com : sans certificat valide pour www, la connexion échoue avant que le navigateur ne voie la 301.

HSTS renforce cette exigence. Une politique HSTS est propre à un hôte : celle de example.com ne protège pas automatiquement www.example.com, sauf si l’apex envoie includeSubDomains. Inversement, une politique définie sur www ne couvre pas l’apex. Pendant la migration, conservez les deux certificats et vérifiez la politique HSTS des deux hôtes avant de modifier les redirections.

Bing n’a pas d’équivalent à Preferred Domain

Bing n’a jamais proposé de bouton de domaine préféré. En pratique, Bing Webmaster Tools traite www, non-www et chaque combinaison HTTP/HTTPS comme des propriétés distinctes à vérifier. Les mêmes signaux de consolidation s’appliquent : redirection permanente, canoniques cohérentes, sitemap et liens internes. Ne cherchez pas un réglage Bing inexistant.

Comment choisir une version et l’imposer

1. Décidez selon les contraintes DNS et d’hébergement, pas selon le SEO. Si le CDN exige un CNAME et que le fournisseur DNS ne propose ni ALIAS ni aplatissement, www est la voie la plus simple. Si le DNS sait aplatir l’apex et que vous préférez le domaine nu, choisissez non-www ; la préférence de marque peut départager ce véritable ex æquo.
2. Redirigez l’autre version en 301, de façon permanente, et non en 302, qui signale un déplacement temporaire et ne produit pas la consolidation voulue.
3. Alignez les balises canoniques, le sitemap et les liens internes sur la version retenue.
4. Vérifiez si les cookies de connexion ou de préférence sont limités à l’hôte. Si les sessions doivent survivre, définissez Domain sur l’apex avant de modifier la redirection ; sinon, prévoyez des déconnexions.
5. Vérifiez que les deux noms d’hôte possèdent un certificat valide afin que la redirection n’entraîne aucune alerte.
6. Ajoutez ou vérifiez les propriétés dans Google Search Console — une propriété de domaine couvre toutes les variantes — et dans Bing Webmaster Tools, où les variantes se vérifient séparément.

Ensuite, n’y touchez plus. Comme pour tout changement d’URL, rouvrir le débat www/non-www sur un site qui fonctionne ne produit aucun gain de classement.

Résumé par l’IA

Une synthèse de la version Avancé :

• Définitions : www est un sous-domaine ; example.com est le domaine apex, nu ou racine. Les deux servent le même contenu : c’est un choix de canonicalisation, pas de classement.
• Aucune différence de classement : Google le dit depuis 2005. En mars 2024, Mueller a expliqué qu’une canonique changeant dans le même domaine “it just switches” (traduction) « change simplement », avec au plus une brève fluctuation. Son propos distinct sur les sous-domaines et sous-répertoires répond à une question d’organisation du contenu, pas à celle-ci. La cohérence ne garantit ni classement, ni trafic, ni citation par une IA ; elle donne une adresse claire.
• Le réglage Preferred Domain de GSC a disparu le 18 juin 2019, et les anciennes configurations ne sont plus utilisées. Il est remplacé par des signaux concordants : rel=canonical, un sitemap limité à la version choisie et une 301 depuis l’autre.
• Les signaux canoniques sont des indices, pas des règles : tous doivent donc s’accorder. www/non-www fait partie d’environ 40 signaux de canonicalisation.
• Le vrai motif du choix de www est le DNS : un CNAME ne peut pas se trouver à l’apex à cause des enregistrements SOA/NS (RFC 1912/2181). Le domaine nu exige A/AAAA, ALIAS, ANAME ou l’aplatissement CNAME ; www accepte toujours un CNAME simple.
• Les cookies sont liés au nom d’hôte : un cookie sans attribut Domain ne passe pas de www à non-www. Définissez Domain=example.com avant la migration si les sessions doivent survivre.
• L’argument du domaine sans cookies est obsolète depuis HTTP/2, HPACK et les CDN.
• Piège TLS/HSTS : l’hôte source de la redirection a toujours besoin d’un certificat valide. HSTS est propre à l’hôte ; includeSubDomains ne se propage que du parent vers le sous-domaine.
• Bing ne propose aucun réglage de domaine préféré et traite les variantes comme des propriétés distinctes.
• Recommandation : choisissez selon le DNS et l’hébergement, redirigez l’autre version en 301, alignez canoniques, sitemap et liens internes, certifiez les deux hôtes, puis n’y touchez plus.

Documentation officielle

Documentation de première main publiée par les moteurs de recherche.

Google

• Bye Bye Preferred Domain setting (2019) — suppression du 18 juin 2019 et liste exacte des signaux de remplacement.
• What is URL canonicalization — facteurs pondérés par Google, dont rel=canonical, et principe de l’« indice, pas une règle ».
• Consolidate duplicate URLs — déclaration de la version préférée.
• www vs non-www versions of a site (2005) — article fondateur, désormais signalé comme ancien par Google.
• SEO Starter Guide — cadre général sur les URL dupliquées et leur consolidation.

Bing / Microsoft

• Bing Webmaster Guidelines — position générale de Bing sur la canonicalisation, sans réglage de domaine préféré.
• Better than canonical: URL Normalization — approche de normalisation de Bing : 301 en priorité, rel=canonical en second.

Citations des sources

Déclarations officielles de Google. Chaque lien mène directement au passage cité.

Google, 2005 — formulation d’origine

• “Two URLs to a site—one that is prefaced with www and one that is not (for instance, https://www.example.com/ and https://example.com/)—often point to the same location on a server. But depending on the server configuration, they may point to different locations, so search engines can’t assume they are the same.” (traduction) « Deux URL d’un site, l’une précédée de www et l’autre non, pointent souvent vers le même emplacement sur un serveur. Selon sa configuration, elles peuvent toutefois pointer vers des emplacements différents ; les moteurs ne peuvent donc pas supposer qu’elles sont identiques. » — Vanessa Fox, Google. Accéder à la citation
• “Note that having both versions of the site’s URL listed in your account won’t affect the indexing of your site as long as you have submitted a Sitemap for only one version—the version you want to be indexed.” (traduction) « La présence des deux versions de l’URL dans votre compte n’affectera pas l’indexation tant que vous n’avez soumis un sitemap que pour la version à indexer. » — Vanessa Fox, Google. Accéder à la citation

Google, juin 2019 — suppression de Preferred Domain

• “As we progress with the migration to the new Search Console experience, we will be saying farewell to one of our settings: preferred domain.” (traduction) « À mesure que nous avançons dans la migration vers la nouvelle expérience Search Console, nous allons dire adieu à l’un de nos réglages : le domaine préféré. » — Daniel Waisberg, Google. Accéder à la citation
• “Note that with the deprecation we will no longer use any existing Search Console preferred domain configuration.” (traduction) « Avec cette suppression, nous n’utiliserons plus aucune configuration existante de domaine préféré dans Search Console. » — Daniel Waisberg, Google. Accéder à la citation
• “Use rel=“canonical” link tag on HTML pages” (traduction) « Utilisez une balise de lien rel=canonical dans les pages HTML » — première des quatre options de remplacement. Accéder à la citation

Google — la canonicalisation est un indice, pas une règle

• “There are a handful of factors that play a role in canonicalization” (traduction) « Plusieurs facteurs interviennent dans la canonicalisation » — la liste inclut HTTP ou HTTPS, les redirections, le sitemap et les annotations rel=canonical ; “indicating a canonical preference is a hint, not a rule.” (traduction) « indiquer une préférence canonique est un indice, pas une règle ». Accéder à la citation
• “The canonical page will be crawled most regularly; duplicates are crawled less frequently in order to reduce the crawling load on sites.” (traduction) « La page canonique sera explorée le plus régulièrement ; les doublons le seront moins souvent afin de réduire la charge d’exploration des sites. » Accéder à la citation

John Mueller, Google — mars 2024, sur le changement de canonique www ⇄ non-www

• “This won’t cause problems with search visibility / rankings / indexing: when the canonical URL switches, it just switches. You might see a little blip, but it goes to normal very quickly.” (traduction) « Cela ne posera pas de problème de visibilité, de classement ou d’indexation : lorsque l’URL canonique change, elle change simplement. Vous pourriez observer une légère fluctuation, mais tout revient très vite à la normale. » — John Mueller, sur Reddit.
• “The only time it would cause bigger changes is if you switch canonicals to a different domain, and the domains have something different set up… with a www/non-www switch it’s all within the same domain and you should be fine.” (traduction) « Le seul cas où cela provoquerait de plus grands changements serait un passage des canoniques vers un autre domaine configuré différemment… avec www/non-www, tout reste dans le même domaine et cela devrait bien se passer. » — John Mueller, sur Reddit. Ces deux réponses de Mueller sur Reddit sont rapportées par Barry Schwartz dans Search Engine Roundtable, le 19 mars 2024. Le fil Reddit original n’ayant pas été récupéré indépendamment, cet article reste ici la source de référence.

John Mueller, Google — traitement identique des sous-domaines (contexte, non spécifique à www)

• “In general, we see these the same… I would personally try to keep things together as much as possible… Use subdomains where things are really kind of slightly different.” (traduction) « En général, nous les considérons de la même manière… Personnellement, j’essaierais de regrouper les éléments autant que possible… Utilisez des sous-domaines lorsque les choses sont réellement un peu différentes. » — John Mueller, à propos des sous-domaines et sous-répertoires. Lire l’article Cette réponse concerne l’organisation de contenus différents entre sous-domaine et sous-répertoire, non l’effet de www/non-www sur le classement. Elle montre uniquement que www est structurellement un sous-domaine ; la preuve de l’absence de différence repose sur l’article de 2005 et la réponse de Mueller en 2024.

Quelle version choisir, et comment ?

Il n’existe pas de réponse SEO correcte en soi. Cet arbre vous guide selon les contraintes DNS et d’hébergement, puis indique les mesures à appliquer.

Checklist de consolidation www/non-www

Vérifications pour confirmer qu’une version est canonique et que l’autre redirige proprement :

• Une seule version est choisie comme canonique, selon le DNS et l’hébergement, pas selon un avantage SEO imaginaire.
• Le DNS résout correctement l’apex avec A/AAAA, ALIAS/ANAME ou aplatissement CNAME ; un CNAME nu est invalide.
• Une seule 301, et non une 302, relie l’hôte secondaire à l’hôte préféré, sans règles concurrentes.
• Les deux noms d’hôte présentent un certificat TLS valide, afin que la redirection n’entraîne jamais d’alerte.
• HSTS est cohérent sur les deux hôtes ; includeSubDomains ne se propage que du parent vers le sous-domaine.
• Les cookies définissent Domain=example.com avant la migration si les sessions ou préférences doivent survivre.
• Chaque page utilise une balise rel=canonical vers la version choisie.
• Le sitemap XML ne contient que les URL de cette version.
• Les liens internes utilisent systématiquement cette version.
• Aucun sous-domaine d’assets sans cookies n’est créé pour une raison héritée de HTTP/1.1.
• Une propriété de domaine est ajoutée dans Google Search Console.
• Les variantes sont vérifiées comme propriétés distinctes dans Bing Webmaster Tools.
• Aucun changement d’une configuration fonctionnelle n’est prévu « pour le SEO ».

www ou non-www — aide-mémoire

La décision en un coup d’œil

Réalité DNS de l’apex et de www

Repères rapides

• Preferred Domain supprimé le 18 juin 2019, anciennes configurations comprises.
• Environ 40 signaux de canonicalisation, dont www/non-www.
• Domaine statique sans cookies : pratique obsolète depuis HTTP/2.
• Les cookies limités à l’hôte ne passent pas de www à non-www sans Domain=example.com.
• HSTS includeSubDomains se propage uniquement du parent vers le sous-domaine.

Rediriger une version vers l’autre

Choisissez la version canonique, puis redirigez l’autre en 301. Voici la configuration des trois serveurs web courants ; inversez le sens selon votre choix.

Apache (.htaccess) — rediriger non-www vers www

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

Apache (.htaccess) — rediriger www vers non-www

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Nginx — rediriger non-www vers www (bloc serveur dédié, sans if à chaque requête)

server {
    listen 443 ssl;
    server_name example.com;
    # This host still needs a valid cert, or the 301 never fires:
    ssl_certificate     /etc/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://www.example.com$request_uri;
}

Nginx — rediriger www vers non-www

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/www.example.com.pem;
    ssl_certificate_key /etc/ssl/www.example.com.key;
    return 301 https://example.com$request_uri;
}

IIS (web.config) — rediriger non-www vers www

<rule name="Redirect to www" stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTP_HOST}" pattern="^example\.com$" />
  </conditions>
  <action type="Redirect" url="https://www.example.com/{R:1}"
          redirectType="Permanent" />
</rule>

Conservez la règle à un seul endroit. Une seconde règle dans un plugin, le CDN ou le CMS qui pointe dans le sens inverse est la cause classique d’une boucle www/non-www.

Vérifier la redirection et les deux certificats

macOS / Linux — confirmez une seule 301 et un certificat valide sur les deux hôtes :

# Follow the redirect chain — you want ONE 301 to the canonical host
curl -sIL https://example.com/ | grep -Ei 'HTTP/|^location:'

# Check the cert on the host you redirect FROM (must be valid, or the 301 never fires)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates

Windows (PowerShell)

# Inspect the redirect without auto-following it
Invoke-WebRequest -Uri "https://example.com/" -MaximumRedirection 0 `
  -ErrorAction SilentlyContinue | Select-Object StatusCode, Headers

Si l’en-tête Location pointe vers la version choisie avec une 301 et que les deux hôtes présentent un certificat valide, la configuration est terminée.

Ce qu’il ne faut pas faire

Servir les deux versions sans redirection. C’est le seul résultat réellement nuisible : chaque page est accessible sur www et non-www sans consolidation. Les moteurs voient alors des URL dupliquées et doivent choisir une canonique. Le problème vient de cette absence de consolidation, pas du choix www/non-www.

Utiliser une 302 au lieu d’une 301. Une 302 signifie « temporaire ». Pour une consolidation permanente et le transfert des signaux, utilisez une 301 ; réservez les 302 aux déplacements vraiment temporaires.

Laisser deux règles de redirection s’affronter. Une règle du CMS envoie non-www vers www tandis que le CDN renvoie www vers non-www : la boucle est infinie. Imposez le choix dans une seule couche.

Oublier le certificat sur l’hôte qui redirige. Si www redirige vers non-www mais que seul le domaine nu est certifié, les visiteurs de https://www. voient une alerte avant l’exécution de la 301. Couvrez les deux noms d’hôte.

Changer une configuration fonctionnelle et consolidée « pour le SEO ». Il n’existe aucun gain de classement, seulement un risque de redirection ratée ou de fluctuation temporaire. Si cela fonctionne, n’y touchez pas.

Chercher l’ancien réglage Preferred Domain de GSC. Il a disparu en juin 2019 et les anciennes configurations sont ignorées. Un tutoriel qui demande encore de l’activer fait perdre du temps : le vrai travail est la combinaison 301, canonique et sitemap.

Créer un sous-domaine d’assets sans cookies pour accélérer le site. Cette technique de l’époque HTTP/1.1 est obsolète depuis HTTP/2 ; le coût de la connexion supplémentaire dépasse généralement les octets de cookies économisés.

Mélanger les signaux. Une canonique vers non-www alors que le sitemap et les liens internes utilisent www constitue un indice contradictoire. Puisque la canonicalisation est un indice et non une règle, faites concorder chaque signal.

Échecs courants de canonicalisation des noms d’hôte

Les deux noms d’hôte renvoient 200

Symptôme : www.example.com/page et example.com/page se chargent indépendamment. Cause probable : le DNS dirige les deux hôtes vers le site, mais aucune redirection vers l’hôte préféré n’est appliquée. Correction : choisissez l’hôte établi, redirigez définitivement l’autre en un saut et alignez canoniques, liens internes et sitemaps.

Le nom d’hôte secondaire affiche une erreur de certificat

Symptôme : HTTPS échoue avant que le navigateur puisse suivre la redirection. Cause probable : le certificat ne couvre que l’hôte préféré. Correction : conservez un DNS et un certificat TLS valides sur l’hôte qui redirige ; la connexion HTTPS doit réussir avant qu’une redirection HTTP puisse être reçue.

Les requêtes bouclent ou forment une chaîne

Symptôme : les requêtes rebondissent entre les hôtes ou traversent séparément HTTP, HTTPS, le changement d’hôte et le slash. Cause probable : les règles du CDN, de l’origine et de l’application ne visent pas la même destination. Correction : définissez une seule politique d’URL finale et faites pointer chaque variante directement vers elle dans la première couche contrôlée.

Examiner un plan de migration de nom d’hôte

Collez les enregistrements DNS, les noms couverts par les certificats, les règles de redirection, des exemples de canoniques, les hôtes du sitemap, la configuration analytique et une table représentative d’URL :

Audit this www/non-www migration plan. Identify contradictions between DNS, TLS,
redirects, canonicals, internal links, sitemaps, and measurement. For every issue,
state the observed evidence, the likely user or crawler impact, the exact check to
run, and whether it blocks launch. Do not claim one hostname has an SEO ranking
advantage. Return a pre-launch table and a post-launch verification sequence.

Outils pour choisir et imposer un nom d’hôte

• Analyseur de chaînes de redirection — suivre ensemble HTTP/HTTPS, www/non-www, slash et chemin jusqu’à une seule URL en un saut.
• Vérificateur de canonicalisation — repérer les pages dont l’hôte canonique contredit la réponse ou la destination finale.
• Vérificateur de redirection — contrôler les mêmes chemins sur les deux hôtes après modification.
• Outils DNS et TLS — confirmer que les deux hôtes se résolvent et présentent des certificats valides.
• Crawler de site complet — trouver les liens internes, canoniques, hreflang et URL de sitemap qui utilisent encore l’autre hôte.

Vérifier les URL équivalentes sur les deux hôtes

Test : soumettez les mêmes chemins www et non-www à l’analyseur de chaînes de redirection. Résultat attendu : l’hôte préféré répond correctement et l’autre redirige définitivement en un saut vers le même chemin. Interprétation d’un échec : règle absente, sens inversé ou perte des chemins et paramètres. Fenêtre de surveillance : immédiatement après déploiement. Motif de rollback : boucle, redirection générale vers l’accueil ou erreurs sur l’hôte préféré.

Vérifier TLS et les signaux émis

Test : connectez-vous aux deux hôtes HTTPS, puis crawlez canoniques, liens internes et URL du sitemap. Résultat attendu : les deux certificats sont valides et tous les signaux SEO utilisent l’hôte préféré. Interprétation d’un échec : l’hôte secondaire ne peut pas livrer sa redirection ou une configuration utilise encore l’ancien hôte. Fenêtre de surveillance : immédiate pour TLS, puis après un crawl complet pour les signaux du site. Motif de rollback : erreurs de certificat ou grand nombre de canoniques contradictoires.

Testez vos connaissances : WWW ou non-WWW

Cinq questions rapides sur la nature de ce choix et la manière de l’imposer. Sélectionnez chaque réponse, puis vérifiez.

Ressources utiles

Mes articles connexes

• Google utilise environ 40 signaux de canonicalisation — vue d’ensemble des signaux auxquels appartient www/non-www.
• Guide simple et complet des redirections pour le SEO — passage d’une version à l’autre avec des 301.
• Slash final : faut-il l’utiliser ? — même logique : choisir une version et l’imposer.
• Guide du débutant en SEO technique — place de la canonicalisation et de la consolidation des hôtes.

Mes conférences

• How Search Works (SlideShare) — parcours de l’exploration, du rendu, de l’indexation et du classement. Mon avertissement habituel s’applique : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « C’est ma compréhension des systèmes… elle ne sera pas complète ni exacte à 100 %. »

Ailleurs dans le secteur

• Adieu au réglage Preferred Domain — Google décrit précisément sa suppression survenue en juin 2019 ainsi que les signaux désormais nécessaires.
• Comprendre la canonicalisation des URL — documentation détaillée : une préférence reste simplement indicative, jamais obligatoire.
• Passer de WWW à non-WWW ne modifie pas le classement — réponse explicite donnée par Mueller au mois de mars 2024.
• WWW ou non-WWW : quel choix pour le SEO ? — présentation claire montrant pourquoi aucune variante ne l’emporte et comment appliquer correctement la 301.
• Pourquoi la racine d’un domaine ne peut-elle pas être un CNAME ? — explication pédagogique concernant cette contrainte particulière à l’apex.
• Aplatissement CNAME — fonctionnement technique du mécanisme proposé chez Cloudflare.
• Redirections HSTS entre WWW, non-WWW, HTTP et HTTPS — analyse pratique du piège associant certificats et politique HSTS.

Journal des modifications