Skroutz is where Greek shoppers start, and it is stricter than the comparators around it. Thirteen fields are mandatory, an ean is required across every category, the quantity has to be a real number rather than a yes/no, and the whole file has to stay under 10 MB uncompressed. Feeds usually fail here not on structure but on completeness.
The shape of the file
<?xml version="1.0" encoding="UTF-8"?>
<mywebstore>
<created_at>2026-09-19 08:30</created_at>
<products>
<product>
<id>SKU-1024</id>
<name>Brand Model 128GB Black</name>
<link>https://shop.gr/p/1024</link>
<image>https://shop.gr/img/1024.jpg</image>
<category>Τηλεφωνία > Smartphones</category>
<price_with_vat>249.00</price_with_vat>
<vat>24</vat>
<manufacturer>Brand</manufacturer>
<mpn>XY-1024-BK</mpn>
<ean>5901234123457</ean>
<availability>Άμεσα διαθέσιμο</availability>
<quantity>8</quantity>
<description>…</description>
</product>
</products>
</mywebstore>The root element wraps a created_at timestamp in YYYY-MM-DD HH:MM and a products list. Every field above is mandatory (Skroutz Developer: XML Feed, Mandatory Product Information).
The limits, because they are where files break
id up to 200 characters and never reused for a different product; name up to 300; link HTTPS, up to 1,000; image HTTPS, up to 400; category the full path, up to 250; mpn up to 80 (the ISBN, for books); ean up to 13 digits; quantity an integer between 0 and 10,000,000; description up to 10,000 characters with no HTML anywhere.
And the file itself: 10 MB uncompressed. Above that it must be zipped or gzipped. A catalogue with long descriptions crosses that line sooner than anyone expects — which is an argument for trimming descriptions rather than for compressing your way out.
price_with_vat and vat are two fields, both required
The price Skroutz shows is the final price the shopper pays, in euros, VAT included, with at most two decimals — and the VAT rate goes in its own field. Sending a net price with the rate beside it is the most common mistake on migration from a Google feed, where price is a single tax-inclusive value and no VAT field exists.
availability is a vocabulary, not free text
Skroutz crosslinks the availability you send to its own fixed set of delivery descriptions. Invented wording does not map, and an unmapped product loses the delivery badge shoppers filter on. quantity sits alongside it and has to be honest: it is a count, and a zero is a product that should not be competing for a click.
ean is mandatory everywhere, and that is the real work
Most channels treat the barcode as a strong recommendation. Skroutz requires it across all categories for classification — it is how an offer joins the product card rather than floating alone. If your catalogue has gaps, that is the migration project, not the XML: where to find barcodes, and what to do for products that genuinely have none.
Variations, when size matters
For apparel and footwear, a product can carry a variations block, each variation holding variationid, availability, size and quantity, with optional link, ean, manufacturersku, price_with_vat and outlet. It is the cleanest variant model of any comparator we have read — but each variation needs its own stock number, which a store exporting parent products only cannot provide.
Questions merchants ask
Can I reuse my Google Shopping feed for Skroutz?
No. Google Shopping is RSS with g: attributes and one tax-inclusive price; Skroutz expects a mywebstore document with price_with_vat and vat as separate fields, a mandatory ean and a real quantity. The files are not convertible by renaming.
What happens if a product has no EAN?
The ean field is mandatory for all categories for classification, so products without one do not classify properly and lose the product-card placement where the comparison happens.
My feed is larger than 10 MB. What now?
Compress it — zip or gzip is accepted above the 10 MB uncompressed ceiling. Before that, check descriptions: the 10,000-character allowance per product is generous, and trimming boilerplate usually brings a catalogue back under the limit on its own.
Can I send HTML inside the description?
No. Skroutz asks for no HTML notation in any field, so strip the markup your store stores rather than passing the product page's HTML through.
Where FeedRobin stands on Skroutz
Straight answer: FeedRobin does not generate the Skroutz file yet. We build Google, Meta, Microsoft, Heureka and Compari/Árukereső, idealo and the ChatGPT format. Skroutz is on the roadmap and the order is decided by who asks — if you need it, write to contact@feedrobin.com.
What is useful today: every field Skroutz insists on — barcode, brand, part number, a title that describes the product, a price that matches the page — is the same data every other channel judges you on. The free feed check reads the feed you already have and lists what is missing, with no account. A catalogue that passes it is most of the way to a Skroutz file.
Sources
Skroutz's own documentation: XML Feed (Skroutz Developer) for the element reference, field limits and the size ceiling; XML structure and Mandatory Product Information in Partner Support for what is required and how availability is matched.