Domaines www et Apex : pourquoi les unifier ? (L'importance des redirections 301/308)

Avez-vous remarqué comment les navigateurs modernes comme Chrome, Edge ou Safari se comportent ? Si vous tapez www.naver.com ou www.google.com dans la barre d'adresse, le www disparaît souvent, ne laissant que le nom de domaine principal (Apex Domain). Il arrive même que les sous-domaines mobiles m. soient masqués.

Cette pratique est due à la politique de masquage des « sous-domaines triviaux » adoptée par les navigateurs modernes pour offrir une barre d'adresse plus épurée. Si cela peut être agréable pour l'utilisateur de voir une adresse plus courte, un développeur web doit aller plus loin : il est crucial de comprendre qu'il y a une différence majeure entre ce que « le navigateur masque » et ce qui « fonctionne réellement comme des domaines distincts ».

Diagramme de flux comparant avant et après l'application de la redirection

DNS et les robots d'exploration voient clairement le 'www'

Pour le processus DNS et les robots des moteurs de recherche (comme Googlebot), www.example.com et example.com sont des destinations distinctes. Si ces deux adresses renvoient une réponse 200 OK et affichent le même contenu, cela signifie techniquement que deux sites avec du 'contenu dupliqué' sont en fonctionnement.

Voyons comment les grandes entreprises technologiques gèrent ce problème en utilisant la commande curl.

1. Le cas de Yahoo Japan

$ curl -I https://yahoo.co.jp/
HTTP/2 301 
location: https://www.yahoo.co.jp:443/
...

Yahoo Japan redirige l'accès au domaine Apex vers l'adresse avec www via une redirection 301 Moved Permanently.

2. Le cas de Google

$ curl -I https://google.com/
HTTP/2 301 
location: https://www.google.com/
...

$ curl -I https://www.google.com/
HTTP/2 200 
...

Google fait de même. Accéder à google.com redirige vers www.google.com, et seule l'adresse avec www renvoie finalement une réponse 200 OK.

Pourquoi est-il impératif de rediriger vers une seule version ?

Il ne s'agit pas seulement d'une question d'esthétique. Il y a des raisons claires liées au SEO (optimisation pour les moteurs de recherche) et à l'efficacité opérationnelle.

1. Les limites de la balise Canonical

Beaucoup de développeurs pensent que la configuration de la balise <link rel="canonical" href="..."> est suffisante. Cependant, cette balise n'est qu'une « indication » pour les moteurs de recherche. Le fait que les robots doivent explorer les deux URL ne change pas, ce qui entraîne un gaspillage du budget d'exploration (Crawl Budget). En d'autres termes, les robots explorent des « copies » d'articles existants au lieu de découvrir de nouveaux contenus sur votre site.

2. La dispersion du Link Juice

Lorsque d'autres sites web créent des liens vers votre contenu, certains utiliseront le www et d'autres non. Sans une redirection appropriée, l'autorité (Authority) que votre page devrait accumuler sera dispersée entre les deux domaines, ce qui vous désavantagera dans la compétition pour le classement de recherche.

La solution : la redirection forcée au niveau du serveur web

Ce traitement est le plus efficace lorsqu'il est géré au niveau du serveur web (infrastructure), comme Nginx ou Apache, plutôt qu'au niveau du code de l'application (Django, Node.js, etc.). Rediriger la requête directement depuis le serveur, avant qu'elle n'atteigne l'application, permet de réduire la consommation de ressources et d'améliorer la vitesse.

Voici un exemple de configuration Nginx pour unifier toutes les requêtes vers le domaine Apex (https://example.com) lorsque vous utilisez example.com. (Si vous souhaitez l'unifier vers www, il suffit de changer l'adresse cible.)

# 1. www (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name www.example.com;
    return 308 https://example.com$request_uri;
}

# 2. www (HTTPS) -> Apex (HTTPS)
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 308 https://example.com$request_uri;
}

# 3. Apex (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 308 https://example.com$request_uri;
}

# 4. 실제 서비스 로직 (Apex HTTPS 200 OK)
server {
    listen 443 ssl http2;
    server_name example.com;
    # ... 서비스 설정 및 Proxy Pass 등
}

Astuce : La raison pour laquelle le code de statut 308 est utilisé au lieu de 301 est que la 308 Permanent Redirect maintient la méthode HTTP (POST, PUT, etc.) intacte lors de la redirection, ce qui la rend plus sûre dans l'environnement web moderne.

En conclusion

Ce n'est pas parce que les navigateurs masquent l'adresse que le serveur doit rester passif. Si vos domaines www et Apex coexistent et renvoient tous deux un 200 OK, vérifiez immédiatement la configuration de votre serveur web. Une redirection claire vers une seule version est une tâche fondamentale et cruciale pour informer les moteurs de recherche de l'identité précise de votre site.