Search Console crawle et indexe des page bloquées par robot.txt

nza2k · 16 Mars 2018

Bonjour tout le monde,

Sur la nouvelle version de Google Search Console, très prometteuse au demeurant, j'ai une centaine d'avertissements me prévenant que Google a décidé de crawler et indexer des pages qui sont pourtant bloquées par le robots.txt

C'est très ennuyeux, car dans le tas, il y a beaucoup d'url qui ne correspondent pas à de vraies pages mais des contenus html appelés en Ajax (je ne peux donc pas mettre de meta robots.txt sur ces contenus html).

=> Google gaspille sont budget crawl et indexe du contenu de faible qualité.

Voyez-vous comment prévenir cela ?

Un exemple : http://www.avygeo.fr/top-destinations/incontournables/europe/france/ile-de-france/paris

Le fait de changer l'ordre de tri via le menu déroulant apparaissant au dessus de la liste actualise la page sans la recharger en injectant le contenu de http://www.avygeo.fr/top_destinatio...ntournables/europe/france/ile-de-france/paris

Merci par avance pour votre aide

Madrileño · 16 Mars 2018

Bonjour,

Google et les autres moteurs, ne vont pas toujours suivre les directives du fichier robots.txt .
Il faut bloquer l'indexation via la page ou changer le système que vous utilisez.
Vous pouvez aussi bien ajouter une balise noindex (cf. 2017), qu'un header adéquat.

Complément : Google : crawl et indexation malgré interdiction via fichier robots.txt

Temps de réponse : 7 minutes.
Cordialement.

nza2k · 16 Mars 2018

Merci pour ce retour Madrileño, toujours aussi réactif 14 ans après

Les contenus html appelés en Ajax n'ont pas de <head>, et si j'en ajoutais un avec une meta noindex, j'ai peur du conflit puisque cela voudrait dire que la page parente qui charge ce contenu va se retrouver avec 2 <head> (pas propre), dont un avec une meta noindex (est-ce que ça ne va pas désindexer la page parente ?).

Personne n'a rencontré ce genre de situations avec des formulaires actualisant le contenu d'une page à la volée ?

cthierry · 17 Mars 2018

Dans ce cas la balise canonical de la page par défaut devrait faire l'affaire je pense.

Et oui, pour répondre à ta dernière question, il a trouvé le moyen de m'indexer des pages bloquées, des pages de redirections, des pages de validation de soumissions... qui étaient bloquées par le robots.txt. Du coup il a fallu mettre les mains dans le code. Et je te parle pas de Bing

, car là on peut faire un autre chapitre complet.

nza2k · 22 Mars 2018

Merci pour ton témoignage Cthierry,

Pour bien comprendre, tu suggères d'ajouter un <head> dans le code html appelé en Ajax et d'y injecter une meta canonical pointant vers la page parente ? Tu as constaté une amélioration de ta visibilité en faisant ça ?

cthierry · 22 Mars 2018

Oui mais de mon coté j'ai modifié le comportement de ces pages pour ne plus qu'elles soient indexées, ce qui n'a rien à voir avec canonical. Dans ton cas il s'agit que la page parente reste la seule page indexée, donc je pense que canonical est une bonne idée. Si d'autres Wrinautes ont un autre avis ...

eldk · 1 Avril 2018

Bonjour,

Pour ma part le même soucis : j'ai reçu ce matin, un mail m'indiquant cela :

`
La Search Console a déterminé que votre site est affecté par 1 nouvelle
erreur en lien avec Couverture de l'index. Cela signifie que Couverture de
l'index peut subir des conséquences négatives dans les résultats de
recherche Google. Nous vous encourageons à examiner et à corriger ce
problème.
`

Le domaine a plus de 15 ans, le fichier robots.txt n'a pas été modifié depuis ... l'ancienne Search Console n'indique aucune erreur dans pages bloquées, les sitemaps établis pour suivre l'indexation des pages ne montrent aucun changement. La nouvelle n'indique pas de pages bloquées par robots.txt - pas d'intitulé correspondant dans la colonne raison; aucune erreur dans la console de vérification du fichier robots.txt.

Cependant, sur les 2 mots clefs principaux (recherche sur 1 mot) concernant le thème du site (pas ceux qui amènent les visiteurs), c'est la chute, à pic, depuis 2 jours.

Je mets un allow sur tout et laisse l'IA se dépatouiller. Peut-être qu'elle parviendra à comprendre le message et trouvera une solution.

Si elle n'y parviens pas, assez rapidement, je met un disallow pour mon très cher ami.

Cordialement,

Eric

PS : Un nouveau bouton est apparu dans la nouvelle Search Console : recrawl now : humour ...?

cthierry · 1 Avril 2018

eldk a dit:
PS : Un nouveau bouton est apparu dans la nouvelle Search Console : recrawl now : humour ...?

Mouarffffffffff du 1er avril => Never Gonna Give You Up / Je ne t'abandonnerai jamais

eldk · 2 Avril 2018

Bonjour,

La nouvelle search console indique la page qui a provoqué l'envoie de l'alerte mail : il s'agit de la page de connexion au backoffice du site (site participatif). Un lien vers celle-ci est présent sur chaque page du site.

Le webmaster "affecté" par une telle alerte verra apparaître la/les page(s) concernées dans le segment "valides avec des avertissements" avec la motivation "Indexée malgré le blocage par le fichier robots.txt".

L'url de cette page est de la forme https://domain.tld/repertoire/.

Une des solutions semble donc d'ajouter un noindex sur cette page (ce que signale déjà le fichier robots.txt - depuis toujours avec disallow ).

Mais quid des liens en partie publique : comment serait interprété un lien en nofollow présent sur chaque page du site ?

Il ne s'agit ni d'un lien sponsorisé, ni d'un lien "sitewide" ... visant à artificiellement multiplier les liens vers celle-ci : aucun intérêt.

Cordialement,

Eric

cthierry · 2 Avril 2018

Solution toute simple à mettre en oeuvre :
https://support.google.com/webmasters/answer/96569?hl=fr

Tout en sachant qu'il y a la réponse sur WRI mais un peu la flemme de chercher en fait

eldk · 2 Avril 2018

Merci, vais chercher

eldk · 2 Avril 2018

Après vérification, seul le nofollow sur les liens vers cette page en partie publique "manquerai".

La page vers laquelle les liens "sitewide" dirige (indexée malgré le disallow dans le robots.txt), contient déjà la méta :

```
<meta name="robots" content="none"/>
```

ref : https://webmasters.googleblog.com/2007/03/using-robots-meta-tag.html

cthierry · 2 Avril 2018

C'est la réponse qui se trouve dans le lien que je t'ai donné plus haut

Madrileño · 3 Avril 2018

Bonjour,

cthierry a dit:
Mouarffffffffff du 1er avril

Ce topic c'est aussi le premier avril.

Temps de réponse : 2 minutes.
Cordialement.

eldk · 4 Avril 2018

>C'est la réponse qui se trouve dans le lien que je t'ai donné plus haut

Merci, j'ai bien compris

.

En principe, il faut donc, si l'on ne veut pas voir apparaître cette alerte de Google :

A.
1 - mettre le lien vers les pages d'incription en nofollow.
2 - ajouter une <meta name="robots" content="none"/> sur la page de destination.

B.
Laisser Google crawler ces pages en ne les bloquant pas :
1 - pas de blocage dans le fichier robots.txt
2 - pas de A.

J'avais mis le second lien pour préciser le sens de la balise <meta name="robots" content="none"/>.

Et signaler que cela ne semble pas être suffisant.

Pour ma part, j'applique A.
Je verrai ce que Google en fait.

Cordialement,

Eric

eldk · 5 Avril 2018

Bonjour,

Un autre lien concernant la façon de procéder (éliminer la page de l'index) :

https://support.google.com/webmasters/answer/7489871?hl=fr

Il est bien précisé que le noindex, ou none (noindex+nofollow), qui signifie ne pas indexer le contenu de cette page et ne pas suivre les liens qu'elle contient est suffisant.

Je me demande donc bien pourquoi, alors que :

1 - le fichier robots.txt interdit l'indexation de ce dossier depuis ... au moins 2005
2 - la page contient la meta none depuis ... la même date

Cette "erreur" apparaît.

Autre constat, depuis début mars, les bots Google, crawlent (ou tente de crawler) :

1 - des pages dont l'url est composée de sous-dossiers combinés
ex :
a - domain.tld/dossierA - ce dossier existe bien
b - domain.tld/dossierB - ce dossier existe bien
-> domain.tld/dossierA/dossierB - ce dossier n'existe pas (404)
-> domain.tld/dossierB/dossierA - ce dossier n'existe pas (404)

2 - des liens "olé olé" et supprimés depuis ....
domain.tld/dossierExistant/ol-ol.html (lien correct : domain.tld/dossierExistant/ole-ole.html) - ces "mauvais liens" - scrapping - reprenaient le titre de la page et supprimaient les accents des urls en raison de l'encodage. Ces liens sont désavoués depuis ... Une redirection 301 vers le bon article fonctionne toujours pour celles-ci, mais elles n'avaient pas été crawlées depuis ... Ces sites ayant disparus.

Je pense donc que de "vieux" index sont de sortie ou on été "réinjectés" dans le circuit (2).

Pour le (1), une vérification de la structure du site, recherche de "multiplication" de pages, de contenu artificiel (comment pousser mémé dans les orties, comment pousser pépé sans les orties...) ?

Cordialement,

Eric

eldk · 25 Avril 2018

Bonjour,

Reçu ce jour par mail:

``Nous avons validé votre correction des problèmes de type Couverture de
l'index pour le site http://domain.tld. Le problème
spécifique validé correspondait à l'identifiant "Indexée malgré le blocage
par le fichier robots.txt".``

Cordialement,

Eric