Migrer un site HTML statique vers WordPress

Un site en HTML statique est fait de fichiers : une page, un fichier, souvent écrit à la main ou avec un éditeur qui n'existe plus. Le passer sous WordPress permet de modifier les contenus sans toucher au code, d'ajouter un blog, des formulaires, des extensions. Mais il n'y a ni base de données à exporter ni outil de migration qui fasse tout : la difficulté est propre au point de départ.

Cet article traite de ce qui distingue le départ d'un site HTML. Si votre site est déjà sous WordPress et change seulement de serveur, voyez changer d'hébergeur un site WordPress ; s'il est sur Wix, la migration de Wix vers WordPress.

Sur un site statique, ce qui existe est ce qui est sur le serveur. Récupérez une copie complète des fichiers par FTP ou SFTP, et crawlez le site pour la comparer : le crawl trouve les pages reliées entre elles, le serveur révèle les pages orphelines (anciennes offres, pages de remerciement, pages de campagne) qui reçoivent parfois encore des liens ou du trafic. La Search Console complète la liste avec les pages que Google connaît.

Relevez aussi les fichiers qui ne sont pas des pages : images, documents, feuilles de style et scripts appelés par d'autres sites, inclusions côté serveur (SSI, PHP) qui assemblent l'en-tête et le pied de page.

Les URL d'un site statique finissent souvent par .html, celles de WordPress par une barre oblique. Deux choix :

• garder les mêmes adresses : une structure de permaliens en /%postname%.html le permet pour les articles ; pour les pages, il faut une extension ou une règle dédiée. Rien à rediriger, mais une contrainte qui dure ;
• adopter les adresses de WordPress et rediriger chaque ancienne adresse en 301 vers sa nouvelle page, une par une. Une règle générique qui retire .html ne suffit que si les noms de pages restent identiques, ce qui est rare quand on réorganise le site.

Dans les deux cas, pensez à index.html : l'adresse du dossier et celle du fichier doivent mener à la même page.

Des extensions d'import de pages HTML lisent les fichiers et créent les pages correspondantes dans WordPress, mais le résultat demande presque toujours une reprise : un site statique mélange contenu et mise en page (tableaux de mise en forme, styles en ligne, balises font, menus recopiés dans chaque fichier). Pour un site de quelques dizaines de pages, recopier le texte dans l'éditeur de blocs donne souvent un résultat plus propre et pas plus long.

Profitez-en pour rétablir une hiérarchie de titres claire, compléter les balises title et meta description (souvent identiques sur toutes les pages d'un site statique) et les textes alternatifs des images. Notre article sur la reprise des contenus éditoriaux détaille ces points.

Les images et documents peuvent garder leurs chemins d'origine, déposés tels quels sur le nouveau serveur : c'est le plus sûr pour ceux qui sont indexés ou liés depuis d'autres sites. S'ils passent dans la médiathèque de WordPress, leurs adresses changent et se redirigent comme des pages (voir la redirection des images).

Les formulaires d'un site statique envoient souvent leurs données à un script maison ou à un service externe : recréez-les avec une extension de formulaire et testez chaque envoi.

Pour le reste, la migration suit les étapes de tout changement de CMS : construire le site sur une préproduction, préparer le plan de redirection, basculer, contrôler. Elles sont décrites dans la procédure de changement de CMS.

Si vous teniez aux avantages du statique (rapidité, surface d'attaque réduite), des extensions comme Simply Static ou WP2Static publient une version statique d'un site géré dans WordPress. Les fonctions dynamiques (commentaires, recherche, formulaires, boutique) ne fonctionnent alors pas telles quelles.