Migrer de WordPress à un site statique
Pourquoi, comment, et ce qu'on a appris

WordPress propulse 43% du web. C'est aussi le CMS le plus piraté : 90% des CMS hackés sont des WordPress, selon Sucuri. Si vous avez un WordPress, statistiquement, vous serez piraté au moins une fois tous les 5 ans. C'est mathématique.

Les 4 raisons qui m'ont fait migrer. 1) La performance : un site statique charge 3-5x plus vite qu'un WordPress équivalent. Google classe les sites lents plus bas. 2) La sécurité : 0 plugin = 0 faille = 0 piratage. 3) La maintenance : 0 mise à jour, 0 backup quotidien, 0 stress. 4) Le coût : hébergement OVH à 30€/an au lieu de 200€/an pour un WordPress managé. Total économisé sur 5 ans : 850€ + 60h de maintenance.

Le déclencheur, c'est le piratage de mon premier site C'Print. J'ai perdu 2 jours à restaurer, à patcher, à sécuriser. Sur un site qui fait 500 visites/mois. C'est à ce moment que j'ai réalisé : le ratio effort/valeur est devenu négatif. Il fallait changer de stack.

Un site statique, c'est un ensemble de fichiers HTML, CSS, JS, hébergés sur un serveur web. Pas de base de données. Pas de PHP. Pas d'admin. Chaque page est un fichier que le navigateur interprète. C'est aussi simple que ça — et c'est aussi la source de tous les bénéfices.

Ce qu'un site statique fait TRÈS BIEN. Performance (3-5x plus rapide). Sécurité (0 vulnérabilité logicielle, sauf faille Apache). SEO (Google adore les sites rapides, schema.org, sitemap). Coût (hébergement 10x moins cher). Maintenance (0 mise à jour de plugin, de thème, de core). Durabilité (un fichier HTML de 2026 s'affichera encore en 2050).

Ce qu'un site statique fait MOINS BIEN. Pas de back-office (il faut éditer les fichiers HTML directement). Pas d'admin natif (pas de login, pas d'interface d'édition). Pas de fonctionnalités dynamiques sans JS (commentaires, recherche, login, etc.). Pas de base de données (les formulaires de contact nécessitent un proxy PHP ou un service externe).

Le malentendu classique : un site statique n'est pas un site des années 90. Avec JavaScript moderne, vous pouvez avoir des animations, des filtres dynamiques, des tunnels de vente interactifs. C'est ce que fait pure-communication.fr : 17 tunnels de vente interactifs, en HTML/CSS/JS pur, sans back-office. La différence avec WordPress, c'est juste l'endroit où on édite les contenus.

L'arborescence que j'utilise pour un site de 60 pages. Le root : index.html (home). Un sous-dossier par section majeure (agence, solutions, outils, etc.). Un sous-dossier par outil (questionnaires, diagnostics, livres-blancs, fiches-expertes). Le CSS et le JS dans /css et /js. Les images dans /img. Les PDFs dans le sous-dossier du LB qui les contient.

Le pattern de page. Chaque page est un fichier .html autonome. Le header et le footer sont en dur dans chaque fichier (pas de templating automatique). C'est verbeux, mais c'est ce qui rend le site résilient : vous pouvez casser 1 page, les autres marchent toujours. Pas de SPOF (Single Point of Failure).

Le templating, on peut le faire. Avec des outils comme Jekyll, Hugo, Eleventy. Mais pour un site de 60 pages, ça ajoute une couche de complexité qui n'est pas justifiée. Le copy-paste du header dans 60 fichiers, c'est 2h de travail au début, 0 sur la durée. La complexité du templating, c'est des heures de debugging à chaque mise à jour. Pour 60 pages, le brut est plus rentable que le templating.

Les URLs. Pas de query string, pas de paramètres. Une URL = un fichier. /agence.html, /solutions.html, /questionnaires/maturite-strategique.html. C'est ce que Google préfère, c'est ce que les humains retiennent, c'est ce qui ne casse pas quand vous migrez d'un serveur à l'autre.

Le SEO en statique, ce n'est pas un problème — c'est même un avantage. Vous contrôlez 100% de la sortie HTML. Pas de thème qui pollue les balises, pas de plugin SEO qui ajoute du JavaScript, pas de page admin qui se met en noindex par accident. Vous écrivez ce que vous voulez, et Google lit ce que vous avez écrit.

Les éléments SEO critiques. 1) Title et meta description uniques par page (30 minutes de travail pour 60 pages). 2) Schema.org en JSON-LD (5 minutes par page, c'est ce qui rend les rich snippets possibles). 3) Sitemap XML (5 minutes, une fois). 4) llms.txt (10 minutes, pour les LLM comme ChatGPT/Perplexity/Claude). 5) URLs propres (/agence, pas /?p=42). 6) Alt text sur toutes les images.

Le sitemap.xml, c'est 5 minutes de travail pour 60 pages. Vous listez chaque URL, vous ajoutez la date de dernière modification, vous uploadez dans /sitemap.xml. Google le lit tout seul. Le llms.txt, c'est 10 minutes — un fichier qui décrit votre site aux LLM, pour qu'ils le citent dans leurs réponses. C'est le futur du SEO. Les deux sont des quick wins massifs.

L'audit SEO que je fais après chaque refonte. 1) Toutes les pages ont un title et une meta description uniques (Search Console). 2) Le sitemap est à jour et sans erreur (Search Console > Sitemaps). 3) Le site est indexable sur 100% des pages (commande site:pure-communication.fr dans Google). 4) Les rich snippets sont valides (test Schema.org). Si les 4 sont OK, votre SEO est aussi bon qu'un WordPress, voire meilleur.

Le point faible du statique, c'est la capture de leads. Pas de base de données, pas de traitement côté serveur. Mais il y a 3 solutions, dans l'ordre de complexité.

Solution 1 — Un proxy PHP minimal. Vous gardez 1 fichier PHP sur le serveur, qui reçoit les données du formulaire, qui envoie un email, et qui push dans votre CRM. C'est 50 lignes de PHP, c'est ce que j'ai fait pour pure-communication.fr (17 tunnels, 1 endpoint). Le site reste 99% statique, le PHP est juste un proxy.

Solution 2 — Un service tiers. Formspree, Netlify Forms, Getform. Vous postez le form vers leur endpoint, ils vous envoient l'email. C'est gratuit pour <100 leads/mois, mais ça ajoute une dépendance externe. Pour un site B2B qui veut garder le contrôle, c'est moins bien que la solution 1.

Solution 3 — Serverless. AWS Lambda, Cloudflare Workers, Vercel Functions. Vous avez un endpoint custom sans serveur PHP. C'est la solution moderne, mais c'est plus complexe à mettre en place.

Mon choix : la solution 1 (proxy PHP). Pourquoi : c'est 1 fichier de 50 lignes, ça coûte 0 (déjà sur l'hébergeur OVH), c'est ce qui me donne le plus de contrôle. Et c'est ce que vous avez probablement déjà sur votre hébergement (PHP 5.6 minimum, c'est standard OVH).

Piège 1 — Le cache CSS trop agressif. Apache, par défaut, met un cache de 30 jours sur les fichiers statiques. Quand vous modifiez style.css, le navigateur ne le voit pas pendant 30 jours. Solution : ajouter un cache buster (?v=18) à chaque modif. Ça force le navigateur à re-fetcher.

Piège 2 — L'oubli des redirects. Si vous changez une URL (/vieille-page → /nouvelle-page), Google ne le sait pas tout seul. Il faut mettre en place des 301 redirects dans le .htaccess. Sans ça, vous perdez le SEO accumulé sur les anciennes URLs.

Piège 3 — Le proxy PHP qui crash. Si le PHP est en version incompatible (5.6 vs 8.x), le proxy peut crasher en 500 sans erreur claire. Solution : créer un test.php qui affiche phpversion() avant d'écrire le moindre code. Ne JAMAIS faire confiance à la doc d'hébergeur sur la version PHP — toujours vérifier.

Piège 4 — Analytics mal configuré. Vous oubliez le tag Google Analytics sur certaines pages, ou vous oubliez de le mettre après une refonte. Résultat : des trous dans la mesure, des décisions prises sur des données incomplètes. Solution : après chaque refonte, crawler toutes les pages avec un outil comme Screaming Frog et vérifier que le tag est présent partout.

Piège 5 — L'upload FTP dans le mauvais dossier. OVH a un dossier /www/ qui est servi, et un / qui ne l'est pas. Si vous uploadez dans /, vos fichiers sont sur le serveur mais invisibles au public. Solution : TOUJOURS utiliser REMOTE_DIR = 'www' dans vos scripts d'upload, et vérifier après upload avec un curl -I.