Een WooCommerce feed maakt het mogelijk om grote hoeveelheden productinformatie vanuit een leverancier, groothandel of ander extern systeem in een WooCommerce-webshop te verwerken. In plaats van duizenden producten handmatig aan te maken, kan de webshop productnamen, prijzen, voorraad, afbeeldingen, categorieën en andere gegevens automatisch uit een externe bron halen.
Daarmee begint het interessante deel pas.
Een eenmalige productimport is namelijk iets anders dan een betrouwbare productkoppeling die iedere dag of meerdere keren per dag blijft functioneren. Bij een echte automatische koppeling moet WooCommerce weten welke producten al bestaan, welke gegevens veranderd zijn en wat er moet gebeuren wanneer een artikel uit de bron verdwijnt.
Bij kleinere bestanden valt dat vaak nog eenvoudig op te lossen. Een feed met tienduizenden producten, variaties en afbeeldingen vraagt echter om een andere aanpak.
De server moet de gegevens kunnen verwerken zonder vast te lopen. Daarnaast wil je voorkomen dat iedere synchronisatie opnieuw duizenden afbeeldingen downloadt of bestaande producten dubbel aanmaakt.
In dit artikel leggen we uit hoe zo’n WooCommerce-productfeed technisch werkt, welke mogelijkheden er zijn en hoe je grote feeds betrouwbaar automatiseert.
Wat bedoelen we met een WooCommerce feed?
De term WooCommerce feed wordt voor verschillende soorten gegevensstromen gebruikt.
Daarom is het verstandig eerst onderscheid te maken tussen een inkomende en uitgaande feed.
Bij een inkomende productfeed ontvangt WooCommerce informatie van een externe bron.
Bijvoorbeeld:
leverancier → XML/CSV/API → WooCommerce
Daarmee kun je een assortiment automatisch opbouwen en onderhouden.
Een uitgaande feed werkt anders:
WooCommerce → productfeed → extern platform
Zo’n uitgaande feed kan bijvoorbeeld productinformatie beschikbaar stellen aan een vergelijkingssite of ander verkoopkanaal.
In dit artikel gaat het vooral over de eerste variant: een externe leveranciersfeed die producten naar WooCommerce importeert en later blijft synchroniseren.
Wat kan er in een WooCommerce productfeed staan?
Een WooCommerce productfeed kan heel eenvoudig zijn of juist honderden verschillende velden bevatten.
Een eenvoudige leverancier levert misschien alleen een artikelnummer, productnaam, prijs en voorraad.
Een uitgebreidere bron kan daarnaast gegevens bevatten voor merk, EAN, gewicht, afmetingen, productomschrijving, afbeeldingen, categorieën, kleur, materiaal en variaties.
Bij XML kan één product bijvoorbeeld conceptueel zo zijn opgebouwd:
<product>
<sku>ABC-10025</sku>
<title>Voorbeeldproduct</title>
<ean>8712345678901</ean>
<price>49.95</price>
<stock>17</stock>
<brand>Voorbeeldmerk</brand>
<image>https://leverancier.example/images/ABC-10025.jpg</image>
</product>
WooCommerce begrijpt deze willekeurige structuur niet automatisch.
Er moet eerst worden bepaald welk veld uit de feed bij welk WooCommerce-veld hoort.
Dat noemen we mapping.
Mapping is de basis van een goede WooCommerce feed
Stel dat een leverancier het veld gebruikt:
article_number
terwijl WooCommerce dit product als SKU moet herkennen.
Dan moet de koppeling weten:
article_number → SKU
Hetzelfde gebeurt bijvoorbeeld met:
retail_price → reguliere prijs
en:
inventory → voorraad
Bij uitgebreide imports ontstaan tientallen van zulke koppelingen.
Dat maakt mapping veel belangrijker dan simpelweg “een XML-bestand importeren”.
Wanneer een veld verkeerd wordt gekoppeld, kan technisch gezien de import perfect werken terwijl de productgegevens toch fout zijn.
Een voorraadwaarde kan bijvoorbeeld als prijs worden geïmporteerd. Of een artikelnummer wordt als producttitel gebruikt.
Daarom moet vóór de eerste volledige import altijd met een kleine selectie producten worden getest.
XML feed WooCommerce: waarom XML veel wordt gebruikt
Een XML feed voor WooCommerce komt veel voor bij leveranciers en groothandels.
XML heeft als voordeel dat gegevens hiërarchisch kunnen worden opgebouwd.
Een product kan bijvoorbeeld meerdere afbeeldingen bevatten:
<images>
<image>foto1.jpg</image>
<image>foto2.jpg</image>
<image>foto3.jpg</image>
</images>
Ook categorieën en attributen kunnen binnen een productstructuur worden opgenomen.
Daarmee is XML geschikt voor complexe productcatalogi.
Het nadeel is dat niet iedere XML-feed dezelfde structuur heeft.
De ene leverancier gebruikt:
<product>
terwijl een andere:
<item>
of:
<article>
gebruikt.
Daarom bestaat er geen universele WooCommerce XML-import die iedere leveranciersfeed zonder configuratie begrijpt.
CSV feed WooCommerce
Een CSV feed voor WooCommerce heeft een tabelstructuur.
Bijvoorbeeld:
sku;name;price;stock;brand
ABC100;Product A;24.95;15;Merk A
ABC101;Product B;39.95;8;Merk B
WooCommerce heeft zelf een ingebouwde CSV-importer waarmee producten kunnen worden toegevoegd en bestaande producten kunnen worden bijgewerkt. WooCommerce gebruikt daarvoor onder andere ID’s of SKU’s om bestaande producten te herkennen. De ingebouwde importer ondersteunt ook productdata, categorieën, attributen en verschillende andere WooCommerce-velden.
Voor een handmatige eenmalige CSV-import kan deze ingebouwde functie prima voldoen.
Een continu veranderende leveranciersfeed stelt echter andere eisen.
Dan wil je bijvoorbeeld dat WooCommerce iedere nacht automatisch een nieuw bestand binnenhaalt zonder dat iemand handmatig op Importeren hoeft te klikken.
Eenmalig producten importeren of automatisch synchroniseren?
Dit verschil bepaalt in grote mate welke oplossing je nodig hebt.
Stel dat je één webshop migreert en 3.000 producten eenmalig vanuit een CSV-bestand importeert.
Na die import verandert het bestand niet meer.
Dan heb je vooral een goede productimport nodig.
Een leverancierskoppeling werkt anders.
De leverancier verandert morgen misschien:
-
de voorraad;
-
de inkoopprijs;
-
een omschrijving;
-
een afbeelding;
-
de productstatus.
WooCommerce moet die wijzigingen later opnieuw verwerken.
Daarmee ontstaat een synchronisatieproces.
Een automatische productfeed moet dus niet alleen producten kunnen creëren. Hij moet ook bestaande artikelen betrouwbaar herkennen en alleen de juiste gegevens bijwerken.
De unieke sleutel is misschien wel het belangrijkste onderdeel
Om bestaande producten te kunnen bijwerken moet WooCommerce weten welk product uit de nieuwe feed overeenkomt met welk product dat al in de webshop staat.
Daarvoor heb je een stabiele unieke sleutel nodig.
De SKU is vaak een goede kandidaat.
Bijvoorbeeld:
SUPPLIER-847263
Wanneer die waarde bij iedere feed hetzelfde blijft, kan de import bij een volgende run zeggen:
“Dit product bestaat al. Ik moet het bijwerken en niet opnieuw aanmaken.”
WooCommerce gebruikt bij zijn ingebouwde CSV-import onder andere product-ID of SKU voor het matchen van bestaande producten.
Bij externe importsoftware kun je soms ook een andere unieke sleutel gebruiken.
Denk aan een leverancier-ID of EAN.
Belangrijk is vooral dat die waarde werkelijk uniek én stabiel is.
Waarom productnamen geen goede unieke sleutel zijn
Een producttitel lijkt misschien uniek.
Toch kan een leverancier morgen:
Apple iPhone 17 256GB zwart
veranderen in:
Apple iPhone 17 256 GB – Zwart
Voor mensen is duidelijk dat dit hetzelfde product is.
Voor een geautomatiseerde import kunnen het twee verschillende strings zijn.
Wanneer de titel als unieke identificatie wordt gebruikt, kan daardoor een nieuw product worden aangemaakt.
De oude versie blijft dan eveneens bestaan.
Dat veroorzaakt dubbele producten.
Een leverancierartikelnummer of andere stabiele identifier is daarom veel betrouwbaarder.
Hoe werkt een geautomatiseerde WooCommerce product import?
Een volwassen importproces bestaat uit meerdere stappen.
Eerst wordt het bronbestand opgehaald.
Daarna wordt gecontroleerd of het bestand daadwerkelijk bruikbaar is.
Vervolgens worden de records gelezen en genormaliseerd.
Pas daarna begint WooCommerce met het matchen en schrijven van producten.
Conceptueel ziet dat er zo uit:
leveranciersfeed → ophalen → controleren → gegevens vertalen → product herkennen → velden bijwerken → afbeeldingen verwerken → logging
Die tussenstappen zijn belangrijk.
Stel dat een leverancier door een fout ineens een leeg XML-bestand aanbiedt.
Wanneer je import zonder controle alle ontbrekende producten automatisch verwijdert, kan in theorie je complete assortiment verdwijnen.
Een goede koppeling behandelt een lege of duidelijk afwijkende feed daarom als fout en niet als normale productupdate.
WooCommerce feed importeren met de standaard importer
WooCommerce beschikt standaard over een product-CSV-importer.
Daarmee kunnen nieuwe producten worden toegevoegd of bestaande producten worden bijgewerkt. Ook externe afbeeldings-URL’s kunnen bij de core-importer worden gebruikt wanneer deze rechtstreeks bereikbaar zijn; WooCommerce importeert die afbeeldingen vervolgens in de mediabibliotheek.
Voor handmatige imports is dit een sterke basis.
De officiële WooCommerce-documentatie wijst er bij grote catalogi wel op dat imports afhankelijk zijn van beschikbare serverresources, uploadlimieten en verwerkingstijd. WooCommerce adviseert bij grote catalogi bovendien eerst een back-up en test op staging te maken en eventueel bestanden in kleinere batches te splitsen.
Voor terugkerende leveranciersfeeds heb je meestal meer automatisering nodig.
WP All Import WooCommerce voor leveranciersfeeds
Een veelgebruikte route is WP All Import met WooCommerce.
Deze oplossing kan CSV- en XML-bestanden uitlezen en bronvelden aan WooCommerce-velden koppelen.
Daarmee kun je bijvoorbeeld producttitel, omschrijving, SKU, voorraad en prijs uit een leveranciersbestand halen.
WP All Import ondersteunt daarnaast producttypes, voorraadgegevens, afbeeldingen, variaties en verschillende andere WooCommerce-velden.
Een belangrijk voordeel is dat de bronstructuur niet exact gelijk hoeft te zijn aan de standaard WooCommerce CSV-structuur.
Je kunt zelf aangeven welk element uit een XML- of CSV-bestand bij welk productveld hoort.
Dat maakt het interessant voor leveranciersfeeds die oorspronkelijk helemaal niet voor WooCommerce zijn ontworpen.
Wanneer heb je maatwerk nodig?
Niet iedere productfeed past goed binnen een standaard importplugin.
Stel dat een leverancier een API aanbiedt waarbij voor ieder product afzonderlijke requests nodig zijn.
Of prijzen worden opgebouwd uit verschillende bronnen.
Misschien moet voorraad realtime worden bijgewerkt, terwijl omschrijvingen slechts eenmaal per dag veranderen.
Dan kan een eigen koppeling efficiënter worden.
Bij maatwerk kun je precies bepalen wat wanneer gebeurt.
Een eigen integratie kan bijvoorbeeld iedere vijf minuten alleen gewijzigde voorraadregels ophalen en ’s nachts een uitgebreidere productsynchronisatie uitvoeren.
Hierdoor hoeft de webshop niet voortdurend een bestand met honderdduizend complete producten opnieuw te verwerken.
De juiste oplossing hangt dus sterk af van hoe de leverancier de data aanbiedt.
Hoe groot kan een WooCommerce feed worden?
Er bestaat geen magisch aantal producten waarbij WooCommerce ineens niet meer kan importeren.
Een feed met 50.000 eenvoudige producten kan in sommige omgevingen lichter zijn dan 10.000 ingewikkelde variabele producten met tien foto’s per artikel.
Je moet daarom verder kijken dan alleen het aantal regels.
Een productimport belast verschillende onderdelen van de server.
PHP moet de bron lezen en verwerken.
WooCommerce schrijft gegevens naar de database.
Afbeeldingen moeten mogelijk via HTTP worden gedownload.
WordPress maakt mediabijlagen en verschillende metadata aan.
Daarnaast kunnen plugins reageren wanneer een product wordt aangemaakt of bijgewerkt.
Daarom kan één geïmporteerd product technisch veel meer werk veroorzaken dan je op basis van één XML-regel zou verwachten.
Waarom één enorme import de server kan vastzetten
Stel dat een feed 80.000 producten bevat.
Als je probeert alles binnen één webrequest te verwerken, kan het proces zeer lang actief blijven.
Ondertussen groeit het geheugengebruik en worden grote aantallen databasebewerkingen uitgevoerd.
Een server kan daardoor tegen limieten aanlopen.
Dat kan leiden tot een timeout, memory error of een import die ergens halverwege stopt.
Daarom werken goede grote imports in batches.
In plaats van:
80.000 producten in één proces
verwerk je bijvoorbeeld telkens een beheersbare hoeveelheid records en laat je daarna het volgende deel uitvoeren.
Het exacte optimale batchformaat hangt af van de server en de complexiteit van de producten.
Groter is niet automatisch beter.
Batchverwerking maakt herstel ook eenvoudiger
Batches hebben nog een tweede voordeel.
Stel dat product 34.215 een onverwachte fout veroorzaakt.
Wanneer de volledige import één enorm proces is, kan het moeilijk zijn te bepalen waar het misging.
Bij batchverwerking weet je veel beter welk deel faalde.
Een mislukte batch kan eventueel opnieuw worden verwerkt zonder dat de volledige feed vanaf het begin hoeft te worden uitgevoerd.
Dat maakt grote imports betrouwbaarder.
Ook kun je tussen batches de serverbelasting controleren.
Voor zeer grote catalogi is dit vaak belangrijker dan proberen de import puur met hogere PHP-limieten door te drukken.
Meer geheugen is niet altijd de oplossing
Bij een vastlopende WooCommerce-feed wordt vaak als eerste de memory_limit verhoogd.
Soms helpt dat.
Maar wanneer de importsoftware structureel te veel informatie tegelijk in geheugen houdt, verschuif je het probleem alleen.
Hetzelfde geldt voor execution time.
Een timeout van 60 seconden verhogen naar 600 seconden kan nuttig zijn voor een normaal proces dat iets langer nodig heeft.
Maar een architectuur die drie uur binnen één HTTP-request probeert te draaien blijft kwetsbaar.
Voor grote imports zijn batchverwerking, echte cronjobs en efficiënte databasebewerkingen meestal belangrijker.
Servercapaciteit en softwarearchitectuur moeten samenwerken.
Afbeeldingen zijn vaak zwaarder dan de productdata zelf
Een XML-bestand met 50.000 producten kan qua bestandsgrootte nog redelijk beheersbaar zijn.
Wanneer ieder product drie afbeeldingen heeft, verandert het verhaal.
Dan moeten mogelijk 150.000 externe afbeeldingsbestanden worden opgehaald.
Voor iedere afbeelding moet WordPress daarnaast een mediabijlage aanmaken en kan het systeem verschillende afbeeldingsformaten genereren.
De officiële WooCommerce CSV-importer kan externe afbeeldings-URL’s downloaden wanneer die direct bereikbaar zijn.
WP All Import ondersteunt eveneens het downloaden van afbeeldingen vanaf externe HTTP- en HTTPS-URL’s en kan de eerste afbeelding als uitgelichte productafbeelding gebruiken.
Juist daarom moet je voorkomen dat iedere dagelijkse synchronisatie alle afbeeldingen opnieuw downloadt.
Voorkom dubbele productafbeeldingen
Stel dat product ABC100 gisteren drie foto’s heeft geïmporteerd.
Vandaag staat exact dezelfde afbeelding-URL opnieuw in de feed.
Een slechte configuratie kan de bestanden opnieuw downloaden en nieuwe media-items creëren.
Na maanden krijg je dan enorme hoeveelheden duplicaten.
Dat kost opslagruimte en maakt de mediabibliotheek onnodig groot.
Een goede import controleert daarom of een afbeelding al aanwezig is of stelt expliciet in dat bestaande media behouden moeten blijven.
Bij wijzigingen kun je alleen de afbeeldingen vervangen wanneer de bron daadwerkelijk veranderd is.
Dat vermindert serverbelasting enorm.
Afbeeldingen optimaliseren tijdens een feedimport
Leveranciers leveren niet altijd webvriendelijke afbeeldingen.
Een productfoto kan bijvoorbeeld enkele megabytes groot zijn terwijl de webshop veel kleinere bestanden nodig heeft.
Wanneer je tienduizenden van zulke afbeeldingen rechtstreeks opslaat, groeit de WordPress-installatie snel.
Daarom kan beeldoptimalisatie onderdeel van de importarchitectuur zijn.
Denk aan het verkleinen van extreem grote afmetingen en het gebruiken van efficiënte formaten waar dat binnen de website past.
Dat moet wel zorgvuldig gebeuren.
Je wilt bestandsgrootte verminderen zonder productfoto’s zichtbaar slecht te maken.
Bij grote catalogi levert deze stap niet alleen snellere pagina’s op, maar ook aanzienlijk minder opslag- en back-upverkeer.
WooCommerce voorraad synchroniseren
WooCommerce voorraad synchroniseren is vaak belangrijker dan de oorspronkelijke productimport.
Een product hoeft maar één keer aangemaakt te worden.
Voorraad kan ieder uur veranderen.
Stel dat een leverancier 20 stuks beschikbaar heeft en jouw webshop toont dat aantal.
Een paar uur later verkoopt de leverancier via andere verkoopkanalen 18 stuks.
Wanneer jouw feed slechts één keer per week wordt bijgewerkt, verkoop je mogelijk voorraad die niet meer beschikbaar is.
Daarom moet de updatefrequentie passen bij het soort product en de snelheid waarmee voorraad verandert.
Een dropshipping-assortiment vraagt bijvoorbeeld een andere synchronisatiestrategie dan producten die je zelf op voorraad hebt.
Niet iedere synchronisatie hoeft alle productvelden bij te werken
Dit is een van de belangrijkste optimalisaties bij grote feeds.
Stel dat een product de volgende gegevens heeft:
titel, lange omschrijving, korte omschrijving, categorie, merk, afbeeldingen, prijs en voorraad.
De titel verandert misschien bijna nooit.
De afbeeldingen veranderen zelden.
Voorraad kan iedere vijftien minuten veranderen.
Waarom zou je dan iedere vijftien minuten alle productgegevens opnieuw verwerken?
Je kunt verschillende synchronisaties maken.
Bijvoorbeeld een lichte voorraad- en prijsimport die vaak draait.
Daarnaast draait eenmaal per nacht of week een uitgebreidere productsynchronisatie.
WP All Import ondersteunt bijvoorbeeld het bijwerken van alleen prijs en/of voorraad bij bestaande producten, in plaats van alle productvelden opnieuw te verwerken.
Dat kan bij grote webshops enorm veel onnodig werk voorkomen.
Prijzen uit een leverancier feed berekenen
De prijs die een leverancier levert hoeft niet automatisch de verkoopprijs te zijn.
Een feed kan bijvoorbeeld een netto inkoopprijs bevatten.
De webshop moet vervolgens een marge toepassen.
Conceptueel:
inkoopprijs × marge = verkoopprijs
Maar in de praktijk kan prijsberekening ingewikkelder zijn.
Je kunt verschillende marges per categorie hebben.
Ook minimale marges, btw, afrondingen of specifieke merkregels kunnen een rol spelen.
Een product van €10 kan bijvoorbeeld een andere procentuele marge nodig hebben dan een product van €2.000.
Daarom is het verstandig prijslogica los te zien van de ruwe feedwaarde.
De feed levert de bronprijs. De webshop bepaalt vervolgens hoe die prijs wordt vertaald naar de uiteindelijke verkoopprijs.
Prijsafronding in WooCommerce
Ook afronding kan automatisch.
Stel dat een berekening uitkomt op:
€37,43
maar de webshop werkt met prijzen die eindigen op:
,95
Dan kan een prijsfunctie de uitkomst bijvoorbeeld aanpassen naar:
€37,95
Dit soort logica kun je tijdens de import toepassen.
Het belangrijkste is dat dezelfde regels consequent gebruikt worden.
Wanneer handmatige prijswijzigingen en automatische feedberekeningen door elkaar lopen, kan de volgende synchronisatie handmatige aanpassingen weer overschrijven.
Daarom moet vooraf duidelijk zijn welke bron eigenaar is van ieder productveld.
Wie is eigenaar van de prijs?
Dit klinkt misschien vreemd, maar het voorkomt veel problemen.
Stel dat de leverancier de basisprijs levert.
Een medewerker wijzigt handmatig één product in WooCommerce.
Bij de volgende automatische import komt opnieuw de leveranciersprijs binnen.
Moet de handmatige wijziging blijven staan of moet de feed hem overschrijven?
Dat moet je vooraf beslissen.
Je kunt bijvoorbeeld bepalen:
voorraad → altijd leverancier
inkoopprijs → altijd leverancier
verkoopprijs → eigen berekening
SEO-omschrijving → nooit overschrijven na eerste import
Zo krijgt ieder veld een duidelijke bron.
Dat voorkomt dat automatische synchronisatie eigen content steeds vernietigt.
Productomschrijvingen van leveranciers en SEO
Veel webshops importeren de productomschrijving letterlijk uit de leveranciersfeed.
Technisch werkt dat.
Voor SEO is het niet altijd ideaal.
Dezelfde leverancier levert namelijk vaak aan tientallen of honderden webshops.
Daardoor kan exact dezelfde producttekst op veel websites verschijnen.
Bij belangrijke producten kan eigen content daarom waardevoller zijn.
Je kunt bijvoorbeeld bij de eerste import een basisomschrijving gebruiken en deze later handmatig verbeteren.
Daarna configureer je de automatische feed zo dat hij de aangepaste omschrijving niet opnieuw overschrijft.
Zo combineer je automatisering met eigen SEO-content.
Categorieën uit een feed importeren
Leveranciers hebben meestal hun eigen categorie-indeling.
Bijvoorbeeld:
Elektronica > Audio > Koptelefoons
Je kunt die structuur rechtstreeks overnemen.
Maar dat is niet altijd verstandig.
Misschien wil jouw webshop:
Audio > Draadloze koptelefoons
gebruiken.
In dat geval is categorie-mapping nodig.
De broncategorie:
Wireless headphones
wordt dan gekoppeld aan jouw WooCommerce-categorie:
Draadloze koptelefoons
Zo houd je controle over de navigatie van je eigen webshop.
Anders bepaalt de interne administratie van de leverancier feitelijk de structuur van jouw website.
Wat gebeurt er met nieuwe categorieën?
Stel dat de leverancier morgen ineens een nieuwe categorie introduceert.
Een volledig automatische import kan deze categorie direct in WordPress aanmaken.
Dat lijkt handig.
Maar misschien ontstaat daardoor een lege of slecht benoemde SEO-categorie.
Een andere aanpak is onbekende categorieën eerst te loggen.
Daarna bepaal je handmatig aan welke webshopcategorie ze gekoppeld moeten worden.
Welke methode beter is hangt af van het assortiment.
Bij duizenden snel wisselende producten kan automatisering noodzakelijk zijn.
Bij een zorgvuldig gecureerde webshop is meer controle vaak beter.
Variabele producten maken een productfeed ingewikkelder
Een simpel product is relatief duidelijk.
Eén SKU hoort bij één WooCommerce-product.
Bij een variabel product heb je een ouderproduct met daaronder variaties.
Denk aan een T-shirt:
model: Basic Shirt
maat: S, M, L, XL
kleur: zwart, wit
Iedere combinatie kan een eigen SKU, voorraad en prijs hebben.
De feed moet daarom aangeven welke variaties bij hetzelfde hoofdproduct horen.
WP All Import ondersteunt het importeren van variabele WooCommerce-producten waarbij variaties aan een bovenliggend product worden gekoppeld en eigenschappen zoals prijs, SKU, voorraad en attributen worden gemapt.
Een slechte parent-childstructuur kan anders duizenden losse simpele producten opleveren.
Attributen moeten consequent zijn
Stel dat leverancier A gebruikt:
Color
leverancier B:
Colour
en leverancier C:
Kleur
Je wilt waarschijnlijk niet drie afzonderlijke WooCommerce-attributen voor hetzelfde concept.
Daarom normaliseer je de brongegevens.
Alle drie worden bijvoorbeeld:
pa_kleur
Hetzelfde geldt voor waarden.
Black, black, Zwart en BLACK
kunnen allemaal worden omgezet naar:
Zwart
Dit is vooral belangrijk voor filters en variabele producten.
Zonder normalisatie raakt de productdatabase na verloop van tijd vervuild met bijna identieke eigenschappen.
EAN, GTIN en andere productidentifiers
Naast SKU kan een feed internationale identifiers bevatten.
Bijvoorbeeld EAN of GTIN.
Die gegevens kunnen nuttig zijn voor externe verkoopkanalen, productvergelijking en interne matching.
Toch moet je voorzichtig zijn met de aanname dat EAN altijd een perfecte unieke sleutel is.
Niet ieder product heeft een EAN.
Sommige leveranciers leveren verkeerde of ontbrekende waarden.
Bij bepaalde pakketten of eigen varianten kan de structuur bovendien anders zijn.
Gebruik daarom een identifier die betrouwbaar is binnen jouw specifieke bron.
Bij één leverancier is dat misschien het artikelnummer. Bij een andere koppeling kan een combinatie van leverancier-ID en artikelnummer beter zijn.
Meerdere leveranciers in één WooCommerce webshop
Het wordt interessanter wanneer één webshop meerdere feeds combineert.
Stel dat leverancier A en leverancier B toevallig allebei SKU:
12345
gebruiken.
Als je uitsluitend de losse SKU gebruikt als unieke sleutel, kunnen beide producten met elkaar botsen.
Een oplossing is een samengestelde interne sleutel.
Bijvoorbeeld:
LEVA-12345
en:
LEVB-12345
Daarmee blijft de identiteit uniek.
Ook moet je bepalen wat er gebeurt wanneer twee leveranciers hetzelfde fysieke product aanbieden.
Wil je twee losse producten?
Of één WooCommerce-product waarbij de webshop automatisch kiest bij welke leverancier wordt besteld?
Dat laatste vraagt veel meer logica dan een gewone productimport.
Producten van meerdere leveranciers combineren
Stel dat exact dezelfde EAN bij twee leveranciers beschikbaar is.
Leverancier A:
prijs €25
voorraad 2
Leverancier B:
prijs €27
voorraad 50
De webshop kan verschillende strategieën gebruiken.
Je kunt altijd de goedkoopste leverancier kiezen.
Of je kiest de leverancier met voldoende voorraad.
Misschien heeft leverancier A een slechte levertijd en geef je daarom B de voorkeur.
Dan verandert een WooCommerce feed in feite in een voorraad- en sourcing-engine.
Dit soort logica is vaak beter geschikt voor een maatwerkkoppeling dan voor een eenvoudige standaardimport.
Wat doe je als een product uit de feed verdwijnt?
Dit is een cruciale beslissing.
Een product staat vandaag in de feed.
Morgen ontbreekt het.
Wat betekent dat?
Misschien is het definitief uit het assortiment.
Maar misschien heeft de leverancier een tijdelijk technisch probleem.
Direct verwijderen kan daarom gevaarlijk zijn.
Mogelijke strategieën zijn het product op concept zetten, voorraad op nul plaatsen of pas na meerdere ontbrekende synchronisaties de status veranderen.
WP All Import heeft instellingen waarmee bestaande items kunnen worden bijgewerkt en waarmee afhankelijk van de configuratie kan worden omgegaan met producten die niet langer in de bron voorkomen.
Voor zakelijke feeds is het verstandig een duidelijke lifecycle-regel te bepalen.
Product verwijderen of op niet op voorraad zetten?
Voor SEO kan direct verwijderen bovendien ongewenst zijn.
Een productpagina kan al bezoekers en externe links hebben.
Wanneer je hem verwijdert, kan de URL een 404 geven.
Soms is het beter de pagina te behouden en het artikel als niet op voorraad te tonen.
Bij een permanent verdwenen product kun je later een passende redirect of andere SEO-oplossing kiezen.
Welke aanpak goed is hangt af van het product en assortiment.
De feed hoort daarom niet blind alle verdwenen artikelen te wissen zonder rekening te houden met de website.
Automatische productfeed met cronjobs
Een WooCommerce cronjob kan een import op vaste momenten starten.
Voor eenvoudige WordPress-taken bestaat WP-Cron.
Voor grote leveranciersimports is een echte servercron vaak betrouwbaarder, omdat de uitvoering dan niet afhankelijk is van websitebezoekers.
WP All Import ondersteunt terugkerende imports via handmatig ingestelde servercronjobs. Daarbij gebruikt het systeem voor zo’n import een trigger- en processingproces. De bron kan bijvoorbeeld via URL, FTP/SFTP of een bestaand bestand worden geleverd.
Hierdoor kan de server zelfstandig bijvoorbeeld iedere nacht de nieuwe feed ophalen en verwerken.
Dat is veel geschikter dan dagelijks iemand handmatig laten inloggen.
Waarom een trigger en verwerking apart kunnen zijn
Een grote import hoeft niet in één enorme cronrun uitgevoerd te worden.
De trigger controleert of een nieuwe import moet beginnen.
Daarna kan een processing-job regelmatig een stuk van de import verwerken.
Conceptueel:
02:00 → nieuwe feed beschikbaar → import starten
Daarna:
02:02 → batch verwerken
02:04 → volgende batch
02:06 → volgende batch
Totdat de feed klaar is.
Deze aanpak voorkomt dat één proces onbeperkt lang moet blijven draaien.
WP All Import documenteert voor handmatige planning inderdaad aparte trigger- en processing-URL’s.
Voor grote productcatalogi is die verdeling erg nuttig.
Waarom de normale WordPress cron niet altijd ideaal is
WP-Cron wordt standaard door websiteverkeer geactiveerd.
Dat is handig voor een normale WordPress-site.
Een grote productfeed moet echter betrouwbaar op een bepaald moment starten, ook wanneer er ’s nachts niemand op de website komt.
Daarom is een echte servercron vaak geschikter.
Daarnaast heb je bij servercron meer controle over de frequentie en uitvoering.
Dit sluit aan op ons andere artikel over WordPress cron werkt niet, waarin we uitgebreider uitleggen waarom zware imports beter niet volledig afhankelijk zijn van bezoekersverkeer.
Voorkom dat twee imports tegelijk gaan draaien
Stel dat een voorraadimport normaal 20 minuten duurt.
Je cronjob start iedere 15 minuten een nieuwe run.
De tweede import kan dan beginnen terwijl de eerste nog bezig is.
Nu verwerken twee processen dezelfde producten tegelijk.
Dat kan extra CPU- en databasebelasting veroorzaken.
Bij slecht ontworpen imports kan het zelfs voor inconsistenties zorgen.
Daarom moet een import weten of er al een actieve run bestaat.
Bij maatwerk kun je hiervoor bijvoorbeeld een lock gebruiken.
De volgende run begint dan pas wanneer de vorige klaar is of duidelijk gefaald heeft.
Automatisering moet immers juist betrouwbaarheid toevoegen.
Wat als de leverancier tijdens de download de feed vernieuwt?
Ook dit is een subtiel probleem.
Stel dat jij om 03:00 uur een XML-bestand begint te downloaden terwijl de leverancier exact op dat moment hetzelfde bestand opnieuw genereert.
Je kunt theoretisch een onvolledige bron ontvangen.
Een goede leverancier lost dit aan zijn kant op door eerst een nieuw tijdelijk bestand te genereren en dat daarna atomair als actieve feed beschikbaar te maken.
Als afnemer kun je eveneens controles uitvoeren.
Is het bestand veel kleiner dan normaal?
Ontbreekt de afsluitende XML-structuur?
Bevat het ineens nul producten?
Dan moet de import niet zomaar doorgaan.
Feedvalidatie vóór import
Een goede koppeling controleert daarom eerst de bron.
Bijvoorbeeld:
De URL geeft HTTP 200.
Het bestand is niet leeg.
XML kan worden geparsed.
De verwachte productnode bestaat.
Het aantal producten wijkt niet extreem af.
Belangrijke velden zijn aanwezig.
Pas daarna wordt de WooCommerce-import gestart.
Dit is veel veiliger dan ieder willekeurig ontvangen bestand direct als waarheid behandelen.
Vooral automatische verwijder- of voorraadlogica kan anders grote gevolgen hebben.
Logging is noodzakelijk bij automatische imports
Een goede feedkoppeling moet kunnen vertellen wat er gebeurd is.
Niet alleen:
import voltooid
maar bijvoorbeeld:
bron opgehaald
42.381 records gevonden
216 nieuwe producten
3.842 producten bijgewerkt
14 afbeeldingen mislukt
7 records overgeslagen wegens ontbrekende SKU
Deze informatie maakt troubleshooting veel eenvoudiger.
Wanneer een leverancier zegt dat product X wel in zijn feed staat, kun je terugzoeken of het record is gezien en waarom het eventueel niet verwerkt werd.
Zonder logging blijft alleen gokken over.
Log niet onbeperkt alles
Logging kan zelf weer een probleem worden wanneer ieder detail voor altijd wordt opgeslagen.
Een feed die iedere vijf minuten 100.000 regels verwerkt kan enorme logbestanden produceren.
Daarom is logretentie nodig.
Gedetailleerde logs kunnen bijvoorbeeld een beperkte periode worden bewaard.
Samenvattingen mogen langer blijven staan.
Foutmeldingen verdienen vaak meer aandacht dan succesvolle records.
Zo houd je genoeg informatie voor onderzoek zonder de server vol te schrijven.
Serverbelasting tijdens een WooCommerce feed import
Een zware import gebruikt voornamelijk CPU, RAM, databasecapaciteit, schijf-I/O en netwerk.
Wanneer tegelijkertijd veel bezoekers in de webshop actief zijn, concurreren beide processen om dezelfde resources.
Daarom kan een import die ’s nachts probleemloos draait overdag de website merkbaar vertragen.
Plan zware volledige synchronisaties daarom waar mogelijk op rustigere momenten.
Lichte voorraadupdates kunnen vaker draaien.
Daarnaast is servermonitoring nuttig.
Wanneer CPU gedurende iedere import langdurig maximaal belast wordt, weet je dat er weinig reserve bestaat.
Een snellere server kan helpen, maar optimaliseer eerst het proces.
Databasebelasting bij tienduizenden producten
WooCommerce bewaart productinformatie op verschillende plaatsen in WordPress en WooCommerce.
Een import doet daarom meer dan één simpele database-insert per product.
Er moeten mogelijk productrecords, metadata, taxonomieën, voorraadgegevens en relaties worden verwerkt.
Variaties voegen daar nog meer records aan toe.
Daarom kan een catalogus met 20.000 hoofdproducten en vijf variaties per product technisch al richting 100.000 verkoopbare variaties gaan.
Het zichtbare productaantal in het WordPress-dashboard vertelt dus niet het hele verhaal.
Bij grotere catalogi moet databaseperformance expliciet onderdeel van de hostingkeuze zijn.
Redis kan helpen, maar lost een slechte import niet op
Een persistent object cache zoals Redis kan WooCommerce bij bepaalde terugkerende databasevragen ontlasten.
Toch moet je niet verwachten dat Redis een inefficiënt importscript repareert.
Wanneer een import voor ieder product tientallen onnodige queries uitvoert, blijft het proces zwaar.
Redis kan sommige gegevens cachen, maar schrijftaken moeten nog steeds plaatsvinden.
Optimaliseer daarom eerst de feedarchitectuur.
Werk alleen gewijzigde velden bij.
Voorkom dubbele media.
Gebruik batches.
Laat daarna caching en serveroptimalisatie de resterende belasting verbeteren.
Hoe weet je welke producten veranderd zijn?
Een simpele import vergelijkt misschien ieder product bij iedere run.
Dat kan prima zijn bij kleinere bestanden.
Bij zeer grote koppelingen kan een wijzigingsindicator efficiënter zijn.
Sommige leveranciers leveren bijvoorbeeld:
last_modified
of een versie/hash.
Wanneer een product sinds de vorige synchronisatie niet veranderd is, hoef je niet alle velden opnieuw te schrijven.
Bij API’s bestaan soms endpoints die alleen gewijzigde producten sinds een bepaald tijdstip teruggeven.
Dat is aanzienlijk efficiënter dan iedere tien minuten een complete catalogus opnieuw verwerken.
Wanneer zo’n functie beschikbaar is, is het verstandig die te gebruiken.
Full feed versus delta feed
Een full feed bevat de volledige catalogus.
Een delta feed bevat alleen wijzigingen sinds de vorige export.
Beide hebben voordelen.
Een full feed is eenvoudig als uiteindelijke waarheid.
Je kunt controleren welke producten nog bestaan.
Een delta feed verwerkt veel minder data.
Een sterke architectuur kan beide combineren.
Bijvoorbeeld:
iedere 15 minuten → delta voorraad/prijzen
iedere nacht → volledige controlefeed
Zo krijg je snelle updates én periodieke controle dat WooCommerce nog volledig overeenkomt met de bron.
API-koppeling versus XML feed
Een XML- of CSV-feed is in feite een momentopname.
Een API kan dynamischer werken.
Je kunt bijvoorbeeld specifiek product ABC100 opvragen zonder de andere 50.000 artikelen te downloaden.
Dat kan efficiënter zijn.
Daar staat tegenover dat API’s limieten kunnen hebben.
Misschien mag je maar een bepaald aantal requests per minuut uitvoeren.
Ook authenticatie en foutafhandeling worden belangrijker.
Voor bulkgegevens is één groot bestand soms verrassend efficiënt.
Voor realtime voorraad of orderverwerking kan een API juist beter passen.
De beste oplossing hangt af van wat de leverancier beschikbaar stelt.
WooCommerce feed en dropshipping
Bij dropshipping is een productfeed vaak een centraal onderdeel van de webshop.
Je verkoopt artikelen waarvan voorraad en levering door een leverancier worden afgehandeld.
Daarom moeten prijs en voorraad betrouwbaar blijven.
Maar een complete dropshipping-koppeling gaat verder dan alleen producten importeren.
Na een bestelling moet mogelijk ook orderinformatie naar de leverancier.
Later moet een trackingcode terugkomen.
De volledige keten wordt dan:
leverancier → productfeed → WooCommerce → bestelling → leverancier → tracking → WooCommerce
Een productfeed verzorgt dus slechts één deel.
Voor volledige automatisering zijn vaak aanvullende API- of orderkoppelingen nodig.
Wat gebeurt er als een feed mislukt?
Een goede webshop moet niet meteen onbruikbaar worden wanneer één synchronisatie faalt.
Stel dat de leverancier om 04:00 uur tijdelijk offline is.
De cronjob krijgt geen feed.
In plaats van alle voorraad op nul te zetten, kan het systeem de bestaande WooCommerce-data behouden en een foutmelding registreren.
Daarna probeert het later opnieuw.
Dit heet fail-safe gedrag.
De vorige bekende gegevens blijven beschikbaar totdat een geldige nieuwe bron is ontvangen.
Bij meerdere opeenvolgende fouten kan een beheerder automatisch worden gewaarschuwd.
Dat is veel veiliger dan een storing bij de leverancier direct doorgeven aan de volledige productcatalogus.
Wanneer moet je een waarschuwing krijgen?
Niet iedere succesvolle cronrun betekent dat de feed gezond is.
Stel dat de import normaal 40.000 producten ziet.
Vandaag zijn het er ineens 400.
Technisch is het bestand geldig.
Toch is dat waarschijnlijk verdacht.
Daarom kun je monitoring baseren op afwijkingen.
Bijvoorbeeld wanneer het productaantal sterk daalt, de feed te oud is of een hoog percentage records fouten geeft.
Zo ontdek je dat er iets misgaat voordat klanten lege categorieën of verkeerde voorraad zien.
Test een nieuwe WooCommerce feed altijd op staging
Een leveranciersfeed direct voor het eerst op een live webshop draaien is riskant.
Gebruik eerst een stagingomgeving.
Importeer daar bijvoorbeeld 20 of 100 producten.
Controleer vervolgens producttitel, prijs, btw, afbeeldingen, categorieën, voorraad, variaties en SKU’s.
Voer daarna dezelfde import opnieuw uit.
Dit is belangrijk.
De eerste run kan namelijk perfect lijken, terwijl de tweede run alle producten dubbel aanmaakt omdat matching verkeerd is ingesteld.
Een feed is pas goed getest wanneer zowel aanmaken als opnieuw synchroniseren correct werkt.
Test ook wat er gebeurt als producten verdwijnen
Maak tijdens de test bewust een product uit het bronbestand onzichtbaar of verwijder een testrecord.
Kijk wat de koppeling doet.
Wordt het product verwijderd?
Op concept gezet?
Uitverkocht gemaakt?
Of gebeurt er niets?
Doe hetzelfde met een gewijzigde prijs en afbeelding.
Zo test je niet alleen de “happy path”.
Juist uitzonderingen bepalen of een automatische koppeling op lange termijn betrouwbaar blijft.
Back-up vóór een grote eerste import
WooCommerce adviseert zelf bij grote productcatalogi een back-up te maken en eerst op staging te testen.
Dat advies is logisch.
Een eerste volledige import kan duizenden databasewijzigingen uitvoeren.
Wanneer de mapping na 30.000 producten fout blijkt, wil je niet noodzakelijk al die records handmatig verwijderen.
Met een goede back-up kun je terug naar de situatie vóór de test.
Bij zeer grote importprojecten kan zelfs een volledige tijdelijke kopie van de webshop verstandiger zijn dan experimenteren op productie.
SEO-titels en meta descriptions importeren
Een feed kan soms SEO-data bevatten.
Toch gebeurt dat niet standaard bij iedere leverancier.
Wanneer je Yoast SEO of een andere SEO-plugin gebruikt, worden bepaalde gegevens vaak in aparte custom fields opgeslagen.
Die kunnen met geschikte importsoftware eventueel gemapt worden.
Maar ook hier geldt de vraag:
wil je dat de leverancier jouw SEO bepaalt?
Voor generieke productdata misschien niet.
Een betere strategie kan zijn basisproducten te importeren en belangrijke categorieën en producten vervolgens eigen SEO-content te geven.
Automatische updates moeten die eigen SEO-velden daarna ongemoeid laten.
Slugs niet bij iedere import opnieuw veranderen
Wanneer een producttitel verandert, hoef je niet automatisch ook steeds de URL te veranderen.
Stel dat:
/zwarte-draadloze-koptelefoon/
al geïndexeerd is.
Een leverancier verandert de naam iets.
Wanneer de feed daar automatisch een nieuwe slug van maakt, verandert de URL.
Dat kan onnodige redirects en SEO-verlies veroorzaken.
Daarom is het vaak verstandig de slug na eerste creatie te behouden, tenzij er een bewuste reden is om hem aan te passen.
Een productfeed hoort commerciële productdata actueel te houden zonder voortdurend de hele SEO-structuur te herschrijven.
WooCommerce feed en bestaande handmatig toegevoegde producten
Een webshop kan zowel feedproducten als eigen producten bevatten.
Dan moet je onderscheid kunnen maken.
Je kunt bijvoorbeeld een custom field opslaan:
_supplier = leverancier_a
Daarmee weet de koppeling welke producten door deze bron beheerd worden.
Wanneer leverancier A een artikel verwijdert, mag de import natuurlijk niet ineens een handmatig toegevoegd product van leverancier B verwijderen.
Dit klinkt vanzelfsprekend, maar bij brede “remove missing products”-regels kan het misgaan.
Beperk synchronisatie daarom altijd tot de productset waarvoor de betreffende feed verantwoordelijk is.
WooCommerce feed beveiligen
Niet iedere feed is openbaar.
Leveranciers kunnen werken met gebruikersnaam en wachtwoord, API-token, IP-whitelisting of tijdelijke downloadlinks.
Die toegangsgegevens horen niet in publiek bereikbare JavaScript of front-endcode te staan.
Bewaar tokens en wachtwoorden op de server.
Zorg daarnaast dat logs geen gevoelige credentials volledig opslaan.
Gebruik waar mogelijk HTTPS voor het ophalen van feeds.
Bij SFTP- of API-koppelingen moeten sleutels en tokens eveneens goed worden beschermd.
Een productfeed bevat misschien geen betaalgegevens, maar toegang tot commerciële prijs- en voorraaddata kan wel degelijk gevoelig zijn.
Kan een leverancier je webshop beschadigen via een feed?
Een externe feed is invoer van buiten je eigen systeem.
Behandel die daarom als onbetrouwbare input.
Een productomschrijving kan onverwachte HTML bevatten.
Een afbeeldingsveld kan een ongeldige URL krijgen.
Een prijs kan leeg of negatief zijn.
Een veld kan ineens een ander datatype bevatten.
Goede importlogica valideert gegevens voordat ze naar WooCommerce worden geschreven.
Daarmee voorkom je niet alleen technische fouten, maar ook dat onverwachte brondata direct op de storefront verschijnt.
Hoe vaak moet een WooCommerce productfeed draaien?
Dat hangt volledig af van de gegevens.
Een productomschrijving hoeft misschien maar eenmaal per dag te worden gecontroleerd.
Voorraad kan iedere paar minuten relevant zijn.
Prijs misschien ieder uur.
Daarom is één universele synchronisatiefrequentie niet altijd optimaal.
Een slimme koppeling verdeelt taken op basis van urgentie.
Veel gewijzigde data → vaker synchroniseren.
Zware stabiele data → minder vaak.
Zo blijft de webshop actueel zonder de server voortdurend onnodig te belasten.
Kan een grote WooCommerce feed op shared hosting draaien?
Soms wel, maar er bestaan duidelijke grenzen.
Shared hosting deelt CPU, geheugen en andere resources met meerdere klanten.
Een import die lange tijd veel CPU of databasecapaciteit gebruikt kan daardoor worden beperkt.
Voor een kleine dagelijkse feed hoeft dit geen probleem te zijn.
Bij tienduizenden producten, veel afbeeldingen en frequente synchronisaties wordt een VPS of andere omgeving met beter controleerbare resources aantrekkelijker.
Het gaat daarbij niet alleen om pure snelheid.
Op een eigen of goed beheerde omgeving heb je ook meer controle over cronjobs, PHP, logging en databaseperformance.
VPS voor WooCommerce productfeeds
Een VPS geeft meer controle over de uitvoering.
Je kunt echte servercronjobs configureren.
PHP-instellingen kunnen worden afgestemd op de workload.
Servermonitoring kan laten zien hoeveel resources een import gebruikt.
Daarnaast kun je bijvoorbeeld Redis en andere cachinglagen inzetten waar ze werkelijk nut hebben.
Dat betekent niet dat iedere webshop direct een grote VPS nodig heeft.
De server moet aansluiten op het werkelijke assortiment en de importbelasting.
Een efficiënte koppeling op een bescheiden server kan beter presteren dan een slecht gebouwde import op zeer zware hardware.
Wanneer is WP All Import voldoende?
Voor veel leveranciersfeeds is WP All Import WooCommerce een praktische oplossing.
Vooral wanneer de leverancier XML of CSV levert en de mapping zonder zeer complexe logica kan worden gemaakt.
Je kunt de bronvelden aan productvelden koppelen, afbeeldingen verwerken en terugkerende imports plannen. Ook stock- en price-only updates zijn mogelijk.
Wanneer de regels steeds ingewikkelder worden, kan een grens ontstaan.
Bijvoorbeeld wanneer gegevens uit vier feeds gecombineerd moeten worden, realtime voorraad nodig is of bestellingen naar meerdere leveranciers moeten worden teruggestuurd.
Dan wordt maatwerk sneller aantrekkelijk.
Wanneer is een maatwerk WooCommerce feed beter?
Maatwerk is vooral interessant wanneer de koppeling onderdeel wordt van het bedrijfsproces.
Stel dat iedere order automatisch naar de leverancier moet.
De leverancier geeft later een trackingcode terug.
Voorraad komt realtime via API.
Prijzen worden berekend aan de hand van merk, categorie, gewicht en wisselkoers.
Producten van meerdere leveranciers worden op EAN samengevoegd.
Dat is geen eenvoudige “import” meer.
Het is een integratieplatform.
Een eigen plugin of externe middleware kan dan veel beter beheersbaar zijn dan tientallen losse importregels en snippets.
Het voordeel is dat logging, retries en foutafhandeling precies op de bedrijfslogica kunnen worden afgestemd.
Een goede WooCommerce feed denkt ook aan herstel
Stel dat een verkeerde prijsregel per ongeluk alle producten voor €0,95 importeert.
Hoe herstel je dat?
Een goede koppeling bewaart voldoende informatie om te achterhalen welke run de fout veroorzaakte.
Daarnaast heb je een databaseback-up van vóór grote wijzigingen.
Bij kritieke prijsupdates kan zelfs een validatieregel verstandig zijn.
Bijvoorbeeld:
“Wanneer de gemiddelde verkoopprijs plotseling 90% daalt, import stoppen en waarschuwen.”
Automatisering zonder veiligheidscontroles kan fouten juist sneller verspreiden.
Een goede feed doet daarom niet alleen automatisch werk. Hij controleert ook of de uitkomst logisch blijft.
WooCommerce feed koppelen: hoe ziet een professionele aanpak eruit?
Een betrouwbare implementatie begint niet met het onmiddellijk importeren van de volledige catalogus.
Eerst wordt de bron geanalyseerd.
Welke velden zijn beschikbaar?
Welke identifier is uniek?
Hoe zijn variaties opgebouwd?
Hoe vaak verandert voorraad?
Daarna wordt bepaald welke WooCommerce-velden door de feed beheerd worden.
Vervolgens bouw je de mapping en test je met een kleine set.
Pas wanneer de eerste én tweede synchronisatie correct werken, schaal je op.
Daarna voeg je planning, logging en monitoring toe.
Zo bouw je stap voor stap een systeem waarvan duidelijk is wat er gebeurt wanneer de bron morgen verandert.
Voorbeeld van een praktische synchronisatiestrategie
Een webshop met een grote leverancier kan bijvoorbeeld als volgt worden ingericht.
’s Nachts wordt een volledige productfeed gecontroleerd. Nieuwe producten worden toegevoegd en relevante productgegevens bijgewerkt.
Overdag draait een veel lichtere import voor alleen prijs en voorraad.
Afbeeldingen worden alleen gedownload wanneer ze nieuw of veranderd zijn.
Handmatig verbeterde SEO-teksten worden niet door de dagelijkse feed overschreven.
Artikelen die één keer ontbreken verdwijnen niet direct. Pas na een ingestelde controle wordt hun status aangepast.
Bij iedere run wordt een samenvatting gelogd.
Dit is veel betrouwbaarder dan iedere tien minuten de complete catalogus opnieuw importeren.
Veelgemaakte fout: alles automatiseren zonder eigenaarschap
Automatisering voelt aantrekkelijk.
Maar niet ieder veld hoeft uit de feed te komen.
Misschien wil je productnaam en technische specificaties van de leverancier gebruiken, maar categorie, verkooptekst en SEO zelf beheren.
Dat is prima.
Sterker nog, het maakt de webshop vaak beter.
Zie een WooCommerce productfeed daarom niet als een systeem dat de leverancier volledige controle over je productdatabase geeft.
Zie het als een gegevensbron.
Jij bepaalt welke informatie je daarvan gebruikt en welke delen je zelf beheert.
WooCommerce feed importeren door Sanum
Sanum kan een WooCommerce feed inrichten voor webshops die producten vanuit leveranciers, groothandels of andere systemen automatisch willen importeren en bijwerken.
Daarbij kan worden gewerkt met XML-, CSV- en andere gegevensbronnen, afhankelijk van wat de leverancier beschikbaar stelt.
De koppeling kan bijvoorbeeld nieuwe producten aanmaken en bestaande producten bijwerken op basis van een betrouwbare SKU of andere unieke identifier.
Ook prijsberekeningen, voorraad, categorieën, variaties en afbeeldingen kunnen onderdeel zijn van de import.
Bij grotere catalogi kijken we daarnaast naar de technische uitvoering.
Een import van tienduizenden producten moet niet iedere synchronisatie onnodig alle media en productvelden opnieuw verwerken.
Daarom kunnen volledige imports en lichtere prijs- en voorraadsynchronisaties van elkaar worden gescheiden.
Ook servercronjobs, logging, monitoring en foutafhandeling kunnen worden meegenomen.
Voor complexere leverancierskoppelingen kan maatwerk geschikter zijn dan een standaardimportplugin.
Wil je een WooCommerce productfeed van een leverancier automatisch laten importeren en synchroniseren? Sanum kan de feedstructuur analyseren, mapping opzetten en de volledige import- en synchronisatieomgeving technisch inrichten.
Veelgestelde vragen over een WooCommerce feed
Wat is een WooCommerce feed?
Een WooCommerce feed is een gegevensbron waarmee productinformatie kan worden geïmporteerd of geëxporteerd. Bij een leveranciersfeed ontvangt WooCommerce bijvoorbeeld productnamen, prijzen, voorraad en afbeeldingen vanuit XML, CSV of een API.
Kan WooCommerce zelf een productfeed importeren?
WooCommerce heeft standaard een CSV-importer waarmee producten kunnen worden toegevoegd en bestaande producten op basis van ID of SKU kunnen worden bijgewerkt. Voor terugkerende XML- of complexe leveranciersfeeds is vaak aanvullende importsoftware of maatwerk nodig.
Kan WooCommerce een XML feed importeren?
Met geschikte importsoftware kan een XML-feed naar WooCommerce-productvelden worden gemapt. WP All Import ondersteunt bijvoorbeeld WooCommerce-productimports uit XML en CSV.
Kan een WooCommerce feed automatisch worden bijgewerkt?
Ja. Terugkerende imports kunnen bijvoorbeeld via servercronjobs of een scheduling-oplossing worden uitgevoerd. WP All Import ondersteunt zowel handmatige servercronjobs als een eigen optionele schedulingdienst.
Hoe voorkom ik dubbele producten?
Gebruik een betrouwbare unieke identifier, zoals een stabiele SKU of leverancier-ID. Bij iedere volgende import moet het systeem op die waarde matchen voordat het besluit een nieuw product aan te maken.
Kan ik alleen voorraad uit een productfeed bijwerken?
Ja. Het is vaak juist efficiënter om een aparte synchronisatie alleen voorraad of prijs te laten bijwerken. WP All Import ondersteunt bijvoorbeeld imports waarbij specifiek deze velden worden geüpdatet.
Kan ik automatisch prijzen verhogen vanuit de leveranciersfeed?
Ja. Je kunt bronprijzen tijdens de import omrekenen naar verkoopprijzen. De exacte mogelijkheden hangen af van de gebruikte importsoftware of maatwerkkoppeling.
Kan ik productafbeeldingen uit een WooCommerce feed downloaden?
Ja. WooCommerce kan bij de ingebouwde CSV-import direct bereikbare externe afbeeldingen importeren. Externe importtools zoals WP All Import ondersteunen eveneens het downloaden en koppelen van productafbeeldingen.
Waarom wordt een grote productfeed traag?
Een grote import gebruikt PHP, databasecapaciteit, schijf-I/O, netwerk en soms veel beeldverwerking. Vooral variaties en externe afbeeldingen kunnen de verwerking aanzienlijk zwaarder maken.
Hoeveel producten kan WooCommerce importeren?
Daar bestaat geen universele harde grens voor. De praktische capaciteit hangt af van serverresources, productcomplexiteit, afbeeldingen en de gebruikte importmethode. WooCommerce geeft zelf aan dat grote imports afhankelijk zijn van geheugen, uploadlimieten en verwerkingstijd.
Moet ik grote WooCommerce feeds in batches verwerken?
Dat is vaak verstandig. Batchverwerking beperkt langdurige zware processen en maakt het eenvoudiger om fouten te vinden en opnieuw te verwerken. WooCommerce adviseert bij grote CSV-catalogi eveneens om kleinere batches te overwegen.
Wat gebeurt er als een product niet meer in de feed staat?
Dat bepaal je in de synchronisatiestrategie. Een product kan bijvoorbeeld op niet op voorraad worden gezet, op concept gaan of uiteindelijk verwijderd worden. Direct verwijderen is niet altijd verstandig.
Kan ik eigen teksten behouden terwijl prijzen automatisch bijgewerkt worden?
Ja. Richt de import zo in dat alleen de velden worden bijgewerkt die de leverancier moet beheren. Een eigen productomschrijving of SEO-tekst kan daardoor behouden blijven terwijl voorraad en prijzen automatisch veranderen.
Kan ik meerdere leveranciersfeeds in één WooCommerce-webshop gebruiken?
Ja. Zorg dan wel dat productidentifiers tussen leveranciers niet botsen. Bij complexere situaties kan aanvullende logica nodig zijn om producten van meerdere leveranciers te combineren.
Kan ik een WooCommerce feed met WP All Import automatiseren?
Ja. WP All Import ondersteunt terugkerende imports en documenteert servercronjobs met afzonderlijke trigger- en processingacties voor automatische verwerking.
Is WP-Cron voldoende voor een grote WooCommerce-feed?
Voor kleine taken kan WP-Cron voldoen. Voor zware en tijdkritische imports geeft een echte servercron doorgaans meer controle omdat uitvoering niet afhankelijk is van websiteverkeer.
Is een VPS nodig voor een grote productfeed?
Niet altijd. Kleine feeds kunnen op normale hosting draaien. Bij grote catalogi en frequente imports kan een VPS interessant worden door de extra controle over CPU, RAM, PHP, database en cronjobs.
Kan een productfeed variabele producten importeren?
Ja, mits de feed voldoende informatie bevat om het hoofdproduct en de bijbehorende variaties te herkennen. WP All Import ondersteunt het koppelen van WooCommerce-variaties aan variable products.
Wat is beter: XML, CSV of API?
Geen formaat is altijd beter. CSV is eenvoudig voor tabulaire data, XML kan complexere structuren bevatten en een API kan gerichte of realtime updates mogelijk maken. De kwaliteit van de bron en de benodigde synchronisatie bepalen de beste oplossing.
Hoe vaak moet een leveranciersfeed worden bijgewerkt?
Dat hangt af van hoe snel de gegevens veranderen. Voorraad kan veel vaker moeten worden bijgewerkt dan productomschrijvingen of afbeeldingen. Daarom kunnen meerdere synchronisaties met verschillende frequenties efficiënter zijn.
Hoe voorkom ik dat een kapotte feed mijn webshop leegmaakt?
Valideer het bronbestand voordat wijzigingen worden uitgevoerd. Een onverwacht leeg bestand, sterke daling van het productaantal of ongeldige XML moet als fout worden behandeld en niet automatisch als normale assortimentswijziging.
Kan Sanum een bestaande leveranciersfeed koppelen aan WooCommerce?
Ja. Afhankelijk van de bron kan de koppeling worden gemaakt via bestaande importsoftware of via maatwerk wanneer bijvoorbeeld API’s, verschillende leveranciers of specifieke prijs- en voorraadlogica nodig zijn.
