J’aime le référencement technique (la plupart du temps). Cependant, il peut être frustrant de rencontrer les mêmes problèmes de site encore et encore. Au cours des années où j’ai fait du référencement, je suis toujours surpris de voir autant de sites Web différents souffrir des mêmes problèmes.
Cet article décrit certains des problèmes les plus courants que j’ai rencontrés lors des audits de site, ainsi que certains problèmes moins courants à la fin. Espérons que les solutions vous aideront lorsque vous rencontrerez ces problèmes, car il y a de fortes chances que vous le fassiez à un moment donné !
1. URL majuscules vs minuscules
D’après mon expérience, ce problème est plus courant sur les sites Web qui utilisent .NET. Le problème provient du fait que le serveur est configuré pour répondre aux URL avec des lettres majuscules et non pour rediriger ou réécrire vers la version minuscule.
J’admettrai que récemment, ce problème n’a pas été aussi courant qu’il l’était parce que généralement, les moteurs de recherche sont devenus beaucoup plus efficaces pour choisir la version canonique et ignorer les doublons. Cependant, j’ai vu trop d’exemples de moteurs de recherche qui ne le font pas toujours correctement, ce qui signifie que vous devez le rendre explicite et ne pas compter sur les moteurs de recherche pour le découvrir par eux-mêmes.
Il existe un module de réécriture d’URL qui peut aider à résoudre ce problème sur les serveurs IIS 7. L’outil a une option intéressante dans l’interface qui vous permet d’appliquer des URL en minuscules. Si vous faites cela, une règle sera ajoutée au fichier de configuration Web qui résoudra le problème.
Ce que tout SEO devrait savoir sur IIS par Dave Sottimano
Les secrets de la boîte à outils SEO IIS que vous ne connaissez peut-être pas par Dan Butler
2. Plusieurs versions de la page d’accueil
Encore une fois, c’est un problème que j’ai rencontré plus souvent avec les sites Web .NET, mais cela peut arriver assez facilement sur d’autres plates-formes. Si je lance un audit de site sur un site dont je sais qu’il est en .NET, j’irai presque immédiatement vérifier si cette page existe :
Le verdict? C’est généralement le cas ! Il s’agit d’une copie de la page d’accueil que les moteurs de recherche peuvent généralement trouver via la navigation ou les plans de site XML.
D’autres plates-formes peuvent également générer des URL comme celle-ci :
Je n’entrerai pas dans les détails mineurs de la façon dont ces pages sont générées car la solution est assez simple. Encore une fois, les moteurs de recherche modernes peuvent résoudre ce problème, mais il est toujours préférable de supprimer le problème en premier lieu et de le clarifier.
Trouver ces pages peut être un peu délicat car différentes plates-formes peuvent générer différentes structures d’URL, de sorte que la solution peut être un peu un jeu de devinettes. Au lieu de cela, faites une exploration de votre site, exportez l’exploration dans un CSV, filtrez par la colonne de titre META et recherchez le titre de la page d’accueil. Vous pourrez facilement trouver des doublons de votre page d’accueil.
Je préfère toujours résoudre ce problème en ajoutant une redirection 301 vers la version dupliquée de la page qui pointe vers la bonne version. Vous pouvez également résoudre le problème en utilisant la balise rel=canonical, mais je maintiens une redirection 301 dans la plupart des cas.
Une autre solution consiste à effectuer un crawl du site à l’aide d’un outil comme Screaming Frog pour trouver des liens internes pointant vers la page dupliquée. Vous pouvez ensuite entrer et modifier les pages en double afin qu’elles pointent directement vers la bonne URL, plutôt que d’avoir des liens internes passant par un 301 et perdant un peu d’équité de lien.
Comment implémenter des redirections en utilisant htaccess
Directives de Google sur les redirections 301
3. Paramètres de requête ajoutés à la fin des URL
Ce problème a tendance à survenir le plus souvent sur les sites Web de commerce électronique basés sur une base de données. Il y a une chance d’occurrence sur n’importe quel site, mais le problème a tendance à être plus important sur les sites de commerce électronique car il y a souvent beaucoup d’attributs de produit et d’options de filtrage telles que la couleur, la taille, etc. Voici un exemple de Go Outdoors (pas un client ):
Dans ce cas, les URL sur lesquelles les utilisateurs cliquent sont relativement conviviales en termes de référencement, mais très souvent, vous pouvez vous retrouver avec des URL telles que celle-ci :
Cet exemple filtrerait la catégorie de produit par une certaine couleur. Le filtrage à ce titre est bon pour les utilisateurs, mais peut ne pas l’être pour la recherche, en particulier si les clients ne recherchent pas le type de produit spécifique à l’aide de la couleur. Si tel est le cas, cette URL n’est pas une excellente page de destination à cibler avec certains mots clés.
Un autre problème possible qui a tendance à utiliser des TONNES de budget de crawl est lorsque lesdits paramètres sont combinés. Pour aggraver les choses, parfois les paramètres peuvent être combinés dans des ordres différents mais renverront le même contenu. Par exemple:
Ces deux URL renverraient le même contenu, mais comme les chemins sont différents, les pages pourraient être interprétées comme du contenu en double.
J’ai travaillé sur le site Web d’un client il y a quelques années qui avait ce problème. Nous avons découvert qu’avec toutes les options de filtrage dont ils disposaient, il y avait plus d’un MILLIARD d’URL pouvant être explorées par Google. Ce nombre était hors du commun si l’on considère qu’il n’y avait qu’environ 20 000 produits proposés.
N’oubliez pas que Google alloue un budget de crawl en fonction de votre PageRank. Vous devez vous assurer que ce budget est utilisé de la manière la plus efficace possible.
Avant d’aller plus loin, je souhaite aborder un autre problème connexe courant : les URL peuvent ne pas être optimisées pour le référencement car elles ne sont pas pilotées par une base de données. Ce n’est pas le problème qui me préoccupe dans ce scénario particulier, car je suis plus préoccupé par le budget d’exploration gaspillé et l’indexation de pages qui n’ont pas besoin de l’être, mais cela reste pertinent.
Le premier point de départ consiste à identifier les pages que vous souhaitez autoriser Google à explorer et à indexer. Cette décision doit être motivée par votre recherche de mots clés et vous devez croiser tous les attributs de la base de données avec vos mots clés cibles principaux. Continuons avec le thème de Go Outdoors pour notre exemple :
Voici nos principaux mots-clés :
-
Vestes imperméables
-
Bottes de randonnée
-
Pantalon de marche femme
Sur un site Web de commerce électronique, chacun de ces produits sera associé à des attributs qui feront partie de la base de données. Voici quelques exemples courants :
-
Taille (c.-à-d. Grand)
-
Couleur (c’est-à-dire noir)
-
Prix (soit 49,99 £)
-
Marque (c.-à-d. North Face)
Votre travail consiste à découvrir lesquels de ces attributs font partie des mots-clés utilisés pour trouver les produits. Vous devez également déterminer quelle combinaison (le cas échéant) de ces attributs est utilisée par votre public.
Ce faisant, vous constaterez peut-être qu’il existe un volume de recherche élevé pour les mots-clés qui incluent “North Face” + “vestes imperméables”. Cela signifie que vous souhaiterez qu’une page de destination pour les “vestes imperméables North Face” soit explorable et indexable. Vous pouvez également vous assurer que l’attribut de base de données a une URL conviviale pour le référencement, donc plutôt que “vestes-impermeables/?brand=5“tu choisiras”vestes-impermeables/north-face/.” Vous voulez également vous assurer que ces URL font partie de la structure de navigation de votre site Web pour assurer un bon flux de PageRank afin que les utilisateurs puissent trouver ces pages facilement.
D’un autre côté, vous constaterez peut-être qu’il n’y a pas beaucoup de volume de recherche pour les mots-clés qui combinent “North Face” avec “Black” (par exemple, “vestes North Face noires”). Cela signifie que vous ne souhaitez probablement pas que la page avec ces deux attributs soit explorable et indexable.
Une fois que vous avez une idée claire des attributs que vous souhaitez indexer et de ceux que vous ne souhaitez pas, il est temps de passer à l’étape suivante, qui dépend du fait que les URL sont déjà indexées ou non.
Si les URL ne sont pas déjà indexées, la démarche la plus simple consiste à ajouter la structure d’URL à votre fichier robots.txt. Vous devrez peut-être jouer avec certaines Regex pour y parvenir. Assurez-vous de tester correctement votre regex afin de ne rien bloquer par accident. Assurez-vous également d’utiliser la fonctionnalité Explorer comme Google dans les outils pour les webmasters. Il est important de noter que si les URL sont déjà indexées, les ajouter à votre fichier robots.txt ne les fera PAS sortir de l’index.
Si les URL sont indexées, je crains que vous n’ayez besoin d’utiliser un plâtre pour résoudre le problème : la balise rel=canonical. Dans de nombreux cas, vous n’êtes pas assez chanceux pour travailler sur un site Web lorsqu’il est en cours de développement. Le résultat est que vous pouvez hériter d’une situation comme celle ci-dessus et ne pas être en mesure de résoudre le problème principal. Dans des cas comme celui-ci, la balise rel=canonical sert de pansement sur le problème dans l’espoir que vous puissiez le résoudre correctement plus tard. Vous voudrez ajouter la balise rel=canonical aux URL que vous ne voulez pas indexer et pointer vers l’URL la plus pertinente que vous voulez indexer.
Utilisation de catégories dans la recherche de mots-clés par Richard Baxter
Guide complet de rel=canonical par Lindsay Wassall
4. Erreurs logicielles 404
Cela arrive plus souvent que prévu. Un utilisateur ne remarquera rien de différent, contrairement aux robots des moteurs de recherche.
Un soft 404 est une page qui ressemble à un 404 mais renvoie un code d’état HTTP 200. Dans ce cas, l’utilisateur voit du texte du type “Désolé, la page que vous avez demandée est introuvable”. Mais en coulisses, un code 200 indique aux moteurs de recherche que la page fonctionne correctement. Cette déconnexion peut entraîner des problèmes d’exploration et d’indexation des pages lorsque vous ne le souhaitez pas.
Un soft 404 signifie également que vous ne pouvez pas repérer de vraies pages cassées et identifier les zones de votre site Web où les utilisateurs reçoivent une mauvaise expérience. Du point de vue de la création de liens (j’ai dû le mentionner quelque part !), aucune des deux solutions n’est une bonne option. Vous pouvez avoir des liens entrants vers des URL cassées, mais les liens seront difficiles à retrouver et à rediriger vers la bonne page.
Heureusement, il s’agit d’une solution relativement simple pour un développeur qui peut configurer la page pour renvoyer un code d’état 404 au lieu d’un 200. Pendant que vous y êtes, vous pouvez vous amuser et créer une page 404 sympa pour le plaisir de votre utilisateur. Voici quelques exemples de superbes pages 404, et je dois pointer vers la propre page de Distilled ici 🙂
Pour trouver les soft 404, vous pouvez utiliser la fonctionnalité de Google Webmaster Tools qui vous indiquera ceux que Google a détectés :
Vous pouvez également effectuer une vérification manuelle en accédant à une URL cassée sur votre site (telle que www.exemple.com/5435fdfdfd) et voir quel code de statut vous obtenez. Un outil que j’aime beaucoup pour vérifier le code d’état est Web Sniffer, ou vous pouvez utiliser l’outil Ayima si vous utilisez Google Chrome.
Blog Google Webmaster sur les soft 404
5. 302 redirections au lieu de 301 redirections
Encore une fois, il s’agit d’une redirection facile pour les développeurs de se tromper car, du point de vue de l’utilisateur, ils ne peuvent pas faire la différence. Cependant, les moteurs de recherche traitent ces redirections très différemment. Pour récapituler, une redirection 301 est permanente et les moteurs de recherche la traiteront comme telle ; ils transmettront l’équité du lien à la nouvelle page. Une redirection 302 est une redirection temporaire et les moteurs de recherche ne passeront pas l’équité du lien car ils s’attendent à ce que la page d’origine revienne à un moment donné.
Pour trouver 302 URL redirigées, je recommande d’utiliser un robot d’exploration profond tel que Screaming Frog ou IIS SEO Toolkit. Vous pouvez ensuite filtrer par 302 et vérifier s’ils doivent vraiment être des 302 ou s’ils doivent plutôt être des 301.
Pour résoudre le problème, vous devrez demander à vos développeurs de modifier la règle afin qu’une redirection 301 soit utilisée plutôt qu’une redirection 302.
Guide SEOmoz sur l’apprentissage des redirections
Guide ultime des redirections 301 par Internet Marketing Ninjas
6. Plans de site cassés/obsolètes
Bien qu’ils ne soient pas essentiels, les sitemaps XML sont très utiles aux moteurs de recherche pour s’assurer qu’ils peuvent trouver toutes les URL qui vous intéressent. Ils peuvent donner aux moteurs de recherche un coup de pouce dans la bonne direction. Malheureusement, certains sitemaps XML sont générés une seule fois et deviennent rapidement obsolètes, ce qui les amène à contenir des liens rompus et à ne pas contenir de nouvelles URL.
Idéalement, vos sitemaps XML devraient être mis à jour régulièrement afin que les URL cassées soient supprimées et que de nouvelles URL soient ajoutées. Ceci est plus important si vous êtes un grand site Web qui ajoute de nouvelles pages tout le temps. Bing a également déclaré qu’ils avaient un seuil de “saleté” dans un sitemap et que si le seuil est atteint, ils ne lui feront pas autant confiance.
Tout d’abord, vous devriez faire un audit de votre sitemap actuel pour trouver les liens brisés. Cet excellent outil de Mike King peut faire le travail.
Deuxièmement, vous devriez demander à vos développeurs de rendre votre plan de site XML dynamique afin qu’il soit mis à jour régulièrement. Selon vos ressources, cela peut être une fois par jour, une fois par semaine ou une fois par mois. Il y aura un peu de temps de développement nécessaire ici, mais cela vous fera (ainsi qu’à eux) gagner beaucoup de temps à long terme.
Un conseil supplémentaire ici : vous pouvez expérimenter et créer des sitemaps qui ne contiennent que de nouveaux produits et faire en sorte que ces sitemaps particuliers soient mis à jour plus régulièrement que vos sitemaps standard. Vous pouvez également faire un peu d’effort supplémentaire si vous avez des ressources de développement pour créer un sitemap qui ne contient que des URL non indexées.
Comment vérifier la saleté dans votre sitemap par Everett Sizemore
Quelques problèmes techniques peu courants
Je veux inclure quelques problèmes qui ne sont pas courants et qui peuvent en fait être difficiles à repérer. Les problèmes que je vais partager ont tous été vus récemment sur mes projets clients.
7. Mauvaise commande de votre fichier robots.txt
Je suis tombé sur un exemple de cela très récemment, qui a conduit à un certain nombre de pages explorées et indexées qui ont été bloquées dans robots.txt.
La raison pour laquelle les URL dans ce cas ont été explorées était que les commandes du fichier robots.txt étaient erronées. Individuellement, les commandes étaient correctes, mais elles ne fonctionnaient pas correctement ensemble.
Google le dit explicitement dans ses directives, mais je dois être honnête, je n’avais pas vraiment rencontré ce problème auparavant, donc c’était un peu une surprise.
Utilisez les commandes de vos robots avec précaution et si vous avez des commandes distinctes pour Googlebot, assurez-vous également d’indiquer à Googlebot les autres commandes à suivre, même si elles ont déjà été mentionnées dans la commande fourre-tout. Utilisez la fonctionnalité de test de Google Webmaster Tools qui vous permet de tester la réaction de Google à votre fichier robots.txt.
8. Caractère invisible dans robots.txt
J’ai récemment effectué un audit technique pour l’un de mes clients et j’ai remarqué un avertissement dans Google Webmaster Tools indiquant que “La syntaxe n’a pas été comprise” sur l’une des lignes. Lorsque j’ai consulté le fichier et que je l’ai testé, tout semblait correct. J’ai montré le problème à Tom Anthony qui a récupéré le fichier via la ligne de commande et il a diagnostiqué le problème : un personnage invisible avait en quelque sorte trouvé son chemin dans le fichier.
J’ai réussi à avoir l’air plutôt idiot à ce stade en rouvrant le fichier et en le cherchant !
La solution est assez simple. Réécrivez simplement le fichier robots.txt et exécutez-le à nouveau via la ligne de commande pour revérifier. Si vous n’êtes pas familier avec la ligne de commande, consultez ce post de Craig Bradford sur Distilled.
9. Google explore les URL base64
Ce problème était un problème très intéressant que nous avons rencontré récemment, et un autre que Tom a repéré. L’un de nos clients a constaté une augmentation massive du nombre d’erreurs 404 signalées dans les outils pour les webmasters. Nous sommes allés jeter un coup d’œil et avons constaté que presque toutes les erreurs étaient générées par des URL dans ce format :
Les outils pour les webmasters vous indiqueront d’où proviennent ces 404, nous sommes donc allés sur la page pour savoir comment cette URL était générée. Malgré tous nos efforts, nous ne l’avons pas trouvé. Après de nombreuses recherches, nous avons pu voir qu’il s’agissait de jetons d’authentification générés par Ruby on Rails pour essayer d’empêcher les requêtes intersites. Il y en avait quelques-uns dans le code de la page, et Google essayait de les crawler !
En plus du problème principal, les jetons d’authentification sont tous générés à la volée et sont uniques, d’où la raison pour laquelle nous n’avons pas pu trouver ceux dont Google nous parlait.
Dans ce cas, nous avons eu beaucoup de chance car nous avons pu ajouter des Regex au fichier robots.txt qui a dit à Google d’arrêter d’explorer ces URL. Il a fallu un peu de temps pour que Webmaster Tools s’installe, mais finalement tout s’est calmé.
10. Serveurs mal configurés
Ce numéro est en fait écrit par Tom, qui a travaillé sur ce projet client particulier. Nous avons rencontré un problème avec la page de destination/de connexion principale d’un site Web qui n’est pas classée. La page avait été classée et avait abandonné à un moment donné, et le client était perdu. Les pages avaient toutes l’air bien, bien chargées et ne semblaient pas faire de masquage pour autant que nous puissions voir.
Après de nombreuses recherches et recherches, il s’est avéré qu’il y avait un problème subtil causé par une mauvaise configuration du logiciel serveur, avec les en-têtes HTTP de leur serveur.
Normalement, un en-tête “Accepter” serait envoyé par un client (votre navigateur) pour indiquer les types de fichiers qu’il comprend, et très rarement cela modifierait ce que fait le serveur. Le serveur lorsqu’il envoie un fichier envoie toujours un en-tête “Content-Type” pour spécifier si le fichier est HTML/PDF/JPEG/autre chose.
Leur serveur (ils utilisent Nginx) renvoyait un “Content-Type” qui était un miroir du premier type de fichier trouvé dans l’en-tête “Accept” des clients. Si vous avez envoyé un en-tête d’acceptation commençant par “text/html”, c’est ce que le serveur renverrait en tant qu’en-tête de type de contenu. C’est un comportement particulier, mais cela n’a pas été remarqué car les navigateurs envoient presque toujours “text/html” au début de leur en-tête Accept.
Cependant, Googlebot envoie “Accept : */*” lorsqu’il explore (ce qui signifie qu’il accepte n’importe quoi).
(Voir : http://webcache.googleusercontent.com/search?sourceid=chrome&ie=UTF-8&q=cache:http://www.ericgiguere.com/tools/http-header-viewer.html)
J’ai découvert que si j’envoyais un en-tête */*, le serveur tombait car */* n’était pas un type de contenu valide et le serveur s’effondrait et envoyait une réponse d’erreur.
Changer l’agent utilisateur de votre navigateur en Googlebot n’influence pas les en-têtes HTTP, et des outils tels que le renifleur Web n’envoient pas non plus les mêmes en-têtes HTTP que Googlebot, vous ne remarquerez donc jamais ce problème avec eux !
Quelques jours après la résolution du problème, les pages ont été réindexées et le client a constaté une augmentation de ses revenus.
