Une blogueuse spécialisée en cuisine, avec plusieurs années de contenu accumulé sur un abonnement WordPress.com Business utilisant déjà un thème bloc du catalogue de la plateforme, souhaitait migrer vers un hébergement autonome pour reprendre la main sur ses coûts et éviter les limites de plugins imposées par certains paliers d’abonnement. Le contenu représentait l’essentiel de la valeur du site : plus de trois cents recettes, chacune avec ses propres images et son organisation en catégories.
Cette migration a révélé un écart important entre ce que l’export standard promet et ce qui arrive réellement intact de l’autre côté, en particulier concernant tout ce qui touche à la configuration du thème bloc plutôt qu’au contenu éditorial lui-même.
Ce qui s’exporte proprement
L’export WordPress.com, disponible depuis Outils > Exporter puis via un fichier XML au format WordPress eXtended RSS, a transféré sans accroc l’ensemble du contenu éditorial : les trois cents articles de recette, leurs catégories, leurs étiquettes, les commentaires des lecteurs et les métadonnées de base comme les dates de publication. Les images, elles, ont nécessité un export séparé via l’outil de migration intégré, plus fiable que le XML seul pour ce volume de médias.
wp import export-wordpress-com.xml --authors=createCe qui ne suit pas automatiquement : la configuration du thème bloc
Le thème bloc utilisé sur WordPress.com, propre au catalogue de la plateforme, n’était disponible qu’en version restreinte ou payante côté auto-hébergement, avec des différences de fonctionnalités notables. Sur les douze templates que comptait le site d’origine, quatre exploitaient des blocs ou des réglages spécifiques à l’écosystème WordPress.com (un bloc de newsletter intégré à la plateforme, un widget d’abonnement propre à Jetpack), sans équivalent direct en dehors de cet environnement.
Ces quatre templates ont dû être reconstruits manuellement avec des blocs natifs et un service de newsletter tiers standard, plutôt que simplement transférés. Le reste des templates, reposant sur des blocs natifs classiques (Groupe, Query Loop, Image), s’est recréé fidèlement sans perte notable une fois le nouveau thème bloc installé côté hébergement autonome.
Le cas des styles globaux personnalisés
La blogueuse avait personnalisé ses couleurs et sa typographie depuis la zone Styles de l’éditeur, directement sur WordPress.com. Ces personnalisations, stockées comme toujours en post wp_global_styles, n’apparaissent dans aucun export XML standard, celui-ci se concentrant sur le contenu éditorial et non sur la configuration du thème. La seule méthode fiable retrouvée a consisté à consulter manuellement chaque réglage de couleur et de police dans l’interface WordPress.com avant la bascule, pour les reconfigurer à l’identique sur le nouveau site.
wp eval '
$styles = wp_get_global_styles();
echo wp_json_encode( $styles["color"] ?? array(), JSON_PRETTY_PRINT );
'Cette commande, exécutée après une première reconstruction approximative des couleurs, a permis de vérifier que les valeurs saisies manuellement correspondaient bien à ce qui avait été relevé sur l’ancienne plateforme, avant validation finale avec la cliente.
Jetpack et les fonctionnalités liées à la plateforme
Plusieurs fonctionnalités actives par défaut sur WordPress.com (statistiques de visite intégrées, protection anti-spam automatique, sauvegardes quotidiennes) dépendaient du module Jetpack lié au compte de la plateforme. Une fois le site auto-hébergé, ces fonctionnalités ont nécessité soit une installation de Jetpack en mode autonome avec ses propres tarifs, soit un remplacement par des solutions équivalentes standards (un plugin de sauvegarde dédié, un service d’analyse d’audience distinct).
Checklist de migration retenue pour ce projet
- Exporter le contenu éditorial complet via XML, en vérifiant l’intégrité des images séparément.
- Relever manuellement, capture d’écran à l’appui, l’ensemble des personnalisations de la zone Styles avant la bascule.
- Identifier les templates utilisant des blocs propres à la plateforme d’origine, à isoler pour reconstruction.
- Lister les fonctionnalités Jetpack actives et prévoir leur équivalent côté hébergement autonome.
- Tester l’intégralité des URL existantes après migration, pour vérifier l’absence de liens brisés côté SEO.
Un export de contenu réussi ne garantit jamais, à lui seul, une migration de configuration réussie. Les deux couches, éditoriale et technique, doivent être vérifiées séparément avant toute bascule définitive du nom de domaine.
En résumé
La migration d’un blog WordPress.com vers un hébergement autonome transfère fidèlement le contenu éditorial, mais laisse de côté toute la configuration liée à la plateforme elle-même : styles globaux, templates spécifiques et fonctionnalités Jetpack demandent une vérification manuelle poste par poste. Anticiper cette double couche de migration, plutôt que de se fier au seul export XML, évite bien des découvertes désagréables une fois le nom de domaine basculé.
