De WordPress à Astro : un site de contenu sans base de données dans le chemin d’accès.

Ce qui est transféré de WordPress vers Astro, et ce qui ne l’est pas?

L'export WXR embarque vos articles, pages, catégories, balises, auteurs, images mises en avant et dates de publication d'origine : tout cela passe sans encombre. Mais vos plugins, votre thème et vos écrans d'administration restent de côté. L'export peut aussi inclure vos commentaires et champs personnalisés. Il ignore en revanche les réglages du site et les fichiers joints eux-mêmes, donc récupérez vos médias à part. Dans Astro, votre contenu rejoint des collections qui chargent à la compilation des fichiers Markdown, MDX, Markdoc, YAML, TOML ou JSON. Votre interface d'administration, elle, reste inchangée.

Vos types de publications personnalisés deviennent des collections dont vous définissez le schéma. Rien de piégeux ici. Vos pages Elementor, elles, sortent dans le JSON propre à Elementor : vous devez reconstruire leur mise en page sous forme de composants au lieu de la convertir directement. Vos commentaires exigent un service hébergé et vos formulaires un point de terminaison. Les champs de votre plugin SEO, eux, doivent passer dans le frontmatter. Et si votre domaine change, attendez-vous à voir les URL de vos médias casser, un problème documenté dans la section « Export » du Trac de WordPress.

Comment planifiez-vous la structure des URL et les redirections afin de préserver votre trafic de recherche ??

Pour organiser ce chantier, listez toutes les URL publiques de votre site et associez chacune à sa nouvelle adresse avant d'écrire le code Astro. Commencez par ce tableau [avant le code]. Le plan du site de votre plugin SEO liste déjà les articles, les pages, les types de publications personnalisés et les taxonomies, avec leurs dates de dernière modification : prenez-le comme point de départ. Si vous conservez tous les slugs, votre tableau de redirection ne contiendra que les exceptions.

Choisissez ensuite comment gérer vos redirections. La configuration d'Astro associe une route à une destination, et elle accepte les routes dynamiques comme /blog/[...slug]. Avec un adaptateur serveur ou un adaptateur statique configuré en sortie statique, vous renvoyez de vrais codes 301 et 308. Sans adaptateur ? Vous n'avez qu'une balise meta refresh, sans code d'état : un signal faible, alors que Google recommande une redirection permanente côté serveur.

Surveillez vos barres obliques finales : selon Astro, les redirections ne peuvent pas encore les gérer, donc testez leur comportement chez votre hébergeur. Ne vous fiez pas à des suppositions. Évitez les chaînes de redirections et vérifiez que vos balises « canonical » pointent vers les nouvelles URL. Maintenez ensuite vos redirections au moins un an : en supprimer une trop tôt revient à perdre du trafic.

Comment transférer le contenu depuis WordPress : exportation, API ou exploration ??

Menez cette migration avec un export pour la structure et l'API REST pour les rattrapages incrémentiels. Et n'explorez que ce qui manque dans ces deux sources. Votre fichier WXR, issu d'un export natif de WordPress ou d'un plugin, contient les articles, les termes, les commentaires et les auteurs, ainsi que les enregistrements de pièces jointes. Les fichiers joints eux-mêmes n'y figurent pas : récupérez vos médias séparément, ou passez par un plugin qui génère des archives .wxrz ou .zip.

Votre API REST renvoie les articles, les pages et les médias en JSON aux adresses /wp/v2/posts, /wp/v2/pages et /wp/v2/media. Pensez à paginer vos médias : `per_page` vaut 10 par défaut, tandis que `modified_after` indique ce qui a changé depuis votre dernière récupération. Et si vous construisez vos pages avec Elementor, exportez leur JSON (un plugin peut aussi enregistrer chaque article en .html si vous tenez à manipuler des fichiers).

Avant d’écrire la moindre ligne de code, comparez les données extraites à la liste complète des contenus publiés, des termes, des auteurs et des URL d’origine. Cherchez d’abord les manques. Si vous en trouvez sans explication, arrêtez-vous net pour les corriger avant de passer au développement : plus tard, un oubli laissé de côté sera bien plus difficile à retracer.

Quels avantages vos rédacteurs tirent-ils d’Astro par rapport à WordPress ??

Vos rédacteurs perdent l’interface d’administration de WordPress et ses extensions, mais ils gagnent des déploiements en prévisualisation et un site sans correctif à appliquer. Le compromis est bien réel. Si vous gardez le contenu en Markdown, vos rédacteurs publient en modifiant un fichier, en faisant un commit dans Git, puis en lançant une compilation. Une source présente d'ailleurs les aperçus locaux comme un obstacle majeur pour les profils non techniques ; testez donc ce flux avec votre propre équipe (elle vous le dira très vite).

Vous pouvez associer Astro à un CMS « headless » pour que vos rédacteurs remplissent des champs plutôt que des fichiers. Avec l’édition visuelle de Sanity, ils cliquent sur un élément dans un aperçu et arrivent directement au champ correspondant dans Studio ; la documentation de Sanity indique d’ailleurs qu’Astro est pris en charge. Mais en contrepartie, vous gérez un deuxième système qui héberge votre contenu, avec ses propres identifiants de connexion.

Et vous perdez aussi l’espace d’édition visuel de WordPress : quand vos mises en page changeront, il faudra forcément faire appel à un développeur.

Combien de temps dure une migration de WordPress vers Astro, et quels sont les facteurs qui déterminent l’ampleur de la tâche ??

Votre calendrier dépend de cinq facteurs que vous pouvez déjà évaluer aujourd’hui : le nombre de vos URL et vos types de contenu. Ajoutez vos médias, vos intégrations et vos paramètres régionaux. Commencez par les recenser. Il n’existe pas de chiffre universel ; méfiez-vous donc de toute estimation qui les ignore. Une étude de cas publiée fait état d’une migration de 22 jours, mais votre site est peut-être plus lourd ou bien plus simple que celui-ci.

Chaque facteur ajoute du travail, et vous pouvez tout à fait l’anticiper. Plus d’URL, c’est un tableau de redirections plus long et davantage de contrôles de parité. Avec plus de types de contenu, vous avez davantage de schémas à définir. Il faut aussi récupérer et réhéberger vos fichiers multimédias ; vos formulaires, commentaires et outils d’analyse demandent chacun un service de remplacement. Enfin, chaque locale multiplie les vérifications hreflang et celles du plan du site.

Je planifie et mène ce type d’opérations, et j’en estime l’ampleur à partir de ces facteurs. Commencez par l’évaluation gratuite. Vous verrez ainsi le poids de votre script, vos en-têtes et vos données structurées avant de vous engager : les chiffres bruts valent toujours mieux que les avis.

Quand ne faut-il pas passer de WordPress à Astro ??

Ne changez pas de plateforme si votre site exige des connexions, de la personnalisation ou beaucoup d’interactivité : c’est alors une application, et mieux vaut choisir Next.js avec un CMS « headless » comme Sanity ou Contentful. Évitez aussi de changer si de nombreux rédacteurs travaillent chaque jour sur votre site et dépendent de l’interface d’administration visuelle et de ses extensions. Leurs habitudes quotidiennes font partie de vos coûts.

Rester sur votre plateforme actuelle est un choix judicieux lorsque vos pages fonctionnent déjà bien, que vos rédacteurs publient sans difficulté et que quelqu’un applique les mises à jour et les correctifs des plugins. Un changement coûte du temps à votre équipe. Il expose aussi votre trafic de référencement à des risques inutiles, pour des gains dont vous n’avez peut-être pas besoin. Migrez plutôt lorsque votre site est essentiellement statique, que vos modifications ne passent pas par un CMS et que vos frais d’hébergement et de mise à jour dépassent le coût d’utilisation de l’interface d’administration.

Votre note d’évaluation donne le test le plus rapide : si le résultat est bon, vous n’avez sans doute aucune raison valable de changer quoi que ce soit.

Vos questions, nos réponses.

À lire ensuite.

1. 01Alternatives à WordPressRestez, optez pour le mode « headless » ou changez de plateforme : c'est à vos pages d'en décider.
2. 02De WordPress à Next.jsD'abord WordPress « headless », ou importation du contenu dans Sanity.
3. 03Analyse SEO AstroÎles, collections de contenu, données structurées, Core Web Vitals.