Pages explorées par GoogleBot : Forte chute

[noren]

Bonsoir

Voila je viens de constater dans le GWT dans la section "Statistiques sur l'exploration" une assez forte chute des pages crawlés par googlebot depuis le 20 avril. je suis passé d'une moyenne de 1000 pages visitées à 400.

Avez vous constatez une chute également? qu'elles peuvent être les raisons d'une telle chute?
je n'ai par contre pas constaté de chutes de visiteurs.

 

[MikeR]

GGbot s'adapte au rythme de changement des pages.
La réduction du rythme d'exploration est un problème seulement si tes pages changent souvent.

 

[zeb]

Il faudrait avoir plus d'info pour savoir si c'est mauvais signe. Par exemple un site jeune est souvent fortement crawlé au début puis ça se clame quand GG a pris la mesure du site et de son évolution. Inversement si un site se met a ne plus trop publier, les crawls ralentissent au bout d'un moment, idem a l'inverse dans le cas contraire.

 

[noren]

le site en question à 7 ans, je publie environ 3-4 fois par semaine (parfois une ou 2 fois par jour), j'ai toujours gardé le même rythme
Des commentaires d'internautes sont également ajoutés chaque jour.

je soupçonne un problème serveur, j'ai de temps en temps dans la journée quand je navigue des "internal servor error" et googlebot m'a détecté dans le GWT 4-5 erreurs 500 (dans une courte période).

Mais je pense quand même pas que google réduirait autant les visites sous prétextes qu'il y a parfois une erreur 500 qui se glisse :? , surtout si le site est à 98% opérationnel.

Peut être qu'ils ont revu également l'algorythme du googlebot et que celui-ci repère plus facilement les pages qui sont le plus en mouvement!

 

[jolm]

Personnellement, je constate d'énormes mouvements googlebot (courbe qui plonge et remonte anormalement) sur plusieurs sites (thématiques différentes) ces derniers jours (voire 15 jours). A priori, ça sent l'update google ...

 

[zeb]

La piste du ralentissement suite aux erreurs 500 me semble plus crédible que celle des changement du bot. D'une part car des changements comme le signale Jolm j'en ai eu mais il y a un mois ou deux (c'est revenu a la normale depuis) et d'autre part car c'est pas la première fois que je constate que les bots sont très sensible a la qualité de réponse et vitesse de chargement des pages.

La piste publication et age du site est en effet a exclure je pense.

As tu fait des optimisation serveur (qui auraient foirées en l'espèce) ces derniers temps ? Note que ça peut être l'hébergeur qui t'a basculé sur une autre machine aussi et que les temps de réponse du site sont plus les mêmes (dans GWT il y a moyen de mettre en corrélation le nombre de page et les temps de réponse de façon assez imprécise certes mais ça peut donner un indice).

 

[noren]

Merci zeb pour ton aide.

Sur OVH ils ont ajouté fin avril des répartiteurs de charges sur les mutualisés. (peu de temps après j'ai eu ces problèmes d'erreurs qui apparaissent aléatoirement.
les répartiteurs ont d'ailleurs nettement amélioré les temps de téléchargement moyen d'une page , je suis passé de 400 o/s environ à 200 o/s

Normalement ça aurait du faire l'effet inverse sur le nombre de pages visitées par Googlebot :/

Depuis quelques jours j'ai plus d'une quinzaine d'erreurs suivante par jour dans mes logs serveurs :

[Thu May 02 23:51:03 2013] [error] [client ip] [host monsite] Premature end of script headers: xxxx.php

Et j'ai également constaté que depuis novembre 2012 à partir du moment ou j'ai perdu 50% de visiteurs de google j'ai pas mal d'erreurs suivantes dans mes logs serveurs :

[Thu May 02 22:17:24 2013] [error] [client ip] [host monsite] (9)Bad file descriptor: failed to stat mapfile, referer: xxxx.php

xxx.php = pages diverses et variées

je n'arrive vraiment pas à comprendre ses erreurs. D'autant plus que le site est opérationnel 98% du temps. Si ça venait de mon site (htaccess...) j'aurais constamment l'erreur 500 (qui correspond aux Premature end of script headers sur les logs)

Et je ne comprend absolument pas les "failed to stat mapfile"


Autre piste, j'ai mes fichiers PHP qui sont enregistrés en "western european cp 1152" (j'utilise l'éditeur komodo et je me suis rendu compte qu'il mettait ça par défaut) et j'utilise sur mes pages et ma BDD l'encodage UTF-8.
Est-ce que ça pourrait être la cause de ces erreurs serveurs aléatoires? (J'ai un doute mais bon, je balance mes pistes)

 

[zeb]

Il y a un jeu d'erreur similaires ici Et la solution proposé (augmentation du "execution and input time") me semble un emplâtre sur une jambe de bois (même si ça peut fonctionner).

les répartiteurs ont d'ailleurs nettement amélioré les temps de téléchargement moyen d'une page , je suis passé de 400 o/s environ à 200 o/s

C'est a ranger dans la série de mesure que prend OVH en ce moment pour désengorger il me semble. En revanche je me demande si ce changement de répartiteur qui induit des temps de réponse plus rapides n'est pas assorti d'une réduction du temps machine alloué a chaque script (cf ci dessus), ce qui aurait un effet bénéfique en pénalisant les scripts lourds, mais qui plomberait définitivement les scripts un peut "limite". Il faudrait regarder le poids du traitement que tes pages "Premature end of script headers: xxxx.php" occasionnent.

Après c'est assez difficile de trouver un truc pertinent sur "failed to stat mapfile" mais je me demande si les deux ne sont pas liés. Quoi qu'il en soit il y a pas mal de soucis du même genre sur le forum OVH autour de solutions prestachop. Est ce ton cas?

 

[noren]

Pour le "execution and input time" je suis moyennement chaud, je préfèrerais éviter pour le moment

J'ai fait l'analyseur de script (analyseur proposé par OVH) de ma page d'accueil qui rencontre aussi parfois ce probleme de "premature blablabala..."

J'ai obtenu ceci :

Utilisation cpu (%) 40
Utilisation ram (ko) 40096
Nombre de fichiers lus 17
Nombre de fichiers écrits 0
Temps d'execution 0:00.17
Taille du résultat (ko) 2200
Nombre de liens externes html 0
Nombre de requêtes externes du script 1
Nombre de select sql 6
Nombre d'update sql 0
Temps d'exécution sql (secondes) 0.007
Temps d'éxecution de la requête sql la plus longue (secondes) 0.005

Il me semble pas que ça soit très gourmand.

Après je ne sais pas comment regarder le poids du traitement de mes pages :/

J'avais constaté également que beaucoup d'utilisateur de prestahop avaient les mêmes problèmes. Dans mon cas je n'utilise pas prestashop, il ne s'agit pas d'un site ecommerce.Je n'utilise d'ailleurs aucun CMS, et je pense faire des scripts assez légers (mais bon surement pas parfait non plus)

je dois avouer que mes compétences web ne vont pas aussi loin et je ne maitrise absolument pas toutes ces erreurs serveurs :?

 

[noren]

Personne n'a de petites pistes? (j'arrive a trouver aucune info sur internet :/)

PS : j'ai contacté il y a quelques jours le support d'OVH mais actuellement je suis sans réponse de leur part!

 

[david_WRI]

pour info j'ai eu le même problème : je suis passé de 300 000 en moyenne à 20 000 le 22 avril
Pourtant rien n'a changé !

 

[zeb]

doit on rapprocher ça de ce qui c'est passé un mois plus tard ?

 

[noren]

En effet zeb, c'est fort probable.

Vraiment étrange que les c'ets seulement un mois après qu'on en voit les conséquences.
C'est tout aussi étrange que ce phénomène ou on se voit fortement monter dans les SERPS pendant quelques jours (voir semaines) avant de subir la méga chute

 

[jolm]

Peut etre que le crawl est plus "intelligent" qu'avant, dans le but de reduire la charge des bots (et donc la facture pour gg) ?

 

[noren]

Dans un sens ça rassurerait mais j'ai des doutes, tout le monde aurait constater ce phénomène, surtout que ça a été assez brutal :wink:

 

[david_WRI]

Pour info : https://www.webrankinfo.com/forum/forte-chute-pages-explorees-googlebot-t16 ... l#p1441757
mais j'ai pas de soluce encore

 

[noren]

il n'y a pas vraiment de soluce, a part poster souvent, et être considéré comme un bon site
on a malheureusement aucun pouvoir la dessus.