24 juil. 2020

Problème de couverture avec SPIP

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

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

Seule une solution de contournement est envisageable pour le moment : modifier manuellement le fichier /config/ecran_securite.php de SPIP.

Aux environs de la ligne 571 changer le seuil de 0.4 en 0 afin de désactiver le contrôle de charge.

Avant modification :

if (!defined('_ECRAN_SECURITE_LOAD'))
        define('_ECRAN_SECURITE_LOAD', 0.4);

Après :

if (!defined('_ECRAN_SECURITE_LOAD'))
        define('_ECRAN_SECURITE_LOAD', 0);

Important : cette modification est à appliquer de nouveau après chaque mise à jour de SPIP.


Thématique : SPIP, PHP