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 :
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.
b – Différence entre ce que vous voyez dans le navigateur et ce que voit 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 – Votre pagination est-elle fonctionnelle ?
La pagination permet aux moteurs de recherche et aux internautes de découvrir tous les contenus d’un site ou d’une catégorie, sans avoir à tous les afficher sur une même page. Elle doit être conforme aux bonnes pratiques de pagination documentées assez clairement par Google mais malgré ça, les experts SEO peuvent avoir des avis divergents.
La version recommandée d’une pagination est :
- Pages autorisés au crawl et à l’indexation
- Pages nommés comme pagination
- La page d’origine est la page 1
Dans le détail :
Pages autorisées au crawl et à l’indexation
Autoriser la pagination au crawl implique de ne pas bloquer le pattern d’URL de la pagination par le robots.txt. Comment voulez-vous que Google voit les liens vers les pages uniquement accessibles par la pagination ? Exemple de directive à éviter : Disallow: *?page=*
Autoriser la pagination à l’indexation implique de considérer ces pages comme des pages uniques, donc appliquer des consignes techniques comme à une page que l’on voudrait valoriser en SEO. C’est à dire :
On doit donc la laisser indexable (pas de <meta name= »robots » content= »noindex, nofollow »>) : une page crawlable mais non indexable sera vue une première fois par Google, mais ignorée à la longue pour accorder de l’importance aux pages déclarées utiles du site. Les liens qu’elle contient seront eux aussi ignorés mécaniquement, et leurs pages de destination sans valeur. Quand vous achetez un backlink, est-ce que vous accepteriez d’acheter un article sponsorisé en noindex ?
Dans la même logique, chaque page de pagination doit avoir une balise rel=canonical autoréférentielle. Une balise canonical a pour but de signaler plusieurs pages au contenu identique (par exemple des variantes de produits). Par définition, des pages de pagination listent des articles/produits entièrement différents entre elles, elles ont donc un contenu unique.
Pages nommées comme pagination
Bien que Google indique que » Vous pouvez utiliser les mêmes titres et descriptions pour toutes les pages de la séquence« , par sécurité on nommera les pages par leur numéro dans leur <title> afin de bien les distinguer et éviter les ambiguïtés côté Google, qui n’est pas infaillible.
Exemple : SEO Technique Archives • Page 2 sur 3 • SEOlivier
La page d’origine est la page 1
Votre pagination va créer un bloc de liens. Le lien sur le chiffre 1 va s’afficher à partir de la page 2. Ce lien vers la première page de la séquence doit être vers l’URL sans pagination, et non une catégorie?page=1 qui créerait une page dupliquée avec la catégorie d’origine et ferait perdre à cette dernière tout le poids des liens de la pagination.
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.
