In molti negozi Magento il blog è attivo da anni, ma la tecnologia attuale smette progressivamente di essere comoda da mantenere. Con il tempo nasce l'esigenza di semplificare l'architettura, sfruttare meglio i meccanismi nativi di Magento e organizzare i contenuti senza riscrivere manualmente centinaia di articoli.
In molti negozi Magento il blog è attivo da anni, ma la tecnologia attuale smette progressivamente di essere comoda da mantenere. Con il tempo nasce l'esigenza di semplificare l'architettura, sfruttare meglio i meccanismi nativi di Magento e organizzare i contenuti senza riscrivere manualmente centinaia di articoli.
Kowal_Blog risolve questo problema grazie a un meccanismo di migrazione dai moduli blog esistenti verso un nuovo modello basato sul catalogo Magento.
Questo significa che cambiare blog non deve comportare la perdita del lavoro editoriale già svolto né il rischio di un brusco calo della visibilità nei motori di ricerca.
Cosa offre la migrazione
Il valore principale per il cliente è semplice: i contenuti già esistenti possono essere trasferiti nella nuova soluzione senza ricostruire tutto da zero.
La migrazione consente di mantenere e organizzare:
articoli del blog,
categorie,
tag,
dati SEO di base,
struttura delle pubblicazioni,
relazioni tra contenuti e categorie,
storico degli URL necessario per i redirect.
In pratica, questo si traduce in tempi di implementazione più brevi, minore rischio editoriale e costi inferiori per il passaggio alla nuova soluzione.
Supporto per i blog Magento più noti
Il meccanismo di migrazione è stato progettato pensando a implementazioni Magento reali, dove più spesso si incontrano alcune note estensioni blog.
Attualmente sono supportate le migrazioni da:
Amasty Blog,
Magefan Blog.
Questo è importante perché proprio queste soluzioni sono spesso presenti nei negozi che hanno sviluppato il blog indipendentemente dal catalogo Magento e oggi vogliono trasferirlo in un modello più coerente.
Comandi di migrazione
La migrazione viene avviata dalla console Magento:
bin/magento kowal:blog:migrate
Il parametro specifica il modulo da cui devono essere prelevati i dati. Valori disponibili:
amasty - importazione da Amasty Blog Pro,
magefan - importazione da Magefan Blog.
Migrazione di base da Amasty:
bin/magento kowal:blog:migrate amasty
Migrazione di base da Magefan:
bin/magento kowal:blog:migrate magefan
Nella variante di base il comando utilizza la categoria radice del blog impostata nella configurazione:
Stores > Configuration > Kowal > Blog > Blog Root Categories
Se la configurazione non è impostata oppure per una specifica esecuzione è necessario forzare una diversa root del blog, occorre usare l'opzione --root-category-id.
Il valore 123 deve essere sostituito con l'identificatore della categoria Magento sotto cui devono essere create le categorie blog trasferite. Questa categoria diventa la pagina principale di destinazione del blog e la root per l'albero delle categorie importato.
Prefisso dei vecchi URL
Il comando dispone dell'opzione --legacy-prefix, che definisce il vecchio prefisso degli URL del blog usato durante la creazione dei redirect 301.
In questa variante il migratore continua a trasferire categorie, tag e articoli, ma omette la creazione dei redirect 301 per i vecchi URL di articoli e tag.
Cosa significano le varianti dei comandi
Le varianti usate più spesso:
bin/magento kowal:blog:migrate amasty
Importa i dati da Amasty, utilizza la categoria root dalla configurazione e crea redirect con il prefisso predefinito blog.
bin/magento kowal:blog:migrate magefan
Importa i dati da Magefan, utilizza la categoria root dalla configurazione e crea redirect con il prefisso predefinito blog.
Il migratore trasferisce i meta dati SEO di base dove possono essere mappati direttamente nei campi nativi di Magento.
La regola principale è questa: dopo la migrazione un articolo del blog è un prodotto di tipo blog_post, quindi i meta dati dell'articolo finiscono nei campi SEO standard del prodotto Magento. Le categorie del blog sono categorie di catalogo, quindi i loro meta dati finiscono nei campi SEO standard delle categorie Magento.
Meta dati degli articoli del blog
Per gli articoli vengono migrati:
meta title,
meta description,
meta keywords.
Nel blog_post di destinazione i campi vengono salvati come:
meta_titlemeta_descriptionmeta_keyword
In questo modo, dopo la migrazione, l'articolo utilizza i meccanismi SEO nativi di Magento per i prodotti: generazione del titolo pagina, meta description, meta keywords, URL rewrite e gestione dello store view.
Per Amasty Blog Pro la mappatura è la seguente:
meta_title va in meta_title,
meta_description va in meta_description,
meta_tags va in meta_keyword.
Per Magefan Blog la mappatura è la seguente:
meta_title va in meta_title,
meta_description va in meta_description,
meta_keywords va in meta_keyword.
Se l'articolo sorgente ha valori separati per store view, il migratore li salva come valori store-view del prodotto. Questo significa che i meta dati degli articoli in ambienti multilingua o multistore possono essere conservati senza doverli riscrivere manualmente dopo la migrazione.
Meta dati delle categorie del blog
Per le categorie vengono migrati:
meta title,
meta description,
meta keywords.
Nella categoria Magento di destinazione i campi vengono salvati come:
meta_titlemeta_descriptionmeta_keywords
Per Amasty Blog Pro la mappatura è la seguente:
meta_title va in meta_title,
meta_description va in meta_description,
meta_tags va in meta_keywords.
Per Magefan Blog la mappatura è la seguente:
meta_title va in meta_title,
meta_description va in meta_description,
meta_keywords va in meta_keywords.
Le categorie Amasty possono avere dati per store view e in tal caso il migratore salva i valori appropriati a livello dello specifico store view della categoria Magento.
Meta dati dei tag
I tag in Kowal_Blog sono modellati come opzioni dell'attributo prodotto blog_tags. Per questo motivo la loro migrazione funziona in modo diverso rispetto alla migrazione di articoli e categorie.
Il migratore trasferisce il nome del tag nell'etichetta dell'opzione blog_tags e utilizza il vecchio URL key o lo slug del tag per preparare i redirect 301. Dati come:
meta title,
meta description,
meta keywords,
meta robots,
descrizione del tag,
vengono letti dalla sorgente e mantenuti nei dati di mappatura della migrazione, ma non vengono salvati automaticamente come contenuto attivo della pagina tag in kowal_blog_tag_content.
Dopo la migrazione vale quindi la pena controllare separatamente le pagine tag più importanti nel pannello Blog > Tags e completarne descrizione e meta dati, se i tag devono funzionare come landing page per il traffico SEO.
Meta robots e Open Graph
I campi meta_robots vengono letti da Amasty e Magefan nei dati sorgente della migrazione, ma l'attuale modello di destinazione non li salva automaticamente né negli articoli né nelle categorie come campo frontend attivo.
In modo analogo, i campi Open Graph aggiuntivi di Amasty, ad esempio:
open_graph_meta_title,
open_graph_meta_description,
open_graph_meta_type,
e i campi OG di Magefan, ad esempio:
og_title,
og_description,
og_img,
og_type,
vengono mantenuti nei dati di migrazione, ma non vengono pubblicati automaticamente sul frontend da Kowal_Blog.
Se il cliente utilizza meta robots avanzati o Open Graph nel blog attuale, occorre tenerne conto nell'audit post-migrazione. Le possibili varianti sono:
impostazione manuale dei valori più importanti nel modulo SEO di destinazione,
preparazione di un adapter aggiuntivo o di un'estensione della migrazione,
utilizzo di un modulo SEO esterno che generi robots e Open Graph per i prodotti di tipo blog_post e per le categorie del blog.
Verifica dei meta dati dopo la migrazione
Dopo la migrazione occorre controllare un campione degli URL SEO più importanti:
articoli con il maggior traffico organico,
categorie del blog che generano accessi da Google,
tag che avevano pagine indicizzate proprie,
articoli con meta title e meta description personalizzati,
versioni per store view, se il negozio è multilingua.
Controllo minimo nel pannello Magento:
Apri l'articolo importato di tipo blog_post.
Controlla Search Engine Optimization.
Confronta Meta Title, Meta Description e Meta Keywords con i dati sorgente.
Apri la categoria blog importata.
Controlla la sezione SEO della categoria.
Per i tag importanti vai in Blog > Tags e completa descrizione e meta dati, se devono essere visibili sul frontend.
Migrazione senza riscrivere manualmente i contenuti
Uno dei maggiori vantaggi è l'assenza della necessità di ricreare manualmente il blog.
Invece di:
copiare i testi articolo per articolo,
ricreare la struttura delle categorie,
riscrivere i tag,
correggere manualmente decine o centinaia di indirizzi,
si può eseguire una migrazione controllata verso Kowal_Blog.
Per il team del cliente questo significa meno lavoro operativo e, per il progetto, maggiore prevedibilità.
Protezione del SEO esistente
Durante la migrazione di un blog emerge quasi sempre una domanda chiave: cosa succederà agli URL esistenti?
È una domanda assolutamente legittima, perché i vecchi articoli spesso:
hanno già traffico organico,
sono indicizzati in Google,
hanno link esterni,
sono utilizzati nei materiali marketing,
sono collegati a campagne o newsletter.
Per questo il meccanismo di migrazione in Kowal_Blog tiene conto della creazione di redirect per le strutture URL note di articoli e tag. Questo consente di passare a un nuovo modello URL senza lasciare utenti e crawler dei motori di ricerca su pagine non funzionanti.
Inoltre il sistema genera report dei redirect eseguiti e un report separato dei conflitti di indirizzo, grazie ai quali il team di implementazione vede subito quali percorsi sono stati gestiti automaticamente e quali richiedono una decisione.
Una base migliore per l'ulteriore sviluppo del negozio
La migrazione non è solo un trasferimento una tantum dei dati. È anche una riorganizzazione delle fondamenta su cui il negozio continuerà a lavorare.
Dopo la migrazione il blog passa a un modello che utilizza i meccanismi nativi di Magento, come:
categorie di catalogo,
store views,
URL rewrites,
attributi EAV,
SEO standard di Magento,
form amministrativi di Magento.
Questo semplifica lo sviluppo nel lungo periodo e riduce il numero di livelli separati e personalizzati da mantenere.
Possibilità di preparare una migrazione su richiesta del cliente
Non tutti i negozi utilizzano uno dei moduli più diffusi. Alcune implementazioni funzionano su estensioni più vecchie, soluzioni proprietarie o versioni modificate di moduli disponibili sul mercato.
Per questo il meccanismo di migrazione è stato progettato in modo estendibile.
Ciò significa che, oltre al supporto pronto per i blog Magento più noti, è possibile preparare la migrazione anche:
da un altro modulo blog commerciale,
da una soluzione proprietaria del cliente,
da una struttura dati personalizzata creata in un progetto specifico,
da una versione dell'estensione precedentemente modificata per quel negozio.
Dal punto di vista commerciale questo è un vantaggio molto importante. Il cliente non è limitato esclusivamente all'elenco delle integrazioni già pronte. Se nel negozio è in funzione un blog personalizzato, si può preparare un percorso di migrazione dedicato ai suoi dati specifici e al suo processo di business.
Per chi questa possibilità è particolarmente preziosa
La migrazione del blog verso Kowal_Blog sarà particolarmente utile per:
negozi con un gran numero di articoli,
brand che pubblicano regolarmente contenuti SEO,
progetti multilingua,
aziende che pianificano una ristrutturazione del blog senza perdere il traffico esistente,
negozi che vogliono semplificare l'architettura Magento e ridurre il numero di sistemi di contenuto paralleli.
Argomento di vendita, in modo diretto
Qui il cliente non acquista soltanto un nuovo modulo blog.
Acquista la possibilità di passare dalla soluzione attuale a un modello più coerente con Magento:
senza riscrivere manualmente i contenuti,
mantenendo il valore del content esistente,
con controllo sui redirect,
con un report delle operazioni eseguite,
con l'opzione di preparare una migrazione dedicata se il blog attuale funziona in modo non standard.
Questo accorcia il percorso dalla decisione di cambiare all'effettiva attivazione del nuovo blog e abbassa in modo significativo la barriera d'ingresso per i negozi che hanno già una storia di pubblicazione.
