PlanetHoster ou o2switch pour éviter un sitemap WordPress incomplet

Un sitemap peut répondre 200 pendant qu’il est encore en cours d’écriture

Une extension WordPress personnalisée produit chaque nuit le fichier `sitemap-editorial.xml`. Le fichier est complet quand vous l’ouvrez plus tard, mais une lecture au moment de la tâche reçoit un document qui s’arrête après les premières adresses. Le serveur répond pourtant HTTP 200. Si le générateur ouvre le fichier public en écriture et le remplit progressivement, une requête peut lire les octets déjà écrits avant que la balise de fermeture soit présente. Le statut de la réponse n’indique pas si le XML est exploitable.

Le cas concerne un sitemap statique publié sous une URL stable. WordPress dispose aussi de son propre index `wp-sitemap.xml`, qui peut être servi par une règle et généré à la demande. Avant de modifier un fichier, identifiez le composant qui répond à l’URL de votre sitemap. Si le document est produit à chaque requête par le cœur, par une extension SEO ou par une autre application, diagnostiquez ce composant. La procédure de remplacement de fichier s’applique au document écrit sur disque par la tâche. Le guide de dépannage associé couvre les sitemaps absents, les routes WordPress et les adresses en erreur.

Le comparatif suit la même opération sur les deux offres. Retrouver le site et le script, lire le sitemap pendant une génération de recette, puis préparer la nouvelle version à part. Le fichier précédent reste disponible tant que le candidat n’a pas été validé. PlanetHoster documente des tâches Cron dans N0C et o2switch les documente dans cPanel. La recette locale vérifie les deux façons d’écrire le fichier, avec des lectures HTTP à des étapes connues.

Capturer la réponse au moment où le document est régénéré

Sur une copie privée, notez l’adresse exacte du sitemap personnalisé, la racine du site, le chemin du fichier et la commande qui le produit. Relevez la période où la tâche s’exécute ou lancez-la une fois depuis le mécanisme prévu sur cette copie. Pendant l’essai, gardez au moins une lecture avant la génération, une pendant et une après. Notez l’heure et, si possible, l’identifiant de l’exécution pour rapprocher les réponses du journal de la tâche.

Conservez les en-têtes et le corps de chaque réponse GET. Sous PowerShell, placez l’URL de recette dans `$url`, puis utilisez `curl.exe -sS -D entetes.txt -o sitemap-recu.xml "$url"`. Donnez des noms différents aux fichiers des trois lectures. Vérifiez le statut, les octets reçus et l’analyse XML. Si le serveur annonce le même nombre d’octets que celui effectivement reçu, le transfert HTTP peut avoir livré une réponse complète du point de vue du transport alors que le fichier source était encore en cours de génération.

Le problème peut disparaître une fois la tâche terminée. Une lecture manuelle plusieurs heures après l’incident peut donc réussir. Sur la recette, choisissez une génération assez longue pour observer l’état intermédiaire ou faites instrumenter temporairement le générateur pour rendre ce moment visible. Si un cache sert une copie différente, identifiez la couche qui a répondu et répétez la mesure dans le parcours prévu pour la recette. Lisez aussi l’adresse publique après correction, car elle peut conserver une ancienne version encore valide.

• Identifier la tâche qui écrit le fichier et noter l’heure de début et de fin.
• Comparer les réponses HTTP avant, pendant et après la génération.
• Faire analyser le XML réellement reçu et conserver le résultat avec le relevé.

Vérifier les adresses en plus de la syntaxe XML

Un sitemap bien formé peut rester incomplet. Un générateur peut fermer correctement le document après avoir oublié des pages, par exemple si une étape de sélection s’interrompt. Sur un petit jeu témoin, préparez la liste des adresses attendues et comparez-la aux valeurs de `loc`. Contrôlez la racine XML et l’espace de noms du protocole, puis vérifiez le nombre d’entrées. Un nombre correct peut masquer un doublon et une adresse manquante. Une comparaison des adresses reste donc utile pour ce test.

Sur un site plus grand, relevez la liste des adresses attendues avec les mêmes critères que le générateur. Précisez notamment les contenus publiés, les adresses canoniques et les types de contenus inclus selon votre procédure. Si le générateur produit plusieurs fichiers enfants, validez les fichiers concernés et vérifiez que l’index référence des versions disponibles. Pour le cas de cet exercice, le fichier est unique et la comparaison porte sur deux ou trois adresses fictives connues à l’avance.

Enregistrez une empreinte du dernier fichier validé et gardez une copie de retour dans un espace protégé. Après une génération interrompue, cette empreinte permet de vérifier que la version publique reste bien celle que vous aviez validée. Si l’adresse pointe en réalité vers une réponse dynamique, conservez le relevé HTTP et vérifiez la source du contenu dans le générateur concerné. Ne remplacez un fichier que lorsque vous avez confirmé qu’il est celui servi par l’URL.

PlanetHoster The World, retrouver le projet qui publie le sitemap

Dans l’Espace Client PlanetHoster, identifiez le Projet Web qui sert le domaine de recette. Ouvrez son interface N0C, puis la rubrique Crons. L’aide N0C documente l’ajout d’une tâche, la fréquence, le chemin complet de la commande et un commentaire qui permet de l’identifier. Les détails du Projet Web aident à retrouver les informations d’accès du projet. Relevez le domaine, la racine servie et le dossier de génération à partir du projet sélectionné. Un autre Projet Web peut avoir un fichier de même nom.

Vérifiez dans la tâche le chemin du script et celui du fichier publié. Identifiez aussi l’utilisateur qui écrit le fichier et la possibilité pour le serveur web de le lire après remplacement. Utilisez une copie privée et une génération sur un catalogue fictif pour tester les droits de lecture et de remplacement. La documentation N0C indique qu’un courriel peut être envoyé lorsque la tâche produit une sortie. Si le script journalise un échec, conservez dans le journal l’identifiant de l’exécution, l’heure, le nombre d’adresses validées et le résultat de la publication.

Dans un pack qui regroupe plusieurs projets, consignez ces valeurs par site. Un essai réussi sur un Projet Web n’établit pas les droits ni l’emplacement du sitemap d’un autre. Vérifiez le comportement de la tâche en cas d’interruption, ainsi que le moyen de remettre le fichier précédent depuis l’espace protégé retenu pour ce projet.

o2switch Grow, relier la tâche cPanel à la racine du site

Dans cPanel, ouvrez la section des tâches Cron documentée pour Grow. Relevez la commande et sa périodicité, puis associez-la au domaine qui sert le fichier. La documentation recommande un chemin absolu pour le script. Lorsque plusieurs sites sont présents, confirmez le dossier de destination avant d’ajuster la tâche. Pour une première recette, conservez une copie de la configuration de départ et faites écrire le script de test dans le périmètre prévu pour ce site.

Vérifiez si une autre tâche ou un lancement manuel peut produire le même fichier. Préparer une version à part protège les lecteurs pendant sa création. Deux producteurs distincts peuvent néanmoins publier dans l’ordre inverse de celui qui était prévu. La documentation o2switch présente `flock` pour éviter les exécutions simultanées. Si vous retenez ce mécanisme, placez le verrou dans un emplacement accessible aux tâches concernées et associez le même verrou à tous les points d’entrée qui publient ce sitemap. Un verrou propre à chaque commande ne coordonnerait pas ces deux écritures.

Vérifiez le journal de génération et faites une lecture depuis l’URL de recette. Si la commande s’exécute alors que le fichier reste ancien, regardez si la validation a échoué, si un verrou a empêché l’exécution ou si le cache sert une autre version. Pour revenir à la situation de départ, restaurez la commande précédente et la copie validée. Contrôlez ensuite dans la réponse HTTP ce que le serveur livre.

Offres et conditions relevées le 11 novembre 2026

PlanetHoster The World affiche une offre de lancement de 5,49 € par mois pour un cycle de 24 mois, applicable notamment au pack de dix Projets Web Standard retenu ici. Cela représente 131,76 € sur ce cycle au prix affiché. Le tarif cité correspond au pack. La fiche Standard indique 10 Go NVMe ou SSD par projet. Les conditions publiques indiquent des prix toutes taxes comprises et un renouvellement automatique par défaut, à désactiver au plus tard 30 jours avant l’échéance si vous souhaitez arrêter. Confirmez au panier le total TTC et le montant de renouvellement propre au pack.

o2switch Grow affiche 7 € HT par mois en équivalent, soit 84 € HT payés pour douze mois. Le prix de renouvellement annuel publié au barème consulté est également de 84 € HT. L’offre annonce huit threads vCPU et 16 Go de RAM. Le domaine est offert la première année selon la fiche. Au récapitulatif, relevez le total TTC adapté au dossier et le prix du domaine pour le prochain cycle. Le tarif n’indique pas à lui seul le résultat d’une tâche ni les droits qu’elle aura sur un dossier.

Comparez le coût sur la durée retenue et l’organisation des sites que vous utilisez réellement. Chez PlanetHoster, le prix de lancement cité concerne dix projets pendant deux ans. Grow est facturé sur douze mois au tarif décrit. Pour un seul sitemap, l’intérêt technique vient surtout de la possibilité de retrouver la tâche, son fichier de destination et une copie valide. Notez le périmètre des accès et la procédure de reprise avant de déplacer la tâche sur une autre offre.

Écrire et contrôler la nouvelle version avant le remplacement

Dans le générateur, écrivez le XML dans un fichier candidat propre à l’exécution. Choisissez un emplacement qui ne sera pas servi publiquement et qui se trouve sur le même système de fichiers que la destination. Laissez le fichier publié en place pendant cette étape. Fermez le candidat avant de l’analyser. Vérifiez que sa structure, son encodage et ses adresses correspondent au jeu de recette. Si la tâche s’arrête pendant cette écriture, l’adresse publique continue à servir la version précédente.

Après validation, demandez un remplacement du fichier en une opération adaptée à l’environnement. En Python, l’exercice utilise `os.replace(candidat, destination)`. En PHP, un générateur peut utiliser `rename($candidat, $destination)` lorsque son environnement permet le remplacement dans les conditions vérifiées. Contrôlez le résultat de l’appel et traitez un échec comme un échec de publication. Vérifiez les droits du répertoire et la capacité du serveur web à lire le fichier après le remplacement. Gardez la version précédente en place jusqu’à la publication du candidat validé.

Sur une copie de recette, provoquez l’arrêt du générateur juste avant la validation, puis observez l’adresse servie. Rejouez avec un XML qui s’analyse correctement mais dont une adresse manque. Le résultat attendu est le même : le fichier déjà validé reste en place. Si plusieurs tâches peuvent remplacer la destination, convenez d’un seul producteur ou d’un verrou commun. Le remplacement protège le lecteur pendant la préparation d’un candidat. Il faut aussi que la version finalement publiée soit bien celle attendue.

• Écrire et fermer un candidat protégé sur le même système de fichiers que la destination.
• Vérifier le XML et les adresses, puis effectuer le remplacement et contrôler son résultat.
• Lire l’URL et comparer les adresses et l’empreinte de la réponse au candidat validé.

Revenir à un fichier déjà vérifié si une publication échoue

Conservez la dernière version validée avant de publier. Pour un retour arrière, préparez cette copie comme un nouveau candidat et vérifiez son empreinte et son XML. Remplacez ensuite le fichier selon la même méthode. Lisez l’adresse avec une requête réelle et vérifiez que l’ancienne liste est revenue. Si un cache conserve la version intermédiaire ou la dernière version, utilisez le mécanisme d’invalidation prévu pour l’URL après avoir constaté que le fichier servi à l’origine correspond à la copie choisie.

Le journal de la tâche doit permettre de savoir si l’échec vient de la génération, de la validation ou du remplacement. Lors d’un échec de génération, la dernière version peut rester exploitable pendant que l’équipe corrige le script. Relevez cependant sa date et vérifiez qu’elle correspond toujours au périmètre que vous voulez déclarer. Une version lisible peut devenir trop ancienne pour le besoin métier. La conservation de l’ancienne copie et le suivi de l’actualisation répondent à deux questions différentes.

Faites aussi un retour complet de recette en restaurant la commande précédente si vous avez changé le déclencheur, le répertoire de travail ou le chemin de sortie. Vérifiez qu’un lancement manuel et la tâche programmée utilisent le même fichier de destination. Si le composant produit un index et plusieurs sitemaps, vérifiez les liens de l’index avant de le remettre en service. Un plan qui pointe vers un fichier enfant indisponible doit être corrigé même si son propre XML est valide.

Ce que les huit lectures de recette ont montré

Le script écrit un sitemap fictif de 214 octets contenant deux adresses. Pendant la réécriture directe, la requête reçoit 151 octets avec un statut 200 et une longueur annoncée de 151 octets. Le parseur rejette ce document incomplet. Une fois l’écriture terminée, le document de 266 octets contient les trois adresses attendues. Avec la préparation séparée, la lecture au même stade intermédiaire retrouve exactement les 214 octets de l’ancienne version. Après le remplacement, elle reçoit les 266 octets validés.

Le test refuse ensuite un fichier XML coupé, puis un fichier bien formé auquel deux adresses manquent. Dans les deux cas, la version publique conserve la même empreinte. Le retour arrière rétablit exactement l’ancienne version. Les huit contrôles ont réussi avec Python 3.14.4 depuis le ZIP extrait. Le serveur et les écritures sont réels sur la boucle locale. L’exercice utilise des données fictives et ne lance pas WordPress ni les tâches des offres comparées.

Choisissez PlanetHoster si votre organisation retrouve ses publications par Projet Web et peut isoler la recette dans N0C. Choisissez o2switch si l’équipe gère déjà ses tâches par compte ou sous-compte cPanel et dispose d’une procédure vérifiable pour le script. Dans les deux cas, validez la lecture pendant la génération, le refus du candidat incomplet et le retour à la copie précédente. Ces trois observations lient le choix de l’offre à la façon dont le sitemap reste disponible pendant son actualisation.

• Extraire le ZIP et lancer `python recette.py`.
• Comparer les lectures pendant l’écriture directe, pendant la préparation séparée et après le remplacement.

Pour aller plus loin

• Lire la fiche PlanetHoster
• Lire la fiche o2switch
• Dépanner un sitemap WordPress absent ou invalide
• Télécharger la recette du sitemap statique (ZIP)