Le site s'ouvre avec www et sans, mais les moteurs de recherche voient deux adresses différentes avec un contenu identique. Doublons de pages, dilution du link equity, confusion dans la Search Console. Cela vous dit quelque chose?

Ni Grav ni WordPress ne résolvent ce problème par défaut. Le fichier .htaccess et exactement un bloc de code règlent tout en cinq minutes. Voici des lignes testées pour serveurs Apache: universelles, sans domaine codé en dur, avec HTTPS et sans. Plus une méthode pour vérifier que la redirection fonctionne au-delà du simple navigateur.

💡 Aperçu rapide:

• Choisissez une version canonique (avec www ou sans) et ajoutez une redirection 301 universelle dans le .htaccess
• Vérifiez la chaîne de redirection via curl -I ou un vérificateur en ligne: les navigateurs mettent en cache les 301 et peuvent mentir
• Un seul bloc de code résout simultanément le problème du www et force le HTTPS

Pourquoi choisir entre www et non-www

Google n'exprime aucune préférence pour l'une ou l'autre variante; la position officielle est inchangée depuis des années. Mais vous devez en choisir une et vous y tenir. Sans redirection, www.site.ru/page et site.ru/page sont indexés comme des URL distinctes, le link equity se divise en deux et l'analytique comptabilise le même trafic deux fois.

Que choisir? Pour les projets d'envergure, le www est plus pratique: les cookies ne fuient pas vers les sous-domaines comme cdn. et api., et les enregistrements DNS sont plus faciles à configurer. Pour les sites plus modestes, il n'y a presque aucune différence. Concentrez-vous sur ce qui est déjà indexé: saisissez site:yourdomain.ru dans un moteur de recherche et voyez quelle variante apparaît le plus souvent dans les résultats. Faites-en votre version canonique.

Note technique: Grav ne génère pas de redirections par lui-même. WordPress le fait uniquement si le paramètre siteurl dans les réglages correspond explicitement à la variante souhaitée, mais même cela fonctionne de manière inconstante. La solution est unique: mod_rewrite dans Apache via .htaccess.

Où se trouve le.htaccess et comment ne pas le casser

Le fichier .htaccess se situe à la racine du site, aux côtés de index.php ou du dossier wp-admin. Si le fichier n'existe pas (Grav sans template prêt à l'emploi, hébergement vierge), créez un fichier texte nommé .htaccess avec le point initial obligatoire.

Avant toute modification, téléchargez la version actuelle sur votre ordinateur. Une erreur de syntaxe dans .htaccess plante le site avec une erreur 500 instantanément. Règle d'or: une copie de sauvegarde en local, une autre avec un nom différent directement sur le serveur (.htaccess.backup). Vous pourrez restaurer même sans accès au panneau d'administration, via FTP ou le gestionnaire de fichiers de l'hébergement.

Pour Grav et WordPress, la règle est la même: si le fichier contient déjà RewriteEngine On, ne dupliquez pas cette ligne. Ajoutez le nouveau bloc de redirection après celle-ci. Dans le .htaccess standard de Grav, cette ligne est présente par défaut.

Redirection 301 de www vers non-www: code universel

Le code ci-dessous fonctionne pour n'importe quel domaine; vous n'avez pas besoin de remplacer example.com manuellement. Pratique si vous gérez plusieurs sites ou transférez des règles entre projets. À ajouter dans .htaccess après RewriteEngine On:

1
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
2
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Ligne par ligne: RewriteCond intercepte tout hôte commençant par www. et capture le domaine entre parenthèses. RewriteRule redirige la requête vers le même chemin sans le www, en substituant le domaine capturé via %1. Le drapeau R=301 signifie redirection permanente. L indique au serveur «stop, n'applique pas d'autres règles». NC rend la vérification insensible à la casse.

Si le site fonctionne en HTTPS, remplacez http:// par https:// dans RewriteRule. Mieux encore, utilisez un bloc combiné qui résout à la fois le www et le HTTPS en un seul passage:

1
RewriteCond %{HTTPS} off [OR]
2
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
3
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

La première condition se déclenche sur les requêtes HTTP, la seconde sur le www. Si l'une ou l'autre est vraie ([OR]), la requête est dirigée vers https://domain-without-www/path. Un seul bloc, deux problèmes résolus.

Scénario inverse: de non-www vers www

Si vous avez besoin que la barre d'adresse affiche toujours www, utilisez la variante miroir:

1
RewriteCond %{HTTP_HOST} !^www\. [NC]
2
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

La logique est la même, seule la condition est inversée: si l'hôte ne commence pas par www, on ajoute www. au début. %{HTTP_HOST} substitue l'hôte actuel en entier, contrairement au bloc précédent où l'on supprimait le www. via une capture par parenthèses.

Version avec HTTPS:

1
RewriteCond %{HTTPS} off [OR]
2
RewriteCond %{HTTP_HOST} !^www\. [NC]
3
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]

Utilisez un seul des quatre blocs, celui qui correspond à votre variante de domaine canonique et à la présence du HTTPS. Deux blocs à la suite sont inutiles et créeront un saut supplémentaire dans la chaîne de redirection.

Comment vérifier que la redirection fonctionne

Ne vous fiez pas au navigateur; il met en cache les redirections 301 et affiche l'ancienne situation même après modification du .htaccess. Trois méthodes pour connaître la vérité:

• curl** -I.** Dans le terminal: curl -I http://www.example.com. Une réponse correcte commence par HTTP/1.1 301 Moved Permanently, et l'en-tête Location: contient l'URL cible. Vérifiez les deux variantes, avec www et sans.
• Vérificateurs en ligne. Redirect Checker ou HTTP Status Code Checker: collez l'URL, visualisez la chaîne de redirection complète et le code de réponse final.
• Google Search Console. Après avoir changé le domaine canonique, allez dans les paramètres de la propriété et indiquez la version préférée. Cela ne remplace pas le .htaccess mais donne un signal supplémentaire au moteur de recherche.

Un conseil spécifique pour Grav: après avoir modifié le .htaccess, videz le cache du CMS via Admin → Configuration → Performance → Clear Cache. Grav met les pages en cache de manière agressive et, sans vidage, la redirection peut ne pas s'appliquer aux copies déjà générées.

⁉️🤔 Questions fréquentes

Quelle variante est la meilleure pour le SEO, avec www ou sans?

Google déclare officiellement: il n'y a aucune différence. Choisissez l'une ou l'autre et tenez-vous-y. Le facteur clé est la cohérence: les liens internes, le sitemap et les balises canoniques doivent pointer vers une seule variante. Selon une enquête Ahrefs, environ 55% des 100 premiers sites utilisent la version sans www, mais les deux variantes se classent aussi bien.

Que se passe-t-il si vous ne configurez aucune redirection?

Les moteurs de recherche verront deux sites en doublon indépendants. Le link equity se divisera, les pages commenceront à se concurrencer dans les résultats et les rapports d'analytique répartiront le même trafic sur deux hôtes. Après quelques mois, le tableau typique: la moitié des pages indexées avec www, l'autre moitié sans, des classements instables.

Peut-on se passer du.htaccess?

Oui, mais les alternatives sont soit plus complexes, soit plus lentes. Les extensions WordPress comme Redirection et Rank Math fonctionnent au niveau PHP; chaque requête passe par le cœur de WordPress, ce qui génère de la charge. Pour les sites à fort trafic, le .htaccess au niveau Apache est sensiblement plus rapide. Pour Grav, les extensions de redirection sont pratiquement inexistantes, le .htaccess reste donc la voie principale. Sur les serveurs NGINX, l'équivalent est constitué des directives return 301 dans le bloc server {}.

Faut-il configurer une redirection pour chaque page séparément?

Non, les règles fournies sont universelles; elles s'appliquent automatiquement à toutes les URL du site. Un seul bloc couvre la page d'accueil, les pages internes, les images et les fichiers CSS. Les redirections distinctes d'anciennes URL vers de nouvelles se configurent en supplément avec des lignes Redirect 301 /old-page /new-page, mais elles n'ont rien à voir avec le problème du www.

Erreur 500 après modification du.htaccess, que faire?

Recopiez .htaccess.backup via FTP ou le gestionnaire de fichiers de l'hébergement; le site reviendra instantanément. Vérifiez le code à la recherche de coquilles: un espace manquant, un slash en trop, des parenthèses non appariées. Ajoutez les règles une par une et testez après chaque modification. Et ne modifiez jamais le .htaccess en production sans une sauvegarde à jour à portée de main.

La redirection fonctionne, mais Google continue d'afficher l'ancienne version dans les résultats. Pourquoi?

La réindexation prend de quelques jours à deux semaines. Assurez-vous que les balises canoniques sur les pages pointent vers la variante choisie et que le sitemap contient les URL sans l'ancien hôte. Dans la Search Console, vous pouvez demander une nouvelle exploration via l'outil d'inspection d'URL; cela accélère le processus mais ne garantit pas des résultats instantanés.

Quelle variante choisir: le verdict en bref

Si le site est nouveau, optez pour le non-www et le HTTPS. Moins de caractères dans la barre d'adresse, plus facile à dicter à l'oral, aucun problème de cookies avec les sous-domaines. Pour la plupart des projets, c'est amplement suffisant.

Déjà indexé avec www? Ne cassez pas ce qui fonctionne. Configurez une redirection de non-www vers www, mettez à jour les balises canoniques et poursuivez votre route.

Le processus complet: ouvrez .htaccess, ajoutez l'un des quatre blocs ci-dessus, videz le cache du CMS, vérifiez via curl -I. Cinq minutes, et les doublons disparaissent du paysage de recherche. D'autres techniques .htaccess sont rassemblées dans le guide de configuration serveur; consultez-le si vous configurez un site de manière exhaustive.