Faut-il vraiment choisir entre www et non-www pour son domaine ?

Pourquoi Google impose-t-il ce choix entre www et non-www ?

Pour les moteurs de recherche, exemple.com et www.exemple.com constituent deux entités distinctes. Chacune possède son propre profil de backlinks, son historique de crawl et ses signaux de ranking. Sans directive explicite, Google peut indexer les deux versions simultanément, créant du contenu dupliqué qui dilue vos performances.

La redirection 301 sert de signal sans ambiguïté : elle indique quelle version doit hériter de toutes les propriétés SEO accumulées. Google transfère alors le PageRank, les backlinks, l'ancienneté du domaine et les signaux utilisateurs vers l'URL canonique. Ce transfert n'est jamais instantané mais s'opère progressivement lors des phases de recrawl.

Quelle différence entre redirection 301 et balise canonical ?

La redirection 301 est côté serveur : elle renvoie un code HTTP permanent qui force le navigateur et les bots vers l'URL cible. C'est la méthode la plus robuste pour consolider les signaux. La balise canonical, elle, reste une simple suggestion que Google peut ignorer si d'autres signaux contradictoires existent.

Dans le cas www/non-www, la canonical seule ne suffit pas. Les utilisateurs qui saisissent manuellement l'URL non redirigée verraient du contenu en double. Les backlinks pointant vers la mauvaise version resteraient dilués. La 301 résout les deux problèmes d'un coup : elle unifie le flux utilisateur et concentre l'équité SEO.

Cette règle s'applique-t-elle différemment selon les CMS ?

WordPress, Shopify ou Prestashop gèrent cette redirection différemment. WordPress impose souvent le choix dès l'installation via les réglages généraux, mais beaucoup d'hébergeurs configurent un redirect automatique au niveau Apache ou Nginx sans que l'utilisateur en soit conscient. Shopify force systématiquement la version www ou non-www selon la configuration DNS initiale.

Le problème surgit lors de migrations ou de changements d'hébergeur. Un site migré peut perdre ses règles de redirection si le fichier .htaccess ou la configuration Nginx n'est pas transféré correctement. Résultat : les deux versions redeviennent accessibles et Google réindexe du duplicate content. Vérifier cette règle après chaque changement d'infrastructure est crucial.

• Choisir une version canonique (www ou non-www) et s'y tenir définitivement
• Implémenter une redirection 301 permanente au niveau serveur pour toutes les URLs de la version non choisie
• Vérifier la cohérence dans Google Search Console en déclarant le domaine préféré
• Auditer les backlinks entrants pour identifier ceux pointant vers la version non canonique
• Tester la redirection sur toutes les pages, pas seulement la homepage, car certaines règles .htaccess mal écrites ne redirigent que la racine

Cette consigne de Google est-elle encore pertinente avec HTTPS généralisé ?

Absolument. L'arrivée du HTTPS a même compliqué le problème en multipliant les variantes possibles : http://exemple.com, http://www.exemple.com, https://exemple.com, https://www.exemple.com. Quatre URLs distinctes pour un même contenu. Beaucoup de sites ne redirigent correctement que trois de ces versions, laissant une faille par laquelle Google peut indexer du duplicate.

J'ai vu des sites perdre 15-20% de leur trafic organique après une migration HTTPS simplement parce que les redirections www/non-www n'ont pas été répliquées pour les deux protocoles. Google indexait simultanément la version HTTP non-www (anciens backlinks) et HTTPS www (nouvelle version), diluant les signaux. [A vérifier] : la vitesse de transfert des signaux varie énormément selon l'autorité du domaine, de 2 semaines à 6 mois.

Quelle version choisir : www ou non-www ?

Google affirme que le choix est indifférent, mais la pratique nuance ce discours. Les domaines non-www sont légèrement plus courts (meilleur pour le branding, moins de caractères dans les URLs) et constituent la tendance moderne. Les grandes marques tech (Apple, Tesla, Stripe) privilégient cette forme.

Les domaines www présentent un avantage technique historique : ils permettent une gestion DNS plus flexible (cookies séparés pour les sous-domaines, CDN configuré sur un CNAME www). Pour les sites d'envergure internationale avec infrastructure complexe, cette flexibilité reste précieuse. Mais pour 90% des sites, cet argument ne tient plus. Choisis selon ta cohérence de marque, pas selon un supposé avantage SEO.

Que se passe-t-il si on change de version canonique après des années ?

Techniquement faisable, mais risqué. Changer de www à non-www (ou inverse) après 5 ans d'historique équivaut à une migration de domaine partielle. Google doit recrawler toutes les URLs, transférer les signaux, mettre à jour son index. Pendant cette période de transition, des fluctuations de ranking sont inévitables.

J'ai accompagné un client qui a switché de non-www à www après 8 ans d'existence. Malgré des redirections 301 parfaites, le transfert complet des signaux a pris 4 mois, avec une perte temporaire de 12% du trafic organique. Google a maintenu les deux versions dans l'index pendant 6 semaines avant de consolider. Sauf impératif technique majeur, garde ta version actuelle si ton site a déjà de l'ancienneté.

Comment implémenter correctement la redirection 301 ?

Sur Apache (.htaccess), la règle doit capturer toutes les variantes HTTP/HTTPS et rediriger vers la version canonique. Une erreur fréquente : écrire une règle qui ne redirige que la homepage, laissant les pages profondes accessibles dans les deux versions. Utilise des expressions régulières qui capturent l'intégralité du path.

Sur Nginx, la logique est similaire mais la syntaxe diffère. Beaucoup d'hébergeurs mutualisés ne donnent pas accès au fichier de configuration Nginx, obligeant à passer par leur interface propriétaire (cPanel, Plesk). Vérifie que l'interface propose bien une option "redirection permanente" et non "alias" ou "pointage DNS", qui ne génèrent pas de 301.

Quelles erreurs éviter lors de la configuration ?

La boucle de redirection : si ta règle redirige www vers non-www, mais qu'une autre règle (plugin WordPress, CDN) fait l'inverse, le serveur renvoie une erreur 500 ou trop de redirections. Teste toujours avec curl -I pour voir la chaîne de redirections complète. Une seule 301 doit apparaître, pas deux ou trois en cascade.

Autre piège : les redirections 302 temporaires au lieu de 301 permanentes. Certains hébergeurs ou CMS mal configurés utilisent des 302 par défaut. Google ne transfère pas les signaux sur une 302, considérant que le changement est temporaire. Résultat : après des mois, les deux versions restent indexées et tes backlinks ne se consolident jamais.

Comment vérifier que tout fonctionne correctement ?

Dans Google Search Console, déclare ton domaine préféré (propriété de type domaine ou préfixe d'URL selon ton choix). Surveille l'onglet Couverture pour détecter des URLs indexées dans la version non canonique. Si des pages non-www apparaissent alors que tu as choisi www, ta redirection n'est pas appliquée partout.

Lance un crawl Screaming Frog en mode "liste" avec les deux versions de 50-100 URLs internes. Si SF renvoie des codes 200 pour les deux versions, ta redirection échoue. Teste aussi manuellement les URLs avec paramètres (UTM, session ID) : certaines règles .htaccess oublient de préserver les query strings, cassant le tracking analytics.

• Auditer les 4 variantes (http/https + www/non-www) avec curl -I pour vérifier les codes de statut
• Tester des URLs profondes, pas seulement la homepage, pour s'assurer que la règle s'applique globalement
• Vérifier la préservation des query strings dans la redirection (utm_source, paramètres de session)
• Configurer Google Search Console avec la version canonique choisie et surveiller les erreurs d'indexation
• Mettre à jour les backlinks majeurs en contactant les sites référents pour qu'ils pointent directement vers la version canonique
• Documenter le choix dans un wiki interne pour éviter qu'un futur prestataire ne casse la configuration lors d'une migration