19 problèmes techniques courants de référencement (avec solutions recommandées)
Publié: 2020-08-19Chez Semetrical, nos spécialistes du référencement ont entrepris d'innombrables audits techniques de référencement au fil des ans et ont rencontré des problèmes techniques courants que les sites Web souffrent dans plusieurs secteurs. Notre guide décrit les problèmes techniques de référencement les plus courants avec les solutions recommandées.
Vous trouverez ci-dessous la liste des problèmes techniques de référencement les plus courants :
- Règles insensibles à la casse dans Robots,txt
- Duplication d'URL en majuscules et minuscules
- HTTP 302 redirection vers HTTPS
- URL canoniques ayant un impact sur les liens internes
- URL canoniques liées à des URL 404
- Plusieurs balises canoniques
- Duplication de la page d'accueil
- Version mobile et version de bureau des sites différentes
- Détection IP internationale
- Duplication de sites Web internationaux
- Sitemap XML comprenant des URL historiques et des URL de staging
- Le site Web intermédiaire est indexé, ce qui entraîne une duplication
- Recherche interne en cours d'indexation
- Paramètres provoquant la duplication
- Duplication d'URL de produit
- Profondeur d'un site web
- Javascript
- Utilisation incorrecte de Meta Robots NOINDEX
- Doux 404 Pages
1. Règles insensibles à la casse dans Robots,txt
Publier:
Lors d'audits SEO techniques, nous constatons souvent que les règles d'interdiction dans le fichier robots.txt ne prennent pas en compte les règles majuscules et minuscules.
Par exemple, sur les sites de commerce électronique, les chemins du panier partent souvent à la fois de /basket/ et de /Basket/, mais seul le chemin en minuscules est généralement inclus dans le fichier robots.txt. Cela signifie que les URL avec /Basket/ seraient toujours indexables et cela entraînerait une duplication de contenu, ce que vous devez éviter pour une meilleure indexation de votre site Web sur les moteurs de recherche.
Règles Robots.txt :
Interdire : /panier/
Interdire : /panier/*
La solution:
Auditez votre site Web et vérifiez s'il existe des versions majuscules et minuscules d'un chemin qui doivent être bloquées. Vous pouvez le faire en utilisant un robot d'exploration Web, comme nos amis de DeepCrawl. Si les deux versions sont actives sur le site Web, ajoutez une deuxième règle dans le robots.txt pour répondre au blocage du chemin en majuscules. Par exemple, Interdire : /Panier/*
Si vous n'avez pas accès à un robot d'indexation Web, une recherche de protocole de site peut être très utile pour voir si les versions majuscules et minuscules sont indexées.
2. Duplication d'URL en majuscules et minuscules
Publier:
Un problème courant que nous constatons est la duplication d'URL insensibles à la casse liées à l'ensemble d'un site Web et Google voit qu'il s'agit de deux URL différentes. Par exemple:
Cela peut se produire lorsque les éditeurs d'un article de blog ajoutent un lien direct vers une page de produit, mais qu'ils ont saisi une lettre majuscule au lieu d'une lettre minuscule.
Nous avons également vu cela se produire en raison de modules de liaison internes ayant un bogue où les liens de produits populaires sont liés via des lettres majuscules.
La solution:
Nous vous recommandons de configurer une règle au niveau du serveur où toutes les URL en majuscules redirigent vers les minuscules via une redirection 301. Cela protégera le site Web de toute duplication future où une URL majuscule et minuscule est liée.
L'ajout d'une règle de redirection 301 consolidera également toute équité de lien lorsqu'un site externe peut créer un lien vers votre site par erreur via une lettre majuscule.
Si une redirection 301 n'est pas possible, nous vous recommandons d'ajouter une balise canonique dans le code source des URL en majuscules pour référencer la version de l'URL en minuscules.
3. HTTP 302 redirection vers HTTPS
Publier:
Les entreprises migrent souvent leur site Web vers des URL HTTPS sécurisées, mais elles n'implémentent pas toujours une règle de redirection 301, et implémentent à la place une redirection 302, donc cela indique en théorie aux moteurs de recherche que la version HTTP d'une URL n'a été déplacée que temporairement au lieu de définitivement. Cela peut réduire l'équité des liens et l'autorité globale de votre site Web, car les URL HTTP qui ont acquis des backlinks au fil du temps ne passeront pas entièrement l'équité des liens vers la version HTTPS à moins qu'une redirection 301 ne soit en place.
La solution:
Nous vous recommandons de configurer une règle au niveau du serveur où toutes les URL HTTP 301 redirigent vers la version HTTPS.
4. URL canoniques impactant les liens internes
Publier:
Sur un certain nombre de sites Web de commerce électronique, nous avons vu des produits ayant plusieurs variantes d'URL de produit, mais chaque variante étant liée à une URL de produit canonique pour éviter la duplication. Cependant, la page de produit canonique ne peut être trouvée que via des balises canoniques et aucun autre lien interne.
De plus, la page de produit canonique n'inclut aucun fil d'Ariane qui a un impact sur les liens internes sur le site Web.
Cette configuration canonique de liaison interne a parfois empêché les moteurs de recherche de récupérer la version de l'URL canonique en ignorant l'instruction, car les liens internes à travers le site envoient des signaux mitigés. Cela peut entraîner l'indexation des versions non canoniques des produits, ce qui provoque la cannibalisation des URL, ce qui a finalement un impact négatif sur vos performances de référencement.
La solution:
Pour faciliter l'indexation des URL canoniques, les sites Web doivent :
Ajouter les URL canoniques au sitemap XML et non les autres variantes d'URL
Lien interne vers les versions d'URL canoniques dans les modules de liens internes à l'échelle du site tels que les "produits populaires"
Ajoutez une structure de fil d'Ariane principale à la page d'URL canonique.
5. URL canoniques liées à 404 URL
Publier:
Les URL canoniques font parfois référence à 404 URL, mais cela envoie des signaux mitigés à la recherche
moteurs. L'URL canonique demande à un robot d'exploration de l'URL préférée d'indexer, mais l'URL préférée n'existe plus actuellement.
La solution:
Tout d'abord, vous devez déterminer si l'URL canonique doit être une 404 ou si elle doit être rétablie. S'il est rétabli, le problème est résolu, mais si l'URL canonique doit être un 404, vous devez choisir une nouvelle URL canonique ou mettre à jour l'URL canonique pour qu'elle se référence automatiquement.
6. Plusieurs balises canoniques
Publier:
Dans le code HTML d'une page Web, il peut parfois y avoir deux balises canoniques. Cela peut envoyer des messages contradictoires à un moteur de recherche et seul le premier canonique sera compté et utilisé.
La solution:
Certains robots d'exploration de sites Web peuvent signaler plusieurs balises canoniques. Toutefois, si ce n'est pas le cas, vous devez configurer une extraction personnalisée lors de l'exploration du site pour rechercher plusieurs balises canoniques.
Les pages Web avec plusieurs balises canoniques dans le code HTML doivent être mises à jour lorsqu'une est supprimée et seule la balise canonique correcte reste.
7. Duplication de la page d'accueil
Publier:
Les sites Web ont parfois plusieurs URL de page d'accueil, ce qui entraîne une duplication et peut entraîner une division de l'équité des liens. Les URL de duplication de page d'accueil courantes incluent :
www.exemple.com
www.exemple.com/accueil
www.exemple.com/index.html
www.example.com/home.html
La solution:
Si votre site Web comporte plusieurs URL de page d'accueil, nous vous recommandons de configurer une redirection 301 dans laquelle toutes les versions dupliquées redirigent vers la version principale de la page d'accueil.
8. Version mobile et bureau des sites différents
Publier:
Les sites mobiles doivent contenir le même contenu que la version de bureau d'un site Web. Lors de la réalisation d'audits de sites Web et de la comparaison d'explorations de sites Web de bureau et de sites Web mobiles, nous avons rencontré des différences de contenu où la version mobile contient moins de contenu que la version de bureau sur certaines pages.
Cela peut causer des problèmes car presque toute l'indexation d'un site Web provient de la version mobile et si le contenu prioritaire est manquant, les classements peuvent commencer à baisser.
La solution:
La version mobile d'un site doit contenir le même contenu que la version de bureau et le contenu manquant doit être ajouté au site Web mobile.
9. Détection IP internationale
Publier:
Pour les sites Web qui ont mis en œuvre des redirections géo IP, le problème le plus courant est que la mise en œuvre redirige pour tous les utilisateurs, y compris les bots.
Googlebot explorera généralement à partir d'une adresse IP américaine et si les robots sont redirigés en fonction de l'emplacement géographique, Googlebot n'explorera et n'indexera que la version américaine d'un site Web. Cela empêchera d'autres versions géographiques du site d'être explorées et indexées.
De plus, cela peut entraîner des problèmes pour la tarification des produits. Balisage du schéma sur les sites de commerce électronique où la tarification est mise à jour en fonction de l'emplacement géographique, car seul le prix américain apparaîtra sur tous les marchés. Par exemple, l'extrait ci-dessous montre les prix américains apparaissant sur la version britannique d'un site Web au Royaume-Uni.
La solution:
Si vous devez implémenter des redirections géo IP, nous vous recommandons d'exclure tous les bots des règles de redirection, car cela permettra aux bots tels que Googlebot d'explorer et d'indexer toutes les versions internationales.
Si vous n'implémentez pas de redirections géo IP, nous vous recommandons de garder vos sites Web ouverts à tous les utilisateurs depuis n'importe quelle géolocalisation et d'afficher une bannière JavaScript conviviale qui permet aux utilisateurs de sélectionner leur propre langue/emplacement.
Il s'agit d'une fonctionnalité UX utile si un utilisateur a atterri sur la mauvaise version du site Web international. La fenêtre contextuelle apparaîtra en fonction de la détection IP, par exemple, si un utilisateur atterrit sur le site Web américain à partir d'une adresse IP britannique, la bannière apparaîtra indiquant à l'utilisateur que le site britannique peut être plus approprié.
10. Duplication de sites Web internationaux
Publier:
Il est courant de voir plusieurs versions d'un site Web lorsque les entreprises opèrent dans différents pays du monde. Il s'agit d'une pratique courante car, idéalement, vous souhaitez offrir la meilleure expérience utilisateur et, pour ce faire, les sites Web spécifiques à chaque pays permettent aux entreprises d'adapter le parcours de l'utilisateur en fonction de l'endroit où l'utilisateur se trouve dans le monde.
Cependant, les entreprises peuvent commettre l'erreur de créer plusieurs versions de leur site Web, mais n'envoient aucun signal aux moteurs de recherche pour indiquer quel site Web doit cibler un pays ou une région spécifique.
Lorsque les propriétaires de sites Web créent plusieurs versions de site sans instructions pour les moteurs de recherche, cela peut provoquer un chaos tel que la duplication de sites Web et la cannibalisation entre domaines.
La solution:
Lors de la création de versions internationales de votre site Web, les balises Hreflang doivent être utilisées pour signaler aux moteurs de recherche tels que Google la page Web correcte à proposer à un utilisateur en fonction de son emplacement et de sa langue.
Les balises Hreflang empêchent également les versions internationales d'un site Web d'être considérées comme des doublons par les moteurs de recherche, car la balise Hreflang indique essentiellement qu'une page spécifique est nécessaire pour servir un utilisateur dans un emplacement X avec un paramètre de langue X.
La configuration et la cartographie des balises Hreflang peuvent prêter à confusion et constituent une tâche importante en fonction de la taille de votre site Web. S'il est mal configuré, cela peut nuire au trafic de votre site Web.
Veuillez visiter notre page de services de référencement international si vous êtes en train de planifier l'expansion d'un site Web international ou si vous rencontrez des problèmes avec vos sites Web internationaux.
11. Plan du site XML incluant les URL historiques et les URL intermédiaires
Publier:
Un problème intéressant que nous rencontrons plus souvent que vous ne le pensez est celui des sites Web ayant d'anciennes URL dans leurs sitemaps XML ou des URL de mise en scène qui se glissent d'une manière ou d'une autre dans un sitemap XML.
Cela peut causer des problèmes, car si des URL de staging apparaissent dans vos sitemaps et que votre site de staging n'est peut-être pas bloqué par les moteurs de recherche, ces URL pourraient commencer à être indexées et à leur tour provoquer une duplication inutile.
Les URL historiques de votre sitemap qui servent désormais un code d'état 4xx ou 3xx peuvent envoyer des signaux déroutants aux moteurs de recherche sur les pages que vous souhaitez explorer ou indexer.
La solution:
Assurez-vous d'auditer régulièrement votre sitemap XML en gardant un œil sur la Search Console et en surveillant les erreurs qui apparaissent ou en configurant un crawl régulier dans un outil tel que Deepcrawl.
La configuration d'une analyse régulière des sitemaps XML dans Deepcrawl est très utile car cela peut rapidement signaler toutes les URL qui ne devraient pas apparaître dans votre sitemap et vous permet de rester au courant de ce problème potentiel.
12. Le site Web intermédiaire est indexé, ce qui entraîne une duplication
Publier:
Étonnamment, un certain nombre d'entreprises ont leurs sites Web de mise en scène indexables sur des moteurs de recherche tels que Google, non pas exprès mais par erreur. Cela peut entraîner une duplication importante, car le site Web intermédiaire sera généralement une réplique de votre environnement en direct. À partir d'une simple recherche de protocole d'URL sur Google, il existe des millions de pages Web de mise en scène en direct et indexables.
La solution:
Chez Semetrical, nous vous recommandons d'ajouter une couche d'authentification dans laquelle vous devez entrer un nom d'utilisateur et un mot de passe pour accéder au site Web de développement. L'ajout d'une règle d'interdiction est également une option pour empêcher l'indexation des environnements intermédiaires, mais il est préférable de l'implémenter si le site intermédiaire n'a pas déjà été indexé. Par exemple:
Agent utilisateur: *
Interdire : /
La plupart des outils de robot d'exploration de sites Web ont une fonctionnalité d'écrasement de robots.txt en place afin que vous puissiez facilement remplacer la règle d'interdiction lors de la réalisation de tests sur votre environnement de staging.
13. Recherche interne en cours d'indexation
Publier:
Les URL de recherche internes sur les sites Web peuvent être idéales pour le référencement, car elles permettent aux sites Web de se classer pour les requêtes de recherche hyper-longue queue, ou de se classer pour les mots-clés où ils n'ont pas d'URL principale à classer.
Cependant, dans de nombreux cas, les pages de recherche internes peuvent entraîner de nombreuses duplications sur les sites Web et peuvent également entraîner des problèmes de budget d'exploration sur les sites Web à grande échelle. Pour ce guide, nous nous concentrerons sur le côté négatif de la recherche interne.
Les pages de recherche internes sont généralement de très mauvaise qualité car elles ne seront pas optimisées et seront souvent classées comme contenu léger car elles hébergeront un faible nombre de résultats tels que des produits.
La solution:
Avant de décider de bloquer les pages de recherche interne, il est conseillé de vérifier que ces pages ne se classent actuellement pour aucun mot-clé ou n'apportent pas de trafic régulier.
Vérifiez également que ces URL n'ont pas créé de backlinks au fil des ans. Si vos pages de recherche internes n'ont pas de backlinks faisant autorité et ne génèrent pas de trafic organique, chez Semetrical, nous recommandons deux étapes :
Première étape : ajoutez les balises NOINDEX, FOLLOW à toutes les pages de recherche pour permettre aux moteurs de recherche de désindexer ces pages. Une fois que ces pages ont été désindexées sur quelques mois, nous mettrons en œuvre la deuxième étape.
Deuxième étape : Ajoutez le répertoire de recherche interne au fichier robots.txt tel que Disallow : */search*
14. Paramètres provoquant une duplication
Publier:
La duplication des paramètres de tri et de filtrage peut être un problème courant lors de l'audit de sites Web. De nombreux sites Web utiliseront des filtres car ils peuvent améliorer l'expérience utilisateur et permettre aux utilisateurs de filtrer leurs résultats de recherche. Cependant, le principal problème est lorsque les sites Web gardent les filtres indexables, car cela génère une quantité importante de duplication sur le site Web. Par exemple:
Parfois, nous rencontrons des sites Web qui ajoutent des paramètres de suivi à la fin des URL sur les liens internes pour indiquer où dans le site ce lien a été cliqué. Nous ne recommandons pas cette configuration dans un premier temps, cependant, lorsque les sites l'ont déjà en place, cela peut entraîner de nombreuses duplications sur un site Web car il peut créer plusieurs versions de la même page. Par exemple:
Un autre paramètre de suivi courant pouvant entraîner une duplication est le paramètre de suivi UTM dans lequel des liens sont utilisés pour des campagnes spécifiques afin de suivre les performances de la campagne. Par exemple:
La solution:
Il existe plusieurs façons d'empêcher l'indexation des paramètres et la duplication, notamment :
Canonicaliser l'URL du paramètre vers la version de l'URL propre
Ajout d'une règle dans le fichier robots.txt pour interdire des paramètres spécifiques
Ajout de paramètres à l'outil de paramètres d'URL dans la Search Console qui signale à Google que certains paramètres ne doivent pas être explorés.
15. Duplication d'URL de produit
Publier:
Sur les sites Web de commerce électronique, la duplication d'URL de produit peut être un gros problème, ainsi que sur les sites Web d'éditeurs. La principale raison de la duplication d'URL de produit est que les produits peuvent hériter de la catégorie/sous-catégorie dans sa structure d'URL et si le produit se trouve dans plusieurs catégories/sous-catégories, plusieurs URL sont donc créées.
Sur les sites Web des éditeurs, les documents peuvent également se trouver dans plusieurs zones et si l'URL du document hérite de l'emplacement du document, plusieurs versions sont créées. Par exemple:
La solution:
Lorsque nous rencontrons une duplication comme celle-ci, il existe différentes manières de la nettoyer afin que nous puissions nous assurer que la version correcte de l'URL est explorée et indexée.
Pour corriger la duplication d'URL, nous vous recommandons de canoniser toutes les variantes d'URL de produit vers le parent ou vers une version générique. Par exemple:
Exemple canonique parent
femmes-collections-robes-robes-de-jour
/71hdo/robe-mini-florale-bella-lula
canoniserait en :
robes-collections-femme
/71hdo/robe-mini-florale-bella-lula
Exemple canonique générique :
femmes-collections-robes-robes-de-jour
/71hdo/robe-mini-florale-bella-lula
robes-collections-femme
/71hdo/robe-mini-florale-bella-lula
Canoniserait à
Alternatives :
Si vous avez accès à des développeurs, une solution alternative consisterait à créer un lien interne vers les canoniques de produits sur tout le site Web et à rediriger 301 toutes les URL de produits qui sortent des catégories/sous-catégories vers l'URL de produit canonique générique.
Cela empêcherait la duplication des produits et vous permettrait de vous connecter aux produits via plusieurs itinéraires
16. Profondeur d'un site Web
Publier:
La profondeur de page est le nombre de clics sur une page spécifique à partir de la page d'accueil d'un site Web. Lors de la réalisation d'audits de sites Web, nous rencontrons des sites Web dont la profondeur de site Web est supérieure à 10. Cela signifie que ces pages sont à 10 clics de la page d'accueil !
Plus il faut de clics pour trouver une page Web, plus il est difficile pour un moteur de recherche de trouver cette URL et il est plus probable que l'URL ne soit pas revisitée aussi souvent que les pages plus haut dans le site Web.
De plus, plus une page est élevée dans l'architecture de votre site Web, plus elle a de chances d'être considérée comme une page prioritaire par les moteurs de recherche. Si les pages prioritaires sont plus bas dans l'architecture, il y a un risque qu'elles ne soient pas aussi bien classées.
La solution:
Les principaux moyens d'améliorer la profondeur du site Web et de s'assurer que les pages prioritaires sont placées en haut de l'architecture du site Web incluent :
Liens internes sur le site Web, tels que les produits recommandés, les produits connexes et les pages en vedette
L'utilisation de fils d'Ariane sur le site Web
Configuration de la pagination où elle inclut la première, la dernière et les deux pages de résultats de chaque côté de la page sur laquelle vous vous trouvez
Effectuer des recherches de mots clés pour découvrir les pages de catégorie de niveau supérieur qui devraient être liées dans la navigation principale d'un site Web et ajouter des liens vers des pages prioritaires
17. Problèmes techniques de référencement JavaScript
Publier
De nombreux sites Web utilisent aujourd'hui JavaScript, cependant, lors de la désactivation de JavaScript, certains sites Web ne sont pas entièrement fonctionnels et les liens peuvent disparaître et ne seront pas détectables par les moteurs de recherche. Il s'agit d'un problème de référencement technique courant.
Souvent, nous constatons que les modules "vous pouvez également aimer" sur les pages de produits de commerce électronique ne peuvent pas être vus par les robots des moteurs de recherche, ce qui rend le module de liaison interne redondant.
De plus, les modules d'examen qui incluent des UGC riches en mots clés se trouvent dans des modules JavaScript qui ne peuvent pas non plus être découverts par les robots d'exploration.
Un problème intéressant rencontré par divers sites Web de commerce électronique est que lors de la désactivation de JavaScript sur les pages de résultats, les liens de produits peuvent toujours être trouvés, mais toutes les images disparaissent car il n'y a pas d'option de secours pour les images à découvrir.
La solution:
Travaillez avec l'équipe de développement pour essayer de créer une alternative JavaScript où les images sont toujours présentes dans le code source ainsi que les modules JavaScript pouvant être explorés via HTML.
Un excellent moyen de tester l'indexation du contenu JavaScript consiste à accéder à la version mise en cache de votre page Web et à voir à quoi ressemble la "version complète" de la page, ainsi qu'à examiner la "version texte uniquement".
18. Utilisation incorrecte de Meta Robots NOINDEX
Publier:
Notre équipe technique de référencement a audité des sites Web et découvert que des balises NOINDEX ont été ajoutées au code source des pages par erreur. De plus, les pages vues qui ont historiquement généré du trafic ont une balise NOINDEX en place.
Étonnamment, un problème qui peut se produire plus souvent que vous ne le pensez est que les développeurs poussent les environnements de staging en direct avec la balise NOINDEX toujours présente dans le code source.
En fin de compte, la balise NOINDEX indiquera aux moteurs de recherche de ne pas indexer la page et empêchera la page d'apparaître dans les résultats de recherche.
La solution:
Si vous rencontrez des pages qui ont une balise NOINDEX en place lors de l'audit d'un site Web et que vous ne savez pas pourquoi la balise est en place, vérifiez auprès de l'équipe de développement pour voir quand et aussi pourquoi ces pages incluent la balise.
Si une balise NOINDEX a été ajoutée par erreur, vous devez demander aux développeurs de mettre à jour le code source et de supprimer complètement la balise ou de la mettre à jour pour lire <meta name="robots" content="INDEX, FOLLOW">
19. Soft 404 Pages
Publier:
Une page 404 logicielle ne devrait pas exister sur un site Web, cela se produit lorsqu'une page inexistante qui devrait renvoyer un code d'état 404 renvoie un code d'état 200 OK. Si 404 pages renvoient un code d'état 200, elles peuvent toujours être explorées et indexées.
C'est finalement un problème car les moteurs de recherche tels que Google peuvent perdre du temps à explorer ces pages qui ne fournissent aucun budget d'exploration inutile au lieu de se concentrer sur des pages précieuses. Ces pages peuvent également créer des problèmes de duplication sur un site Web, en particulier si un site Web contient des milliers de pages soft 404 affichant un message « page introuvable ».
Il existe plusieurs façons de trouver des pages soft 404, notamment :
Visiter la Search Console où elle signale les pages soft 404
Explorer votre site Web et rechercher 200 pages de code de statut avec des balises de titre de "Page introuvable"
Explorer votre site Web avec une extraction personnalisée qui recherche le message de copie du corps présent sur les pages de code d'état 404 et toute page de code d'état 200 avec ce message doit être un 404 logiciel
La solution:
Si vous rencontrez des pages soft 404 sur votre site Web, il existe quelques solutions qui peuvent être mises en œuvre, notamment :
301 rediriger les pages soft 404 vers une page alternative appropriée si disponible
Changez le code d'état de ces pages en un code d'état 404 ou 410 mais vérifiez qu'aucune équité de lien ne sera perdue.
Si vous rencontrez des problèmes avec votre site Web ou si vous avez besoin d'un audit technique de référencement, veuillez visiter notre page de services techniques de référencement pour plus d'informations sur la façon dont Semetrical peut vous aider.