Dans de nombreuses boutiques Magento, le blog fonctionne depuis des années, mais sa technologie actuelle devient de moins en moins pratique à maintenir. Avec le temps, le besoin apparaît de simplifier l architecture, de mieux exploiter les mécanismes natifs de Magento et d organiser les contenus sans réécrire manuellement des centaines d articles.
Dans de nombreuses boutiques Magento, le blog fonctionne depuis des années, mais sa technologie actuelle devient de moins en moins pratique à maintenir. Avec le temps, le besoin apparaît de simplifier l architecture, de mieux exploiter les mécanismes natifs de Magento et d organiser les contenus sans réécrire manuellement des centaines d articles.
Kowal_Blog résout ce problème grâce à un mécanisme de migration depuis les modules de blog existants vers un nouveau modèle basé sur le catalogue Magento.
Cela signifie qu un changement de blog ne doit pas entraîner la perte du travail éditorial déjà réalisé ni le risque d une chute brutale de la visibilité dans les moteurs de recherche.
Ce qu apporte la migration
La principale valeur pour le client est simple : les contenus déjà existants peuvent être transférés vers la nouvelle solution sans reconstruire l ensemble depuis zéro.
La migration permet de conserver et d organiser :
les articles de blog,
les catégories,
les tags,
les données SEO de base,
la structure de publication,
les relations entre le contenu et les catégories,
l historique des URL nécessaire aux redirections.
En pratique, cela signifie un temps de déploiement plus court, un risque éditorial réduit et un coût de transition vers la nouvelle solution plus faible.
Prise en charge de blogs Magento connus
Le mécanisme de migration a été conçu pour des implémentations Magento réelles, où l on rencontre le plus souvent plusieurs extensions de blog bien connues.
Les migrations actuellement prises en charge concernent :
Amasty Blog,
Magefan Blog.
C est important, car ce sont justement ces solutions que l on retrouve souvent dans des boutiques ayant développé leur blog indépendamment du catalogue Magento et qui souhaitent aujourd hui le déplacer vers un modèle plus cohérent.
Commandes de migration
La migration est lancée depuis la console Magento :
bin/magento kowal:blog:migrate
Le paramètre indique le module depuis lequel les données doivent être récupérées. Valeurs disponibles :
amasty - import depuis Amasty Blog Pro,
magefan - import depuis Magefan Blog.
Migration de base depuis Amasty :
bin/magento kowal:blog:migrate amasty
Migration de base depuis Magefan :
bin/magento kowal:blog:migrate magefan
Dans la variante de base, la commande utilise la catégorie racine du blog définie dans la configuration :
Stores > Configuration > Kowal > Blog > Blog Root Categories
Si la configuration n est pas définie, ou s il faut forcer une autre racine de blog pour une exécution précise, il convient d utiliser l option --root-category-id.
La valeur 123 doit être remplacée par l identifiant de la catégorie Magento sous laquelle les catégories de blog migrées doivent être créées. Cette catégorie devient la page principale cible du blog ainsi que la racine de l arbre de catégories importé.
Préfixe des anciennes URL
La commande propose l option --legacy-prefix, qui définit l ancien préfixe des URL du blog utilisé lors de la création des redirections 301.
Dans cette variante, le migrateur transfère toujours les catégories, les tags et les articles, mais ignore la création des redirections 301 pour les anciennes URL des articles et des tags.
Signification des variantes de commandes
Variantes les plus utilisées :
bin/magento kowal:blog:migrate amasty
Importe les données depuis Amasty, utilise la catégorie racine définie dans la configuration et crée des redirections avec le préfixe par défaut blog.
bin/magento kowal:blog:migrate magefan
Importe les données depuis Magefan, utilise la catégorie racine définie dans la configuration et crée des redirections avec le préfixe par défaut blog.
Le migrateur transfère les métadonnées SEO de base là où elles peuvent être directement mappées sur les champs natifs de Magento.
Règle la plus importante : après la migration, un article de blog est un produit de type blog_post, c est pourquoi les métadonnées de l article sont enregistrées dans les champs SEO standards des produits Magento. Les catégories du blog sont des catégories du catalogue, c est pourquoi leurs métadonnées sont enregistrées dans les champs SEO standards des catégories Magento.
Métadonnées des articles de blog
Pour les articles, les éléments migrés sont :
meta title,
meta description,
meta keywords.
Dans le blog_post cible, les champs sont enregistrés comme suit :
meta_titlemeta_descriptionmeta_keyword
Ainsi, après la migration, l article utilise les mécanismes SEO natifs de Magento pour les produits : génération du titre de page, meta description, meta keywords, URL rewrite et gestion des store views.
Pour Amasty Blog Pro, le mapping est le suivant :
meta_title va dans meta_title,
meta_description va dans meta_description,
meta_tags va dans meta_keyword.
Pour Magefan Blog, le mapping est le suivant :
meta_title va dans meta_title,
meta_description va dans meta_description,
meta_keywords va dans meta_keyword.
Si l article source possède des valeurs distinctes par store view, le migrateur les enregistre comme valeurs de produit par store view. Cela signifie que les métadonnées d articles multilingues ou multi-boutiques peuvent être conservées sans réécriture manuelle après la migration.
Métadonnées des catégories du blog
Pour les catégories, les éléments migrés sont :
meta title,
meta description,
meta keywords.
Dans la catégorie Magento cible, les champs sont enregistrés comme suit :
meta_titlemeta_descriptionmeta_keywords
Pour Amasty Blog Pro, le mapping est le suivant :
meta_title va dans meta_title,
meta_description va dans meta_description,
meta_tags va dans meta_keywords.
Pour Magefan Blog, le mapping est le suivant :
meta_title va dans meta_title,
meta_description va dans meta_description,
meta_keywords va dans meta_keywords.
Les catégories Amasty peuvent disposer de données par store view et, dans ce cas, le migrateur enregistre les valeurs correspondantes au niveau du store view concerné de la catégorie Magento.
Métadonnées des tags
Dans Kowal_Blog, les tags sont modélisés comme des options de l attribut produit blog_tags. Pour cette raison, leur migration fonctionne différemment de celle des articles et des catégories.
Le migrateur transfère le nom du tag vers le libellé de l option blog_tags et utilise l ancien URL key ou le slug du tag pour préparer les redirections 301. Les données telles que :
meta title,
meta description,
meta keywords,
meta robots,
description du tag,
sont lues depuis la source et conservées dans les données de mapping de la migration, mais ne sont pas automatiquement enregistrées comme contenu actif de la page de tag dans kowal_blog_tag_content.
Après la migration, il est donc utile de vérifier séparément les principales pages de tags dans le panneau Blog > Tags et de compléter leur description ainsi que leurs métadonnées si les tags doivent servir de landing pages pour le trafic SEO.
Meta robots et Open Graph
Les champs meta_robots sont lus depuis Amasty et Magefan dans les données source de migration, mais le modèle cible actuel ne les enregistre pas automatiquement sur les articles ni sur les catégories comme champ frontend actif.
De manière analogue, les champs Open Graph supplémentaires d Amasty, par exemple :
open_graph_meta_title,
open_graph_meta_description,
open_graph_meta_type,
ainsi que les champs OG de Magefan, par exemple :
og_title,
og_description,
og_img,
og_type,
sont conservés dans les données de migration, mais ne sont pas automatiquement publiés sur le frontend par Kowal_Blog.
Si le client utilise des meta robots avancés ou Open Graph sur son blog actuel, il faut en tenir compte dans l audit post-migration. Les variantes possibles sont :
la définition manuelle des valeurs les plus importantes dans le module SEO cible,
la préparation d un adaptateur supplémentaire ou d une extension de migration,
l utilisation d un module SEO externe qui génère robots et Open Graph pour les produits de type blog_post ainsi que pour les catégories du blog.
Contrôle des métadonnées après la migration
Après la migration, il faut vérifier un échantillon des URL SEO les plus importantes :
les articles générant le plus de trafic organique,
les catégories du blog qui génèrent des visites depuis Google,
les tags qui avaient leurs propres pages indexées,
les articles avec des meta title et meta description personnalisés,
les versions par store view si la boutique est multilingue.
Contrôle minimal dans le panneau Magento :
Ouvrez l article importé de type blog_post.
Vérifiez Search Engine Optimization.
Comparez Meta Title, Meta Description et Meta Keywords avec les données source.
Ouvrez la catégorie de blog importée.
Vérifiez la section SEO de la catégorie.
Pour les tags importants, allez dans Blog > Tags et complétez la description ainsi que les métadonnées si elles doivent être visibles sur le frontend.
Migration sans réécriture manuelle du contenu
L un des plus grands avantages est l absence de nécessité de reconstruire manuellement le blog.
Au lieu de :
copier les textes article par article,
recréer la structure des catégories,
réécrire les tags,
corriger manuellement des dizaines ou des centaines d URL,
il est possible de réaliser une migration contrôlée vers Kowal_Blog.
Pour l équipe du client, cela signifie moins de travail opérationnel et, pour le projet, une meilleure prévisibilité.
Protection du SEO existant
Lors d une migration de blog, une question clé revient le plus souvent : que va-t-il arriver aux URL existantes ?
Cette question est tout à fait légitime, car les anciens articles :
génèrent déjà du trafic organique,
sont indexés dans Google,
ont des liens externes,
sont utilisés dans les supports marketing,
sont reliés à des campagnes ou à des newsletters.
C est pourquoi le mécanisme de migration de Kowal_Blog prend en compte la création de redirections pour les structures connues d URL d articles et de tags. Cela permet de passer à un nouveau modèle d URL sans laisser les utilisateurs ni les robots des moteurs de recherche sur des pages qui ne fonctionnent plus.
De plus, le système génère des rapports sur les redirections effectuées ainsi qu un rapport séparé sur les collisions d URL, ce qui permet à l équipe de déploiement de voir immédiatement quels chemins ont été gérés automatiquement et lesquels nécessitent une décision.
Une meilleure base pour le développement futur de la boutique
La migration n est pas seulement un transfert ponctuel de données. C est aussi une mise en ordre des fondations sur lesquelles la boutique continuera de fonctionner.
Après la migration, le blog passe dans un modèle qui utilise les mécanismes natifs de Magento, tels que :
les catégories du catalogue,
les store views,
les URL rewrites,
les attributs EAV,
le SEO standard de Magento,
les formulaires d administration Magento.
Cela simplifie le développement à long terme et réduit le nombre de couches distinctes et non standard à maintenir.
Possibilité de préparer une migration à la demande du client
Toutes les boutiques n utilisent pas l un des modules les plus populaires. Certaines implémentations reposent sur des extensions plus anciennes, des solutions sur mesure ou des versions modifiées de modules disponibles sur le marché.
C est pourquoi le mécanisme de migration a été conçu de manière extensible.
Cela signifie qu en plus de la prise en charge prête à l emploi de blogs Magento connus, il est également possible de préparer une migration :
depuis un autre module de blog commercial,
depuis une solution propriétaire du client,
depuis une structure de données non standard créée dans un projet spécifique,
depuis une version d extension précédemment modifiée pour une boutique donnée.
D un point de vue commercial, c est un avantage très important. Le client n est pas limité uniquement à la liste des intégrations prêtes à l emploi. Si une boutique utilise un blog non standard, il est possible de préparer un parcours de migration dédié à ses données concrètes et à son processus métier.
Pour qui cette possibilité est particulièrement précieuse
La migration du blog vers Kowal_Blog sera particulièrement utile pour :
les boutiques avec un grand nombre d articles,
les marques qui publient régulièrement du contenu SEO,
les projets multilingues,
les entreprises qui prévoient une refonte du blog sans perdre le trafic existant,
les boutiques qui souhaitent simplifier l architecture Magento et réduire le nombre de systèmes de contenu parallèles.
L argument commercial en toute clarté
Le client n achète pas ici uniquement un nouveau module de blog.
Il achète la possibilité de passer de la solution actuelle à un modèle plus cohérent avec Magento :
sans réécriture manuelle du contenu,
en préservant la valeur du contenu existant,
avec un contrôle des redirections,
avec un rapport des opérations effectuées,
avec l option de préparer une migration dédiée si le blog actuel fonctionne de manière non standard.
Cela raccourcit le chemin entre la décision de changer et la mise en ligne effective du nouveau blog, et réduit considérablement la barrière d entrée pour les boutiques qui disposent déjà d un historique de publication.
