Porter un site WordPress vers du PHP natif sans perdre son SEO

Depuis 2021, le site de Printixel tournait sous WordPress avec Beaver Builder. Le site faisait le travail : il était indexé, il générait du trafic, il contenait des dizaines de pages optimisées, des articles de blog, un glossaire, des images référencées sur Google Images et plusieurs positions SEO intéressantes.

Mais avec le temps, pour mon propre site, WordPress devenait moins aligné avec mon usage réel. Je modifiais surtout le code, je voulais un contrôle fin du HTML, et je n'avais plus besoin d'un back-office complet pour chaque page. Dans ce contexte précis, une base PHP légère devenait plus pertinente.

En 2026, j'ai donc décidé de reconstruire Printixel en PHP natif, avec l'aide de deux outils payants d'IA orientés code : Claude Code et Codex d'OpenAI. L'objectif était clair : changer de socle technique pour mon propre site, tout en conservant le SEO et, si possible, en le boostant.

Pourquoi quitter WordPress ?

WordPress n'est pas un mauvais outil. Il reste très puissant pour beaucoup de projets, et je continue à le proposer quand il correspond au besoin. Mais dans le cas du site Printixel, il était devenu moins adapté pour quatre raisons principales :

Je continue d'ailleurs à passer par WordPress pour pas mal de clients. Beaucoup connaissent déjà ce CMS, ou ont déjà une équipe habituée à son interface. Dans ce contexte, WordPress reste très pratique : il permet de donner des accès à plusieurs personnes, de gérer des rôles, de publier du contenu sans toucher au code et de conserver une vraie autonomie côté client.

J'ai aussi une préférence assez claire pour Beaver Builder quand il faut proposer un éditeur visuel à un client. À mon goût, son interface est plus lisible qu'Elementor, et sa gestion en marque blanche est un vrai avantage pour livrer un back-office plus propre, plus professionnel et moins anxiogène pour les équipes. Ce n'est pas forcément une question de stabilité absolue, mais plutôt d'expérience client et de prise en main. Donc le sujet n'est pas de dire que WordPress est mauvais. Le sujet est plutôt : est-ce encore l'outil le plus adapté pour mon propre site, que je peux maintenir moi-même dans le code ?

Il y a aussi la question du budget. Sur WordPress, une bonne optimisation peut passer par des outils comme WP Rocket, Imagify, des plugins SEO, des extensions de sécurité ou de formulaires. Pris séparément, chaque coût semble raisonnable. Mais additionnés sur la durée, ces abonnements peuvent peser. Quand un projet n'a pas besoin de toutes ces couches, une solution plus simple peut être plus cohérente. Quand le projet a besoin d'édition, de publication régulière ou de fonctionnalités métier, WordPress garde tout son sens.

De manière générale, je ne suis pas un grand fan de l'accumulation de plugins en tout genre, même sur WordPress. J'essaie toujours de faire avec le minimum, de mutualiser ce qui peut l'être et de garder un écosystème serveur que je comprends vraiment. Moins il y a de couches intermédiaires, plus il est simple de diagnostiquer un problème. Le sujet n'est donc pas WordPress contre PHP, mais plutôt : quelle architecture est la plus simple, la plus durable et la plus adaptée au projet ?

• Beaver Builder générait un HTML plus lourd que nécessaire pour mon usage actuel, avec beaucoup de classes et d'imbrications. C'est d'ailleurs valable aussi pour Elementor et, plus largement, pour la plupart des visual builders.
• Certaines fonctionnalités dépendaient d'un plugin ou d'un développement WordPress spécifique, alors qu'elles pouvaient être plus simples en PHP.
• Les performances plafonnaient par rapport à ce que je pouvais obtenir sur un site plus statique.
• La maintenance de mon propre site devenait moins fluide qu'une base PHP maîtrisée directement dans le code.

Le site utilisait Beaver Builder, ce qui produisait un HTML assez chargé pour mon besoin : beaucoup de div imbriquées, des classes générées automatiquement et des styles moins directs à maintenir. Pour un client qui édite lui-même ses pages, un builder peut être un vrai confort. Pour mon propre site, que je maintiens principalement dans le code, je voulais pouvoir intervenir plus directement.

Il y avait aussi la dépendance aux plugins. SEO, cache, formulaires, sécurité, optimisation d'images, consentement cookies, sitemap, données structurées : chaque fonction reposait sur une extension différente. C'est normal dans l'écosystème WordPress, et cela fonctionne très bien quand c'est maîtrisé. Dans mon cas, je pouvais gérer plusieurs de ces besoins directement dans le code.

Quand je voulais ajouter une fonctionnalité spécifique à mon site WordPress, je finissais souvent par créer un plugin WordPress maison. C'était propre dans l'écosystème WordPress, mais cela ajoutait encore une couche : structure de plugin, hooks, compatibilité avec le thème, contraintes du back-office, logique WordPress à respecter.

Avec l'avancée des outils d'IA appliqués au code, je me demande si la situation n'est pas en train de s'inverser. Pendant longtemps, WordPress avait un avantage évident : gagner du temps. On installait un plugin, on configurait deux options, et la fonctionnalité était en place.

Mais pour un développeur, ce gain de temps dépend du contexte. Quand l'IA peut aider à écrire, relire, factoriser et documenter du code rapidement, modifier directement une base PHP légère, lisible et versionnable peut devenir plus rapide pour certains sites vitrines ou pages très maîtrisées. À l'inverse, dès qu'il faut beaucoup d'édition côté client, des rôles utilisateurs, un blog actif ou un catalogue, WordPress reste souvent plus confortable.

Enfin, les performances plafonnaient par rapport à l'objectif que j'avais pour Printixel. Même avec WP Rocket, Imagify, du cache, des optimisations CSS et JS, WordPress gardait une certaine inertie. Pour ce site vitrine précis, je voulais quelque chose de plus direct : une URL, un fichier PHP, un HTML maîtrisé.

Récupérer le HTML de la V1

Je ne suis pas reparti d'une page blanche. La première étape a été de récupérer le HTML des pages existantes de la V1.

Cela m'a permis de conserver les contenus importants : titres, textes, sections, images, appels à l'action, galeries de références, articles, glossaire, mentions légales, CGV et pages SEO locales.

L'idée n'était pas de copier le code WordPress tel quel. Au contraire, l'objectif était de récupérer ce qui avait de la valeur, textes, images, URLs, structure SEO, puis de repartir sur un site plus propre, plus léger et plus facile à faire évoluer.

Claude Code et Codex

J'ai utilisé Claude Code et Codex d'OpenAI comme assistants de développement.

Au départ, en avril 2026, j'utilisais principalement Claude Code. Puis Codex est arrivé récemment dans mon flux de travail, et j'ai la sensation qu'il est devenu meilleur que Claude.

J'ai aujourd'hui une offre payante Claude Code et une offre payante Codex. Les deux restent limitées ou restreintes à un certain nombre d'appels. Concrètement, quand l'un des deux outils est bloqué, ralenti ou arrivé à sa limite, je passe sur l'autre. Cela me permet de garder un rythme constant sans attendre plusieurs heures et sans basculer systématiquement sur l'API payante à chaque besoin.

Claude m'a aidé à structurer une première base : architecture PHP, logique de composants, récupération des contenus, réflexion sur la migration WordPress vers un site PHP sur-mesure.

Codex m'a accompagné ensuite sur une grande partie de l'intégration, du nettoyage, du SEO technique, des sitemaps, du blog, du glossaire, des corrections Semrush, du Lighthouse, des optimisations mobiles et des détails d'interface.

Ce n'était pas un simple “génère-moi un site”. Le travail a plutôt ressemblé à une collaboration technique continue : je donnais les pages, les extraits HTML, les problèmes SEO ou UX détectés, et l'IA m'aidait à produire, corriger, tester, comparer et améliorer.

L'architecture PHP de la V2

J'ai choisi une architecture PHP native, sans framework. Pour un site vitrine comme Printixel, Laravel ou Symfony auraient ajouté une complexité inutile.

La structure est volontairement simple : une page correspond à un fichier PHP, les éléments communs sont mutualisés dans des partials, et les cas dynamiques comme le blog, les catégories et le glossaire passent par un routeur.

Le principe : garder une architecture suffisamment simple pour être modifiée vite, mais assez structurée pour rester maintenable. Modifier vite permet de gagner du temps, mais aussi d'économiser des tokens IA : moins il y a de bruit dans le code, plus les assistants comprennent rapidement où intervenir.

/
├── index.php
├── creation-de-logo.php
├── perspectives-3d.php
├── router.php
├── sitemap.php
├── wp-content/uploads/
├── assets/css/style.css
├── assets/js/main.js
└── partials/
    ├── head.php
    ├── header.php
    ├── footer.php
    ├── components.php
    ├── page-start.php
    └── page-end.php

Les composants répétitifs, comme les fils d'Ariane, les avis, les FAQ ou certains blocs de mise en page, sont générés par des fonctions PHP. Cela évite de dupliquer le même HTML sur des dizaines de pages.

La stratégie SEO

Le point le plus sensible de cette migration était le SEO. Une refonte mal préparée peut faire perdre en quelques jours ce qui a été construit pendant plusieurs années.

Une refonte n'est pas seulement une affaire d'apparence. Google associe déjà des URLs, des images, des titres, des ancres, des données structurées et des signaux de popularité à l'ancien site. Si tout change en même temps, Google doit réinterpréter le site comme s'il découvrait une nouvelle structure. Conserver ces repères permet de moderniser la technique sans repartir de zéro.

Conserver les URLs

Les pages importantes de la V1 existaient déjà sous forme d'URLs propres : /creation-de-logo/, /perspectives-3d/, /cartes-de-visite/, /site-internet-vitrine/, /perspectiviste-3d-lyon/.

La V2 conserve ces URLs. Pour les anciennes URLs héritées, notamment les anciennes URLs en /produit/..., j'ai repris les redirections 301 du fichier .htaccess de la V1.

Conserver les images

Les images de la V1 étaient servies depuis /wp-content/uploads/. Google Images connaissait déjà ces URLs. Certaines images de perspectives 3D, de réalisations print ou de captures de sites étaient référencées directement. Vous pouvez d'ailleurs taper site:votresite.com dans Google Images pour voir une partie des images indexées sur votre domaine.

J'ai donc conservé exactement le même chemin dans la V2. Le dossier wp-content/uploads a été rapatrié localement dans le nouveau site. Même sans WordPress, les anciennes URLs d'images continuent de répondre.

Blog, glossaire et sitemaps

La V1 contenait une trentaine d'articles. Il fallait les conserver avec leurs slugs, leurs contenus, leurs images, leurs catégories et leurs métadonnées.

Petit tips au passage : pour recréer la partie blog, j'ai donné à Claude le flux RSS WordPress et les sitemaps de la V1. C'est très pratique pour récupérer rapidement la liste des articles, leurs URLs, leurs dates, leurs catégories et une partie des contenus. Pour ceux que ça intéresse, les URLs utiles ressemblent souvent à ça : https://example.com/feed/ pour le flux RSS et https://example.com/post-sitemap.xml pour les articles.

J'ai recréé une page liste des articles, les pages catégories et les pages single article. Les catégories historiques ont été conservées : Graphisme, Web, Impression, Infographie 3D et Intelligence artificielle.

Le glossaire était aussi important pour le SEO. Certaines définitions, comme “pixelisé”, pouvaient ressortir très haut dans Google, parfois en extrait optimisé. Les URLs du glossaire ont donc été reprises : /glossary/pixelise/, /glossary/vectorisation/, /glossary/seo/, /glossary/rvb/ ou encore /glossary/cmjn/.

Les sitemaps ont également été recréés : pages, articles, catégories et glossaire. Le sitemap index conserve l'URL historique connue par Google Search Console : /sitemap_index.xml.

Performances et contrôle

Une fois le site Printixel migré vers une base PHP, son fonctionnement devient beaucoup plus direct. Il n'y a plus de base de données à interroger pour chaque page, plus de thème à charger, plus de builder, plus de plugins front inutiles pour ce cas précis.

J'ai aussi optimisé plusieurs points : CSS et JS minifiés, polices hébergées localement, images rapatriées en local, chargement différé de certains scripts, suppression des dépendances inutiles, compression côté serveur et lazy loading sur les images secondaires.

Après audit Lighthouse manuel, la homepage obtient 94 en performance, 100 en accessibilité, 100 en bonnes pratiques et 100 en SEO.

Je suis maintenant curieux de voir les retombées réelles sur le SEO. À ce jour, Google n'est pas encore repassé sur l'ensemble du site depuis la mise en ligne de la V2. Les fondations techniques sont en place, les URLs sont conservées, les sitemaps répondent correctement, mais il faudra attendre le recrawl pour mesurer l'impact concret.

Le piège à éviter avec l'IA

Le quatrième piège est de croire que l'IA fait tout. Claude Code et Codex ont été très utiles, mais il faut piloter, vérifier, tester et arbitrer. L'IA accélère énormément le travail, mais elle ne remplace pas la stratégie SEO ni le regard critique. C'est un copilote, pas un pilote automatique.

Conclusion

Migrer hors de WordPress n'est pas une décision universelle. Pour beaucoup de sites, WordPress reste une très bonne solution, notamment quand le client veut modifier ses contenus facilement, gérer un blog, publier régulièrement ou administrer plusieurs utilisateurs.

Dans le cas de Printixel, cette migration vers un site PHP sur-mesure était logique. Le site est plus rapide, plus léger, plus maintenable pour mon usage et plus fidèle à ma manière de travailler. Pour un autre projet, je peux très bien recommander WordPress, un site dynamique sur-mesure ou une architecture plus statique : le bon choix dépend toujours du besoin réel.

Cette V2 n'est pas seulement une refonte graphique. C'est un changement d'architecture adapté au site Printixel. Et franchement, ça fait du bien 🙂

Yann Thabuis

Directeur creatif de Printixel, agence de design graphique a Lyon. Expert en identite visuelle, web design et visualisation 3D, je cree des projets sur mesure pour chaque client. Passionne par l'innovation et le detail, je redige egalement des articles pour le blog Printixel, partageant mes connaissances et inspirations.

Suivre sur LinkedIn