Standard XML Product Feed Parameters

Most articles about XML feeds assume you are selling t-shirts.

That assumption made sense a decade ago, when a "product feed" meant a Google Shopping file and nothing else. It doesn't hold anymore. A car dealership, a job board, a hotel group, a real estate portal and a betting platform all run feed-driven advertising today, and none of them submit size or gtin. They submit VINs, IATA codes, bedroom counts, employment types and kick-off times.

The underlying mechanics are identical. The parameters are not.

This guide covers both: the structural rules that apply to every XML feed regardless of vertical, and the specific attribute sets for each of the major feed types — retail, local inventory, vehicle, travel, property, jobs, and time-bound inventory like matches, events and screenings. Working XML for each.

1. What an XML feed actually is

An XML feed is a structured file that describes an inventory in a way machines can consume without a human interpreting it. A platform fetches the file on a schedule, parses it, and creates listings, ads or search results from what it finds.

The format matters less than most people think. What matters is the contract: each destination publishes a specification saying which fields it requires, what values are legal, and how it will behave when they are wrong. The feed is your side of that contract.

Two consequences follow, and they are the reason feeds are harder than they look:

The contract is per-destination. Google's product specification, Meta's catalog specification and Indeed's job XML share almost no field names. A single source catalogue has to be transformed differently for each.

Violations mostly fail silently. A malformed field rarely breaks the file. It disapproves one item, or downgrades one listing, or drops one attribute from the ad — and nothing in your campaign dashboard says so.

2. The anatomy of the file

Most advertising XML feeds use RSS 2.0 with a namespace extension. The structure is always the same three layers:

<?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>

• The XML declaration sets the encoding. It must be UTF-8 in practice; anything else causes character corruption in non-English catalogues and is the single most common cause of mangled Turkish, German and Czech product titles.
• The namespace declaration (xmlns:g="...") is what makes <g:price> legal. Omit it and every prefixed element is silently ignored — the feed parses, and almost nothing imports.
• <channel> holds feed-level metadata.
• <item> is one unit of inventory. What "one unit" means is a decision, not a given: one SKU, one variant, one vehicle, one job opening, one hotel, one fixture.

Not every vertical uses this shape. Job feeds use <source><job>, and some marketplaces define their own root elements entirely. The three-layer logic — document, container, repeating item — holds regardless.

3. The universal core

Seven parameters appear in essentially every feed specification ever written, under different names. If you understand these, you can read any spec.

Three rules about the ID that apply universally and cause more damage than any other single field:

1. It must be stable. If your ID regenerates on export — derived from row order, a timestamp, a hash of changing content — every sync destroys the item's accumulated performance history and it starts from zero.
2. It must be unique. Duplicate IDs cause later rows to be dropped without an error message. Items simply go missing.
3. It must match what your pixel or tag sends. Meta's catalog matching, Google's dynamic remarketing and every retargeting product depend on the feed ID and the site event ID being the same string. This is the most common reason dynamic retargeting "doesn't work."

4. Retail / e-commerce parameters

This is the best-documented specification and the base most other verticals borrow from.

Required

Identifiers

brand, gtin, mpn, and identifier_exists. GTIN is the field that determines whether your product is matched to Google's product knowledge graph — and therefore whether it appears in comparison and AI shopping surfaces at all. It is not optional in practice, whatever the spec says.

Variants

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

Variants are their own subject; the short version is that item_group_id must be identical across a group and derived from stable source data, and that gender and age_group are group-constant while color and size are not.

Categorisation

google_product_category (Google's taxonomy, ID or full path), product_type (your own taxonomy — this is the field that makes campaign structure possible, and it's free-form, so use it).

Commercial

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

Logistics

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

Campaign control

excluded_destination, included_destination, ads_redirect, custom_label_0 through custom_label_4.

The five custom labels are the most underused fields in the entire specification. They carry no meaning to Google — they exist purely so you can segment. Margin bands, stock depth, seasonality, product age, GA4 performance tier. If your campaign structure can't express a business rule, this is usually why.

Media

additional_image_link, lifestyle_image_link, virtual_model_link, video_link.

A minimal but complete retail item

<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>

Note the & and > in product_type. Unescaped & characters in URLs and category paths are the most frequent cause of XML files that fail to parse entirely.

5. What changed in 2026

Three changes to Google's product data specification are worth acting on now rather than at the deadline.

Minimum image resolution is now 500x500 px for image_link and additional_image_link, across all categories and marketing methods. Warnings began appearing in Merchant Center in April 2026; enforcement starts on 31 January 2027. Google may upscale some smaller images automatically, but treating that as a solution is a mistake — upscaled images look upscaled, and image quality is a click-through variable.

video_link is live and serving. Videos submitted through the attribute became eligible to serve from 30 June 2026, with policy and quality validation attached. Errors block the video but not the offer, which means this is a low-risk field to populate. Most catalogues have no product video for most SKUs, which is precisely why generating them from feed data at scale is now a competitive gap rather than a nice-to-have.

Product-level shipping controls expanded. handling_cutoff_time sets a daily order-processing deadline, and minimum_order_value specifies the minimum spend for delivery. The shipping attribute also gained loyalty_program_label and loyalty_tier_label sub-attributes for loyalty-specific delivery benefits.

The direction of travel is consistent: Google keeps moving detail that used to live at account level down to item level. Anything expressed per-item is something a feed layer can automate and a manual process cannot.

6. The vertical map

Retail is one row in this table, not the table.

Two structural rules worth internalising before you build anything:

A Meta catalog holds exactly one inventory type. You cannot mix hotels and products. If you sell both, you need two catalogs.

Google separates verticals at the data source level. A vehicle data source must be targeted only at vehicle ads. Submitting vehicles into a Shopping data source produces disapprovals, not listings — and vehicle sources should not contain spare parts or accessories, which belong in a normal product feed.

7. Vehicle feeds

Automotive is the vertical where "just use the retail spec" fails most obviously. A car is a unique physical object with a legal identifier, not a SKU with stock depth.

Google's vehicle attributes sit on top of the common core:

<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>

What makes vehicle feeds operationally different:

• Inventory is one-deep. Every item is a single unit. When it sells, it must leave the feed immediately — not on tomorrow's sync. Stale vehicle listings waste high-CPC clicks on cars that no longer exist and damage account quality.
• Refresh frequency is the whole game. Four-hour refresh cycles are standard practice in automotive, not an optimisation.
• Landing page consistency is enforced. Price and mileage in the feed must match the vehicle detail page exactly. A dealer-wide price change that updates the site but not the feed causes a wave of disapprovals within hours.
• Meta's automotive inventory ads use a separate field vocabulary — state_of_vehicle, exterior_color, transmission, drivetrain, dealer_id — so the same source data needs a different transformation per channel.

8. Travel feeds

Travel splits into three distinct catalog types, and the mistake is treating them as one.

Hotels

The property feed is comparatively static: name, description, address, coordinates, star rating, images, a starting price. What moves is availability and rate, which is why hotel setups usually pair a static property feed with dynamic room-type and pricing feeds.

Core parameters: hotel_id, name, description, brand, url, image, latitude, longitude, address (with 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>

Flights

The item is a route, not a seat. The identity is the origin–destination pair: origin_airport and destination_airport as IATA codes, plus price, url, image, description. Prices are typically "from" prices and change constantly, which makes update frequency the binding constraint.

Destinations

The item is a place you sell travel to: destination_id, name, address, neighborhood, types, price, url, image. Useful for upper-funnel prospecting where the traveller has intent but no specific property in mind.

The recurring travel problem is that price and availability are computed, not stored. A hotel's "price" depends on dates, occupancy and length of stay; a flight's depends on the moment you ask. Feeds want a single number. Choosing which number — lowest available in the next 30 days, lowest for the coming weekend, average — is a commercial decision that quietly determines how your ads perform, and it is worth making deliberately rather than defaulting to whatever the export produced.

9. Property / real estate feeds

Structurally similar to vehicles: unique physical assets, one-deep inventory, high value per click, and a listing that must disappear the moment it's taken.

Core parameters: home_listing_id, name, description, address, latitude, longitude, url, image, price, currency, property_type (apartment, house, land, commercial), listing_type (for sale, for rent, new build), 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>

One thing that is not a feed problem but will stop your campaign: housing is a restricted advertising category on Meta. Campaigns promoting home listings must be declared under the housing special ad category, which restricts targeting options. The catalog can be perfect and the campaign still fail if this isn't set.

10. Job feeds

Recruitment uses a different document structure entirely — <source> and <job> rather than <rss> and <item> — and it is worth seeing, because it demonstrates that "XML feed" is a pattern, not a single 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>

Four rules specific to job feeds:

1. CDATA is the norm, not an exception. Job descriptions contain HTML, ampersands and apostrophes. Wrapping every field in <![CDATA[...]]> avoids an entire class of parse failures.
2. Location needs at least city, state and country. Omit them and the posting loses organic visibility on the major aggregators by default.
3. Filled roles must be removed, not marked closed. There is no availability equivalent. Presence in the feed is the availability signal, and aggregators penalise feeds that carry stale postings.
4. One language, one job entry. A posting published in two languages needs two separate entries with distinct reference numbers.

Separately from the feed, JobPosting structured data in JSON-LD on the careers page is what makes a role eligible for job listings in search results. The two are complementary: the feed handles distribution to aggregators, the structured data handles organic search. Most recruitment teams do one and not the other.

11. Time-bound inventory

The most interesting feed category has no official specification, because the platforms never anticipated it: inventory whose defining attribute is when, not what.

Football matches. Concerts. Cinema screenings. Flight departures. Auction lots. Restaurant reservation slots. Delivery windows.

These have all the properties of products — an identity, a price, an image, a landing page — plus one the retail spec has no field for: a shelf life measured in hours. A fixture that has already kicked off is not "out of stock," it is meaningless.

The approach that works is to model them as standard catalog products and encode the time dimension in fields the platform already understands:

<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>

Three things make this work:

• expiration_date or an equivalent removal rule so the item leaves the catalogue at kick-off rather than the next scheduled sync.
• Custom labels carrying the time dimension so campaigns can be structured around "this weekend," "derby," or "odds above 2.0."
• A creative per item. This is where the approach usually stalls. A fixture list of several hundred matches per week needs several hundred images, each carrying teams, date, time and current odds. No design team produces that. Generating the creative from the feed row is the only method that keeps pace — which is exactly how Bilyoner ran catalog ads for the first time, and lifted ROAS 49%.

If your inventory has a start time, it belongs in a catalogue. The barrier is nearly always format, not concept.

12. Local inventory feeds

Local inventory sits between retail and vertical: the same products, described per physical location.

Parameters: id, store_code, quantity, price, sale_price, sale_price_effective_date, availability, pickup_method (buy, reserve, ship to store, not supported), pickup_sla (same day, next day, multi-day).

The structural point is that the local feed is a supplement, not a replacement. It references items in the primary product feed by id and adds per-store facts. One item, many stores, many rows.

A 2026 note worth flagging: online and in-store versions of the same product with different prices or availability now need separate product IDs rather than being collapsed into one. Feeds that consolidated them are being asked to split.

13. Formatting rules

These apply to every feed type in this article, and between them account for the large majority of feeds that fail outright.

Encoding. UTF-8, always, declared in the XML declaration and served with a matching Content-Type header. Mismatches between declared and actual encoding corrupt every non-ASCII character.

Escaping. Five characters must be escaped in XML content: & → &, < → <, > → >, " → ", ' → '. Unescaped ampersands in tracking URLs are the number one cause of feeds that won't parse. The alternative is CDATA, which is standard practice in job feeds and useful anywhere descriptions contain markup.

Dates. ISO 8601 with an explicit timezone offset. 2026-08-16T19:00+0300, not 16.08.2026 19:00. Feeds serving multiple markets from one timezone-naive source produce items that expire hours early or late.

Prices. Value and ISO 4217 currency, decimal point not comma, no thousands separator. 4299.00 TRY. And the price in the feed must match the landing page — this is enforced by crawl on most platforms.

Enumerated values are case- and format-sensitive, and they differ by platform. Google expects in_stock; Meta expects in stock. That single difference has broken more catalogue imports than any other. Never assume an enum transfers between destinations.

File delivery. Gzip compression for large files, a stable HTTPS URL, no authentication wall unless the platform explicitly supports it, and a server that responds within the platform's timeout. A feed URL behind Cloudflare bot protection is a feed URL that doesn't get fetched.

Update frequency should follow the volatility of the underlying data, not a convention: hourly or faster for odds, flight prices and fast-moving retail stock; every few hours for vehicles and property; daily for stable catalogues.

14. XML vs CSV vs JSON vs API

XML remains the default for anything with nesting, which is why vehicle, travel and shipping-heavy retail feeds tend to be XML while simple fashion catalogues are often TSV. Note also that several major destinations are moving toward API-first ingestion, so treating the file as your only integration path is a medium-term risk.

If your titles contain commas — and titles with colour and size almost always do — use TSV over CSV. An entire class of parsing bugs disappears.

15. Pre-launch checklist

• [ ] File parses in an XML validator before it goes anywhere near a platform
• [ ] UTF-8 declared and served correctly; non-ASCII characters render properly
• [ ] Every & in every URL escaped, or the field wrapped in CDATA
• [ ] IDs unique, stable across syncs, and matching your pixel or tag events
• [ ] All required attributes present for the target destination — verified against that destination's spec, not a general one
• [ ] Enum values transformed per destination, not copied
• [ ] Prices match landing pages exactly, including currency and any tax treatment
• [ ] Dates in ISO 8601 with timezone offsets
• [ ] Images meet the 500x500 minimum and resolve over HTTPS without redirects
• [ ] Sold, filled, expired or departed items leave the feed on the right schedule
• [ ] Update frequency matches how fast the underlying data actually changes
• [ ] Feed URL is publicly reachable and not blocked by bot protection
• [ ] A monitoring rule exists for unexpected item-count changes

16. FAQ

Is XML still the right format in 2026? For anything with nested data, yes. For flat catalogues, TSV is simpler and less fragile. For real-time requirements, an API integration beats any file. The format should follow the data, not habit.

Can I use one feed for every platform? One source, yes. One file, no. Field names, enum values, character limits and required attributes differ by destination, and the differences are not cosmetic. The workable architecture is a single canonical catalogue with per-channel transformations applied on export.

What if my inventory isn't products? Then you need the specification for your vertical, not the retail one. Vehicles, hotels, flights, destinations, properties and jobs all have their own. And if your inventory is something no platform has a specification for — matches, screenings, slots, lots — you model it as products and encode the missing dimension in the fields that exist.

How often should the feed update? As often as the underlying data changes materially. A vehicle that sold this morning and is still advertised this afternoon is spending money on nothing.

Do I need GTINs? For retail, effectively yes. GTIN is what connects your item to a platform's product knowledge, which increasingly determines whether you appear in comparison surfaces and AI-driven shopping results at all. For vehicles, properties and jobs, the equivalent identity fields are vin, the listing ID and the reference number.

Where this gets hard

None of the individual rules in this article are difficult. The difficulty is that there are several hundred of them, they differ per destination, they change without warning, and violating them fails quietly.

A single catalogue exported to Google, Meta, TikTok and three marketplaces is six different contracts being satisfied simultaneously from one source of truth. Doing that by hand means maintaining six files and reconciling them every time the catalogue changes.

That's the layer Feedance is built for — feed rules to normalise attributes at source, channel exports that apply the right transformation for each of 200+ destinations without touching your source data, feed protection to catch missing attributes and unexpected item-count changes before a platform does, and a Creative Suite that generates an image or video per feed row for catalogues where manual production was never realistic.

It supports non-retail verticals as first-class citizens rather than afterthoughts — travel inventory with live pricing, betting catalogues with match-time data, automotive, property and job distribution channels.

If you want to know where your current feed stands before changing anything, our free feed audit tool scores it on completeness, data quality and technical health at no cost. Or schedule a 15-minute demo and we'll look at it together.

Last reviewed: August 2026. Platform specifications change frequently; verify current requirements against each destination's official documentation before implementation.