Réconcilier SEO et WebPerf au niveau des redirections de (sous)domaines

Le SEO et la performance Web sont deux disciplines très différentes liées à la mise en ligne de sites Web, avec des objectifs qui parfois peuvent être contradictoires. Mais des fois, ce qui paraît contradictoire ne l’est en fait pas si on y regarde de plus près, avec un peu de pragmatisme.

SEO : un seul (sous-)domaine tu présenteras

Vous le savez sans doute si vous connaissez un peu le sujet du SEO — c’est certain si vous appliquez la bonne pratique nº78 de la liste Opquast SEO — il est conseillé de toujours servir un contenu donné depuis un même (sous-)domaine afin d’éviter ce que l’on appelle le duplicate content. Le duplicate content est mal vu par les moteurs de recherche comme Google qui peuvent prendre cela pour du SPAM, et vous pénaliser dans les résultats de recherche.

Il est donc généralement conseillé de faire une redirection permanente — code HTTP 301 — en cas de requête vers un autre (sous-)domaine.

Par exemple, je préfère que mes pages soient accédées à l’URL http://gasteroprod.com/ plutôt que http://www.gasteroprod.com/, le www. n’ayant franchement aucun intérêt. On va dire que j’adhère au mouvement no-www.

J’avais donc mis dans ma configuration Apache les directives suivantes :

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

WebPerf : les redirections tu éviteras

Malheureusement, chaque redirection provoque une attente supplémentaire pour le visiteur, qui peut être néfaste pour sa perception de qualité de service du site.

Il est donc recommandé par tous les experts WebPerf — Yahoo! YSlow et Google PageSpeed notamment1 — de provoquer un minimum de redirections, particulièrement lors de l’accès à une page.

On est d’accord, cela peut ne représenter que 150 ms par redirection, mais j’ai vu des sites enchaînant plusieurs redirections avant de fournir le contenu.

Si vous utilisez — et vous le devez — WebPageTest pour tester la performance de vos sites, il vous suffit de repérer les lignes jaunes sur la cascade, ce sont les redirections.

La page d’accueil de la FNAC est par exemple finalisée après 11 redirections. L’une — qui impacte le plus l’utilisateur — pour rediriger de http://fnac.fr/ vers http://www.fnac.com/ et les 10 autres à cause de services de publicité et statistiques :

Mais alors comment faire, puisque le SEO me demande de faire des redirections ?

Tout le monde, tu contenteras

C’est en fait assez simple techniquement, mais il faut surtout comprendre deux choses essentielles :

  • L’Internaute moyen2 s’en fiche royalement de naviguer sur http://gasteroprod.com/ ou sur http://www.gasteroprod.com/, c’est le contenu qui l’intéresse3;
  • Seuls les moteurs de recherche sont intéressés par des redirections qui leur permettent de réduire leur travail d’identification de potentiel duplicate content.

Du coup, c’est effectivement simple, il suffit de ne faire les redirections que pour les moteurs de recherche, en les identifiant à l’aide de leur signature User Agent. Oui, je sais, le User Agent Sniffing c’est mal, mais là c’est un cas extrême, on n’essaie pas de servir différents contenus et/ou présentations à des navigateurs.

Voilà donc ce que cela donne en réduisant la cible à Googlebot, la signature du robot d’indexation de Google :

RewriteCond %{HTTP_USER_AGENT} Googlebot
RewriteCond %{HTTP_HOST} ^www\.gasteroprod\.com [NC]
RewriteRule ^(.*) http://gasteroprod.com/$1 [QSA,R=301,L]

Vous pouvez bien entendu ajouter d’autres robots si cela vous chante…

  1. Et même peut-être un jour une bonne pratique Opquast webperf… ⬆︎

  2. Ce n’est pas péjoratif. ⬆︎

  3. Enfin j’espère… ⬆︎

Si vous voulez signaler une erreur ou proposer une modification de ce texte, n'hésitez pas à l'éditer directement à la source sur Github.

15 commentaires

  • Problème plus théorique que réel. Quand tu crées un site en no-www ou bascules d'un sous-domaine www à du no-www, tu dois te donne pour objectif de limiter autant que possible les liens en www.domaine.tld pointant vers tes pages. Ce qui signifie :

    • T'assurer que les liens chez toi sont corrects.
    • T'assurer que les moteurs prennent bien en compte le domaine sans www.
    • Éventuellement faire corriger quelques backlinks majeurs qui pointeraient sur du www, si tu le peux.

    À partir de là, tu récupères 99 % de trafic directement sur le bon domaine, et peut-être 1 % sur du www (ou tout autre domaine ou sous-domaine que tu redirigerais, c'est la même logique). S'embêter pour un très léger impact de perf dans ce cas de figure rare, je vois pas l'intérêt.

    Par ailleurs si tu ne rediriges pas les utilisateurs mais uniquement les moteurs, tu vas te retrouver avec des backlinks pointant tantôt sur no-www et tantôt sur www, et donc des moteurs qui reçoivent une redirection 301 pour un backlink sur deux ; je suis pas sûr que cette situation soit idéale côté SEO.

    En passant : google.tld fait une redirection 301 vers www.google.tld, www.twitter.com une 301 vers twitter.com, facebook.com une 302 vers www.facebook.com, yahoo.com une 301 vers www.yahoo.com.

  • T'assurer que les liens chez toi sont corrects.

    Facile.

    T'assurer que les moteurs prennent bien en compte le domaine sans www.

    C'est dans les buts de ce billet, facile aussi.

    Éventuellement faire corriger quelques backlinks majeurs qui pointeraient sur du www, si tu le peux.

    Plus compliqué, mais faisable avec de la patience.

    Tu oublies — au moins, je ne suis peut-être pas exhaustif — les gens qui tapent systématiquement le préfixe www., ceux qui comme moi font gasteroprod puis <kbd>Cmd</kbd>+<kbd>Entrée</kbd> et ceux qui ne tapent que gasteroprod, laissant le navigateur ajouter www. et .com (il me semble que la plupart des navigateurs le font).

    S'embêter pour un très léger impact de perf dans ce cas de figure rare, je vois pas l'intérêt.

    Je ne m'embête pas vraiment, au contraire, c'est de l'exploration qui m'intéresse !

    Sérieusement, je sais bien que cela n'aura aucun impact sur les visites sur mon pauvre petit blog très peu visité, je cherche plutôt à expérimenter des techniques à utiliser ensuite sur des sites de clients où chaque petit gain — surtout aussi facilement gagné — peut avoir une importance.

    Par ailleurs si tu ne rediriges pas les utilisateurs mais uniquement les moteurs, tu vas te retrouver avec des backlinks pointant tantôt sur no-www et tantôt sur www

    Là tu as clairement raison, il faudrait que mes liens internes soient générés en absolu en no-www et non en relatif reprenant le (sous-)domaine courant. Hop, dans la to-do ! ;-)

    En passant : google.tld fait une redirection 301 vers www.google.tld, www.twitter.com une 301 vers twitter.com, facebook.com une 302 vers www.facebook.com, yahoo.com une 301 vers www.yahoo.com.

    Toujours le bon vieux combat de chapelles entre les no-www et les yes-www, rien de nouveau, à chacun de faire son choix.

  • Cette technique pourrait bien être prise en compte comme étant du cloacking comme le laisse penser, un lien tiré du site d'olivier andrieu « Réussir son référencement web » éd. 2011
    http://support.google.com/webmasters/bin/answer.py?hl=fr&answer=66355

    Je ne serais pas étonné que les moteur de recherche se présente avec un User-Agent standard, pour procéder à une analyse par comparaison, dans le but de se protéger du cloacking.

    La problèmatique est similaire, pour ceux qui sont contraints et forcés d'utiliser deux noms de domaines type « m.site.tld » en parallèle avec un « site.tld ».

    Le livre sus-cité propose d'ailleurs comme solution au problème, de choisir dans Google Webmaster Tools un domaine favoris à indexer, pour éviter le phénomène de Duplicate content.

    Enfin je pense que seul un expert SEO aillant mener des tests sur ce sujet, pourrait être à même de nous éclairer.

  • pour attraper plein de bots tu peux juste mettre
    RewriteCond %{HTTP_USER_AGENT} bot

  • Comme l'évoque rs459 plus haut, sur mon blog j'ai donné le domaine préféré (sans www) dans les webmasters tools, mon hébergement mutualisé OVH acceptant sans problème les www ou non.

    Inconvénient : je suppose qu'il faut faire les réglages pour chaque robots (j'ai pas été voir chez Yahoo, Boing et Cie).

  • Je pense que c'est essayé de réconcilier quelque chose qui n'est pas un problème.

    Si ton référencement est bon et que tu partages de bons liens, tout le monde ira sur le bon domaine. Du coup, la redirection n'arrivera que pour un nombre limité de ton audience.

    Autre chose, comment identifies-tu les bots ? Ton exemple ici est simpliste puisqu'il ne parle qu'à Googlebot. Tu affectes ton SEO si tu rates cela.

    Il faut s'assurer que toutes les ressources pointent vers le bon domaine pour ne pas avoir de duplication de cache sur la page suivante. Tu peux aussi avoir des problèmes de same-origin si tu fais tourner des scripts. Ça rend vraiment la QA de ton site difficile.

  • @Anthony
    J'ai répondu à Florent avec d'autres méthodes conduisant à des www. là où je n'en voudrais pas.
    Pour identifier les bot, Fil propose carrément de matcher bot dans le User Agent, c'est sans doute un peu risqué, mais ça ne provoque après tout qu'une redirection.

    Pour ce qui est des ressources, la plupart sont servies depuis http://static.gasteroprod.com/ donc ça devrait être bon. Il faut que je fasse une passe de vérification tout de même, bonne remarque.

    Le same-origin, je peux faire de même, attaquer le même domaine que celui sur lequel je suis, pas trop compliqué.

  • Le fait que tu dises « je dois vérifier » est l'illustration de ma dernière phrase. Ça complique la QA (et le code) pour le bénéfice de peu d'utilisateurs. Sans oublier les risques de cloaking que l'on a évoqués. Donc ce n'est pas une optimisation que je considère viable. Mais ce n'est que mon avis :)

  • Je suis en retard, j'avais piscine ce week-end.

    A savoir que si tu ne cible que Google, la solution est simple : Google webmaster tools. ;) Tu peux déclarer ton choix prioritaire www ou non.

    Ensuite tu peux limiter l'usage des redirections via plusieurs techniques :
    Que tous les liens internes soient absolus et non pas relatifs
    Utiliser le rel canonical
    Mais sincèrement, à mon humble avis, nous ne parlons pas ici de problème lié aux moteurs de recherche mais plus de problèmes liés aux humains et à leurs usages du web.

    La latence générée par la redirection d'un point de vue webperf est à prendre comme désagrément négligeable comparé à la somme de problèmes pouvant être engendrés par les doublons d'urls (SEO, mais également netlinking, analytics, AB testing etc…).

    Si le choix (www ou non) a été réalisé dés le départ, les visiteurs qui seront soumis aux redirections seront tout de même quantité négligeable.

  • @Anthony j'ai vérifié, ça m'a pris 5 minutes. Aucune URL produite dans mes pages ne contient www. même quand j'arrive avec ce sous-domaine dans l'URL. Donc rien à maintenir, tout est bon. Pour ce qui est du cloaking, c'est à creuser, effectivement.

    @euskadi31 j'utilise déjà rel="canonical" sur les pages des billets, je vais l'ajouter sur les autres pages, bonne idée.

  • @Aymeric merci d'être venu donner ton avis ! Je vais aller faire un tour dans les Webmaster Tools pour voir ça.

    La WebPerf, et notamment la latence, est le chantier sur lequel j'expérimente le plus ces derniers temps, ce qui explique ma démarche ici, mais je suis bien conscient qu'il faut concilier tous les sujets.

  • la 301 n'est presente que pour la migration definitive du pr, pourquoi chercher a detecter le bot… l'ancienne url n'existe plus dans la page de base alors pourquoi l'internaute prendrait-il une 301 ? le bot en revanche a associe le contenu a une url obsolete, s'il decide a un instant de crawler l'url alors la il est important qu'on lui dise de mettre a jour son index (url) et de transmettre le seo acquis, non ? Lorsque l'on a verifie que tt le monde a mis a jour ses index alors on a plus lieu de conserver cette redirection devenue inutile, donc fini le cout supplementaire, d'ailleurs pourquoi chercher a detecter le bot et risquer d'etre pris pour un cloaker en utilisant d'ailleurs une tout autant couteuse detection de user-agent ?

Twitter 500px Flickr Facebook Instagram Github Feed