Een productimport is zelden alleen het uploaden van een CSV-bestand. In één actie kunnen namen, prijzen, categorieën, afbeeldingen, URL's, voorraadgegevens en storeviewteksten veranderen. Als de voorbereiding goed is, bespaart een import dagen handwerk. Als de mapping niet klopt, kan dezelfde import in enkele minuten een complete catalogus vervuilen.
De grootste risico's zijn vaak subtiel. Producten blijven online, maar krijgen de verkeerde filterwaarde. Een lege cel wist bestaande content. Een gewijzigd URL-key veroorzaakt nieuwe URL's. Een variant raakt los van het hoofdproduct. De webshop lijkt nog te werken, terwijl vindbaarheid, feeds en conversie langzaam schade oplopen.
Een veilige Magento-import behandelt productdata daarom als een gecontroleerde wijziging aan een systeem, niet als administratief kopieerwerk.
MagentoSEO.nl voert geen productimports uit en past Magento niet zelf aan. We analyseren brondata en storefrontimpact, leggen SEO- en kwaliteitscriteria vast, briefen de uitvoerende Magento- of datapartij en valideren na de import of URL's, content, filters, feeds en indexatie kloppen.
Begin met het gewenste resultaat
“Alle producten importeren” is geen scherpe scope. Gaat het om nieuwe SKU's, prijsupdates, verrijkte teksten of een volledige migratie uit een ander platform? Moeten categorieën en URL-keys mee veranderen? Welke storeviews krijgen lokale content?
Hoe kleiner en duidelijker de wijziging, hoe eenvoudiger de controle. Wanneer alleen prijzen wijzigen, horen beschrijvingen en categorieën idealiter niet in het bestand. Adobe waarschuwt bij grote catalogi bovendien dat het opnemen van categories en url_key extra URL-rewrites kan laten genereren, ook als je die waarden feitelijk niet wilt aanpassen.
Definieer vooraf:
- welke entiteiten worden toegevoegd, bijgewerkt of verwijderd;
- welke velden mogen veranderen;
- welk systeem per veld de bron is;
- welke producten en storeviews binnen de scope vallen;
- hoe succes en terugval worden bepaald.
SKU is de ruggengraat, maar niet altijd de enige sleutel
Magento gebruikt de SKU als belangrijke productidentifier bij imports. Die waarde hoort stabiel en uniek te zijn. Een leveranciersartikelnummer kan veranderen of door meerdere leveranciers worden gebruikt en is daarom niet automatisch een goede interne SKU.
In een volwassen dataketen bestaan vaak meerdere identifiers naast elkaar:
| Identifier | Functie | Mag veranderen? | Aandachtspunt |
|---|---|---|---|
| Magento-SKU | Productidentiteit in Magento | Bij voorkeur niet | Nodig voor betrouwbare updates |
| Bron-ID | Verwijzing naar ERP of PIM | Alleen gecontroleerd | Bewaar voor herleidbaarheid |
| GTIN/EAN | Marktidentificatie | Alleen bij correctie | Valideer formaat en uniciteit |
| Parent-ID | Relatie met configurable product | Alleen bewust | Varianten mogen niet verwezen raken |
| URL-key | Menselijke URL-component | Zo weinig mogelijk | Wijziging kan SEO-impact hebben |
Koppel systemen op stabiele identifiers en leg vast welk systeem nieuwe waarden uitgeeft. Matching op productnaam is vragen om dubbele of verkeerd bijgewerkte producten.
Exporteer eerst wat Magento nu weet
Voor een update is een actuele export een waardevolle nulmeting. Daarmee zie je de exacte attribuutcodes, bestaande waarden, storeviewregels en relaties. Gebruik ook het voorbeeldbestand uit de Magento-admin om de verwachte kolomstructuur te begrijpen.
Bewaar de export, het importbestand en de mappings bij elkaar met datum en versienummer. Als achteraf een waarde verkeerd blijkt, wil je kunnen reconstrueren wat er vóór en tijdens de import stond.
Een back-up van de database is de verantwoordelijkheid van de technische beheerder en blijft belangrijk. Een export is geen volledige back-up, maar wel een praktische vergelijking voor productdata.
Leeg is niet hetzelfde als niet aangeleverd
Dit is een van de gevaarlijkste importdetails. Bij bestaande entiteiten kunnen lege waarden in het importbestand bestaande, niet-verplichte attribuutwaarden vervangen. Een lege kolom kan dus betekenen: maak dit veld leeg. Een ontbrekende kolom kan betekenen: raak dit veld niet aan. De precieze uitkomst hangt af van importgedrag en veldtype.
Gebruik geen lege cellen als algemene placeholder. Spreek voor elk veld af wat ontbrekend, leeg en “niet van toepassing” betekenen. Magento kent bij imports een constante voor lege attribuutwaarden. Gebruik die alleen wanneer bewust wissen onderdeel van de scope is en de uitvoerende partij de werking heeft getest.
Een veilige regel is eenvoudig: neem alleen kolommen op die je in deze wijziging daadwerkelijk wilt beheren.
Add/Update, Replace en Delete zijn wezenlijk verschillend
Bij Add/Update worden nieuwe producten toegevoegd en bestaande producten bijgewerkt. De SKU zelf kan via deze route niet zomaar worden gewijzigd. Replace vervangt bestaande data veel ingrijpender en kan referenties verwijderen. Delete verwijdert entiteiten op basis van SKU.
Gebruik Replace nooit omdat het woord compleet of netjes klinkt. Het is een destructieve operatie die alleen past bij een expliciet ontworpen migratie met volledige brondata, technische begeleiding en een terugvalplan. Voor gerichte verrijking is Add/Update doorgaans logischer, maar ook daar moeten complexe velden en meervoudige waarden zorgvuldig worden getest.
Attributen en opties moeten al bestaan
Een importbestand maakt niet automatisch ieder onbekend attribuut aan. De technische code, het invoertype en de toegestane opties moeten passen bij het datamodel in Magento. Een kleurwaarde “donker blauw” kan mislukken of verkeerd worden vertaald wanneer de keuzelijst alleen “Navy” bevat.
Normaliseer bronwaarden vóór de import. Maak een mappingtabel waarin bijvoorbeeld leverancierskleuren worden vertaald naar klantvriendelijke filterkleuren, zonder de originele commerciële benaming te verliezen. Doe hetzelfde voor maten, materialen, eenheden en ja/nee-waarden.
Controleer bij meertaligheid of je een globale waarde of een storeviewspecifiek label importeert. Een Nederlandse beschrijving op de standaardregel kan onbedoeld doorwerken naar andere storeviews wanneer lokale overrides ontbreken.
Varianten zijn een relationeel probleem
Configurable products bestaan uit een hoofdproduct en gekoppelde simpele producten. De combinatie van variantattributen, bijvoorbeeld kleur en maat, moet uniek en volledig zijn. Alleen de simpele SKU's importeren is niet genoeg wanneer de parentrelatie of configuratie ontbreekt.
Test minimaal deze situaties:
- een nieuwe variant aan een bestaand hoofdproduct;
- een gewijzigde voorraadstatus van één variant;
- een variant die uit het assortiment verdwijnt;
- een nieuwe kleur met meerdere maten;
- een simpele SKU die per ongeluk aan twee parents wordt gekoppeld.
Bekijk het resultaat op de productpagina. Kan een klant elke zichtbare combinatie kiezen en verandert prijs, afbeelding en voorraad correct?
Afbeeldingen vragen hun eigen kwaliteitscontrole
Magento kan productafbeeldingen uit een importlocatie of externe bron verwerken. Bestandsnamen, paden en toegangsrechten moeten kloppen. Daarnaast moet worden bepaald welke afbeelding base, small, thumbnail of swatch is.
Een technisch geslaagde import kan nog steeds slechte presentatie opleveren. Controleer resolutie, uitsnede, achtergrond, alt-tekst, volgorde en variantafbeeldingen. Let op dubbele bestanden die opslag en beheer vervuilen. Bij externe URL's moet de bron stabiel en bereikbaar zijn tijdens de import.
URL-keys, categorieën en SEO-content beschermen
Een wijziging van productnaam hoeft niet automatisch een wijziging van de URL te betekenen. Bestaande product-URL's kunnen autoriteit, links en gebruikersgeschiedenis hebben. Behandel url_key daarom als beschermd veld. Als een wijziging echt nodig is, definieer dan de oude en nieuwe URL en controleer de redirect.
Categorievelden zijn eveneens gevoelig. Een verkeerde mapping kan producten uit belangrijke categorieën halen of in tientallen onbedoelde categorieën plaatsen. Dat verandert interne links, breadcrumbs en soms canonicals.
Bescherm daarnaast meta titles, meta descriptions en lange productteksten tegen generieke leverancierstekst. Een ERP-omschrijving is nuttig voor logistiek, maar zelden automatisch de beste commerciële of organische content.
Werk met een proefimport die representatief is
Een test met vijf eenvoudige producten zegt weinig over een catalogus met varianten, meerdere storeviews en uitzonderingen. Maak een compacte maar representatieve set. Neem minimaal een eenvoudig product, configurable product, meertalig product, uitverkocht item, product met speciale prijs en product met meerdere afbeeldingen op.
Voer de proef bij voorkeur uit in een acceptatieomgeving die qua configuratie en extensies op productie lijkt. Controleer niet alleen de melding “bestand is geldig”. De ingebouwde Check Data-stap valideert de importstructuur, maar kan niet beoordelen of de inhoud commercieel of SEO-technisch wenselijk is.
Voor en na vergelijken
Maak vooraf een meetlijst met producten en verwachte waarden. Controleer na de import zowel data als gedrag.
| Laag | Voorbeeldcontrole na import |
|---|---|
| Productdata | Naam, attributen, prijs en status correct |
| Relaties | Varianten, categorieën en gerelateerde producten intact |
| Storefront | Productpagina rendert en keuzes werken |
| SEO | URL, canonical, indexeerbaarheid en metadata gelijk of bewust gewijzigd |
| Feeds | GTIN, prijs, voorraad en landingspagina correct |
| Indexatie | Sitemap bevat alleen gewenste product-URL's |
Vergelijk ook totalen: aantal actieve producten, aantal producten zonder afbeelding, ontbrekende verplichte attributen en aantallen per storeview. Grote verschillen zijn sneller zichtbaar in totalen dan bij losse steekproeven.
Rollback is een procedure, geen wens
“We zetten de back-up terug” is pas een plan wanneer duidelijk is wie dat doet, hoe lang het duurt en welke transacties sinds de import verloren kunnen gaan. Een webshop ontvangt ondertussen orders en klantupdates. Een volledige database-rollback kan daardoor meer schade veroorzaken dan de import zelf.
Ontwerp de terugval passend bij de wijziging. Soms is een gecorrigeerde tegenimport veiliger. Soms moet alleen een beperkte productselectie worden hersteld. Bij een grote migratie kan een onderhoudsvenster nodig zijn. Laat de Magento-partner dit technisch uitwerken en test de procedure waar het risico dat rechtvaardigt.
Na livegang begint de bewaking
Controleer de importhistorie en foutbestanden, maar kijk ook naar de storefront en externe kanalen. Monitor in de dagen erna 404's, productuitsluitingen in Merchant Center, veranderingen in de sitemap, producten zonder voorraad en organische landingspagina's die verkeer verliezen.
Bewaar het definitieve importbestand. Wanneer een fout pas een week later wordt ontdekt, is herleidbaarheid belangrijker dan het geheugen van degene die op de importknop drukte.
De kern: beperk de wijziging en vergroot de controle
Een betrouwbare Magento-import bevat alleen de velden die bewust moeten veranderen, gebruikt stabiele identifiers en is getest met representatieve producten. Data-validatie, storefrontcontrole en een realistisch herstelplan horen bij dezelfde operatie.
Wil je vóór een grote import weten welke SEO- en storefrontvelden bescherming nodig hebben? Vraag een Magento-analyse aan. Wij leggen de nulmeting en acceptatiecriteria vast, briefen je uitvoerende partner en controleren of de catalogus na oplevering nog doet wat hij moet doen.
Bron
- Adobe Commerce: Import data
Lees je dit met een Magento-shop in gedachten? Wij helpen dagelijks Magento-shops met technische SEO, contentstrategie, linkbuilding en zoekwoordonderzoek.
MagentoSEO.nl
Onderdeel van Marketingcollega — SEO voor Magento & e-commerce.