5 éléments majeurs à contrôler en SEO technique

Referencement

SEO / Referencement 207 Views comments

1 - Google voit-il bien la page net complète ?

Depuis bien 10 ans, les websites net sont très dépendants du JavaScript pour la génération de leurs pages. Google est en capacité d’exécuter une web page avec toutes ses ressources, mais plus une web page est légère, elle a de possibilities d’être chargée en entier. A l’inverse, le risque est qu’il passe à côté d’éléments essentiels de la page si elle est trop lourde (zones de contenu, liens).

L’outil d’Inspection de l’URL de la Search Console permet de vérifier remark Google a vu la web page : le code HTML généré est-il bien le même que ce qu’on a dans notre navigateur, les ressources utiles (CSS et JS essentiels) sont-elles bien chargées ?

L’outil d’inspection de l’URL suggest en réalité deux fonctions :

  • Index Google : montre la web page telle que Google l’a indexée.
  • Check en direct : montre comment Google voit la web page dans des circumstances idéales, en chargeant le maximum de ressources.

Attention donc à étudier vos pages à travers la version adaptée à votre analyse.


2 - Google ne voit-il que les pages utiles du website ?

On a la mauvaise habitude de considérer qu’une URL en HTTP 200 est une bonne selected, et une URL en HTTP 404 est un problème. Comme souvent en search engine optimization, il n’y a pas de réponse binaire, et une prise de recul est nécessaire.

Prenons l’exemple d’un website e-commerce : il se compose principalement de pages de listings (catégories) et de fiches produit.

Une web page listing (Catégories, Sous-catégories) est prone de proposer des options d’UX à l’internaute comme des filtres (couleur) et des tris (prix).

Ces choices génèlease souvent des URLs avec paramètres quasiment infinies du fait des combinaisons d’options (ce qui donnerait exemple.com/chemises?couleur=Bleu&taille=XS). Le risque est de laisser accesible à Google un nombre incontrôlé de pages inutiles au search engine optimisation, automotive faibles (trop de filtres donc peu de produits) ou dupliquées (produits identiques ordonnées différemment).

Surveillez donc dans la Search Console le nombre de pages “Valides” (vertes). Encore mieux, si vos sitemaps sont proprement configurés pour ne contenir que les pages utiles et connues de votre website, vous pourrez distinguer :&

  • Envoyée et indexée - les pages du sitemap
  • Indexée, mais non envoyée by way of un sitemap - les pages hors sitemap et indexées

Le hazard est donc dans cette seconde catégorie, malgré sa couleur verte rassurante.

L'écart est assez alarmant.

D’un autre côté, un produit a un cycle de vie qui implique sa disparition du website à terme. Sa web page sera naturellement moveée en HTTP 404, qui s’ajoutera aux autres produits disparus récemment - donc au rapport de Couverture de la Search Console sur les URLs Exclues - Introuvable (404). Au même titre que les feuilles mortes qui s’accumulent au pied d’un arbre en automne, c’est un comportement regular pour un website. Et d’une manière générale, quel est le risque pour votre website que Google voie des URLs en 404 ? Aucun.

3 - Google considère-t-il bien le website comme suitable cellular ?

La fixation de Google en web optimization sur le sujet du cellular a abouti à la mise en ligne de son index cellular : la qualité d’un website en search engine optimisation est évaluée selon sa model cellular. Il faut notamment s’assurer qu’il n’y a pas de différences de contenu et de liens entre version desktop et version cellular.

On rencontre parfois un problème plus rare mais plus critique : Google peut considérer qu’un website n’est pas cellular. La plupart des websites sont en Responsive Net Design (RWD) rendant un même website suitable en desktop et en cellular. C’est justement cette technologie qui peut être un piège : elle est gérée par des fichiers de ressources du website (principalement le CSS) qui peuvent être bloqués à Google involontairement.

On retrouve parfois dans le robots.txt (fichier indiquant à Google ce qu’il peut voir ou non sur un website) des consignes bloquant les ressources nécessaires au Responsive Design, souvent dû à un legacy d’ancien CMS (ou de robots.txt gérant plusieurs répertoires sous des CMS différents). Google ne pourra alors générer les pages du website qu’avec des feuilles de type incomplètes et jugera le website non suitable. Heureusement, constater ce problème est simplissime (la Search Console remonte l’erreur, on peut tester une page by way of le Check d’optimisation cellular) et sa réanswer en général relativement rapide.

4 - Voyez-vous bien le même website que Google avec votre navigateur et vos outils ?

Une page web est générée par un serveur net. Celui-ci répond à une requête à une URL qui contient les informations du demandeur, notamment : l’Consumer-Agent pour identifier le sort de demandeur (outil, navigateur, robotic d’exploration) et l’adresse IP. Le serveur renvoie donc une réponse HTTP, accompagnée souvent d’une web page net. Une réponse HTTP200 est accompagnée de la web page demandée, une réponse HTTP404 ou HTTP500 ne l’est pas.

En bref, certains sites répondront différemment selon qui fait la demande. Ce qui pose deux problèmes majeurs :

  • Google et vos outils ne voient pas la même page. Les outils d’analyse comme les crawlers (OnCrawl, Screaming Frog) ou les solutions search engine marketing (SEMrush, ahrefs) peuvent être volontairement bloqués par le serveur du website. Soit par leur Consumer-Agent, soit par leur adresses IP lorsqu’ils simulent Googlebot. Les outils n’auront pas toujours la même réponse à une URL demandée selon leur configuration.
Plantage du website, ou blocage de l'outil ?
  • Google ne voit pas la web page comme vous la voyez dans votre navigateur. Un website peut se comporter différemment pour Google et pour l’internaute. Au-delà du risque que ce soit considéré comme une pratique trompeuse par Google (qui demande un website identique pour lui et l’internaute), l’analyse de la performance search engine optimisation du website sera d’autant plus compliquée.

Un exemple courant est le statut en ligne de pages qui sont redirigées pour l’internaute : une page exemple.com peut exister pour Google mais être redirigée vers exemple.com/fr_FR/ pour l’internaute, du fait de la langue de son navigateur et de ses cookies (ce dont ne se sert pas le robot d’exploration de Google).

5 - Les données structurées sont-elles une menace pour le website ?

Les données structurées sont des métadonnées identifiant plusieurs éléments clés d’une web page selon des formats définis. La finalité est une meilleure lecture de ces éléments par les moteurs de recherche, en échange de quoi ils génèlease des extraits enrichis dans leurs résultats de recherche. L’exemple phare est celui des données structurées family members à un produit : on identifie son nom, son prix, sa disponibilité et sa observe moyenne, et ces éléments s’afficheront pour cette page dans les résultats de recherche.

Malgré la grande précision de la documentation des données structurées (par Schema.org et Google) et les outils de check de leur implémentation, les erreurs restent courantes, même parmi les CMS les plus avancés du marché.

Dans le meilleur des cas, une mauvaise implémentation les rend partiellement inopérantes - l’élément en cause ne génèrera pas d’extraits enrichis sans bloquer les autres (un prix bien balisé ne sera pas bloqué par une notice moyenne déficiente).

Plus grave, une implémentation valide à première vue peut nuire au website. Certains CMS du marché se montrent très généreux dans leur balisage : des pages produit où sont balisés le produit principal mais également les produits associés (en cross-sell). Le produit principal est clairement identifié par le reste de la web page (title, H1) mais les prix sont multiples. Google doit choisir un prix à afficher pour cette web page dans les résultats de recherche, et a peu de possibilities de retenir le bon. On se retrouve donc avec des pages produit dans les SERP avec des prix incorrects : inférieurs ou supérieurs, déceptifs pour l’internaute.

Le cas le plus sérieux et malheureusement pas si rare concerne les pénalités manuelles de Google. Une implémentation considérée comme abusive vis-à-vis des pratiques autorisées par Google quant aux données structurées amènera à un retrait complet des extraits enrichis pour le website, jusqu’à réanswer du problème et demande de reconsidération de l’motion manuelle (ensuite validée par une personne physique). Des cas récents ont pris 2 mois à être reconsidérés, pendant lesquels les sites concernés étaient désavantagés dans les SERP vis-à-vis des concurrents (visuellement uniquement, sans impression sur les positions).

Comments