La Search Console de Google vous indique quelles sont vos ressources (fichiers images, Javascript ou Feuilles de style) bloquées, gênant l'analyse de vos pages par les algorithmes du moteur de recherche. Pourquoi faut-il les débloquer et comment faire ? Voici une petite méthodologie simple pour cela...
Google demande, pour de nombreuses raisons (analyse du rendu de la page, lutte contre le spam notamment) d'avoir accès à de nombreuses ressources sur une page web : fichiers Javascript, images et feuilles de style (CSS). Sous peine de voir ces pages moins bien analysées. La Search Console vous aide ainsi à détecter les ressources actuellement bloquées (la plupart du temps par un fichier robots.txt, sur votre site ou sur un site distant). Voici comment détecter ces problèmes, si votre source d'informations en a de semblables, et comment les résoudre :
SEO : Débloquez vos ressources - Vidéo proposée par Olivier Andrieu (Abondance). Source de l'image : Abondance |
Voici quelques vidéos déjà publiées sur un sujet connexe :
- Fichier robots.txt et SEO (31 janvier 2017).
- Nouveau Site Web et Compte Search Console (6 juin 2017).
Voici également quelques articles complémentaires (listés par ordre chronologique) pour approfondir le sujet :
- Google propose un générateur de fichier robots.txt (28 mars 2008).
- Le fichier robots.txt OK, mais connaissez-vous Humans.txt ? (9 juillet 2012).
- Google signale lorsqu'une description est bloquée par un fichier robots.txt (20 août 2012).
- Google ne crawle pas votre site si votre fichier robots.txt n'est pas disponible (6 janvier 2014).
- Plaidoyer pour une nouvelle directive Noindex: dans le robots.txt (3 février 2017).
- Google a modifié son mode de lecture des fichiers robots.txt (25 février 2016).
Etc.
N'hésitez pas également à visiter la zone "Vidéos SEO" du site et à vous abonner à la chaîne YouTube du site Abondance (ou à son fil RSS) pour découvrir, semaine après semaine, les prochaines vidéos que nous vous proposerons.
Google a une sale manie de re-crawler les pages qu’il a indexé sans vérifier au préalable les pages ayant des liens pointants. Les pages supprimées réappraissent en erreur 404 avec une liste de liens pointant qui n’existe pourtant plus depuis presque 1 an.
Sur des gros site comme le notre de 10 millions de pages, cela conduit a effacer des erreurs internes par centaine de millier, sous domaine par sous domaine, puisque les 1000 catégories sont chacune en sous domaine.
C’est un problème récurent de la Search Console depuis plusieurs années qui est bourrée de bug et mal conçue pour les professionnels. Nous avons toujours des retours a nouveau d’erreur de http et https du genre : « 63-puy-de-dome-dept/https//elevage.annuairefrancais.fr/63-puy-de-dome-dept/index-8.html » , nous avons vérifié et passé de nombreux outils et aucun lien ne semble mal formé, hormis une erreur ponctuelle de notre part en FEVRIER 2017 que nous avons rectifié immédiatement .
Le retour de ces erreurs de FEVRIER 2017 dans la search console démontre que Google réutilise des pages crawles vieilles de presque 1 an … Bravo !
Ce serait une petite boite, on comprendrait, mais là, c’est ce moquer du monde a laisser un outil aussi « pourri » en service.
Merci pour cette vidéo Olivier.
Une petite remarque : sauf erreur de ma part, tu ne mentionnes pas dans la vidéo que le fait de bloquer certaines ressources peut aussi être quelque chose de volontaire (ce qui peut porter à confusion…) 😉
C’est-à-dire ?
Je veux dire que le fait de constater que certaines ressources sont bloquées n’est pas forcement quelque chose d’alarmant.
Cela peut-être volontaire, si on souhaite bloquer l’indexation de certaines pages notamment : pages dupliqués, espaces persos, admin…
Oui, mais là, on parle de ressources (JS, CSS? images), pas de pages web du site. Non ?
Ah effectivement désolé, mais il ne faudrait pas sous entendre que je n’ai pas eu une écoute assidue 🙂
Bonjour,
En vérifiant, il n’y a généralement pas de problème de ce côté la.
Par contre, concernant les robots.txt générés par Prestashop, de nombreuses pages (et non langages) sont bloqués (private pages, modules, tolls, adresses, paniers…).
A priori, rien de gênant à bloquer ces pages qui sont elles logiquement privées si ?
L’idée est de ne pas débloquer tous les fichiers bloqués par le robots.txt standard, mais uniquement ceux qui ont une incidence forte pour l’analyse des pages par Google.
C’est bien ce qu’il me semblait, merci pour le retour.