WordPress assemble les pages avec PHP et une base de données, mais le navigateur reçoit finalement du HTML, du CSS, du JavaScript et des médias. Pour un site vitrine, une documentation ou un blog dont les contenus changent peu, il est possible de figer ce rendu en fichiers statiques et de les servir sans moteur WordPress public.
Cette conversion ne remplace pas toujours le CMS. Elle sépare plutôt l’édition et la publication : WordPress peut rester dans un environnement privé pour produire le contenu, ou être abandonné si les pages seront désormais modifiées directement dans le code. Le choix dépend de la fréquence des mises à jour et de l’équipe qui maintient le site.
1. Vérifier si votre WordPress est un bon candidat
Les sites vitrines, portfolios, blogs archivés et landing pages se prêtent bien au statique. Les boutiques, espaces membres, recherches complexes, commentaires et contenus personnalisés par utilisateur demandent davantage de travail. Leur interface peut être statique, mais leurs données et actions doivent rester connectées à un service dynamique.
Si deux visiteurs non connectés voient exactement la même page à la même URL, cette page peut généralement être générée en HTML statique.
- Les contenus publics changent peu ou peuvent être republiés lors de chaque mise à jour.
- Le site ne dépend pas d’un panier ou d’un compte utilisateur géré par WordPress.
- Les formulaires peuvent être raccordés à un endpoint indépendant.
- Les redirections et métadonnées existantes peuvent être inventoriées.
2. Sauvegarder avant toute conversion
Conservez une sauvegarde complète des fichiers, de la base de données et de la configuration DNS. Exportez aussi la liste des extensions, les réglages de permaliens et les redirections. La copie statique ne doit jamais devenir votre seule archive, car elle ne contient pas forcément les brouillons, les médias inutilisés ou l’historique des contenus.
Créez ensuite une référence visuelle sur desktop et mobile. Parcourez le header, les menus, les formulaires, les galeries, les accordéons et le footer. Cette référence permet de distinguer une différence volontaire d’une régression introduite pendant la conversion.
3. Capturer toutes les routes publiques
Partez du sitemap WordPress, mais ne vous y limitez pas. Analysez les liens internes, les rapports de trafic et les pages indexées pour retrouver les URLs orphelines. Les catégories, tags, archives d’auteur et pages paginées doivent être conservés, redirigés ou explicitement retirés selon leur valeur.
Pages et articles
Associez chaque URL canonique à un fichier HTML et vérifiez les liens relatifs depuis les pages profondes.
Archives
Décidez si catégories, tags, auteurs et pagination restent utiles ou doivent rediriger vers une page plus pertinente.
Erreurs et redirections
Préparez une page 404 et conservez les redirections qui protègent les anciens liens et les campagnes existantes.
4. Remplacer ce qui dépend de PHP et de la base
Un formulaire WordPress n’enverra plus rien une fois transformé en simple HTML. Raccordez-le à une fonction serveur, à votre backend ou à un service de formulaires. Faites la même analyse pour la recherche, les commentaires, l’authentification, les contenus filtrés et les appels AJAX.
Les shortcodes doivent être rendus avant la capture. Une extension peut aussi injecter un script qui fonctionne encore en statique, mais il faut vérifier ses appels réseau et sa licence. Supprimez uniquement ce qui est réellement inutile : retirer un script sur la base de son nom peut casser un menu ou une galerie.
5. Localiser et optimiser les assets
Les URLs de médias WordPress contiennent souvent /wp-content/uploads/. Elles peuvent rester valides tant que l’ancien domaine sert les fichiers, mais la copie ne sera pas autonome. Récupérez les images, les variantes responsives, les SVG, les polices et les vidéos utiles, puis réécrivez les chemins sans altérer les attributs srcset et sizes.
Convertissez en WebP ou AVIF lorsque le gain est réel et conservez une résolution adaptée à l’affichage. Une compression trop forte détériore les captures de portfolio et les visuels de produit. Ajoutez les dimensions d’image pour stabiliser la mise en page et chargez paresseusement les médias situés sous la ligne de flottaison.
6. Préserver les signaux SEO de WordPress
Les extensions SEO génèrent souvent les titres, descriptions, canoniques, cartes sociales et données structurées. Ces balises doivent être présentes dans les fichiers statiques. Vérifiez une page de chaque type : accueil, page, article, catégorie et contenu personnalisé.
Conservez les URLs performantes. Si votre nouvelle structure supprime /category/, change un slug ou retire une archive, ajoutez une redirection permanente vers le meilleur équivalent. Mettez à jour le sitemap, gardez les pages privées hors index et testez les codes de réponse avant la bascule du domaine.
7. Comparer, déployer et surveiller
Servez la copie sur une URL temporaire protégée de l’indexation. Comparez-la avec la source aux mêmes dimensions et ouvrez les parcours critiques. Une fois la fidélité visuelle et fonctionnelle validée, déployez le dossier sur un hébergement statique et connectez le domaine.
- Les pages importantes, images, CSS, scripts et polices répondent sans erreur.
- Les formulaires arrivent bien à leur destination.
- Les canoniques pointent vers le domaine final, pas vers l’URL de test.
- Le sitemap est soumis après la bascule et les erreurs 404 sont surveillées.
- L’ancien WordPress reste récupérable pendant toute la période de validation.
Figez le rendu, pas les erreurs.
XportFrame analyse votre WordPress public, récupère ses routes et ses assets, puis affiche la copie avant de produire le ZIP statique.
Tester une URL WordPress →