Auto-diagnostic en trois étapes
La plupart des tickets que nous recevons sont résolus par la personne qui les a ouverts, une fois qu’elle sait où regarder. Parcourez trois couches dans l’ordre et vous trouverez généralement la cause avant d’avoir besoin de nous. Commencez par la couche réseau : demandez votre manifeste avec un client HTTP simple et lisez le code de statut. Un 403 ou une page de défi signifie que quelque chose devant WordPress bloque la requête, et aucun réglage de l’extension n’y changera rien.
Si le statut est correct, passez à la couche contenu. Comparez ce que le tableau de bord de l’extension affirme avoir publié avec le fichier réellement servi. Un écart ici relève presque toujours du cache, au niveau de WordPress, de l’hébergeur ou du CDN. Purgez les trois et revérifiez avant de conclure quoi que ce soit d’autre.
Ce n’est que si les deux couches sont saines qu’il faut regarder la configuration. À ce stade, la question n’est généralement pas de savoir si le protocole fonctionne, mais s’il décrit correctement votre site — mauvais type d’organisation, catalogue vide, ou points d’accès pointant vers des pages qui n’existent plus.
Pannes courantes et ce qui les provoque
| Symptôme |
Cause la plus probable |
| Le manifeste renvoie 404 |
Permaliens non régénérés après l’activation, ou conflit de règle de réécriture avec une autre extension |
| Le manifeste renvoie 403 ou une page de défi |
Règle de pare-feu ou d’anti-bot rejetant les clients non-navigateurs |
| Les modifications de contenu ne sont pas répercutées |
Cache de page ou cache CDN servant une copie périmée |
| Le catalogue est vide |
Aucun type de contenu sélectionné, ou les types sélectionnés ne contiennent aucun élément publié |
| Le score a baissé sans changement de contenu |
Une nouvelle extension de sécurité, de cache ou d’optimisation modifie la réponse |
Délais de réponse et gravité
Tous les problèmes n’ont pas le même poids : classez le vôtre avant d’écrire. Une panne qui empêche complètement les agents de lire le site — un manifeste renvoyant une erreur serveur, par exemple — est urgente, car chaque jour où elle persiste est un jour où le site est mal représenté dans les sources sur lesquelles les agents s’appuient. Un champ de catalogue manquant ou une description de service imprécise relève de l’amélioration plutôt que de la panne, et peut attendre le prochain cycle de mise à jour.
Ce classement détermine aussi quoi faire en attendant. Face à une panne bloquante, ramenez d’abord le site à un état stable — désactivez temporairement le composant fautif — puis poursuivez l’investigation. Face à une panne non bloquante, laissez les choses exactement en l’état : reproduire une panne partiellement corrigée prend plus de temps que d’en diagnostiquer une en cours.
Que joindre à votre message
Quatre éléments transforment un échange de deux jours en une réponse unique : l’URL exacte testée, la réponse brute reçue avec son code de statut, la date et l’heure de début du comportement, et la liste de ce qui a changé sur le site dans les jours précédents. Ce dernier point compte plus qu’on ne le croit — la grande majorité des pannes soudaines remontent à une mise à jour d’extension, un changement d’hébergement ou une nouvelle règle de sécurité plutôt qu’au protocole lui-même.
Si vous gérez plusieurs sites sur la même pile technique, tenez un journal partagé d’une ligne par incident et sa résolution. Il vous montrera vite que la plupart de vos problèmes viennent de trois ou quatre causes récurrentes, et vous pourrez alors corriger la racine plutôt que réparer chaque site à son tour.
