Standaardparameters voor XML-productfeeds

De meeste artikelen over XML-feeds gaan ervan uit dat je T-shirts verkoopt.

Die aanname was tien jaar geleden logisch, toen een "productfeed" een Google Shopping-bestand betekende en verder niets. Vandaag klopt ze niet meer. Een autodealer, een vacaturesite, een hotelgroep, een vastgoedportaal en een bettingplatform draaien allemaal advertenties op basis van feeds, en geen van hen levert size of gtin aan. Zij leveren VIN's, IATA-codes, aantallen slaapkamers, dienstverbanden en aftraptijden aan.

De onderliggende werking is identiek. De parameters niet.

Deze gids behandelt beide: de structurele regels die gelden voor elke XML-feed, ongeacht de branche, en de specifieke attribuutsets voor elk van de belangrijkste feedtypen: retail, lokale voorraad, voertuigen, reizen, vastgoed, vacatures en tijdgebonden aanbod zoals wedstrijden, evenementen en voorstellingen. Met werkende XML voor elk type.

1. Wat een XML-feed eigenlijk is

Een XML-feed is een gestructureerd bestand dat een aanbod beschrijft op een manier die machines kunnen verwerken zonder dat een mens het hoeft te interpreteren. Een platform haalt het bestand volgens een schema op, parseert het en maakt op basis van de inhoud vermeldingen, advertenties of zoekresultaten aan.

Het formaat doet er minder toe dan de meeste mensen denken. Waar het om gaat, is het contract: elke bestemming publiceert een specificatie met welke velden verplicht zijn, welke waarden zijn toegestaan en hoe het platform reageert als ze fout zijn. De feed is jouw kant van dat contract.

Daar volgen twee consequenties uit, en die zijn de reden dat feeds lastiger zijn dan ze lijken:

Het contract verschilt per bestemming. De productspecificatie van Google, de catalogusspecificatie van Meta en de vacature-XML van Indeed hebben vrijwel geen veldnamen gemeen. Eén broncatalogus moet voor elk ervan anders worden getransformeerd.

Overtredingen falen meestal geruisloos. Een fout opgemaakt veld breekt zelden het hele bestand. Het keurt één artikel af, verlaagt één vermelding in rang of laat één attribuut uit de advertentie wegvallen, en niets in je campagnedashboard laat dat zien.

2. De opbouw van het bestand

De meeste XML-feeds voor advertenties gebruiken RSS 2.0 met een namespace-extensie. De structuur bestaat altijd uit dezelfde drie lagen:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
  <channel>
    <title>Example Store — Product Feed</title>
    <link>https://example.com</link>
    <description>Full catalogue, updated hourly</description>

    <item>
      <!-- one inventory item -->
    </item>

  </channel>
</rss>

• De XML-declaratie bepaalt de codering. In de praktijk moet dat UTF-8 zijn; al het andere veroorzaakt beschadigde tekens in niet-Engelse catalogi en is verreweg de meest voorkomende oorzaak van verminkte Turkse, Duitse en Tsjechische producttitels.
• De namespace-declaratie (xmlns:g="...") maakt <g:price> geldig. Laat je die weg, dan wordt elk element met prefix stilzwijgend genegeerd: de feed wordt geparseerd, maar er wordt vrijwel niets geïmporteerd.
• <channel> bevat metadata op feedniveau.
• <item> is één eenheid van het aanbod. Wat "één eenheid" is, is een keuze en geen gegeven: één SKU, één variant, één voertuig, één vacature, één hotel, één wedstrijd.

Niet elke branche gebruikt deze vorm. Vacaturefeeds gebruiken <source><job>, en sommige marktplaatsen definiëren volledig eigen root-elementen. De logica van drie lagen (document, container, herhalend item) blijft echter overeind.

3. De universele kern

Zeven parameters komen, onder verschillende namen, in vrijwel elke feedspecificatie voor die ooit is geschreven. Als je deze begrijpt, kun je elke specificatie lezen.

Drie regels over de ID die overal gelden en meer schade aanrichten dan enig ander veld:

1. Ze moet stabiel zijn. Als je ID bij elke export opnieuw wordt gegenereerd (afgeleid van de rijvolgorde, een tijdstempel of een hash van veranderende content), vernietigt elke synchronisatie de opgebouwde prestatiegeschiedenis van het artikel en begint het weer bij nul.
2. Ze moet uniek zijn. Dubbele ID's zorgen ervoor dat latere rijen zonder foutmelding worden weggelaten. Artikelen verdwijnen gewoon.
3. Ze moet overeenkomen met wat je pixel of tag verstuurt. De catalogusmatching van Meta, de dynamische remarketing van Google en elk retargetingproduct zijn ervan afhankelijk dat de feed-ID en de ID in het site-event exact dezelfde string zijn. Dit is de meest voorkomende reden dat dynamische retargeting "niet werkt".

4. Parameters voor retail / e-commerce

Dit is de best gedocumenteerde specificatie en de basis waarop de meeste andere branches voortbouwen.

Verplicht

Identifiers

brand, gtin, mpn en identifier_exists. GTIN is het veld dat bepaalt of je product wordt gekoppeld aan de productkennisgraaf van Google, en daarmee of het überhaupt verschijnt in vergelijkings- en AI-shoppingomgevingen. In de praktijk is het niet optioneel, wat de specificatie ook zegt.

Varianten

item_group_id, item_group_title, color, size, size_type, size_system, material, pattern, gender, age_group.

Varianten zijn een onderwerp op zich; de korte versie is dat item_group_id binnen een groep identiek moet zijn en moet zijn afgeleid van stabiele brongegevens, en dat gender en age_group binnen een groep constant zijn, terwijl color en size dat niet zijn.

Categorisering

google_product_category (de taxonomie van Google, ID of volledig pad), product_type (je eigen taxonomie: dit is het veld dat een campagnestructuur mogelijk maakt, en het is vrij in te vullen, dus gebruik het).

Commercieel

sale_price, sale_price_effective_date, unit_pricing_measure, unit_pricing_base_measure, installment, subscription_cost, loyalty_program.

Logistiek

shipping, shipping_weight, shipping_length / _width / _height, shipping_label, transit_time_label, min_handling_time, max_handling_time, tax.

Campagnesturing

excluded_destination, included_destination, ads_redirect, custom_label_0 tot en met custom_label_4.

De vijf custom labels zijn de minst benutte velden in de hele specificatie. Voor Google hebben ze geen betekenis: ze bestaan puur zodat jij kunt segmenteren. Margeklassen, voorraaddiepte, seizoensgebondenheid, productleeftijd, GA4-prestatieniveau. Als je campagnestructuur een bedrijfsregel niet kan uitdrukken, is dit meestal de reden.

Media

additional_image_link, lifestyle_image_link, virtual_model_link, video_link.

Een minimaal maar volledig retailartikel

<item>
  <g:id>KRC-4210-BLK</g:id>
  <g:title>Karaca Fine Pearl 6-Person Dinner Set — Black</g:title>
  <g:description>26-piece porcelain dinner set for six. Dishwasher and microwave safe.</g:description>
  <g:link>https://example.com/urun/fine-pearl-6-kisilik</g:link>
  <g:image_link>https://cdn.example.com/krc-4210-blk-01.jpg</g:image_link>
  <g:additional_image_link>https://cdn.example.com/krc-4210-blk-02.jpg</g:additional_image_link>
  <g:video_link>https://cdn.example.com/video/krc-4210.mp4</g:video_link>
  <g:availability>in_stock</g:availability>
  <g:price>4299.00 TRY</g:price>
  <g:sale_price>3499.00 TRY</g:sale_price>
  <g:sale_price_effective_date>2026-11-24T00:00+0300/2026-12-01T23:59+0300</g:sale_price_effective_date>
  <g:brand>Karaca</g:brand>
  <g:gtin>8680150042109</g:gtin>
  <g:condition>new</g:condition>
  <g:google_product_category>672</g:google_product_category>
  <g:product_type>Home &amp; Kitchen &gt; Dinnerware &gt; Dinner Sets</g:product_type>
  <g:custom_label_0>high-margin</g:custom_label_0>
  <g:custom_label_1>bf-2026</g:custom_label_1>
</item>

Let op de & en > in product_type. Niet-geëscapete &-tekens in URL's en categoriepaden zijn de meest voorkomende oorzaak van XML-bestanden die helemaal niet geparseerd kunnen worden.

5. Wat er in 2026 is veranderd

Drie wijzigingen in de productdataspecificatie van Google zijn het waard om nu al op te pakken in plaats van pas bij de deadline.

De minimale beeldresolutie is nu 500x500 px voor image_link en additional_image_link, in alle categorieën en voor alle marketingmethoden. Waarschuwingen verschenen vanaf april 2026 in Merchant Center; de handhaving begint op 31 januari 2027. Google schaalt sommige kleinere afbeeldingen mogelijk automatisch op, maar dat als oplossing zien is een vergissing: opgeschaalde afbeeldingen zien er opgeschaald uit, en beeldkwaliteit beïnvloedt de doorklikratio.

video_link is live en wordt vertoond. Video's die via het attribuut worden aangeleverd, komen sinds 30 juni 2026 in aanmerking voor vertoning, met validatie op beleid en kwaliteit. Fouten blokkeren de video, maar niet het aanbod, waardoor dit een veld met weinig risico is om in te vullen. De meeste catalogi hebben voor de meeste SKU's geen productvideo, en precies daarom is het op schaal genereren van video's uit feeddata nu een concurrentievoordeel in plaats van een leuke extra.

De verzendinstellingen op productniveau zijn uitgebreid. handling_cutoff_time stelt een dagelijkse deadline in voor orderverwerking, en minimum_order_value bepaalt het minimale bestelbedrag voor bezorging. Het attribuut shipping heeft bovendien de subattributen loyalty_program_label en loyalty_tier_label gekregen voor bezorgvoordelen die aan een loyaliteitsprogramma zijn gekoppeld.

De richting is consistent: Google verplaatst steeds meer details die vroeger op accountniveau lagen naar artikelniveau. Alles wat per artikel wordt uitgedrukt, kan een feedlaag automatiseren en een handmatig proces niet.

6. Het overzicht per branche

Retail is één regel in deze tabel, niet de hele tabel.

Twee structurele regels die je moet kennen voordat je iets bouwt:

Een Meta-catalogus bevat precies één type aanbod. Je kunt hotels en producten niet mengen. Verkoop je beide, dan heb je twee catalogi nodig.

Google scheidt branches op het niveau van de gegevensbron. Een gegevensbron voor voertuigen mag alleen op voertuigadvertenties worden gericht. Voertuigen aanleveren in een Shopping-gegevensbron levert afkeuringen op, geen vermeldingen, en voertuigbronnen mogen geen onderdelen of accessoires bevatten; die horen in een gewone productfeed.

7. Voertuigfeeds

Automotive is de branche waar "gebruik gewoon de retailspecificatie" het duidelijkst misgaat. Een auto is een uniek fysiek object met een wettelijke identifier, geen SKU met voorraaddiepte.

De voertuigattributen van Google komen bovenop de gemeenschappelijke kern:

<item>
  <g:id>STK-88214</g:id>
  <g:title>2023 Volkswagen Passat 1.5 TSI Business DSG</g:title>
  <g:description>Single owner, full service history, no accident record.</g:description>
  <g:link>https://example.com/ilan/88214</g:link>
  <g:image_link>https://cdn.example.com/88214-01.jpg</g:image_link>
  <g:price>1450000.00 TRY</g:price>
  <g:condition>used</g:condition>
  <g:brand>Volkswagen</g:brand>
  <g:model>Passat</g:model>
  <g:trim>1.5 TSI Business DSG</g:trim>
  <g:year>2023</g:year>
  <g:vin>WVWZZZ3CZPE000000</g:vin>
  <g:mileage>
    <g:value>42500</g:value>
    <g:unit>km</g:unit>
  </g:mileage>
  <g:body_style>sedan</g:body_style>
  <g:color>Grey</g:color>
  <g:vehicle_fulfillment>
    <g:option>in_store</g:option>
    <g:store_code>IST-01</g:store_code>
  </g:vehicle_fulfillment>
</item>

Wat voertuigfeeds operationeel anders maakt:

• De voorraad is één diep. Elk artikel is een enkele eenheid. Zodra het verkocht is, moet het direct uit de feed verdwijnen, niet pas bij de synchronisatie van morgen. Verouderde voertuigvermeldingen verspillen dure klikken aan auto's die niet meer bestaan en schaden de kwaliteit van je account.
• De verversingsfrequentie is alles. Verversingscycli van vier uur zijn in automotive standaardpraktijk, geen optimalisatie.
• Consistentie met de landingspagina wordt gehandhaafd. Prijs en kilometerstand in de feed moeten exact overeenkomen met de detailpagina van het voertuig. Een prijswijziging bij de hele dealer die de site wel bijwerkt maar de feed niet, veroorzaakt binnen enkele uren een golf aan afkeuringen.
• De advertenties voor autovoorraad van Meta gebruiken een eigen veldvocabulaire (state_of_vehicle, exterior_color, transmission, drivetrain, dealer_id), dus dezelfde brongegevens hebben per kanaal een andere transformatie nodig.

8. Reisfeeds

Reizen valt uiteen in drie verschillende catalogustypen, en de fout is ze als één te behandelen.

Hotels

De accommodatiefeed is relatief statisch: naam, beschrijving, adres, coördinaten, sterrenclassificatie, afbeeldingen, een vanafprijs. Wat beweegt, zijn beschikbaarheid en tarief. Daarom combineren hotelopstellingen meestal een statische accommodatiefeed met dynamische feeds voor kamertypen en prijzen.

Kernparameters: hotel_id, name, description, brand, url, image, latitude, longitude, address (met city, region, country, postal_code), base_price, currency, star_rating, neighborhood, phone, guest_ratings.

<item>
  <g:hotel_id>HTL-BDR-114</g:hotel_id>
  <g:name>Blue Bay Resort Bodrum</g:name>
  <g:description>Seafront resort with private beach, three restaurants and a spa.</g:description>
  <g:url>https://example.com/otel/blue-bay-bodrum</g:url>
  <g:image>https://cdn.example.com/htl-114-01.jpg</g:image>
  <g:latitude>37.0344</g:latitude>
  <g:longitude>27.4305</g:longitude>
  <g:address>Yalıkavak Mah. Sahil Cad. 12, Bodrum, Muğla, TR, 48990</g:address>
  <g:base_price>4200.00 TRY</g:base_price>
  <g:star_rating>5</g:star_rating>
  <g:neighborhood>Yalıkavak</g:neighborhood>
</item>

Vluchten

Het artikel is een route, geen stoel. De identiteit is het paar van vertrek en bestemming: origin_airport en destination_airport als IATA-codes, plus price, url, image, description. Prijzen zijn doorgaans vanafprijzen en veranderen voortdurend, waardoor de updatefrequentie de beperkende factor is.

Bestemmingen

Het artikel is een plek waar je reizen naartoe verkoopt: destination_id, name, address, neighborhood, types, price, url, image. Handig voor prospecting bovenin de funnel, wanneer de reiziger wel de intentie heeft maar nog geen specifieke accommodatie in gedachten.

Het terugkerende probleem bij reizen is dat prijs en beschikbaarheid worden berekend, niet opgeslagen. De "prijs" van een hotel hangt af van data, bezetting en verblijfsduur; die van een vlucht van het moment waarop je ernaar vraagt. Feeds willen één getal. Kiezen welk getal (laagst beschikbare in de komende 30 dagen, laagste voor het komende weekend, gemiddelde) is een commerciële beslissing die ongemerkt bepaalt hoe je advertenties presteren, en het loont om die bewust te nemen in plaats van genoegen te nemen met wat de export toevallig opleverde.

9. Vastgoedfeeds

Structureel vergelijkbaar met voertuigen: unieke fysieke objecten, een voorraad van één diep, een hoge waarde per klik en een vermelding die moet verdwijnen zodra het object weg is.

Kernparameters: home_listing_id, name, description, address, latitude, longitude, url, image, price, currency, property_type (appartement, huis, grond, commercieel), listing_type (te koop, te huur, nieuwbouw), num_beds, num_baths, area_size, area_unit, year_built, availability, agent_name, agent_phone.

<item>
  <g:home_listing_id>EMK-2291</g:home_listing_id>
  <g:name>3+1 Apartment with Sea View — Kadıköy</g:name>
  <g:description>Renovated 3+1 apartment, 4th floor, elevator, closed parking.</g:description>
  <g:address>Caferağa Mah., Kadıköy, İstanbul, TR</g:address>
  <g:latitude>40.9862</g:latitude>
  <g:longitude>29.0299</g:longitude>
  <g:url>https://example.com/ilan/2291</g:url>
  <g:image>https://cdn.example.com/emk-2291-01.jpg</g:image>
  <g:price>12500000.00 TRY</g:price>
  <g:property_type>apartment</g:property_type>
  <g:listing_type>for_sale</g:listing_type>
  <g:num_beds>3</g:num_beds>
  <g:num_baths>2</g:num_baths>
  <g:area_size>135</g:area_size>
  <g:area_unit>sq_m</g:area_unit>
  <g:availability>available</g:availability>
</item>

Iets wat geen feedprobleem is, maar je campagne wel stillegt: huisvesting is op Meta een beperkte advertentiecategorie. Campagnes die woningvermeldingen promoten, moeten worden aangemeld onder de speciale advertentiecategorie voor huisvesting, wat de targetingopties beperkt. De catalogus kan perfect zijn en de campagne toch mislukken als dit niet is ingesteld.

10. Vacaturefeeds

Werving gebruikt een volledig andere documentstructuur (<source> en <job> in plaats van <rss> en <item>), en die is het bekijken waard, omdat ze laat zien dat "XML-feed" een patroon is en geen enkel schema.

<?xml version="1.0" encoding="UTF-8"?>
<source>
  <publisher>Example Company</publisher>
  <publisherurl>https://example.com</publisherurl>
  <lastBuildDate>Wed, 12 Aug 2026 09:00:00 GMT</lastBuildDate>

  <job>
    <title><![CDATA[Senior Backend Engineer]]></title>
    <date><![CDATA[Mon, 10 Aug 2026 08:00:00 GMT]]></date>
    <referencenumber><![CDATA[ENG-4471]]></referencenumber>
    <url><![CDATA[https://example.com/careers/eng-4471]]></url>
    <company><![CDATA[Example Company]]></company>
    <city><![CDATA[İstanbul]]></city>
    <state><![CDATA[İstanbul]]></state>
    <country><![CDATA[TR]]></country>
    <postalcode><![CDATA[34394]]></postalcode>
    <description><![CDATA[<p>We are hiring a senior backend engineer to work on our data pipeline...</p>]]></description>
    <salary><![CDATA[120000 - 160000 TRY monthly]]></salary>
    <jobtype><![CDATA[fulltime]]></jobtype>
    <category><![CDATA[Engineering]]></category>
    <experience><![CDATA[5+ years]]></experience>
  </job>

</source>

Vier regels die specifiek gelden voor vacaturefeeds:

1. CDATA is de norm, geen uitzondering. Vacatureteksten bevatten HTML, ampersands en apostrofs. Door elk veld in <![CDATA[...]]> te verpakken, voorkom je een hele categorie parseerfouten.
2. De locatie heeft minimaal stad, provincie/staat en land nodig. Laat je die weg, dan verliest de vacature standaard organische zichtbaarheid op de grote aggregators.
3. Vervulde functies moeten worden verwijderd, niet als gesloten gemarkeerd. Er bestaat geen equivalent van availability. Aanwezigheid in de feed is het beschikbaarheidssignaal, en aggregators straffen feeds af die verouderde vacatures bevatten.
4. Eén taal, één vacaturevermelding. Een vacature die in twee talen wordt gepubliceerd, heeft twee afzonderlijke vermeldingen met verschillende referentienummers nodig.

Los van de feed zorgt gestructureerde JobPosting-data in JSON-LD op de carrièrepagina ervoor dat een functie in aanmerking komt voor vacaturevermeldingen in de zoekresultaten. De twee vullen elkaar aan: de feed regelt de distributie naar aggregators, de gestructureerde data regelt de organische zoekresultaten. De meeste recruitmentteams doen het een en niet het ander.

11. Tijdgebonden aanbod

De interessantste feedcategorie heeft geen officiële specificatie, omdat de platforms er nooit op hebben gerekend: aanbod waarvan het bepalende attribuut wanneer is, niet wat.

Voetbalwedstrijden. Concerten. Bioscoopvoorstellingen. Vluchtvertrekken. Veilingkavels. Tijdsloten voor restaurantreserveringen. Bezorgvensters.

Deze hebben alle eigenschappen van producten (een identiteit, een prijs, een afbeelding, een landingspagina) plus één waarvoor de retailspecificatie geen veld heeft: een houdbaarheid die in uren wordt gemeten. Een wedstrijd die al is begonnen, is niet "uitverkocht", maar betekenisloos.

De aanpak die werkt, is ze te modelleren als standaard catalogusproducten en de tijdsdimensie vast te leggen in velden die het platform al begrijpt:

<item>
  <g:id>MTC-2026-08-16-GS-FB</g:id>
  <g:title>Galatasaray - Fenerbahçe | Super League, Week 2</g:title>
  <g:description>Saturday 16 August, 19:00. Live odds and in-play betting.</g:description>
  <g:link>https://example.com/mac/2026-08-16-gs-fb</g:link>
  <g:image_link>https://cdn.example.com/creatives/mtc-2026-08-16-gs-fb.jpg</g:image_link>
  <g:availability>in_stock</g:availability>
  <g:price>1.00 TRY</g:price>
  <g:product_type>Football &gt; Super League &gt; Week 2</g:product_type>
  <g:custom_label_0>2026-08-16</g:custom_label_0>
  <g:custom_label_1>derby</g:custom_label_1>
  <g:custom_label_2>ms1-2.10</g:custom_label_2>
  <g:expiration_date>2026-08-16T19:00+0300</g:expiration_date>
</item>

Drie dingen zorgen ervoor dat dit werkt:

• expiration_date of een gelijkwaardige verwijderingsregel, zodat het artikel bij de aftrap uit de catalogus verdwijnt en niet pas bij de volgende geplande synchronisatie.
• Custom labels met de tijdsdimensie, zodat campagnes kunnen worden opgebouwd rond "dit weekend", "derby" of "odds boven 2.0".
• Een creative per artikel. Hier loopt de aanpak meestal vast. Een wedstrijdlijst met enkele honderden wedstrijden per week vraagt om enkele honderden afbeeldingen, elk met teams, datum, tijd en actuele odds. Geen designteam produceert dat. De creative genereren uit de feedregel is de enige methode die het tempo bijhoudt, en precies zo draaide Bilyoner voor het eerst catalogusadvertenties en verhoogde het de ROAS met 49%.

Als je aanbod een starttijd heeft, hoort het in een catalogus. De drempel is bijna altijd het formaat, niet het concept.

12. Feeds voor lokale voorraad

Lokale voorraad zit tussen retail en branchespecifiek in: dezelfde producten, beschreven per fysieke locatie.

Parameters: id, store_code, quantity, price, sale_price, sale_price_effective_date, availability, pickup_method (kopen, reserveren, verzenden naar winkel, niet ondersteund), pickup_sla (dezelfde dag, volgende dag, meerdere dagen).

Het structurele punt is dat de lokale feed een aanvulling is, geen vervanging. Ze verwijst via id naar artikelen in de primaire productfeed en voegt feiten per winkel toe. Eén artikel, veel winkels, veel rijen.

Een opmerking voor 2026: online- en winkelversies van hetzelfde product met verschillende prijzen of beschikbaarheid hebben nu afzonderlijke product-ID's nodig in plaats van te worden samengevoegd tot één. Feeds die ze hadden samengevoegd, wordt gevraagd ze te splitsen.

13. Opmaakregels

Deze gelden voor elk feedtype in dit artikel en zijn samen verantwoordelijk voor het overgrote deel van de feeds die volledig mislukken.

Codering. Altijd UTF-8, vermeld in de XML-declaratie en geserveerd met een bijpassende Content-Type-header. Een mismatch tussen de opgegeven en de werkelijke codering beschadigt elk niet-ASCII-teken.

Escaping. Vijf tekens moeten in XML-content worden geëscapet: & → &, < → <, > → >, " → ", ' → '. Niet-geëscapete ampersands in tracking-URL's zijn de belangrijkste oorzaak van feeds die niet geparseerd kunnen worden. Het alternatief is CDATA, wat standaardpraktijk is in vacaturefeeds en overal nuttig is waar beschrijvingen opmaak bevatten.

Datums. ISO 8601 met een expliciete tijdzoneverschuiving. 2026-08-16T19:00+0300, niet 16.08.2026 19:00. Feeds die meerdere markten bedienen vanuit één bron zonder tijdzone-informatie, leveren artikelen op die uren te vroeg of te laat verlopen.

Prijzen. Waarde en ISO 4217-valuta, decimale punt in plaats van komma, geen scheidingsteken voor duizendtallen. 4299.00 TRY. En de prijs in de feed moet overeenkomen met de landingspagina; de meeste platforms controleren dat door te crawlen.

Vaste waarden zijn gevoelig voor hoofdletters en opmaak, en ze verschillen per platform. Google verwacht in_stock; Meta verwacht in stock. Dat ene verschil heeft meer catalogusimports laten mislukken dan wat dan ook. Ga er nooit van uit dat een vaste waarde tussen bestemmingen overdraagbaar is.

Bestandslevering. Gzip-compressie voor grote bestanden, een stabiele HTTPS-URL, geen authenticatiemuur tenzij het platform dat expliciet ondersteunt, en een server die binnen de time-out van het platform reageert. Een feed-URL achter de botbescherming van Cloudflare is een feed-URL die niet wordt opgehaald.

De updatefrequentie moet de volatiliteit van de onderliggende gegevens volgen, niet een conventie: elk uur of vaker voor odds, vliegprijzen en snel wisselende retailvoorraad; om de paar uur voor voertuigen en vastgoed; dagelijks voor stabiele catalogi.

14. XML vs CSV vs JSON vs API

XML blijft de standaard voor alles met nesting. Daarom zijn feeds voor voertuigen, reizen en retail met veel verzendgegevens meestal XML, terwijl eenvoudige modecatalogi vaak TSV zijn. Let er ook op dat verschillende grote bestemmingen overstappen op API-first-verwerking, dus het bestand als je enige integratieroute behandelen is op middellange termijn een risico.

Als je titels komma's bevatten (en titels met kleur en maat doen dat bijna altijd), gebruik dan TSV in plaats van CSV. Een hele categorie parseerbugs verdwijnt dan.

15. Checklist vóór lancering

• [ ] Het bestand wordt door een XML-validator geparseerd voordat het ook maar in de buurt van een platform komt
• [ ] UTF-8 correct gedeclareerd en geserveerd; niet-ASCII-tekens worden goed weergegeven
• [ ] Elke & in elke URL geëscapet, of het veld verpakt in CDATA
• [ ] ID's uniek, stabiel over synchronisaties heen en gelijk aan je pixel- of tag-events
• [ ] Alle verplichte attributen aanwezig voor de beoogde bestemming, gecontroleerd tegen de specificatie van die bestemming en niet tegen een algemene
• [ ] Vaste waarden per bestemming getransformeerd, niet gekopieerd
• [ ] Prijzen komen exact overeen met de landingspagina's, inclusief valuta en eventuele btw-behandeling
• [ ] Datums in ISO 8601 met tijdzoneverschuiving
• [ ] Afbeeldingen voldoen aan het minimum van 500x500 en laden via HTTPS zonder redirects
• [ ] Verkochte, vervulde, verlopen of vertrokken artikelen verdwijnen volgens het juiste schema uit de feed
• [ ] De updatefrequentie past bij hoe snel de onderliggende gegevens werkelijk veranderen
• [ ] De feed-URL is publiek bereikbaar en wordt niet geblokkeerd door botbescherming
• [ ] Er is een monitoringregel voor onverwachte veranderingen in het aantal artikelen

16. Veelgestelde vragen

Is XML in 2026 nog steeds het juiste formaat?
Voor alles met geneste gegevens wel. Voor platte catalogi is TSV eenvoudiger en minder kwetsbaar. Voor realtime eisen verslaat een API-integratie elk bestand. Het formaat moet de gegevens volgen, niet de gewoonte.

Kan ik één feed gebruiken voor elk platform?
Eén bron, ja. Eén bestand, nee. Veldnamen, vaste waarden, tekenlimieten en verplichte attributen verschillen per bestemming, en de verschillen zijn niet cosmetisch. De werkbare architectuur is één canonieke catalogus met transformaties per kanaal die bij de export worden toegepast.

Wat als mijn aanbod geen producten zijn?
Dan heb je de specificatie voor jouw branche nodig, niet die voor retail. Voertuigen, hotels, vluchten, bestemmingen, vastgoed en vacatures hebben allemaal een eigen specificatie. En als je aanbod iets is waarvoor geen enkel platform een specificatie heeft (wedstrijden, voorstellingen, tijdsloten, kavels), dan modelleer je het als producten en leg je de ontbrekende dimensie vast in de velden die wel bestaan.

Hoe vaak moet de feed worden bijgewerkt?
Zo vaak als de onderliggende gegevens wezenlijk veranderen. Een voertuig dat vanochtend is verkocht en vanmiddag nog steeds wordt geadverteerd, geeft geld uit aan niets.

Heb ik GTIN's nodig?
Voor retail in feite wel. GTIN koppelt je artikel aan de productkennis van een platform, en dat bepaalt steeds vaker of je überhaupt verschijnt in vergelijkingsomgevingen en AI-gedreven shoppingresultaten. Voor voertuigen, vastgoed en vacatures zijn de gelijkwaardige identiteitsvelden vin, de vermeldings-ID en het referentienummer.

Waar het lastig wordt

Geen van de afzonderlijke regels in dit artikel is moeilijk. De moeilijkheid is dat het er enkele honderden zijn, dat ze per bestemming verschillen, dat ze zonder waarschuwing veranderen en dat overtredingen geruisloos falen.

Eén catalogus die wordt geëxporteerd naar Google, Meta, TikTok en drie marktplaatsen, betekent zes verschillende contracten waaraan tegelijk moet worden voldaan vanuit één bron van waarheid. Dat handmatig doen betekent zes bestanden onderhouden en ze bij elke wijziging in de catalogus met elkaar in overeenstemming brengen.

Dat is de laag waarvoor Feedance is gebouwd: Feed Rules om attributen bij de bron te normaliseren, kanaalexports die de juiste transformatie toepassen voor elk van de meer dan 200 bestemmingen zonder je brongegevens aan te raken, Feed Protection om ontbrekende attributen en onverwachte veranderingen in het aantal artikelen op te sporen voordat een platform dat doet, en een Creative Suite die per feedregel een afbeelding of video genereert voor catalogi waarbij handmatige productie nooit realistisch was.

Het ondersteunt branches buiten retail als volwaardige toepassingen in plaats van als bijzaak: reisaanbod met live prijzen, betting-catalogi met match-timedata, en distributiekanalen voor automotive, vastgoed en vacatures.

Wil je weten hoe je huidige feed ervoor staat voordat je iets verandert? Onze gratis tool voor feedaudits beoordeelt hem kosteloos op volledigheid, datakwaliteit en technische gezondheid. Of plan een demo van 15 minuten en we bekijken hem samen.

Laatst gecontroleerd: augustus 2026. Platformspecificaties veranderen vaak; controleer de actuele vereisten in de officiële documentatie van elke bestemming voordat je iets implementeert.