Most catalogue scrapers give you a row per product. This one goes a level deeper: submit a collection page and you get a row for every size and colour, each with its own SKU, its own price and its own stock status.
Our run submitted a single men's gloves collection page and got back 66 rows, all reporting ok, spread across ten distinct products - between 4 and 12 rows each. The vendor's own published testing example for this service is that same collection URL, so the fan-out is the intended workflow rather than a side effect of how we asked.
This is the part that changes how you model the data. Each row is one size and colour - its own sku, its own availability, and a name that carries the suffix, as in … Steel Blue / XS. Twelve of our rows shared one product_url. Group by product_url to get products; keep the rows to get the size curve.
Across our 66 rows, 39 came back InStock and 27 OutOfStock - for products that are nominally available. A product-level scraper would call all ten of those products in stock. Here you can see that a given colour is missing in L but not in M, which is the difference between a stock report and a stock report you can act on.
Both columns are empty on all 69 of our rows. We checked why: fetching one of those product pages returns a structured-data block describing the product and every variant - and it carries no rating and no review count at all. The columns are empty because the page does not publish the figures, not because the run failed. Do not plan a review workflow around this service.
Our 66 rows carried four brand values - Forclaz on 40, Wedze on 14, Quechua on 6 and Kiprun on 6. These are Decathlon's in-house labels, so the brand column groups a catalogue rather than identifying a manufacturer you could look up elsewhere. If your workflow is cross-retailer matching, this is the wrong source; if it is own-label assortment research, it is a good one.
A second run on the same URL returned a single row describing the page - name "Men's Gloves", the Decathlon logo as its image, no sku and no product_url. It is also the only row whose price carries a currency symbol. Filter on sku being present before you aggregate, and that row drops out cleanly.
Read from a real export, in sheet order. The counts below come from our 66-row collection run, so where this says a column carried a value it is describing rows we actually hold.
sku on every row we hold, unlike our distributor pages where the two columns carry different numbering.$49.99. Read currency rather than inferring one from the string.USD on every product row of our run. Read it rather than assuming: Decathlon operates national storefronts and the column exists precisely because the answer is not always the same.InStock or OutOfStock, per variant. Our run split 39 to 27. This is the column that makes the service worth running on a schedule rather than once.rating.sku_code. Keep both if you are writing one importer across several of our catalogue services, where they often differ; use either here.product_url - the row points at its own product page rather than at the collection it came from.images.ok on 67 rows and http 404 on 2, the latter from a placeholder address that does not exist. Reconcile on this column rather than on row count, which a variant fan-out makes meaningless on its own.Seventeen columns per row · CSV, JSON or Excel
The thing to design your importer around is that a row is a variant. One collection URL produced 66 rows over ten products in our run - 4 to 12 rows each - with the size and colour in the name suffix and stock decided per row. That is why availability is worth having: 39 of those 66 were in stock and 27 were not, on products that a product-level scraper would have reported as available. Two columns are empty for a reason we verified rather than guessed. Fetching one of the product pages returns a structured-data block that describes the product and lists every variant with its own price, currency and stock - and carries no rating and no review count anywhere. rating and reviews are empty because the source does not publish them.
Stock arrives per variant, so a weekly run tells you that a colour is gone in M and L while XS sits on the shelf. That is the shape of demand within a product, and it is invisible to any scraper that reports one availability value per product page.
Four brands covered our whole run - Forclaz, Wedze, Quechua and Kiprun. Group by brand and product_url and a couple of collection URLs give you the shape of an own-label range: how many products, how many variants each, at what prices.
parsed_price is a bare number and currency tells you what it is denominated in, so a scheduled collection run produces a clean price series without any string cleaning. Our run held seven distinct prices across ten products.
images carried up to 25 URLs per row and image is verified to be the first of them, so you can build a feed with a hero shot and a gallery without splitting strings for the common case. The description repeats across a product's variants, which is what you want for a feed.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned - worth planning for here, because variants multiply. One collection URL produced 66 rows in our run, and 66 rows is what it would cost.
Credits do not expire on a monthly cycle. Sweep the winter range in October and nothing again until spring if that is the shape of the work.
LIVESCRAPER10 at checkout.Another apparel catalogue on the same schema, where size and colour matter as much as they do here.
A European consumer retailer on the identical seventeen columns - read its page before running it, the story there is different.
Department-store assortment on the same columns. Useful when you are comparing an own-label range against a multi-brand one.
A dated image of the listing beside the rows. Handy when the claim you are making is that a size was out of stock on a particular day.
Prices, sizes and stock on a public product page are ordinary commercial facts. The caveats worth naming here are about rate and about what the data is and is not good for.
A price, a product name, a size and whether it is in stock are facts about goods offered for sale. Reading them from a page served to any visitor is the same activity a shopper performs by hand, at a useful speed. Nothing in the seventeen columns describes a person: no name, no email address, no phone number, no account - so the data-protection questions that shape our people-facing services do not arise here.
The thing specific to this site is volume. A collection URL that fans out to every variant does more work per request than a product fetch, and it produces a lot more rows: one collection page gave us 66. We run at a considerate pace and surface any failure in the status column rather than retrying it into the ground, and you should schedule with the multiplication in mind rather than treating a collection URL as a free shortcut. For what it is worth, none of our runs against this site were blocked - the two non-ok rows in our export are 404s from a placeholder address that does not exist, and the vendor's catalogue records no blocker for this service.
Our own terms are the same as on every other service here. Publicly available pages only, nothing behind a login, no third-party trackers on the data layer, and exports auto-delete after 30 days. Your first 500 rows are free and need no credit card.
ok, all sharing the same query. The vendor's published testing example for this service is that same collection URL.sku, its own availability and a name ending in something like - Steel Blue / XS. In our run one product produced twelve rows. Group by product_url if you want one row per product.InStock and 27 OutOfStock - on ten products that a product-level scraper would have called available. That is the difference between knowing a product exists and knowing you can buy it in a large.parsed_price is a bare number and, on the product rows, price holds the same figure without a symbol; currency was USD on every product row of our run. The one row that carried a symbol was the collection page itself rather than a product.sku and no product_url. Filter on sku being present before aggregating and it drops out.One collection URL, a row for each size and colour, with price, stock and images on each. Your first 500 rows are free, then $0.002 each.
Decathlon is a sporting-goods retailer that sells mostly its own labels, and the service on this page reads its collection and product pages into the same seventeen-column table our other catalogue scrapers produce. What makes it different from those is the depth of the fan-out. Our run submitted a single men's gloves collection URL and received sixty-six rows, every one reporting success, spread across ten distinct product pages at between four and twelve rows each. The vendor's own published testing example for this service is that same collection URL, so this is the intended workflow rather than an accident of how we asked.
The rows are variants, not products. Each one is a specific size in a specific colour, with its own article number in sku, its own stock status in availability, and a name that ends with the variant - something like Steel Blue / XS. That is the whole reason to run this rather than a product-level scraper: of our sixty-six rows, thirty-nine were in stock and twenty-seven were not, on ten products that a page-level check would have reported as available. Knowing that a colour has gone in medium and large while extra-small sits untouched is a different fact from knowing the product exists, and it is the one that supports a restock alert or a size-curve report. Group by product_url when you want products back; keep the rows when you want the detail.
Two columns arrive empty on every row, and we checked why rather than guessing. Fetching one of the product pages returns a large document carrying a structured-data block that describes the product and lists all of its variants, each with a price, a currency and a stock status - and it contains no average rating and no review count anywhere. So rating and reviews are empty because the source does not publish them, and no amount of re-running will change that. The same fetch corroborated the rest of the export: the number of variants listed in the page matched the number of rows our run produced for that product exactly, the article number appeared in both, and the brand agreed. Prices arrive as bare numbers in parsed_price, with currency alongside - read the currency rather than assuming, since Decathlon runs national storefronts.
The brand column deserves one caveat. Our run returned four values - Forclaz, Wedze, Quechua and Kiprun - all of which are Decathlon's in-house labels. That makes this an excellent source for mapping an own-label assortment and a poor one for matching a product against another retailer, because there is no third-party manufacturer to match on. Beyond that, plan for volume: variants multiply, one collection URL cost us sixty-six rows rather than one, and billing follows rows returned. None of our runs against this site were blocked - the only non-ok rows in our export are 404s from a placeholder address - and the vendor catalogue records no blocker for the service. Publicly available pages only, no third-party trackers on the data layer, exports auto-delete after 30 days, and your first 500 rows are free with no credit card.