In veel Magento-webshops draait de blog al jaren, maar de huidige technologie wordt steeds minder prettig om te onderhouden. Na verloop van tijd ontstaat de behoefte om de architectuur te vereenvoudigen, beter gebruik te maken van native Magento-mechanismen en content te ordenen zonder honderden berichten handmatig te herschrijven.
In veel Magento-webshops draait de blog al jaren, maar de huidige technologie wordt steeds minder prettig om te onderhouden. Na verloop van tijd ontstaat de behoefte om de architectuur te vereenvoudigen, beter gebruik te maken van native Magento-mechanismen en content te ordenen zonder honderden berichten handmatig te herschrijven.
Kowal_Blog lost dit probleem op dankzij een migratiemechanisme van bestaande blogmodules naar een nieuw model dat is gebaseerd op de Magento-catalogus.
Dit betekent dat een blogwissel niet hoeft te leiden tot verlies van eerder redactiewerk of tot het risico van een sterke daling van de zichtbaarheid in zoekmachines.
Wat levert de migratie op
De belangrijkste waarde voor de klant is eenvoudig: content die al bestaat, kan worden overgezet naar de nieuwe oplossing zonder alles vanaf nul op te bouwen.
De migratie maakt het mogelijk om het volgende te behouden en te structureren:
blogberichten,
categorieën,
tags,
basis SEO-gegevens,
de publicatiestructuur,
relaties tussen content en categorieën,
de URL-geschiedenis die nodig is voor redirects.
In de praktijk betekent dit een kortere implementatietijd, minder redactioneel risico en lagere kosten voor de overstap naar een nieuwe oplossing.
Ondersteuning voor bekende Magento-blogs
Het migratiemechanisme is ontwikkeld met echte Magento-implementaties in gedachten, waar meestal een aantal bekende blogextensies worden gebruikt.
Momenteel worden migraties ondersteund vanuit:
Amasty Blog,
Magefan Blog.
Dit is belangrijk, omdat juist deze oplossingen vaak voorkomen in winkels die hun blog los van de Magento-catalogus hebben ontwikkeld en deze nu willen overzetten naar een consistenter model.
Migratiecommando's
De migratie wordt gestart vanuit de Magento-console:
bin/magento kowal:blog:migrate
De parameter bepaalt uit welke module de gegevens moeten worden opgehaald. Beschikbare waarden:
amasty - import uit Amasty Blog Pro,
magefan - import uit Magefan Blog.
Basis migratie vanuit Amasty:
bin/magento kowal:blog:migrate amasty
Basis migratie vanuit Magefan:
bin/magento kowal:blog:migrate magefan
In de basisvariant gebruikt het commando de hoofdblogcategorie die in de configuratie is ingesteld:
Stores > Configuration > Kowal > Blog > Blog Root Categories
Als de configuratie niet is ingesteld of als voor een specifieke uitvoering een andere blogroot moet worden afgedwongen, gebruik dan de optie --root-category-id.
De waarde 123 moet worden vervangen door de identifier van de Magento-categorie waaronder de overgezette blogcategorieën moeten worden aangemaakt. Deze categorie wordt de doelhomepage van de blog en de root voor de geïmporteerde categorieboom.
Prefix van oude URL's
Het commando heeft de optie --legacy-prefix, die de oude prefix van blog-URL's bepaalt die wordt gebruikt bij het aanmaken van 301-redirects.
In deze variant zet de migrator nog steeds categorieën, tags en berichten over, maar slaat het aanmaken van 301-redirects voor oude bericht- en tag-URL's over.
Wat betekenen de varianten van de commando's
De meest gebruikte varianten:
bin/magento kowal:blog:migrate amasty
Importeert gegevens uit Amasty, gebruikt de rootcategorie uit de configuratie en maakt redirects aan met de standaardprefix blog.
bin/magento kowal:blog:migrate magefan
Importeert gegevens uit Magefan, gebruikt de rootcategorie uit de configuratie en maakt redirects aan met de standaardprefix blog.
De migrator zet basis SEO-metadata over waar deze direct kunnen worden gemapt op native Magento-velden.
De belangrijkste regel: na de migratie is een blogbericht een product van het type blog_post, daarom worden de metadata van het bericht opgeslagen in de standaard SEO-velden van een Magento-product. Blogcategorieën zijn cataloguscategorieën, daarom worden hun metadata opgeslagen in de standaard SEO-velden van Magento-categorieën.
Metadata van blogberichten
Voor berichten worden het volgende gemigreerd:
meta title,
meta description,
meta keywords.
In het doeltype blog_post worden de velden opgeslagen als:
meta_titlemeta_descriptionmeta_keyword
Daardoor maakt het bericht na de migratie gebruik van native Magento SEO-mechanismen voor producten: het genereren van de paginatitel, meta description, meta keywords, URL rewrite en ondersteuning voor store view.
Voor Amasty Blog Pro ziet de mapping er als volgt uit:
meta_title gaat naar meta_title,
meta_description gaat naar meta_description,
meta_tags gaat naar meta_keyword.
Voor Magefan Blog ziet de mapping er als volgt uit:
meta_title gaat naar meta_title,
meta_description gaat naar meta_description,
meta_keywords gaat naar meta_keyword.
Als het bronbericht aparte waarden per store view heeft, slaat de migrator deze op als store-viewwaarden van het product. Dit betekent dat meertalige of multi-store metadata van berichten behouden kunnen blijven zonder ze na de migratie handmatig te herschrijven.
Metadata van blogcategorieën
Voor categorieën worden het volgende gemigreerd:
meta title,
meta description,
meta keywords.
In de doelcategorie van Magento worden de velden opgeslagen als:
meta_titlemeta_descriptionmeta_keywords
Voor Amasty Blog Pro ziet de mapping er als volgt uit:
meta_title gaat naar meta_title,
meta_description gaat naar meta_description,
meta_tags gaat naar meta_keywords.
Voor Magefan Blog ziet de mapping er als volgt uit:
meta_title gaat naar meta_title,
meta_description gaat naar meta_description,
meta_keywords gaat naar meta_keywords.
Amasty-categorieën kunnen gegevens per store view hebben en dan slaat de migrator de juiste waarden op op het niveau van de specifieke store view van de Magento-categorie.
Metadata van tags
Tags in Kowal_Blog worden gemodelleerd als opties van het productattribuut blog_tags. Daarom werkt hun migratie anders dan de migratie van berichten en categorieën.
De migrator zet de tagnaam over naar het optielabel van blog_tags en gebruikt de oude URL key of slug van de tag voor het voorbereiden van 301-redirects. Gegevens zoals:
meta title,
meta description,
meta keywords,
meta robots,
tagbeschrijving,
worden uit de bron gelezen en bewaard in de mappinggegevens van de migratie, maar worden niet automatisch opgeslagen als actieve content van de tagpagina in kowal_blog_tag_content.
Na de migratie is het daarom verstandig om de belangrijkste tagpagina's apart te controleren in het paneel Blog > Tags en hun beschrijving en metadata aan te vullen als tags landingspagina's voor SEO-verkeer moeten zijn.
Meta robots en Open Graph
De velden meta_robots worden uit Amasty en Magefan gelezen in de brongegevens van de migratie, maar het huidige doelmodel slaat ze niet automatisch op bij berichten of categorieën als actief frontendveld.
Op dezelfde manier worden aanvullende Open Graph-velden uit Amasty, bijvoorbeeld:
open_graph_meta_title,
open_graph_meta_description,
open_graph_meta_type,
en OG-velden uit Magefan, bijvoorbeeld:
og_title,
og_description,
og_img,
og_type,
bewaard in de migratiegegevens, maar niet automatisch gepubliceerd op de frontend door Kowal_Blog.
Als de klant geavanceerde meta robots of Open Graph gebruikt in de huidige blog, moet hiermee rekening worden gehouden in de audit na de migratie. Mogelijke varianten zijn:
het handmatig instellen van de belangrijkste waarden in de doel-SEO-module,
het voorbereiden van een extra adapter of migratie-extensie,
het gebruik van een externe SEO-module die robots en Open Graph genereert voor producten van het type blog_post en blogcategorieën.
Controle van metadata na de migratie
Na de migratie moet een steekproef van de belangrijkste SEO-URL's worden gecontroleerd:
berichten met het meeste organische verkeer,
blogcategorieën die verkeer uit Google genereren,
tags die hun eigen geïndexeerde pagina's hadden,
berichten met aangepaste meta title en meta description,
versies per store view als de winkel meertalig is.
Minimale controle in het Magento-paneel:
Open het geïmporteerde bericht van het type blog_post.
Controleer Search Engine Optimization.
Vergelijk Meta Title, Meta Description en Meta Keywords met de brongegevens.
Open de geïmporteerde blogcategorie.
Controleer de SEO-sectie van de categorie.
Ga voor belangrijke tags naar Blog > Tags en vul de beschrijving en metadata aan als deze zichtbaar moeten zijn op de frontend.
Migratie zonder content handmatig te herschrijven
Een van de grootste voordelen is dat het niet nodig is om de blog handmatig opnieuw op te bouwen.
In plaats van:
teksten bericht voor bericht te kopiëren,
de categorieënstructuur opnieuw op te bouwen,
tags over te schrijven,
tientallen of honderden adressen handmatig te corrigeren,
kan een gecontroleerde migratie naar Kowal_Blog worden uitgevoerd.
Voor het team van de klant betekent dit minder operationeel werk en voor het project meer voorspelbaarheid.
Bescherming van bestaande SEO
Bij een blogmigratie komt meestal één cruciale vraag naar voren: wat gebeurt er met de bestaande URL's?
Dat is heel terecht, want oude berichten hebben vaak:
al organisch verkeer,
een indexering in Google,
externe links,
een rol in marketingmaterialen,
een koppeling met campagnes of nieuwsbrieven.
Daarom houdt het migratiemechanisme in Kowal_Blog rekening met het aanmaken van redirects voor bekende URL-structuren van berichten en tags. Zo kan worden overgestapt op een nieuw URL-model zonder gebruikers en zoekmachinerobots achter te laten op niet-werkende pagina's.
Daarnaast genereert het systeem rapporten van uitgevoerde redirects en een apart rapport met URL-conflicten, zodat het implementatieteam direct ziet welke paden automatisch zijn afgehandeld en welke een beslissing vereisen.
Een betere basis voor de verdere ontwikkeling van de webshop
Migratie is niet alleen een eenmalige gegevensoverzetting. Het is ook het ordenen van de basis waarop de webshop verder zal draaien.
Na de migratie komt de blog terecht in een model dat gebruikmaakt van native Magento-mechanismen, zoals:
cataloguscategorieën,
store views,
URL rewrites,
EAV-attributen,
standaard Magento SEO,
Magento-beheerformulieren.
Dat vereenvoudigt de ontwikkeling op langere termijn en beperkt het aantal aparte, niet-standaard lagen dat moet worden onderhouden.
Mogelijkheid om migratie op klantverzoek voor te bereiden
Niet elke webshop gebruikt een van de populairste modules. Een deel van de implementaties draait op oudere extensies, maatwerkoplossingen of aangepaste versies van modules die op de markt beschikbaar zijn.
Daarom is het migratiemechanisme ontworpen als uitbreidbaar.
Dit betekent dat naast de kant-en-klare ondersteuning voor bekende Magento-blogs ook migraties kunnen worden voorbereid:
vanuit een andere commerciële blogmodule,
vanuit de eigen oplossing van de klant,
vanuit een niet-standaard datastructuur die in een specifiek project is ontstaan,
vanuit een versie van de extensie die eerder voor een bepaalde webshop is aangepast.
Vanuit commercieel oogpunt is dit een zeer belangrijk voordeel. De klant is niet uitsluitend beperkt tot de lijst van kant-en-klare integraties. Als er in de webshop een niet-standaard blog draait, kan een dedicated migratietraject worden voorbereid voor de specifieke gegevens en het bedrijfsproces.
Voor wie deze mogelijkheid bijzonder waardevol is
Een blogmigratie naar Kowal_Blog is vooral waardevol voor:
webshops met een groot aantal artikelen,
merken die regelmatig SEO-content publiceren,
meertalige projecten,
bedrijven die een blog willen herstructureren zonder bestaand verkeer te verliezen,
webshops die de Magento-architectuur willen vereenvoudigen en het aantal parallelle contentsystemen willen beperken.
Commercieel argument, direct geformuleerd
De klant koopt hier niet alleen een nieuwe blogmodule.
De klant koopt de mogelijkheid om over te stappen van de huidige oplossing naar een model dat consistenter is met Magento:
zonder content handmatig te herschrijven,
met behoud van de waarde van bestaande content,
met controle over redirects,
met een rapport van uitgevoerde bewerkingen,
met de optie om een dedicated migratie voor te bereiden als de huidige blog niet-standaard werkt.
Dit verkort de weg van de beslissing om te veranderen tot de daadwerkelijke lancering van de nieuwe blog en verlaagt de instapdrempel aanzienlijk voor webshops die al een publicatiegeschiedenis hebben.
