Export WordPress statique : le site affiche encore l’ancienne version

Déterminer quelle version le domaine sert

Une page a changé dans WordPress, l’export annonce qu’il a terminé, mais le site public affiche encore le texte précédent. C’est le symptôme d’un signalement sur le forum Simply Static. L’auteur du fil avait aussi constaté des réponses 404 pour les pages dans le journal. Ces deux indices doivent être vérifiés ensemble : un nombre de fichiers copiés indique qu’un transfert a eu lieu ; il ne dit pas que chaque fichier contient le bon document. Le forum ne confirme pas la cause finale. On peut toutefois la localiser en comparant la page rendue par WordPress, la copie exportée et la réponse réellement servie.

Dans ce guide, le site public est censé servir une copie HTML. WordPress reste la source éditoriale, souvent sur une autre adresse. Il n’est pas nécessaire d’ouvrir le tableau de bord sur la destination pour vérifier ou publier un paquet statique déjà prêt. En revanche, un fichier d’export ne permet pas de récupérer une modification qui n’existe que dans une base WordPress inaccessible. Si le changement manque dans la source ou dans le paquet, il faut obtenir une nouvelle version auprès de la personne qui gère la source. N’éditez pas l’ancien HTML à la main pour masquer cette absence : l’export suivant l’écraserait.

Commencez par deux pages précises : l’accueil et une page interne modifiée. Ajoutez une page témoin qui doit rester inchangée. Notez les URL finales et une courte phrase publique propre à la nouvelle version. Sur une recette, préférez un marqueur fictif comme VERSION-RECETTE-42. Un numéro de fichier ou une date de modification ne suffit pas : une archive récente peut contenir une page ancienne, et une date de fichier peut changer pendant la copie. Relevez le code HTTP et le contenu obtenu après les redirections. Une page d’erreur avec un code 200 ne passe pas le contrôle si elle ne contient pas le contenu attendu.

1. Dans une fenêtre privée, ouvrez les trois URL sur la destination. Notez pour chacune l’adresse finale, le statut dans l’onglet Réseau et le texte visible attendu.
2. Identifiez l’adresse de la source et le dossier ou l’identifiant de déploiement censé alimenter la destination. Si le domaine public et l’adresse de génération sont distincts, ne les intervertissez pas.
3. Ne touchez pas au cache ni aux fichiers avant cette comparaison. Si les pages modifiées donnent des résultats différents, notez lesquelles : un accueil à jour ne prouve pas que le reste du site l’est.

Vérifier que l’export contient de vraies pages

Si vous avez accès au tableau de bord de la source, ouvrez les URL sources dans le contexte qui doit pouvoir les lire. Vérifiez que la page est publique pour le public visé et que son HTML contient bien le changement. Une prévisualisation connectée peut inclure un brouillon ou une version privée que le générateur ne reçoit pas. Si le site source est protégé, utilisez seulement le mode d’accès prévu pour le générateur ou demandez à l’équipe qui le gère de vérifier la requête depuis son contexte ; n’ouvrez pas la source à tous pour contourner une erreur.

Pour Simply Static, les versions documentées exposent un journal d’export, avec l’URL et le statut de chaque ressource traitée, distinct du journal de progression. Recherchez le chemin exact de la page et le code renvoyé pendant la génération. Une série de 404 sur des pages qui répondent par ailleurs peut signaler que l’exporteur interroge une autre adresse, un mauvais sous-dossier ou un hôte virtuel inattendu. Un 403 peut signaler une protection. Une redirection vers une connexion peut finir en 200 tout en livrant le mauvais document. Comparez la réponse finale et la configuration de la source de génération ; ne corrigez ni DNS ni permaliens sans avoir confirmé lequel de ces chemins diffère.

Si vous utilisez déjà Simply Static et avez besoin d’un paquet à transmettre, la documentation de son éditeur indique Simply Static > Deploy, méthode ZIP Archive, puis Push et téléchargement dans Activity Log. Les libellés peuvent différer selon la version. Vérifiez d’abord que la destination choisie est bien une archive, en recette : une autre méthode peut transférer vers un hébergement configuré. Avant génération, contrôlez la réécriture des URL pour le domaine ou le préfixe final. Un paquet destiné à l’ouverture hors ligne n’a pas nécessairement les mêmes liens qu’un paquet destiné à un site.

1. Comparez une URL source correcte avec sa ligne de journal. Si le journal indique une erreur, corrigez ce point sur la source et regénérez le paquet avant toute mise en ligne.
2. Ouvrez l’archive extraite dans un dossier neuf. Cherchez l’accueil index.html et le fichier qui correspond au chemin interne, par exemple a-propos/index.html si l’export utilise des dossiers par page.
3. Vérifiez que les fichiers contiennent le texte attendu et que les ressources liées se trouvent au bon chemin. Une archive qui ne contient que du CSS et des images ne peut pas publier les pages qui manquent.

Prévisualiser la copie via un serveur HTTP local

Ouvrir directement un fichier HTML peut masquer un problème de chemin : les liens qui partent de la racine ou les URL relatives ne se résolvent pas toujours comme sur un site web. Avec Python installé, ouvrez un terminal et démarrez le serveur ci-dessous sur le dossier extrait qui contient réellement index.html. Remplacez le chemin d’exemple par celui de votre copie. L’adresse 127.0.0.1 limite cette prévisualisation à votre poste. Ne servez que le dossier d’export : le serveur de test ne doit pas exposer une sauvegarde ni les fichiers de la source.

Ouvrez http://127.0.0.1:8765/ puis http://127.0.0.1:8765/a-propos/ si cette page existe. Dans l’onglet Réseau du navigateur, regardez aussi une feuille CSS et une image nécessaires. Si le site public doit être sous /vitrine/ et que le paquet contient des liens qui commencent par ce préfixe, reproduisez-le en plaçant la copie dans un dossier de test vitrine sous un dossier parent réservé à cet essai, puis servez ce parent. Ne modifiez pas chaque lien à la main pour faire réussir la prévisualisation.

Le serveur de test ne reproduit pas les règles Apache, Nginx ou d’un hébergeur statique. Un lien absolu vers le domaine public peut aussi quitter la prévisualisation et afficher l’ancienne version : vérifiez toujours l’adresse après avoir cliqué. L’essai sert à vérifier les fichiers et leur arborescence ; il faut encore vérifier les redirections et les chemins sur l’hébergement choisi. Pour arrêter le test, revenez au terminal et faites Ctrl+C. Vous n’avez modifié ni le paquet ni le site.

python -m http.server 8765 --bind 127.0.0.1 --directory "/chemin/vers/export"

Publier avec l’accès de l’hébergeur statique

Si le paquet est correct sur votre poste, comparez-le au déploiement actif. Cette voie convient à une personne qui a accès au panneau de l’hébergeur statique ou à son système de versions, sans compte WordPress sur la destination. Dans la liste des déploiements du projet, trouvez celui associé au domaine public. Une version peut exister à une URL de prévisualisation alors que le domaine reste associé à une version précédente. Vérifiez le nom du projet, le domaine et le dossier d’entrée. Si vous avez extrait un ZIP, déposez le dossier qui contient directement index.html selon les règles de l’hébergeur. Un dossier ajouté autour de l’export décale tous les chemins d’un niveau.

Créez une prévisualisation avec le paquet complet. Utilisez les mêmes chemins qu’en local : accueil, page modifiée, page témoin et ressource. Testez une URL volontairement inexistante. Elle doit recevoir le traitement d’erreur prévu, plutôt qu’un accueil apparemment valide pour tous les chemins. Sur une plateforme qui sait gérer des versions, notez l’identifiant de la version active avant de promouvoir la nouvelle. En cas d’échec après promotion, réactivez la version précédente dans le panneau, puis vérifiez de nouveau les deux pages de référence. Conservez le paquet fautif hors du dossier publié pour l’analyser.

Si l’URL de prévisualisation est correcte mais que le domaine public reste ancien, comparez d’abord l’association domaine et version dans le panneau. Une purge ne fera pas apparaître un paquet que le projet n’utilise pas. Si la bonne version est active et que seul le domaine public conserve le contenu précédent, identifiez la couche de cache et purgez les URL confirmées après la correction. Un en-tête de cache est un indice ; le texte reçu et la version réellement servie constituent la preuve.

1. Notez l’identifiant de la version actuelle et confirmez que vous savez la réactiver. Chargez le dossier qui commence au bon niveau.
2. Vérifiez le paquet via l’adresse de prévisualisation du projet, puis activez cette version selon le flux de publication prévu.
3. Ouvrez le domaine public dans une session sans compte. Comparez les chemins, les statuts et le texte attendu. Si un test critique échoue, restaurez la version précédente et vérifiez qu’elle est effectivement servie.

Publier avec un accès aux fichiers et traiter le cas mixte

Si vous disposez d’un gestionnaire de fichiers ou d’un accès SFTP, commencez par lire la racine publique dans le panneau qui associe le domaine à son dossier. Ne supposez pas qu’elle se nomme toujours public_html. Cherchez l’index.html de l’ancienne version, un fichier d’une page interne et la ressource CSS utilisée par cette page. Téléchargez ces témoins sur votre poste pour les comparer à la réponse publique et au nouveau paquet. Si vous n’êtes pas dans un dossier dont vous pouvez démontrer le lien avec le domaine, interrompez la copie : un transfert réussi vers un mauvais dossier ne change pas le site.

Sur un hébergement statique classique, préparez un nouveau dossier complet, hors du répertoire public tant qu’il n’est pas prêt. Prévoyez une prévisualisation autorisée ou une copie de recette avec les mêmes règles. Si l’hébergeur permet de basculer la racine du domaine entre deux dossiers, confirmez que cette bascule est prévue pour votre hébergement et conservez l’ancien chemin pour le retour. Si le panneau ne propose pas de bascule et que vous ne pouvez pas mettre en ligne le paquet sans mélanger les versions, demandez le mécanisme pris en charge avant d’écraser le dossier actif. Ne lancez pas de synchronisation qui supprime les fichiers absents du nouveau paquet tant que la racine et la sauvegarde ne sont pas confirmées.

Dans un autre cas signalé sur le forum WordPress, les intervenants ont repéré un mélange plausible de pages statiques et d’un WordPress dans le même dossier. Si vous trouvez index.html et index.php, inspectez la configuration réelle de l’accueil. Apache peut servir le premier fichier disponible dans la liste DirectoryIndex ; Nginx peut utiliser la directive index. L’ordre dépend du site et peut être modifié par des règles de redirection ou de réécriture. La présence d’un fichier ne prouve donc pas qu’il gagne la priorité. Comparez le contenu de l’index.html à celui reçu sur /, puis vérifiez avec la personne qui gère l’hébergement le dossier et la règle actifs.

Si la destination doit rester statique, corrigez le dossier de publication et vérifiez que l’index de la nouvelle version est servi. Si WordPress doit reprendre l’accueil, traitez cette décision comme un changement de configuration distinct. Sur une copie du site, gardez l’index statique précédent et testez le réglage ou le retrait ciblé qui permet à WordPress de répondre. Vérifiez aussi les pages profondes : changer la priorité de l’accueil ne remplace pas les fichiers HTML qui masquent d’autres chemins. Ne retirez aucun fichier de démarrage WordPress pour forcer l’affichage de la copie.

1. Identifiez la racine et faites une sauvegarde de la version servie. Téléversez le nouveau paquet dans le dossier de préparation et comparez les fichiers témoins au paquet local.
2. Utilisez la méthode de bascule autorisée pour ce domaine. En cas de coexistence HTML et PHP, vérifiez le chemin effectivement servi avant et après la modification.
3. Si une page de référence ou une ressource échoue, rétablissez le dossier ou la règle précédente, puis contrôlez le retour sur le domaine public.

Valider une mise en ligne que l’on peut annuler

Un contrôle abouti compare la même page à chaque étape. Si la source ne contient pas le texte, le travail revient à l’équipe éditoriale. Si elle le contient mais que le fichier exporté ne l’a pas, corrigez la génération. Si la prévisualisation locale est bonne mais que celle de l’hébergement échoue, regardez le dossier chargé, le préfixe, le nom des fichiers et les règles de l’hébergeur. Si les deux prévisualisations réussissent mais que le domaine public répond avec l’ancienne version, contrôlez l’association du domaine, le déploiement actif et le cache. Chaque résultat désigne une action différente ; ne répétez pas l’export à chaque étape.

Vérifiez aussi ce qui dépendait de WordPress au moment de la visite. Un fichier HTML ne traite pas une connexion, une recherche serveur, un panier ou un formulaire de contact. Certaines copies utilisent un service externe pour ces fonctions : leur présence à l’écran ne prouve pas qu’elles fonctionnent. Si la page contient un formulaire, faites un essai autorisé sur la recette avec des valeurs fictives et contrôlez le résultat de bout en bout. Si un paiement ou un espace privé est requis et n’a pas de solution testée, gardez cette partie sur le site dynamique et vérifiez le parcours qui y mène.

Consignez le domaine, le dossier ou la version active, le paquet utilisé, l’heure du changement et les résultats par URL. Conservez le paquet précédent et les références nécessaires au retour. Répétez le contrôle après le délai de cache connu si vous avez purgé. Pour une mise en ligne depuis un sous-dossier, testez les liens internes depuis une page profonde, ainsi que les ressources dont les URL commencent par la racine. Vous pouvez clore le cas quand la destination sert le contenu attendu à un visiteur, que la page témoin reste correcte et que le chemin de retour a été vérifié en recette.