UrlEdge
Retour au blog
17 mai 2026 UrlEdge Editorial5 min read

www, domaine racine et wildcard forwarding sans casser le SEO

La normalisation d’hôte semble simple jusqu’à ce que domaine racine, www, sous-domaines, chemins et query strings suivent des règles différentes. Une policy claire garde l’URL canonique stable.

Carte de normalisation montrant domaine racine, www et sous-domaines wildcard vers un hôte canonique

La normalisation d’hôte ressemble à une petite tâche DNS. En migration réelle, elle devient vite une policy d’URL.

Une équipe préfère le domaine racine. Une ancienne stack utilise www. Un lancement produit passe par un sous-domaine. Une agence ajoute du wildcard forwarding dans son plan de migration. Des campagnes doivent encore conserver leurs UTMs. Si tout cela est décidé au dernier moment, vous obtenez rarement une redirection propre.

La question n’est pas de savoir si www ou le domaine racine est toujours meilleur. La question est : quel hôte est canonique, et comment toutes les variantes le rejoignent sans chaîne inutile ?

Si le changement fait partie d’une migration plus large, commencez par la checklist de redirections pour migration de site. Ici, on se concentre sur la couche hôte.

L’hôte fait partie de la policy URL

example.fr, www.example.fr et *.example.fr ne sont pas équivalents opérationnellement.

  • Le domaine racine peut être plus lisible en marketing.
  • www reste courant dans des stacks plus anciennes.
  • Un sous-domaine peut être un produit, une aide ou une app distincte.
  • Le wildcard forwarding est utile quand beaucoup d’hôtes doivent suivre la même règle.

Ce qui compte, c’est d’éviter les décisions implicites.

Host normalization map for apex, www, and wildcard subdomains

Choisir l’hôte canonique avant le lancement

Décidez tôt :

QuestionPourquoi cela compte
Le site public vit-il sur domaine racine ou www ?Définit l’URL canonique visible
Quels sous-domaines sont des alias ?Certains sous-domaines ne doivent pas être fusionnés
Les chemins doivent-ils survivre ?SEO, favoris, docs et liens profonds en dépendent
Les query strings doivent-elles survivre ?Les UTMs et IDs partenaires peuvent disparaître
Existe-t-il des exceptions temporaires ?Campagnes et lancements peuvent avoir une intention différente

Sans ces réponses, plusieurs couches vont essayer d’aider en même temps.

Le DNS ne décide pas tout

DNS indique où envoyer le trafic. Il ne crée pas à lui seul la redirection HTTP qui change l’URL visible.

Modèle propre :

http://www.ancienne-marque.fr/tarifs?utm_source=newsletter
  -> https://nouvelle-marque.fr/tarifs?utm_source=newsletter

Modèle fragile :

http://www.ancienne-marque.fr/tarifs
  -> https://www.ancienne-marque.fr/tarifs
  -> https://ancienne-marque.fr/tarifs
  -> https://nouvelle-marque.fr/tarifs

Un seul hop est plus simple à tester, expliquer et maintenir.

Le wildcard forwarding est utile si la structure reste alignée

Une règle wildcard marche bien quand l’ancien et le nouveau site gardent des chemins compatibles :

ancien.example.fr/* -> nouveau.example.fr/$1

C’est utile si :

  • beaucoup d’anciennes URLs doivent rester valables
  • les chemins ne changent pas beaucoup
  • vous voulez éviter une règle par page
  • certains sous-domaines sont de vrais alias

Si l’architecture change fortement, les URLs les plus importantes méritent des mappings explicites.

Conserver chemin et query quand le lien compte

La normalisation d’hôte ne doit pas effacer le reste de la requête.

http://docs.ancienne-marque.fr/api?ref=partner&utm_source=email

doit, si la structure le permet, arriver sur :

https://nouvelle-marque.fr/api?ref=partner&utm_source=email

C’est crucial pour :

  • pages SEO
  • documentation
  • campagnes paid
  • liens affiliate
  • favoris utilisateurs

Un redirect peut sembler correct tout en perdant sa valeur si le chemin ou les paramètres disparaissent.

Éviter la chaîne

Le piège classique :

  • HTTP vers HTTPS à un endroit
  • www vers racine ailleurs
  • migration de domaine dans une règle CDN
  • app ou CMS ajoute une règle canonique

Résultat : http -> https -> www -> final.

Si votre stack ressemble à cela, lisez ensuite Chaînes et boucles de redirection.

Construire une matrice de lancement

Avant publication, testez les variantes réelles :

TestExemple
Racine apexhttps://example.fr/
Racine wwwhttps://www.example.fr/
URL profondehttps://example.fr/tarifs
URL profonde avec queryhttps://example.fr/tarifs?utm_source=email
Ancien hôte avec cheminhttps://ancien.example.fr/blog/post-1
Sous-domaine wildcardhttps://docs.example.fr/guide

Launch QA matrix for canonical host, path preservation, query preservation, and redirect hops

Vérifiez :

  • hôte final prévu
  • conservation du chemin
  • conservation de la query string
  • code de statut cohérent
  • absence de hop inutile

Où UrlEdge intervient

UrlEdge est utile quand la normalisation d’hôte doit devenir une policy de routing, pas un fragment .htaccess ou une règle perdue.

La valeur est simple : un endroit possède l’hôte canonique, les variantes, les chemins, les paramètres et le code de statut.

FAQ

Faut-il toujours préférer le domaine racine à www ?

Non. Les deux peuvent fonctionner. L’important est de choisir un hôte canonique et de faire suivre les autres variantes proprement.

Peut-on gérer les sous-domaines wildcard avec une seule règle ?

Oui, si la structure reste alignée. Si elle diverge, mappez explicitement les URLs importantes.

Le DNS suffit-il ?

Non. DNS ne remplace pas une policy HTTP de redirection visible par l’utilisateur.

Faut-il conserver les paramètres de campagne ?

Oui dans la plupart des cas, sauf raison explicite de les supprimer. L’attribution est difficile à reconstruire après coup.

Références

Fixez l’hôte canonique une fois pour toutes

Redirigez domaine racine, www et sous-domaines wildcard avec HTTPS automatique, conservation du chemin et destination canonique.

Essayer le service gratuit

Articles associés

Tout afficher