Le SEO technique a le défaut d’être perçu soit comme trop simple, soit comme trop complexe. Entre un export des URLs en 404 et le paramétrage du cache serveur, il y a pourtant largement de quoi travailler pour repérer des problèmes sérieux sur un site. Voici 6 questions à se poser :
Contents
- 1 1 – Google voit-il bien la page web complète ?
- 2 2 – Google ne voit-il que les pages utiles du site ?
- 3 3 – Google considère-t-il bien le site comme compatible mobile ?
- 4 4 – Voyez-vous bien le même site que Google avec votre navigateur et vos outils ?
- 5 5 – Les différents sites pays se gênent-ils entre eux ?
- 6 6 – Les données structurées sont-elles une menace pour le site ?
1 – Google voit-il bien la page web complète ?
La Search Console nous gratifie d’un outil bien pratique, l’Outil d’inspection de l’URL (2e entrée dans le menu de gauche). Il permet de vérifier comment Google a vu la page à laquelle l’URL fait référence (ou la ressource, pour être plus précis) : 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 ? On l’oublie souvent, mais Google charge rarement l’ensemble des ressources d’une page lors de son passage (tous les scripts JS ne sont pas essentiels, certains proviennent de sites tiers qui les bloquent au robots.txt), ce qu’on peut mesurer via l’onglet “Plus d’infos” et l’information “Ressources de la page”.
L’outil d’inspection de l’URL propose en réalité deux fonctions :
- Index Google : relève de quelle manière Google a vu l’URL lors de son dernier passage.
- Test en direct : relève comment Google voit la page si on réalise un test ponctuel sur une URL à la fois. Ce test est identique aux autres outils de test de Google que sont ceux de Compatibilité mobile et d’Extraits enrichis.
Depuis bien 10 ans, les sites web sont de plus en plus dépendants du JavaScript pour la génération de leurs pages, et fortement côté navigateur. Si vous coupez le JavaScript dans votre navigateur, il est probable qu’une page web devienne inutilisable, voire vide de tout contenu. Google est largement en capacité d’exécuter le JavaScript, mais plus une page est légère en ressources, plus ça sera facile pour lui. Si une page est dépendante de trop de ressources, il y a un risque que Google ne les charge pas toutes et passe à côté d’éléments essentiels de la page.
Ces considérations prises en compte, on est donc confrontés à trois versions possibles d’une même page :
- le code HTML généré par notre navigateur – version idéale de la page, vue par les internautes (visible par les DevTools de Chrome, par exemple)
- le code HTML généré par Google lors d’un Test en direct par l’outil de test – version optimale de ce que Google charge réellement
- le code HTML généré par Google lors du passage réel de son robot d’exploration sur le site – c’est cette version que l’on doit étudier et surveiller
2 – Google ne voit-il que les pages utiles du site ?
Les rapports de Couverture de la Search Console sont une mine d’informations.
On a le réflexe de considérer qu’une URL en HTTP 200 (“OK”) est une bonne chose, et une URL en HTTP 404 (“Not Found”) est un problème. Comme souvent en SEO, il n’y a pas de réponse binaire, et une prise de recul est nécessaire. Il est probable que les problèmes de votre site se trouvent dans les pages valides plutôt que dans les pages exclues.
Prenons l’exemple d’un site e-commerce : il se compose principalement de pages de listings et de pages produit. Une page listing (Catégories, Sous-catégories) est susceptible de proposer des options d’UX à l’internaute, principalement des filtres (ex : par couleur) et des tris (ex : par prix).
a – Trop de pages = danger potentiel
Ce genre d’options peut générer des URLs parasites, quasiment infinies du fait des combinaisons d’options si ce n’est pas maîtrisé en SEO (ce qui donnerait exemple.com/chemises?couleur=Bleu&taille=XS). Le risque est de générer un nombre incontrôlé de pages inutiles au SEO, car faibles (trop de filtres donc peu de produits) ou dupliquées (produits identiques ordonnés 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 site, vous pourrez distinguer :
- Envoyée et indexée – les pages du sitemap
- Indexée, mais non envoyée via un sitemap – les pages hors sitemap et indexées
Le danger est donc dans cette seconde catégorie, malgré sa couleur verte rassurante. Ce qui ouvre vers des problématiques de pages stratégiques en SEO, voire de budget de crawl pour les sites de grande volumétrie.
b – Trop de 404 = c’est sans doute normal
D’un autre côté, un produit a un cycle de vie qui implique sa disparition du site à terme. Sa page sera naturellement passé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 normal pour un site.
Des URLs en 404 accessibles par des liens internes (détectables par le crawl d’un outil) sont par contre potentiellement intéressantes à corriger, afin d’éviter que les internautes n’aboutissent à une page d’erreur.
D’une manière générale, quel est le risque pour votre site que Google voie des URLs en 404 ? Aucun.
3 – Google considère-t-il bien le site comme compatible mobile ?
L’insistance de Google en SEO sur le sujet du mobile a atteint sa conclusion logique avec la mise en ligne de son index mobile : la qualité d’un site en SEO est évaluée selon sa version mobile. Il faut notamment s’assurer qu’il n’y ait pas de différences de contenu et de liens entre version desktop et version mobile.
Plus rare mais plus bloquant : Google peut considérer qu’un site n’est pas mobile. C’est en principe inconcevable pour tout site développé il y a moins de 6 ans. La plupart ont adopté la solution du Responsive Web Design (RWD) rendant un même site compatible en desktop et en mobile. C’est justement cette technologie qui peut être un piège : elle est gérée par des fichiers de ressources du site (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 site) 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 site qu’avec des éléments graphiques disproportionnés par rapport à une taille d’écran mobile et jugera le site non compatible. Heureusement, constater ce problème est simplissime (la Search Console remonte l’erreur, on peut tester une page via le Test d’optimisation mobile) et le résoudre en général relativement rapide.
Une page web est générée par un serveur web. Celui-ci répond à une requête à une URL qui contient les informations du demandeur, notamment : l’User-Agent pour identifier le type de demandeur (outil, navigateur, robot d’exploration) et l’adresse IP. Le serveur renvoie donc une réponse HTTP, accompagnée souvent d’une page web. Une réponse HTTP200 est accompagnée de la 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 :
a – Différence entre ce que voient vos outils SEO et ce que voit Google
Les outils d’analyse comme les crawlers (OnCrawl, Screaming Frog) ou les solutions SEO (SEMrush, ahrefs) peuvent être volontairement bloqués au niveau du serveur du site, généralement par leur User-Agent, Et c’est logique : un serveur contrôle qui peut accéder à son site, et les outils sont souvent très demandeurs – ils dedmandent souvent l’ensemble des pages du site, avec des vitesses très rapides. La profusion d’outils SEO cherchant tous à se créer leur propre index et à le maintenir à jour est une menace contre laquelle les sites sont légitimes à se défendre. En bref, avec leurs User-Agents propres ou en simulant Googlebot, les outils n’auront pas toujours la même réponse à une URL demandée.
On constatera par exemple qu’une page répond en HTTP503 dans un crawler alors qu’elle est bien vue et indexée par Google. Difficile d’analyser le site dans son ensemble avec cette contrainte (la solution est à discuter avec votre client, si le site concerné lui appartient), mais le site n’a pas un problème en SEO. La vision de l’outil n’est pas celle de Google.
Plus compliqué à analyser, un site 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 site identique pour lui et l’internaute), l’analyse de la performance SEO du site 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 différents sites pays se gênent-ils entre eux ?
Un site multilingue est souvent confronté à des problèmes de concurrence involontaire entre ses différents répertoires langues / pays. Si le site cible plusieurs pays avec une langue commune et des répertoires distincts, il est probable qu’il propose plusieurs pages identiques dans leur contenu, voire un répertoire entièrement identique. Si Google est confronté à deux pages au contenu identique, il n’en retiendra qu’une seule à indexer. Sans stratégie SEO internationale, les pages du répertoire le moins fort seront cannibalisées par celles du répertoire le plus fort.
Exemple : un site e-commerce cible la France et la Belgique, avec deux répertoires en langue française (exemple.com/fr-FR/ et exemple.com/fr-BE/). Le site est français à l’origine, et bien établi sur Google France. Le catalogue est identique à 95%, les fiches produit communes comportent le même texte. Il est très probable que les pages du répertoire français prennent le dessus et se positionnent sur Google Belgique au détriment des pages du répertoire belge. Les conséquences sont limitées pour des pays voisins partageant une devise, mais plus sérieuses si un océan les séparent (les Etats-Unis et le Royaume-Uni, par exemple).
On évite la plupart du problème grâce aux bases du SEO international : les balises hreflang permettent de distinguer deux pages identiques d’une même langue afin que Google puisse les indexer séparément et les servir dans les bons pays. Néanmoins, cette implémentation n’est pas toujours suffisante ou bien configurée, et une analyse des débordements entre répertoires pays est nécessaire pour dresser un état des lieux et proposer des solutions.
6 – Les données structurées sont-elles une menace pour le site ?
Les données structurées sont des métadonnées identifiant plusieurs éléments clés d’une page selon des formats définis. La finalité est une meilleure compréhension de la page par les moteurs de recherche, en échange de quoi ils génèreront des extraits enrichis dans leurs résultats de recherche. L’exemple phare est celui des données structurées relatives à un produit : on identifie son nom, son prix, sa disponibilité et sa note 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 test 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 note moyenne déficiente).
Plus grave, une implémentation valide à première vue peut cacher un loup. Certains CMS du marché se montrent très généreux dans leur balisage. On voit souvent des pages produit où sont balisés le produit principal mais également les produits associés, dont le nom et le prix sont affichés sur cette même page. Le produit principal est clairement identifié par le reste de la page (title, H1) mais les prix sont en vrac. Si on y réfléchit avec une logique et des mots courants, il est question d’un produit pour lequel on propose plusieurs prix. Dans cette profusion d’informations confuses, Google doit choisir un prix à afficher pour cette page dans les résultats de recherche, et a peu de chances de retenir le bon. On se retrouve donc avec des pages produit dans les SERP avec des prix incorrects : inférieurs ou supérieurs (par exemple si les produits associés sont de la même gamme, mais dans des capacités différentes). C’est sans conséquence pour les positionnements naturels de la page, mais déceptif 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 site, jusqu’à résolution du problème et demande de reconsidération de l’action 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 impact sur les positions).
L’abus le plus courant est une tentative de note moyenne appliquée à l’ensemble du site et affichée en footer. Le but recherché est d’afficher un grand nombre d’avis et une note moyenne flatteuse pour l’ensemble des pages du site, alors que ce ne sont pas les produits individuels en soi qui sont évalués. La pratique est trompeuse et va à l’encontre du bon sens : les données structurées doivent être uniques à une page et ne s’appliquer qu’à un élément à la fois. A la fois trompeuse pour les internautes et déloyales pour les concurrents, la pénalité est méritée.
Conclusion – l’audit c’est vous, pas les outils. On remarque que trois points de vue parallèles se confrontent lors d’un audit SEO : le vôtre, celui des outils dont vous vous servez et celui de Google. Les outils sont faillibles : ils sont plutôt là pour vous donner des données pour votre analyse, que vous devez vérifier vous-même, que de vous produire des recommandations. Restez au plus près du résultat final : ce que voit Google et comment il traite votre site.