Migrer WordPress vers Payload CMS de la bonne manière

Une migration WordPress vers Payload CMS ne se joue pas dans un script d'import. Elle se joue dans la structure du contenu, pensée avant le premier import.

Vous avez déjà pris la décision : votre site WordPress freine plus qu'il n'aide, et Payload CMS fait partie des pistes sérieuses pour le remplacer. Reste la question qui fâche : comment migrer sans tout recommencer, et surtout sans se retrouver, six mois plus tard, avec le même sentiment de blocage qu'avant ?

Cet article ne vous apprendra pas à écrire un script qui va chercher vos contenus via l'API WordPress pour les réinjecter dans Payload. Cette partie existe, elle est bien documentée, et un développeur compétent la mène en quelques jours selon le volume de contenu. Ce qui l'est beaucoup moins, c'est ce qu'il faut décider avant d'écrire ce script, et ce qu'il ne faut surtout pas sacrifier après. C'est cette partie, la moins visible mais la plus déterminante, que nous avons vue mal gérée sur plusieurs projets, y compris des projets déjà migrés vers Payload.

Le vrai risque : changer d'outil sans changer de modèle

On nous a confié un jour la reprise d'un site déjà construit sur Payload CMS. Sur le papier, tout allait bien : la stack était la bonne, l'équipe avait quitté WordPress, le projet tournait. Dans les faits, l'équipe marketing était à nouveau bloquée. Chaque type de page avait ses blocs imposés, sans possibilité d'en ajouter, d'en retirer ou de les réorganiser. Créer une landing un peu différente du modèle prévu supposait de rouvrir le code.

C'est le piège central d'une migration WordPress vers Payload : croire que le problème, c'est WordPress. Le vrai problème, la plupart du temps, c'est l'absence de réflexion sur la structure du contenu. Payload est un CMS code-first : ses collections, ses globals et ses blocks sont exactement ce que vous décidez d'en faire. Rien n'empêche de reconstruire, avec de meilleurs outils, la même rigidité qu'avant.

La méthode : penser la structure avant de coder

C'est là que se joue vraiment la réussite d'une migration, bien avant l'écriture du moindre script d'import. L'objectif n'est pas de copier le site WordPress existant dans Payload, mais de repartir d'un inventaire honnête de vos contenus : quels types de pages avez-vous réellement, quelles sections se répètent, où l'équipe marketing a-t-elle besoin de liberté, où au contraire un cadre strict protège la cohérence de votre marque.

Collections, globals, blocks : à quoi ça sert vraiment

Dans Payload, une collection regroupe des contenus répétables (articles, pages, réalisations, membres d'équipe). Un global correspond à un contenu unique, défini une seule fois (le header, le footer, une page de paramètres). Un block est une section réutilisable qu'on vient assembler pour construire une page (un bloc FAQ, un bloc contenu + image, une galerie, une liste d'articles).

Une page bien pensée dans Payload ressemble souvent à ceci : un champ slug, un title, un hero interchangeable, un tableau de blocks librement composable, et un groupe de champs SEO partagé entre tous les types de contenu. C'est ce découpage, et pas la technologie en elle-même, qui donne à votre équipe la capacité de construire une nouvelle page sans dépendre d'un développeur à chaque fois.

Le bon dosage entre cadre et liberté

Trois postures reviennent souvent, et aucune n'est bonne ou mauvaise en soi : tout dépend de l'endroit où vous placez le curseur. Un WordPress en ACF avec des templates Twig verrouille tout : rassurant pour la cohérence visuelle, mais chaque exception devient un ticket de développement. Elementor, à l'inverse, laisse tout ouvert : rapide à prendre en main, jusqu'au jour où chaque page a sa propre mise en page, où la charte graphique se dilue page après page, et où plus personne ne sait pourquoi telle page fonctionne différemment des autres.

Un Payload bien structuré vise l'entre-deux : un cadre de blocs pensé avec votre direction artistique (pas n'importe quel bloc n'importe où), mais une vraie liberté de composition à l'intérieur de ce cadre. C'est la différence entre donner des LEGO à assembler et donner une statue déjà coulée.

Comment procéder concrètement

Avant d'écrire la moindre ligne de configuration Payload, nous passons systématiquement par un inventaire des contenus existants (types de pages, sections récurrentes, besoins métier spécifiques), puis par une phase de modélisation : quels champs regrouper dans un groupe partagé (SEO, lien, appel à l'action), quelles sections deviennent des blocks réutilisables, quels contenus méritent leur propre collection plutôt qu'un champ noyé dans une page générique.

Cette étape prend du temps, souvent plus que l'import technique lui-même. C'est un choix assumé : une structure mal pensée coûte bien plus cher à corriger a posteriori, une fois que des dizaines de pages ont déjà été créées dessus.

La migration SEO : ce qui ne se négocie pas

Une migration réussie côté structure peut encore se faire rattraper par une migration SEO bâclée. Le principe reste toujours le même : chaque URL qui change doit être redirigée en 301, sans exception, sous peine de perdre le référencement accumulé sur des années.

Concrètement, cela veut dire partir de l'ancien sitemap WordPress, lister l'intégralité des URLs indexées, et construire un plan de redirections avant même la mise en ligne. Croiser ce plan avec Google Search Console (les URLs qui reçoivent encore des clics ou des impressions) et avec GA4 (les pages qui génèrent du trafic ou des conversions) permet de prioriser : certaines pages méritent une attention particulière au mot près, d'autres peuvent être fusionnées ou redirigées vers une page plus pertinente dans la nouvelle architecture.

Pour la migration des contenus eux-mêmes, le choix entre le faire à la main ou via un script dépend surtout du volume. Quelques dizaines de pages et articles se reprennent tranquillement à la main, ce qui permet au passage de nettoyer un contenu vieillissant. Au-delà de quelques centaines, un script d'import devient nécessaire pour des raisons de temps, mais il ne dispense jamais de la relecture ni du plan de redirections construit en amont.

Nous détaillons les bonnes pratiques SEO propres à Payload (métadonnées, structure technique, sitemap) dans notre guide sur le CMS optimisé pour le SEO.

Migrer, oui. Mais avec la bonne base.

Une migration WordPress vers Payload CMS réussie ne se mesure pas au nombre d'articles importés avec succès. Elle se mesure à la liberté que retrouve votre équipe une fois le projet livré, et à la stabilité de votre référencement dans les semaines qui suivent. Les deux se jouent en amont : dans la structure du contenu, pas dans le script d'import.

Si vous envisagez cette transition, notre expertise Payload CMS part toujours de cette étape de modélisation avant d'écrire la moindre ligne de configuration.

Vous avez un projet de migration en tête ? Planifions un échange pour évaluer la structure la plus adaptée à votre contenu.