Magento-migratie zonder SEO-verlies: complete voorbereiding en go-livecheck

Een Magento-migratie voelt vaak als een technisch project: data overzetten, een nieuw thema bouwen, koppelingen aansluiten en op vrijdagavond de schakelaar omzetten. Voor zoekmachines en klanten is het iets anders. Zij zien in korte tijd mogelijk duizenden gewijzigde URL’s, andere navigatie, nieuwe productdata, aangepaste content en een webshop die zich opnieuw moet bewijzen.

Daarom bestaat een Magento-migratie zonder SEO-schade niet uit één redirectbestand en een controle na livegang. Het is een keten van beslissingen die begint vóór het ontwerp en pas eindigt wanneer verkeer, indexatie, omzet en technische stabiliteit weer aantoonbaar op niveau zijn.

Volledig risicoloos wordt een migratie nooit. Google waarschuwt zelf dat tijdelijke schommelingen normaal zijn terwijl oude en nieuwe URL’s opnieuw worden gecrawld en geïndexeerd. Het doel is dus niet om een onrealistische garantie te geven, maar om vermijdbaar verlies te voorkomen, afwijkingen snel te zien en vooraf te weten wie moet handelen.

De rolverdeling: MagentoSEO.nl migreert geen database, schrijft geen redirects in de serverconfiguratie en past geen Magento-code aan. Wij inventariseren de organische uitgangssituatie, maken het SEO-migratieplan, vertalen dit naar testbare requirements voor de webbouwer en controleren vóór en na livegang of de afgesproken werking aanwezig is.

Begin met de vraag: wat verandert er eigenlijk?

“We migreren naar Magento” kan vijf verschillende projecten betekenen. Die varianten hebben niet dezelfde SEO-risico’s.

1. Magento 1 naar Magento Open Source 2 of Adobe Commerce 2. Niet alleen de applicatie verandert; ook thema’s, extensies, datamodellen, URL-rewrites en koppelingen moeten opnieuw worden beoordeeld.

2. Een ander platform naar Magento. Producttypen, categorieën, filters, contentvelden en klantprocessen moeten naar een ander model worden vertaald.

3. Magento naar een ander platform. De bestaande Magento-structuur is dan het vertrekpunt, maar het nieuwe systeem bepaalt welke functionaliteit en URL-logica behouden kan blijven.

4. Een nieuwe frontend op dezelfde Magento-installatie. Een overstap naar bijvoorbeeld Hyvä of een headless storefront kan URL’s gelijk laten, maar HTML-output, interne links, structured data, rendering en performance sterk veranderen.

5. Een reorganisatie van domeinen, landen of storeviews. Denk aan meerdere domeinen samenvoegen, een internationale mapstructuur invoeren of talen naar aparte storefronts verplaatsen.

Maak deze veranderingen expliciet. Een project met dezelfde domeinnaam kan alsnog een zware sitemigratie zijn als categorieën, URL keys, navigatie en templates wijzigen. Andersom kan een verhuizing van hosting zonder URL-wijzigingen vooral een infrastructuurproject zijn.

Google adviseert bij grote wijzigingen waar mogelijk niet alles tegelijk te veranderen. Een nieuw domein, een nieuw CMS, een compleet redesign en een nieuwe navigatie in één release maken oorzaken achteraf moeilijk te scheiden. Soms kan faseren niet, maar dan hoort het extra risico bewust in de planning en monitoring te staan.

Maak eerst een nulmeting, niet pas wanneer het verkeer daalt

Na livegang wil je kunnen beantwoorden of een daling door de migratie komt, door seizoen, door een campagne die stopte of door een bredere marktbeweging. Dat lukt alleen met een vastgelegde uitgangssituatie.

Een bruikbare nulmeting bevat minimaal:

• organische landingspagina’s met klikken, vertoningen, posities en omzet;

• indexeerbare URL’s per paginatype en storeview;

• bestaande XML-sitemaps en hun indexatiestatus;

• interne links en belangrijke navigatiepaden;

• statuscodes, redirects, canonicals, robotsregels en hreflang;

• titles, meta descriptions, headings en inhoudelijke hoofdblokken;

• product-, categorie-, merk-, CMS- en adviespagina’s met backlinks;

• gestructureerde productgegevens, breadcrumbs en andere relevante markup;

• Core Web Vitals en representatieve labmetingen;

• belangrijke analytics-events, conversiestappen en omzetwaarden;

• actieve productfeeds, advertentielandingspagina’s en campagne-URL’s;

• patronen in serverlogs en veel gecrawlde filter- of parameter-URL’s.

Sla niet alleen gemiddelden op. Een webshop kan op totaalniveau stabiel lijken terwijl een categorie die een groot deel van de organische omzet levert uit de index verdwijnt. Segmentatie per land, apparaat, paginatype en commerciële waarde maakt problemen zichtbaar.

Leg bij iedere export de datum, databron en meetperiode vast. Daarmee voorkom je discussies over dashboards die later opnieuw zijn verwerkt of over cijfers uit niet-vergelijkbare perioden.

De URL-mapping is een beslisdocument, geen zoek-en-vervangbestand

De URL-mapping verbindt iedere relevante oude URL aan een bewuste bestemming. Dat klinkt eenvoudig, totdat een catalogus duizenden producten, categorieën, merken, filters, adviespagina’s, afbeeldingen en taalvarianten bevat.

Begin met meer bronnen dan alleen de oude sitemap:

• een crawl van de huidige webshop;

• XML-sitemaps;

• landingspagina’s uit Search Console en analytics;

• URL’s met externe links;

• actieve feed- en advertentie-URL’s;

• serverlogs voor URL’s die bots en gebruikers daadwerkelijk bezoeken;

• exports uit Magento van producten, categorieën, CMS-pagina’s en URL-rewrites;

• afbeeldingen, downloads en andere assets met organisch verkeer of links.

Geef iedere oude URL vervolgens een bestemming en een reden. Mogelijke uitkomsten zijn:

Beslissing	Wanneer passend	Technisch resultaat
Behouden	De pagina blijft inhoudelijk en commercieel gelijk	Dezelfde URL met status 200
Eén-op-één verplaatsen	Er is een duidelijke equivalente nieuwe pagina	Permanente server-side redirect naar de eind-URL
Samenvoegen	Meerdere oude pagina’s worden één betere pagina	Iedere relevante oude URL redirect naar die geconsolideerde pagina
Vervangen	Een product of pagina heeft een logische opvolger	Redirect naar de inhoudelijk dichtstbijzijnde opvolger
Verwijderen	Er is geen relevante vervanging en geen blijvende waarde	Echte 404 of 410, zonder misleidende omleiding

Stuur niet duizenden verwijderde producten naar de homepage. Google noemt zulke irrelevante bulkredirects expliciet een risico: ze helpen de bezoeker niet en kunnen als soft 404 worden behandeld. Ook redirectketens moeten worden vermeden. Laat de oude URL direct naar de definitieve bestemming wijzen, niet via drie historische tussenstappen.

De officiële Google-richtlijn voor site moves adviseert permanente server-side redirects, bijgewerkte interne links, zelfverwijzende canonicals op de nieuwe URL’s en een nieuwe sitemap. De webbouwer implementeert dat; het migratieplan maakt controleerbaar welke URL welk gedrag moet hebben.

Behoud waardevolle informatie, niet blind de oude structuur

SEO behouden betekent niet dat ieder probleem uit de oude webshop moet worden gekopieerd. Een migratie is juist een kans om dubbele categorieën, vergeten landingspagina’s en onbegrijpelijke URL’s op te ruimen. De kunst is onderscheid maken tussen historische rommel en waarde die je niet wilt verliezen.

Beoordeel per belangrijk paginatype:

• welke zoekintentie de pagina bedient;

• op welke zoektermen en vragen zij zichtbaar is;

• welke omzet, leads of ondersteunende conversies zij oplevert;

• hoeveel interne en externe links zij ontvangt;

• welke content uniek is en wie die beheert;

• welke nieuwe pagina dezelfde taak overneemt.

Een nieuwe categorie met een fraaiere naam is geen volwaardige vervanging wanneer belangrijke filters, toepassingsinformatie en subcategorieën verdwijnen. Een productpagina is niet behouden omdat SKU en afbeelding zijn gemigreerd als specificaties, varianten, voorraadstatus of adviescontent ontbreken.

Maak daarom een contentpariteitscontrole. Vergelijk oud en nieuw niet teken voor teken, maar op functie: kan de bezoeker nog dezelfde keuze maken en kan een zoekmachine nog dezelfde betekenis vaststellen?

Productdata en producttypen vragen een eigen migratieplan

Magento kent simple, configurable, grouped, bundle, virtual en downloadable producten. Een ander platform kan dezelfde catalogus anders modelleren. Dat beïnvloedt URL’s, zichtbaarheid, prijs, voorraad, varianten en structured data.

Leg voor representatieve producten vast:

• welke SKU de parent is en welke SKU’s verkoopbare varianten zijn;

• welke URL indexeerbaar moet zijn;

• waar titel, beschrijving, merk, GTIN, prijs en voorraad vandaan komen;

• hoe kleur, maat en andere variantkenmerken zichtbaar zijn;

• wat er gebeurt met tijdelijk uitverkochte varianten;

• of categorie-, feed- en pagina-informatie hetzelfde product beschrijven;

• welke structured data op de uiteindelijke HTML staat.

Controleer niet alleen de broncode van één simpel product. Test ook configureerbare producten, meerdere valuta, promotieprijzen, klantprijzen en producten met afwijkende voorraadlogica. De Google-documentatie over productvarianten helpt om variantrelaties en ProductGroup te beoordelen, maar de Magento-webbouwer moet de uiteindelijke markup passend implementeren.

Storeviews, landen en talen zijn meer dan een vertaalvraag

Bij internationale Magento-webshops komen website, store, storeview, domein, taal en valuta samen. Een migratie kan die hiërarchie wijzigen zonder dat dit in het ontwerp direct opvalt.

Maak per markt een matrix met:

• oude en nieuwe hostnaam of mapstructuur;

• taal en landdoel;

• indexeerbare categorieën en producten;

• canonical-doel;

• hreflang-relaties, inclusief terugverwijzingen;

• XML-sitemap;

• standaardvaluta en prijsweergave;

• lokale voorraad, verzending en retourinformatie;

• vertaalde content en fallbackgedrag.

Hreflang is geen reparatie voor twee halfvertaalde storefronts die allebei naar dezelfde canonical wijzen. Iedere indexeerbare marktversie moet een zelfstandige, bruikbare pagina zijn. Test bovendien of taalswitches echte crawlbare links gebruiken en naar de equivalente pagina leiden, niet altijd naar de homepage.

Een Magento 1-naar-2-migratie is niet automatisch een SEO-migratie

Adobe heeft voor Magento 1-migraties een Data Migration Tool. De officiële tool bevat configuraties voor Magento Open Source 1 naar Magento Open Source 2, Magento Open Source 1 naar Adobe Commerce 2 en Adobe Commerce 1 naar Adobe Commerce 2. De technische documentatie beschrijft onder meer de migratie van websites, stores, storeviews, configuratie en data, plus een deltafase voor gegevens die na de hoofdmigratie aan de Magento 1-database zijn toegevoegd. Dat helpt bij de gegevensoverdracht, maar neemt inhoudelijke SEO-keuzes niet over.

De tool beslist bijvoorbeeld niet:

• welke oude filter-URL’s waardevol waren;

• welke categorieën moeten worden samengevoegd;

• of nieuwe canonicals inhoudelijk correct zijn;

• hoe een nieuw thema interne links rendert;

• of productmarkup overeenkomt met de zichtbare pagina;

• welke redirects commercieel en inhoudelijk logisch zijn;

• of analytics en consent na livegang goed meten.

Zie de technische specificatie van Adobe’s Data Migration Tool dus als onderdeel van het technische migratieproces, niet als SEO-checklist.

Staging moet afgeschermd zijn én vóór livegang testbaar worden

Een acceptatieomgeving hoort niet voortijdig in zoekmachines te verschijnen. Alleen een regel in robots.txt is daarvoor onvoldoende: die kan crawling beperken, maar voorkomt niet altijd dat een bekende URL in de zoekresultaten verschijnt. Scherm een niet-openbare omgeving daarom af met HTTP-authenticatie of vergelijkbare toegangsbeveiliging. Gebruik je op een bereikbare testomgeving tijdelijk noindex, dan moet een crawler de pagina wel kunnen ophalen om die instructie te zien.

Daar zit een beruchte valkuil. Een omgeving wordt maandenlang veilig op noindex gehouden en die instelling gaat mee naar productie. Maak daarom een expliciete go-livecontrole voor:

• HTTP-authenticatie en IP-beperkingen;

• robots.txt;

• meta robots en X-Robots-Tag;

• canonicals naar productie-URL’s;

• absolute interne links;

• sitemaplocaties;

• analytics- en consentconfiguratie;

• testbetaalmethoden en testaccounts.

Sommige SEO-controles kunnen pas goed wanneer de definitieve productiehostnaam beschikbaar is. Plan een gecontroleerd testvenster en laat vooraf vastleggen wie welke blokkade op welk moment verwijdert.

Meet ook performance en capaciteit vóórdat echte klanten komen

Een nieuwe Magento-webshop kan in een lege acceptatieomgeving snel lijken. Productie krijgt caches die warm en koud kunnen zijn, echte integraties, marketingtags, crawlers, cronjobs, imports en gelijktijdige bezoekers.

Test daarom meerdere situaties:

• homepage, lichte en zware categorie;

• categorie met veel filters;

• simpel en configureerbaar product;

• intern zoeken met populaire en resultaatloze termen;

• winkelmand en checkout;

• anonieme en ingelogde bezoeker;

• koude en warme caches;

• normaal verkeer en representatieve piekbelasting;

• vlak na deployment, cacheflush of grote import.

Google merkt in de migratierichtlijn op dat de nieuwe omgeving tijdelijk extra crawlbelasting kan krijgen doordat zowel oude als nieuwe URL’s worden bezocht. Capaciteit en caching zijn dus ook SEO-randvoorwaarden. De hostingpartij en Magento-bouwer testen en dimensioneren; MagentoSEO helpt belangrijke organische paginatypen en acceptatiecriteria selecteren.

Maak eigenaarschap zichtbaar vóórdat er een probleem is

Een migratie mislukt zelden door een compleet gebrek aan expertise. Vaker dacht iedere partij dat iemand anders een controle uitvoerde.

Onderdeel	MagentoSEO.nl	Magento-webbouwer	Hosting/integratiepartner	Webshopeigenaar
Nulmeting en SEO-risico’s	Leidend	Levert technische input	Levert logs/capaciteitsdata	Bevestigt prioriteiten
URL-mapping	Adviseert en valideert	Implementeert redirects	Ondersteunt serverconfiguratie	Beslist over assortiment/content
Data- en contentmigratie	Controleert output en pariteit	Migreert en rendert	Implementeert datastromen	Levert brondata en acceptatie
Technische SEO	Formuleert requirements en test	Bouwt oplossing	Borgt infrastructuurgedrag	Accepteert restrisico’s
Livegang en rollback	Controleert SEO-signalen	Voert release uit	Bewaakt omgeving en koppelingen	Neemt go/no-go-besluit
Monitoring	Analyseert organische impact	Herstelt applicatieproblemen	Herstelt infra- en integratiefouten	Bewaakt omzet en klantmeldingen

Vul per organisatie echte namen, bereikbaarheid en beslisrechten in. “Development” is geen eigenaar; een persoon of team met afgesproken reactietijd wel.

Pre-launch SEO-checklist voor Magento

Een checklist vervangt geen analyse, maar voorkomt dat basale fouten tussen projecttickets verdwijnen.

Crawl en indexatie

• Productie-robots.txt is voorbereid en blokkeert geen belangrijke assets of pagina’s.

• Tijdelijke noindex-regels en stagingverwijzingen zijn verwijderd.

• Canonicals zijn absoluut, indexeerbaar en passen bij de paginalogica.

• Hreflang gebruikt definitieve URL’s en bevat wederzijdse relaties.

• Nieuwe XML-sitemaps bevatten alleen canonieke 200-URL’s.

• Interne links verwijzen direct naar definitieve URL’s.

Redirects en statuscodes

• Alle belangrijke oude URL’s hebben een besluit in de mapping.

• Permanente redirects gaan direct naar de eindbestemming.

• Er zijn geen brede irrelevante homepage-redirects.

• Verwijderde content retourneert bewust 404 of 410.

• Oude queryparameters en trailing-slashvarianten zijn getest.

• Redirects werken per domein, taal en protocolvariant.

Content en templates

• Titles, headings en belangrijke tekstblokken zijn inhoudelijk overgenomen of bewust verbeterd.

• Breadcrumbs, paginering en interne linkmodules werken.

• Filters genereren alleen afgesproken crawl- en indexatiegedrag.

• Afbeeldingen hebben correcte URL’s, afmetingen en alternatieve tekst waar relevant.

• Belangrijke CMS-, merk- en adviespagina’s zijn aanwezig.

Producten, data en meting

• Prijs, voorraad, SKU, GTIN, merk en varianten zijn consistent.

• Structured data komt overeen met zichtbare informatie.

• Productfeeds gebruiken nieuwe URL’s en juiste waarden.

• Analytics, consent, e-commerce-events en omzetwaarden zijn getest.

• Orders, betalingen, e-mails en koppelingen zijn end-to-end gecontroleerd.

De go-livecheck: werk in een vaste volgorde

Een goede livegang heeft een draaiboek met stappen, eigenaren, bewijs en terugvalmomenten. Een praktische volgorde is:

1. Freeze en laatste delta. Leg vast welke content- en datawijzigingen tijdelijk stoppen en hoe de laatste orders, klanten en catalogusmutaties worden verwerkt.

2. Technische release. De webbouwer en hostingpartij voeren deployment, databasewerk, configuratie en cacheprocessen uit.

3. Basisgezondheid. Controleer TLS, DNS, belangrijkste pagina’s, checkout, koppelingen, foutlogs en responstijden.

4. Indexatiesignalen. Test robots, noindex, canonicals, hreflang, sitemaps, statuscodes en een steekproef uit de URL-mapping.

5. Commerciële keten. Plaats echte of gecontroleerde orders, controleer betaling, ERP/WMS, e-mail en analytics.

6. Redirecttest op schaal. Test niet alleen tien handmatige URL’s, maar de volledige mapping of een aantoonbaar representatieve set.

7. Go/no-go. Beoordeel vooraf vastgelegde blokkades; laat tijdsdruk geen nieuw acceptatiecriterium worden.

8. Monitoring aan. Start dashboards en alerts voordat campagneverkeer en nieuwsbrieven worden verhoogd.

Maak schermafbeeldingen, exports en testlogs onderdeel van de oplevering. “Gecontroleerd” is sterker wanneer later terug te vinden is wat, wanneer en met welk resultaat is getest.

Een rollbackplan is meer dan “de oude shop staat nog ergens”

Terugrollen wordt moeilijk zodra nieuwe orders, accounts, betalingen en voorraadmutaties in het nieuwe systeem ontstaan. Spreek daarom vooraf af:

• tot welk moment een volledige rollback mogelijk is;

• welke data tijdens het beslisvenster in welk systeem wordt geschreven;

• hoe nieuwe orders en klanten behouden blijven;

• wie DNS, deployment, database en koppelingen kan terugzetten;

• welke redirects en feeds moeten worden teruggedraaid;

• welke gedeeltelijke herstelopties bestaan als alleen één onderdeel faalt.

Soms is een volledige rollback riskanter dan gericht herstel. Het draaiboek moet daarom niet alleen een knop beschrijven, maar besliscriteria: bij welke fout, impact en duur wordt welke terugvaloptie gebruikt?

Monitoring na livegang: kijk naar patronen, niet naar paniekcijfers

De eerste uren zijn operationeel. Daarna wordt het beeld van zoekmachines en gebruikers steeds belangrijker.

In de eerste 24 uur

• serverfouten, time-outs en responstijden;

• checkout, betalingen, orders en integraties;

• robots, canonicals, noindex en sitemapbereikbaarheid;

• redirectfouten en onverwachte 404’s;

• analytics- en omzetmeting;

• top-URL’s op mobiel en desktop.

In de eerste twee weken

• crawlactiviteit op oude en nieuwe URL’s;

• indexatie per paginatype en storeview;

• zoekverkeer en omzet per landingspagina;

• uitgesloten URL’s en canonicalkeuzes in Search Console;

• structured-datafouten en feedafkeuringen;

• Core Web Vitals, vooral op nieuwe templates;

• nieuwe crawlpatronen rond filters en parameters.

In de eerste maanden

• herstel van klikken, omzet en zichtbaarheid per cluster;

• pagina’s die structureel achterblijven;

• externe links die nog naar oude of omgeleide URL’s wijzen;

• redirects die nog via tussenstappen lopen;

• content- en navigatieverbeteringen die na stabilisatie verantwoord zijn.

Vergelijk week op week én met een passende historische periode. Houd rekening met seizoen, campagnes en assortimentswijzigingen. Een totaalindex zegt weinig wanneer slechts één strategische categorie geraakt is.

Veelvoorkomende oorzaken van SEO-verlies

Dezelfde fouten keren opvallend vaak terug:

• SEO wordt pas aan het einde van de bouw betrokken;

• de nieuwe informatiearchitectuur is al definitief voordat zoekvraag en historische prestaties zijn bekeken;

• alleen sitemap-URL’s worden gemapt;

• redirects worden na livegang “op basis van 404’s” aangevuld;

• filter- en parameterlogica verandert zonder crawlstrategie;

• canonicals wijzen naar oude, niet-indexeerbare of verkeerde storeview-URL’s;

• staging-noindex gaat mee naar productie;

• contentvelden of interne links verdwijnen in het nieuwe thema;

• productvarianten, prijzen en structured data spreken elkaar tegen;

• feeds en campagnes blijven oude URL’s gebruiken;

• analytics lijkt te werken, maar transacties of consentvarianten worden niet goed gemeten;

• er is geen eigenaar voor indexatieproblemen na livegang.

Geen van deze fouten vraagt om een geheime SEO-truc. Ze vragen om vroeg eigenaarschap, een volledige inventarisatie en acceptatiecriteria die technisch te testen zijn.

Briefingtemplate voor de Magento-webbouwer

Gebruik per migratiebevinding dezelfde structuur.

1. Doel en risico

Beschrijf welke gebruikers- en zoekmachinefunctie behouden moet blijven. Benoem de commerciële impact als dat niet gebeurt.

2. Scope

Noem domeinen, storeviews, paginatypen, URL-patronen, apparaten en uitzonderingen.

3. Huidig en gewenst gedrag

Voeg voorbeelden toe van oude URL, nieuwe URL, verwachte statuscode, canonical, robotsregel, interne link en relevante markup.

4. Implementatieverantwoordelijkheid

De webbouwer beschrijft de technische oplossing, gewijzigde componenten, afhankelijkheden en mogelijk neveneffect.

5. Acceptatiecriteria

Maak ze observeerbaar. Bijvoorbeeld: “Iedere URL uit de goedgekeurde mapping retourneert in maximaal één stap een permanente redirect naar de vastgelegde eind-URL; die eind-URL retourneert 200, is indexeerbaar en heeft een zelfverwijzende canonical.”

6. Test en bewijs

Leg vast welke volledige dataset of steekproef wordt getest, met welke tool, op welke omgeving en wie het resultaat accepteert.

7. Terugval en monitoring

Beschrijf rollbackvoorwaarden, alerts en de eigenaar van herstel na livegang.

Veelgestelde vragen over Magento-migraties

Kun je een Magento-migratie uitvoeren zonder tijdelijke rankingdaling?

Dat is niet te garanderen. Zoekmachines moeten gewijzigde URL’s en inhoud opnieuw verwerken. Een goede voorbereiding beperkt vermijdbare schade en verkort de tijd voordat problemen worden gevonden, maar sluit schommelingen niet uit.

Moeten alle oude URL’s altijd worden behouden?

Nee. Behoud waarde en intentie, niet iedere historische fout. Een sterke bestaande URL kan gelijk blijven of gericht worden omgeleid. Waardeloze of onvervangbare content mag bewust verdwijnen met een correcte 404 of 410.

Wanneer moet SEO bij het project aansluiten?

Vóór beslissingen over navigatie, categorieën, URL’s, productmodellen en templates definitief zijn. Als SEO pas tijdens acceptatie aansluit, kunnen de duurste keuzes vaak alleen nog worden gerepareerd.

Is Adobe’s Data Migration Tool voldoende voor Magento 1 naar Magento 2?

Niet voor het volledige project. Het ondersteunt technische gegevensmigratie, maar neemt geen inhoudelijke besluiten over URL’s, zoekintentie, redirects, contentpariteit, structured data of meting.

Hoe lang moeten redirects blijven bestaan?

Google adviseert redirects bij een siteverhuizing zo lang mogelijk en doorgaans minimaal één jaar te behouden. Voor gebruikers kan langer of permanent zinvol zijn zolang oude URL’s nog worden gebruikt. Verwijder redirects dus niet automatisch na enkele maanden en voorkom dat latere migraties redirectketens creëren.

Wie moet redirects implementeren?

De Magento-webbouwer of hostingpartij implementeert ze op de juiste technische laag. MagentoSEO.nl maakt en valideert de SEO-logica en controleert de output, maar past de server of code niet zelf aan.

Moeten we tegelijk redesignen en migreren?

Soms is dat praktisch onvermijdelijk, maar het vergroot het risico en maakt oorzaken moeilijker te isoleren. Leg dan extra nulmetingen, templatepariteit, prestatietests en herstelcriteria vast.

Conclusie: een goede migratie maakt afwijkingen beheersbaar

Een Magento-migratie zonder SEO-verlies begint niet met redirects en eindigt niet bij een succesvolle order. Ze begint met een nulmeting en expliciete keuzes over URL’s, content, productdata, storeviews, meting en eigenaarschap.

Daarna volgt een controleerbare keten: de webbouwer en technische partners migreren en implementeren, de organisatie accepteert data en processen, en MagentoSEO.nl bewaakt de organische randvoorwaarden, briefing en QA. Zo wordt een onvermijdelijk spannend project geen sprong in het donker.

Wil je vóór ontwerp of livegang weten waar het grootste organische risico zit? Met een Magento SEO-analyse brengen we de uitgangssituatie en prioriteiten in kaart, stellen we een uitvoerbare briefing voor de webbouwer op en controleren we na implementatie of de afgesproken werking er echt staat.