4 mai 2021

Problème de couverture avec SPIP

Problème de couverture avec SPIP visible dans la Search Console. Résolu autour du 7/7

Article de 2020 mis à jour suite à un correctif paru en février 2021.

Le constat

C’est l’histoire d’un site sous SPIP plutôt bien référencé. A partir de juillet 2019, le nombre des pages présentes dans l’index de Google s’est mis à diminuer progressivement. Quand le client m’a alerté sur son problème de référencement , il restait moins de 2% de pages indexées.

La Google Search Console indiquait des erreurs 500 sur un grand nombre de pages. Pourtant, ces mêmes pages étaient bien visibles à partir du navigateur.

Pour approfondir le diagnostic, je suis allé voir les fichiers de log "bruts". Les accès directs d’un navigateur renvoyaient bien un code 200 (OK), alors que ceux des moteurs de recherche écopaient d’une erreur 429 (too many requests / retry later).

En d’autres termes, le site SPIP n’avait pas envie de parler aux moteurs de recherche. Au bout d’un moment, ceux-ci cessaient de référencer les pages fautives, ce qui est bien normal.

La cause

Avant d’envoyer une page, SPIP vérifie si la demande émane d’un humain ou bien d’un moteur de recherche. Si c’est un robot d’indexation qui demande la page, SPIP vérifie que le serveur dispose de suffisamment de ressources pour envoyer les données. S’il estime que le serveur est déjà trop occupé, alors il envoie une erreur 429 et demande de repasser plus tard.

Ce dispositif est utile pour éviter de surcharger le serveur lors des pointes de fréquentation. La charge serveur est mesurée à l’aide de la fonction sys_getloadavg(). SPIP estime que le taux d’occupation du serveur ne doit pas dépasser 0.4. C’est là que le bât blesse : certains serveurs mutualisés renvoient une valeur bien plus élevée.

Le seuil de 0.4 est fixe et ne peut pas être surchargé par exemple par mes_options.php. C’est un bug présent à l’heure où j’écris ces lignes (SPIP est en version version 3.2.7).

Voici quelques relevés des mesures de sys_getloadavg() en fonction de l’hébergement mutualisé :

  • 1AND1 / Ionos : 30 !!! (hébergement d’un site peu fréquenté)
  • OVH : 0.1 (hébergement d’un site fréquenté)
  • o2switch : entre 0.3 et 0.6 (hébergement d’un site fréquenté)

Conclusion : seul OVH retourne une valeur qui permettra à votre site de rester correctement référencé.

Chez Ionos, la valeur mesurée a fortement augmenté à une date précise, ce qui laisse penser qu’une modification a été faite sur l’infrastructure d’hébergement. Avant juillet 2019, il n’y avait pas ce problème de couverture.

La solution

Un correctif a été mis en place mi-février 2021 : vous pouvez créer un fichier qui détermine le paramètre de charge (et certaines autres constantes).

Pour cela, créer un fichier "ecran_securite_options.php" dans /config (au même niveau que ecran_securite.php donc) et mettez dans celui-ci les informations souhaitées. En l’occurrence, pour ne pas tenir compte de la charge serveur et laisser toujours accessible aux robots :

<?php

define('_ECRAN_SECURITE_LOAD', 0);

Thématique : PHP, SPIP