Les pages 404 avec googlebot

[Fred]

Bonjour,

Depuis de nombreux mois je rencontre des problèmes de temps de téléchargement de page sur GSC (entre 400 ms et 900 ms pour les extrêmes). Pourtant lorsque je fais un test en live avec google insight plusieurs fois dans la journée, sur différentes pages j'ai toujours une excellent note (entre 90 & 100 sur mobile).

Parfois j'ai les temps de téléchargement qui baissent pendant quelques jours jusqu'à 160 ms, puis remontent ensuite régulièrement jusqu'à osciller de nouveau en 400 et 900 ms.Les oscillations sont importantes alors que les tests donnent toujours la même note sur google insight à +/- 1 point.

De même le test complet avec un crawler genre RMTech ou Xenu donne d'excellent temps de téléchargement. Les tests avec pingdom ou gtmetrix confirment ces performances.

Auparavant j'étais sur un hébergement mutualisé et c'était pire. Depuis j'ai migré sur un VPS, j'ai supprimé beaucoup d'extensions Wordpress, et le site est désormais hébergé seul sur un VPS largement dimensionné. Il comporte en 18 extensions, dont Yoast Seo, Woocommerce & WP-Rocket.

WP Rocket me donne satisfaction. J'émets cependant des doutes à causes des 404 que trouve googlebot qui indexe tout ce qui se trouve dans le dossier de cache. Je n'ose pas lui en interdire l'accès via le fichier robots.txt car je pense que s'il les indexes, c'est qu'il en a besoin.

Pour donner une idée des proportion de pages 404, voici les stats de logs google pour une journée type :

- code 20x : 469 (40 %)
- code 30x : 95 (8 %)
- code 40x : 616 (52 %)

- 1 Les temps de téléchargement de page indiqués sur GSC prennent-ils en compte les pages 404. Une page 404 génère plus de temps de traitement qu'une page qui retourne un code 200, et peut-être est-ce la cause de ces temps importants.

- 2 Peut-on mettre le dossier de cache en 410 dans l'extension de redirection ou l'interdire via Robots.txt
- 3 Quelqu'un voit-il une autre raison qui puisse provoquer ces mauvaises performances alors qu'en testant en direct tout semble parfaitement normal.

L'url du site si vous souhaitez jeter un oeil : www.transfert-films-dvd.com

 

[Ehplodor]

Slt,

Je dirais qu'il faudrait tout d'abord que tu traite se problème de 404.
Pourquoi un si grand nombre de page en 404 ?
Quelle bug les créé ?

Si c'est des pages supprimée suite à un nettoyage, c'est soit une redirection 301 vers la nouvelle ressources, soit une 410.
Mais pas de 404.

T'as question 2 est vraiment très étrange...

 

[Fred]

C'est l'extension de cache de wordpress qui génère de fichier temporaires. Googlebot indexes les pages et en même temps les fichiers de cache temporaire.

Quand google cherche à crawler de nouveau ces fichiers ils ont disparu et cela génère un très grand nombre de 404.

 

[Ehplodor]

C'est l'extension de cache de wordpress qui génère de fichier temporaires.

Quel type de fichier ?
Quel intérêt de créer des fichier temporaires ?

Je ne comprend pas le fonctionnement de ton système de cache.

 

[Fred]

Ce sont les .css et les js. Mais ce n'est pas le problème de fond. Le problème c'est que google réclame ces ressources pour des pages qui ont

• soit disparues (404),
  
• soit qui sont passées en https : ca fait plus d'un an que je suis intégralement en https !

Google ne crawle pas la page directement. Il a la page http dans son cache et comme il y a des liens de ressource externe dans le code de la page (des fichiers .js et .css) il les demande. Comme la page ne répond pas en 404, mais en 301 puisqu'elle est redirigée vers la nouvelle page https, il ne l'efface pas de son index et continu de réclamer des ressources qui n'existent plus.

Selon moi voici comment ca se passe :

• Googlebot réclame le fichier :
  

  GET /wp-content/cache/min/1/wp-content/plugins/woo-phone-input-plugin/css/intlTelInput-915a88bfcf3bda6bdd8a8fa954291b48.css

  l'extension et le css n'existe plus depuis longtemps.
  
• Googlebot indique que l'url où il a trouvé ce .css est :
  

  http://www.transfert-films-dvd.com/transfert-numerisation/numerisation-video/numeriser-cassette-vhs/conversion-vhs-html/conversion-vhs-en-dvd/

  .
  • Cette url est redirigée en https si on la demande directement.
    
  • En vérifiant dans le cache google on voit bien que la redirection est correcte.
    
  • Pour googlebot, cette url http est valable et il demande les ressources qu'il trouve dans le code.
• Le serveur lui retourne une 404 concernant la ressource demandée.
• Et comme c'est simplement un lien qui est dans le code de la page http qu'il a enregistré il y a plus d'un an (sic !), et que le lien est redirigé.

Quand la page existe et n'est pas redirigée, google la recrawle et il rafraichit son cache. Les ressources périmées externes à la page n'apparaissent plus dans le code.

Dans ce cas, le problème ce sont des pages redirigées et google ne peut pas rafraichir leur contenu étant donné qu'on lui sert la nouvelle url avec un code 301. La vieille url avec un contenu périmé reste en cache.

Pour moi c'est un joli bug google !

 

[Ehplodor]

Re,

"il ne l'efface pas de son index"
... mais il devrait la mettre à jour.

Donc, je dirais, pour ne pas se prendre le chou... interdire à GG de mettre en cache.
Il va supprimer son cache.
Dés que tu ne remarques plus d'erreur de crawl, tu supprime l'interdiction.

 

[Fred]

Mais l'url en http n'existe plus. La seule chose que je peux mettre en noindex c'est la version https.. Donc elle va disparaitre des résultats de recherche.

hum hum nous sommes justement sur un forum seo qui est destiné à nous aider à nous positionner sur google, pas à nous en faire disparaitre.

Google ne demande pas la page http, il y fait juste référence quand il demande la ressource avec un GET qui ne spécifie qui ne précise le http ou le https.

La requête GET ne précise la racine du site. Pour mon serveur il s'agit d'une ressource en https, alors que google fait référence à une ressource en http. Au moment où il a mis en cache l'url de cette ressource le site était en http. Les requête GET ne précise jamais la racine du site, c'est toujours une url relative (url-racine-du-site-http-ou-https://)\wp-content\cache...

L'url de référence n'a aucune importance, c'est une indication pour les logs du serveur. Le serveur n'utilise pas cette information, mais elle est utile pour un humain qui examine les logs par la suite.

 

[Ehplodor]

Ne confond pas nocache et noindex. ;-)

Y a un bug, faut trouver une solution en essayer des choses.

 

[Fred]

J'ai mis des disallow dans le fichier robots.txt pour les répertoires des extensions qui n'existe plus. Pour le reste je vais renvoyer un 410 systématiquement, mais c'est assez long.