L’un des problèmes les plus négligés de l’optimisation des pages par les clients, et même de nombreuses agences de référencement en sont parfois coupables, est la structure de l’URL d’un site Web. C’est presque en train de devenir ma première escale lorsque je prends un nouveau client, car la correction des URL et la façon dont elles sont formées peuvent être l’une des victoires les plus rapides qu’un site puisse obtenir. Une structure d’URL de sites sous-tend également tous les futurs efforts de référencement et est fondamentale pour tout niveau de réussite que vous souhaitez atteindre.
Par conséquent, pour les propriétaires de sites Web et les agences, veuillez vous référer à ma feuille de triche “Erreurs de référencement liées aux URL courantes” et maximisez à la fois la visibilité et la convivialité de votre moteur de recherche !
1. Manque de mots-clés
Il semble toujours y avoir deux camps à ce sujet : ceux qui pensent que l’utilisation de mots-clés dans la chaîne d’URL est bénéfique, et ceux qui ne le pensent pas. Je vous autorise par la présente à me citer en disant qu’actuellement, dans Google du moins, oui, cela aide effectivement vos efforts de référencement.
Cela est aggravé par le fait qu’une récente mise à jour de Google a vu les pages intérieures se classer désormais plus fréquemment pour certains termes de recherche plutôt que la page d’accueil, qui était historiquement classée en raison de son autorité globale plus élevée.
Dans cet esprit, quelle que soit la pondération et la pertinence que vous pouvez attribuer à une URL aux termes de recherche que vous ciblez, mieux c’est.
Bon exemple d’URL : http://www.jessops.com/compact-system-cameras/Sony/NEX-5-Black-18-55-lens/
Exemple d’URL erronée : http://www.jessops.com/online.store/products/77650/show.html
(Désolé de m’en prendre à vous ici Jessops, mais j’utilise votre site assez régulièrement et vos URL sont un de mes soucis constant !)
2. Trop de mots-clés
Bien qu’avoir des mots-clés dans votre chaîne d’URL soit une chose positive, un trop grand nombre peut vous causer des ennuis. Bien que je n’aie rencontré aucun ensemble de données ferme qui montrerait la corrélation négative entre le bourrage de mots-clés dans les URL et les positions de classement, Google a mentionné il y a quelque temps que leur algorithme fait en fait attention à cela (Matt Cutts fait allusion à la façon dont il peut “look spammy” dans cette vidéo d’aide aux webmasters). Même s’il ne s’agit pas d’un facteur de classement trop important, l’aspect convivialité des URL est entravé lorsque vous commencez à les bourrer de phrases cibles.
Bon exemple d’URL : http://www.example.com/hotels/USA/north-amarica/florida/orlando/
Mauvaise URL Exemple : http://www.example.com/hotels/USA-hotels/north-america-hotels/florida-hotels/orlando-hotels/
C’est un exemple relativement bénin et loin d’être le pire que j’ai vu !
3. Sémantique et structure de répertoire
L’utilisation d’une structure d’URL logique aidera non seulement les utilisateurs à comprendre comment toutes les pages sont liées les unes aux autres et comment naviguer entre les catégories, mais aussi les moteurs de recherche. Un avantage supplémentaire de l’utilisation d’une sémantique bien conçue est que Google peut les extraire dans un SERP et les afficher à la place d’une chaîne d’URL parfois déroutante ;
4. Contenu AJAX dynamique
Passons maintenant à quelque chose d’un peu plus technique.
J’ai récemment eu quelques nouveaux clients qui étaient inquiets, car seules leurs pages de catégories de premier niveau pouvaient être trouvées dans les moteurs de recherche. Cela signifiait que toutes les requêtes de longue traîne ne renvoyaient pas leurs sous-catégories. Après une enquête plus approfondie, il s’est avéré qu’ils utilisaient AJAX pour générer ces pages avec un contenu dynamique en utilisant le paramètre de hachage, et donc ces URL n’étaient pas indexées.
En 2009, Google a annoncé qu’il apportait des modifications pour permettre l’indexation de ces pages dynamiques. Pour ce faire, le jeton de point d’exclamation (“!”) doit être ajouté après le hachage (“#”) dans une URL AJAX.
URL AJAX non indexable : http://www.example.com/news.html#latest
URL AJAX indexable : http://www.example.com/news.html#!latest
5. Canonicaliser www et Non-www
De nos jours, la plupart des webmasters gèrent bien cela, bien que ce soit généralement par accident car leur CMS le fait pour eux. Cependant, il y a encore des poignées qui oublient. Je suppose que cela peut être pardonné dans certains cas, mais en tant que développeurs, après avoir travaillé pendant des mois pour rendre un site joli et s’assurer qu’il fait ce qu’il est censé faire, vérifier que le www et le non-www sont correctement traités est loin de leur les esprits.
Il y a vraiment deux questions ici, qui ont toutes deux la même réponse. La première est que l’URL autre que www ne pointe nulle part et renvoie une erreur 404 “page introuvable”. Le deuxième problème est que l’URL non-www pourrait avoir le même rendu que la version www – cela créerait effectivement deux copies exactes du même site Web.
La solution : assurez-vous que la version non www est redirigée en 301 vers la version www, ou visa verse selon vos préférences personnelles !
6. Pages HTTP sécurisées
Un autre problème potentiel de contenu dupliqué qui passe très souvent inaperçu est celui des pages http et https affichant le même contenu. Cela se produit généralement soit par un développement Web bâclé utilisant des URL relatives sur le site Web, soit par un CMS automatisé. C’est le plus courant lorsqu’un utilisateur entre dans une zone sécurisée du site avec un https, puis quitte la page https pour revenir à la page http non sécurisée ; cependant, la navigation conserve le précurseur https – généralement en raison de liens URL relatifs. Cela se traduit donc par le rendu du https sur toutes les pages du site par la suite.
Pour lutter contre cela, deux mesures doivent être prises. Tout d’abord, toute navigation vers des pages non sécurisées doit être http et non https. Cela peut être réalisé en le codant en dur ou en s’assurant que toutes les URL relatives sont supprimées des pages sécurisées.
Deuxièmement, dans les zones non sécurisées, les versions https doivent être redirigées 301 vers les versions http correctes.
7. ID de catégorie
Beaucoup de ces points sont interconnectés, et celui-ci se prête aux conseils déjà donnés, concernant l’inclusion de mots-clés et la sémantique.
De nombreux sites utilisent des identifiants de catégorie dans leurs URL, générés la plupart du temps par leur CMS. En un mot, une charge de chiffres, de lettres et de symboles dans une URL ne signifie absolument rien pour un visiteur humain ou une araignée de moteur de recherche. Afin de maximiser l’impact sur le référencement des sites et de respecter les conseils d’inclusion de mots-clés dans l’URL et la sémantique logique, ces identifiants doivent être transformés en texte descriptif pertinent.
De nombreuses plates-formes CMS ont cette capacité de “jolie URL” intégrée. Cependant, si cette fonctionnalité n’est pas disponible, mappez simplement chacun des ID à une poignée pertinente telle qu’un nom ou une catégorie de produits.
Exemple d’URL laide : http://www.example.com/product.aspx?ID=11526&IT=5f7d3d
Joli exemple d’URL : http://www.example.com/dvds/anchorman-the-legend-of-ron-burgundy/
8. ID de session
De nombreux sites de commerce électronique suivent les activités des visiteurs, telles que l’ajout de produits aux paniers d’achat, en ajoutant des identifiants de session à la fin des URL. Ces identifiants sont nécessaires pour que les visiteurs puissent interagir avec les fonctionnalités spécifiques à l’utilisateur ; cependant, ils peuvent entraîner de dangereux problèmes de contenu dupliqué. Comme chaque identifiant doit être unique pour chaque visiteur, cela crée potentiellement un nombre infini de pages de site Web en double.
Par exemple:
http://www.example.com/buy?id=2f5e2 et http://www.example.com/buy?id=4k3g1 s’afficheront individuellement, mais seront potentiellement exactement la même page.
La meilleure façon de lutter contre ce problème consiste à supprimer les identifiants de session de la chaîne d’URL et à les remplacer par un cookie de session. Ce cookie fonctionnera de la même manière que l’ID, mais est stocké sur la machine des utilisateurs et n’affectera donc pas l’URL.
9. L’énigme de la barre oblique
Il s’agit d’un autre problème de contenu en double, mais très subtil. Encore une fois, de nombreuses plates-formes CMS gèrent très bien cette situation, mais vous devez en être conscient au cas où.
Dans ce cas, le contenu dupliqué provient d’un site Web affichant des URL, avec et sans la barre oblique finale.
Par exemple:
http://www.example.com/catagory/product et http://www.example.com/catagory/product/ s’afficheront individuellement, mais il s’agira exactement de la même page.
La correction du problème est simple et peut être résolue avec une simple règle de redirection 301 pour toutes les pages sans barre oblique pointant vers la version avec une barre oblique.
10. Rendu du fichier d’index
Un site Web affichera parfois à la fois un répertoire racine dans l’URL et la racine ajoutée au fichier d’index (index.html, index.php, index.aspx, etc.). Lorsque cela se produit, les deux sont traités comme une page individuelle par un moteur de recherche, ce qui entraîne à la fois l’indexation et la création de contenu dupliqué.
Par exemple:
http://www.example.com/catagory/product/ et http://www.example.com/catagory/product/index.html s’afficheront individuellement, mais seront exactement la même page.
C’est l’un des oublis les plus courants que je rencontre quotidiennement et il est très simple à rectifier. Semblable au correctif de la barre oblique finale, une règle de redirection 301 doit être établie pour pointer l’un vers l’autre. Pour permettre un plus grand niveau de convivialité, je suggérerais de rediriger la version, y compris la page d’index vers l’URL du répertoire racine sans la page d’index.
CONSEIL EN PRIME
11. URL de sous-domaine
Ce n’est pas tellement directement un problème lié au référencement ; cependant, c’est celui que j’ai senti que je devais inclure dans cette liste car il m’a causé mal de tête après mal de tête, avec un client particulier l’année dernière, et je veux que vous évitiez ma douleur !
Je parcourais Google Analytics et suis tombé sur une page particulièrement modeste du site d’un client qui générait un grand nombre de pages vues. En fouillant un peu plus loin dans les analyses, après plusieurs heures d’arrachage de cheveux, j’ai découvert que cela était dû au fait qu’une page sur le domaine principal portait exactement le même nom qu’une page sur l’un de leurs sous-domaines. En raison du fonctionnement du suivi des sous-domaines dans Google Analytics, on avait l’impression que ces deux pages très différentes étaient en fait une seule et même page.
Par exemple:
http://www.example.com/page-one/ et http://sub.example.com/page-one/ sont des pages distinctes affichant des informations différentes ; Cependant, le code de suivi de sous-domaine standard de Google Analytics enregistrera toutes les activités des deux comme étant sur la même page.
Donc, pour éviter une perte de cheveux inutile, assurez-vous que toutes les URL du domaine principal et de tous les sous-domaines sont uniques, ou mettez en œuvre une série de filtres personnalisés.
A propos de l’auteur: Paul Martin est analyste SEO senior chez Solutions d’épiphanie. Avec des bureaux à Leeds et à Londres, Epiphany fournit un marketing numérique de classe mondiale aux marques nationales et internationales.
