Otto is one of Germany's largest general-merchandise retailers, and its product pages are assembled in the browser rather than served whole. This service loads them the way a browser does and returns seventeen columns per product URL - the same schema our other catalogue scrapers use, so one importer reads them all.
Request https://www.otto.de with an ordinary client and you get a working page of around 320 KB carrying seventy-odd script tags and no product links in the served markup. The catalogue arrives afterwards, from JavaScript. Anything built on an HTTP library and an HTML parser reads a valid page and finds no products in it - this service loads the page the way a browser does instead.
Otto sells to the public, which is worth saying because the other catalogues on this schema - BiggestBook, Vistaprint, Waxie - are trade sites whose price columns come back empty for reasons specific to each of them. A consumer storefront publishes its prices to everyone. We have not measured Otto's, so we will not promise them either, but the reasons those pages give for empty money columns do not transfer here.
The export carries price and parsed_price, sku and sku_code, image and images, url and product_url. One of each pair is for reading and one for computing, and knowing which is which before you write the importer saves a rewrite.
Livescraper runs this schema across a series of retail and supply sources. The seventeen names and their order are identical, so one importer reads them all, and adding a second source is a configuration change rather than a project.
The last column is status, written by our exporter rather than by the site. A row that could not be retrieved still arrives, carrying the reason. You reconcile against your input list instead of discovering a silent gap three weeks later.
The two runs behind this page both submitted a placeholder URL that returned a 404, so we hold no Otto product data whatsoever. The column list below is real - it is the header row of those exports. The values are not described, because we have not seen any.
Read from the header row of a real export of this service, in sheet order. The two runs we hold returned no data under that header - see the note below the table - so each entry says what the column is for, and stops there.
sku below - check both before choosing a join key, because across this schema family they are filled independently and have been observed both identical and different.url, which reports the address the row was actually produced from; the two diverge whenever a submitted link redirects.parsed_price when you need to compute. On a German storefront the displayed form will not be the one your spreadsheet parses by default.rating. Where both are present they belong together; a score with no count behind it is not enough to rank on.sku_code.query to detect redirects, and with product_url to detect canonicalisation.http 404 here, because the URL submitted was a placeholder that does not exist.Seventeen columns per row · CSV, JSON or Excel
Behind this page are two runs, from 14 and 15 July 2026, whose payloads are byte-identical. Both submitted https://www.example.com/product/123 - a placeholder, not an Otto address - and both returned a single row reading http 404 with all fourteen data columns empty. So we can give you the schema with confidence and nothing at all about Otto's values, and this page does not pretend otherwise. The seventeen names appear in the same order in our BiggestBook, Vistaprint and Waxie exports, and the Waxie runs are populated, which is how we know the schema is live rather than a stub. We deliberately do not describe Otto's columns using those pages' values: they are trade sites whose money columns are empty for reasons particular to each, and Otto is a consumer retailer. Borrowing their measurements would be a guess wearing the clothes of a fact.
Submit the URLs of the products you care about on a schedule and keep parsed_price, currency and the run date. The value is not in any one figure but in the series - a retailer usually moves a whole range at once, and a table shows that where a browser tab does not.
Group an export by brand and count. The depth per brand tells you where a retailer has committed and where it is only testing - the same question a buyer asks before adding a supplier, answered from the catalogue itself.
Product databases tend to be strong on identifiers and thin on copy and imagery. description, image and images close that gap against an identifier you already hold, without re-photographing anything.
A national retailer's catalogue is the cheapest available picture of what a market stocks and at what price point. Keep name, brand and parsed_price and you have the shape of a category without commissioning a study.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned. A row that comes back with a status other than a successful one is not a row of product data, and is not charged as one.
Credits do not expire on a monthly cycle. Run a catalogue sweep in March and nothing until September if that is the shape of the work.
LIVESCRAPER10 at checkout.Another consumer retailer on the same schema - the natural second source when you are reading a European clothing market rather than a trade catalogue.
The same seventeen columns pointed at a trade wholesaler, where the identifier fields carry two different numbers and the price sits behind a login.
Another catalogue that renders client side, on the same schema - useful if you are building one importer for several sources.
A dated image of the page beside the row. On a catalogue assembled in the browser that is worth having: it is the only record of what actually rendered.
Product facts on a publicly reachable page are ordinary competitive information. The caveats worth naming here are about reuse and about a German site being a German site.
A price, a product name, a brand and a stock state are facts about goods offered for sale. Reading them from a page served to any visitor is the same activity a buyer 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. It is worth being explicit about that on a German site, because GDPR is the first thing anyone asks about, and it governs personal data - which a product row is not.
Two caveats are worth naming. First, reuse: descriptions and product photography are somebody's copyrighted work. Using them internally for price monitoring, assortment analysis or reconciliation against your own records is ordinary practice; republishing them as your own catalogue is a different question with a different answer. Second, the site's own stated preferences. Otto publishes a robots.txt, and for a general crawler it carries only a handful of narrow exclusions rather than a blanket one, so product pages are not among the paths it asks crawlers to avoid. We read that file rather than assuming, we stay on publicly available pages, and we run at a considerate rate.
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.
query, sku_code, product_url, name, description, parsed_price, price, currency, availability, rating, reviews, images, brand, sku, url, image and status. One row per product URL you submit.http 404, so every data column came back empty. That is enough to establish the seventeen column names and nothing more - which is why this page describes what each column is for and never what its values look like.https://www.otto.de with an ordinary client returns a working page of roughly 320 KB carrying about seventy script tags and no product links in the served markup. The catalogue is fetched and rendered afterwards, so a scraper built on an HTML parser alone sees a valid page with nothing in it.name and description are whatever the storefront prints, and this is a German storefront. Plan the encoding and collation of those columns accordingly, and remember that the displayed price will use German number formatting even though parsed_price is there to be computed on.price is the price as displayed and parsed_price the same figure as a bare number; sku and sku_code are filled independently across this schema family and have been observed both identical and different, so check both before choosing a join key. The same doubling applies to image and images, and to url and product_url.http 404 there.Seventeen columns per product, from a storefront that assembles itself in the browser. Your first 500 rows are free, then $0.002 each.
Otto is one of Germany's largest general-merchandise retailers, selling clothing, furniture, electronics and household goods to the public through otto.de. That it is a consumer storefront rather than a trade distributor matters more than it sounds, because the other catalogues sharing this schema - BiggestBook, Vistaprint, Waxie - are all trade sites, and each of them has its own reason for returning empty price columns. A retailer that sells to everyone publishes its prices to everyone. We have not measured Otto's, so this page will not promise them, but the reasoning that applies to those pages does not transfer to this one and we would rather say so than let the family resemblance imply something we did not test.
The practical obstacle is how the site is built. A request to https://www.otto.de from an ordinary HTTP client returns a successful response of roughly 320 KB carrying around seventy script tags and no product links in the markup it serves - the listings are assembled client side, after that shell arrives. Anything built on an HTTP library and an HTML parser will therefore read a valid page and find nothing in it, which is the most common reason a homegrown scraper appears to work and returns empty rows. This service loads the page the way a browser does, so the products are present by the time anything is read.
The export is seventeen columns per product URL: query, sku_code, product_url, name, description, parsed_price, price, currency, availability, rating, reviews, images, brand, sku, url, image and status. Four of those are pairs - price as displayed against price as a number, two identifier fields, primary image against all images, requested URL against canonical URL - and knowing which half to use before you write the importer is the difference between a clean load and a rewrite. That the identifier pair is worth checking is not theoretical: on our Waxie export, which uses this same schema, the two columns held genuinely different numbers, the distributor's item number and the manufacturer's. Expect German text in name and description, and German number formatting in the displayed price.
We are deliberately plain about the limits of what we can show. The two runs behind this page, from 14 and 15 July 2026, both submitted a placeholder address rather than an Otto one, and both came back with a 404 and every data column empty. That establishes the schema - a header row is a real header row even with no data beneath it - and it establishes nothing about Otto's values, so you will find no sample prices, article numbers or ratings anywhere on this page. On the legal side, a product row contains no personal data, which is the question a German site usually raises first; descriptions and photography are a separate matter of copyright and reuse. Otto publishes a robots.txt and for a general crawler it lists only a handful of narrow exclusions rather than a blanket one, so product pages are not among the paths it asks crawlers to avoid. Publicly available pages only, 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.