We build the crawler, run it on your schedule and hand back files. Output is CSV, JSON, XLSX or an API endpoint your systems poll. Daily suits most El Corte Ingles price tracking, several runs a day suit a narrow watchlist during rebajas, and weekly is enough for assortment and taxonomy mapping.
Scope is agreed per project: whole departments, one branch of the hierarchy, a brand segment, a supplied list of A-references or EANs, or the supermercado range for a named set of postcodes. Fields are fixed before the first run and the schema stays stable, so downstream joins survive the site changing underneath them.
A product page carries three identifiers at once and they are not interchangeable. We keep all three so rows join cleanly to your own catalogue.
Ratings and reviews are not in the server HTML. El Corte Ingles renders them through Bazaarvoice keyed to the A-reference, so we collect them on a second pass when a project needs them.
Listing pages carry the volume, and they do not paginate the way most catalogues do. The listing route reads an optional brand segment, then the category hierarchy, then any facets, then the page number, all as path segments - so a filtered second page looks like a folder path rather than a query string. A brand can occupy its own segment ahead of the category, as in /adidas/deportes/, and index pages sit under /marcas/. Facets are written as name::value, for example brand::Philips or basic_colour::Plata, while sorting stays in the query string as sorting=bestSellerQtyDesc.
Counts move. One womenswear listing we read on 24 August 2026 paginated twelve products to a page and reported 3,477 results in total. Both figures are a measurement with a date attached, not a constant, and we timestamp them in the output.
Sponsored placements are injected into the product grid by a retail media system, so a raw category pull returns rows that are not organic results. We label them rather than quietly drop them.
The site sits behind an edge that refuses plain HTTP clients: a direct request returns an Akamai access denied page, and even Internet Archive captures of some pages hold a challenge interstitial where the product should be. We work inside what the site permits, follow the disallow rules in its robots.txt, and run at a rate that does not burden the origin.
El Corte Ingles is a Spanish department store group selling fashion, electronics, home goods, beauty, books, toys and groceries from a single domain, elcorteingles.es. Travel, insurance and consumer finance sit on separate hosts - viajeselcorteingles.es, seguros.elcorteingles.es and financieraelcorteingles.es - so a crawl of the retail catalogue never touches them.
Two catalogues live side by side under one roof. The general range uses product pages beneath a department slug with an A-prefixed reference in the path, as in /electronica/A10183119-teclado--raton-logitech-mk270-inalambrico/. The supermercado (supermarket) uses a different scheme in the same position, a long numeric code, as in /supermercado/0110116563002563-de-nuestra-cocina-bacalao-al-pilpil/. One El Corte Ingles scraper has to handle both, because the identifiers do not overlap and neither do the fields.
Alongside the store's own stock, El Corte Ingles hosts third-party sellers on a Mirakl-based marketplace. Those sellers attach offers to an existing catalogue entry by EAN, so one product page can show several prices and several delivery dates at once. Portugal runs at elcorteingles.pt on the same A-reference format, which makes a joint Spain and Portugal pull practical to plan.
Get a Quote
Developers
Customers worldwide
Pages extracted
Hours saved for our clients
€199 / one-time
setup fee - included
€169 / mo
setup fee €499
€229 / mo
setup fee €499
€349 / mo
setup fee €499
€549 / mo
setup fee €799
El Corte Ingles price data tends to answer three questions, and each one wants a different shape of file.
Brands check how their own products are being sold. Because marketplace sellers attach offers to the same catalogue entry by EAN, a brand can find its product listed under a reseller it never appointed, at a price it never set. Reading the provider behind every offer makes that visible in a table.
Retailers and marketplace sellers watch the offers they compete with on shared entries. The page exposes one price per seller and a separate delivery promise per seller, so being cheapest is not the whole story.
Grocery and FMCG teams read the supermercado range for shelf prices, promotions and pack sizes. Grocery results are bound to a fulfilment centre resolved from a postcode, so the same query run against different postcodes returns different assortments, and Canary Islands prices are held back until a postcode is supplied.
Discount periods move fast. During rebajas (the seasonal sales) and campaigns such as Black Friday, struck-through prices and discount badges appear across entire departments, and a weekly crawl will miss most of the movement.
Scraping supplement products from iHerb.com with full details, including descriptions and packaging variations.
Learn More
Daily scraping of lowest prices for 150K products on Allegro.pl to support marketplace pricing and margin optimization.
Learn More
Regular monitoring of Ralph Lauren clothing, footwear, and accessories sold across Amazon subdomains: AE, DE, ES, FR, IT, NL, PL, UK.
Learn MoreLearn how to use web scraping to solve data problems for your organization
If you sell online, run a marketplace, or advise e-commerce clients, you already know why eBay matters: it’s one of the few places where big retailers compete side by side with thousands of small merchants and private sellers.
E-commerce teams do not just need “some” competitor data anymore. They need a continuous stream of real prices, discounts, stock levels, reviews, and seller behavior from the platforms that actually shape their markets.
Amazon provides valuable information gathered in one place: products, reviews, ratings, exclusive offers, news, etc. So scraping data from Amazon will help solve the problems of the time-consuming process of extracting data from e-commerce.
ScrapeIt is a managed web scraping agency. There is no library to install and no browser extension to babysit. We write the crawler, monitor it, repair it when the site changes, and deliver clean, deduplicated data on an agreed schedule.
Every project opens with a sample: a real extract from El Corte Ingles in your format and against your field list, so you can inspect the data before anything is committed.
No documented public API for its catalogue. The front end calls internal endpoints - a general one under /api/firefly/vuestore and a separate supermarket one under /alimentacion/api/catalog - but these are undocumented, carry no terms for outside use, and the robots.txt at elcorteingles.es disallows /api. There is a Mirakl seller API, which only serves merchants who already sell on the marketplace and only exposes their own offers and orders, not the wider catalogue. For catalogue-wide El Corte Ingles data, the public pages are the practical source.
Yes. Every buy option on a product page carries a provider name and a provider id, and marketplace offers are flagged as such. The store's own offer uses the provider id eci, third-party offers use a numeric id, and the stock key for a marketplace offer joins the EAN to that id. We put the seller on every row, so first-party and marketplace lines stay separable after export.
Yes, though it is a separate job. Supermarket products use a long numeric code in the URL instead of an A-reference, results are bound to a fulfilment centre resolved from a postcode, and rows carry a sale type that separates goods sold by unit from goods sold by weight, plus a unit price in euros per kilo or per litre. We run it against a postcode list you supply and keep the postcode on every row.
A product page declares its variant axes, usually Color and Talla, and lists the EAN behind each value. Colour is handled two ways: sometimes as an axis on one page or a colour parameter on the URL, sometimes as a separate A-reference with its own page linked back through a parent product parameter. Sizes normally stay on one page. We expand all of it into one row per purchasable combination, each with its own EAN, price and stock state.
Prices and discount badges move continuously, and marketplace sellers join or leave a listing without notice, which changes both the offer count and the lowest price on a page. During rebajas entire departments reprice within days. Most price monitoring runs daily, a narrow competitive watchlist runs several times a day, and assortment or taxonomy mapping is fine weekly. We agree the cadence up front and keep it steady so your series stays comparable.
Step 1 - Make a Request
You share your needs, expectations, and desired timeframe. We’ll suggest the best solution based on your request and budget.
Step 2 - Configuring Custom Web Crawlers
Our specialists configure the crawlers and extract a sample dataset for your review before proceeding with the full-scale extraction.
Step 3 - Collect and Deliver
Once you approve the sample, we launch the project and start full data collection. We gather, filter, and structure the data for easy use, delivering it on time in your preferred format.
Step 4 - Maintain and Support
Our team manages ongoing processes, monitors website changes, and supports all data extraction cycles. We can also help integrate data into your systems or create dashboards to simplify analysis.
Scrapeit Sp. z o.o.
10/208 Legionowa str., 15-099, Bialystok, Poland
NIP: 5423457175
REGON: 523384582
