We run the crawlers, you receive data. Output comes as CSV, JSON, XLSX or a REST API, on whatever schedule the use case needs: a one-off extraction, daily runs, or several runs a day for price and stock.
Files can be pushed to S3 or Google Cloud Storage, sent over SFTP, or emailed. The API serves the same records with filters on locale, division, category or article number. You choose full snapshots or change-only deltas against the previous run, and one file per locale or a single combined file with locale and currency columns. Schema, field names and cadence are agreed before the first run and stay stable; when H&M changes its storefront, we repair the crawler, not you.
The listing grid and the product detail page (PDP) are both rendered by a Next.js storefront, so the values sit in a __NEXT_DATA__ script tag rather than in a documented feed. Search and category results live under props > pageProps > srpProps > hits; the PDP payload sits under props > pageProps > productPageProps > aemData > productArticleDetails. We parse that embedded JSON state, which is also the only place size-level stock is exposed - the visible markup does not carry it.
Member Prices are shown only to signed-in members, so a logged-out crawl records the public price and flags where a member price exists; we do not sign in to accounts. Any other field visible on the page can be added to the schema.
A single crawl of hm.com is a snapshot. Most of the commercial value in this vertical sits in the difference between snapshots, and H&M is unforgiving about it: the assortment turns over quickly, and once an article sells out it is delisted and its productpage URL stops returning a live product. That history cannot be back-filled afterwards. It exists only if something was recording while the article was still live.
Running the same crawl on a schedule gives you the sequence instead of the state. A price move becomes a series: full price, first markdown, deeper markdown, gone. Size-level stock changes during the day, so a daily or intraday cadence shows which sizes sell through first and how long a size stays unavailable before it comes back, which is a different signal from whether the article as a whole is in stock. New arrivals fall out of a diff against the previous run - the article numbers that were not there yesterday - which is steadier than reading the new-in page, where placement is merchandised.
Because price and currency are set entirely by the locale path, the same article number carries a different figure on en_us, en_gb and en_de. Comparing markets therefore means crawling each locale rather than converting currency, and repeated runs then show whether a markdown is global or local to one market.
H&M trades online as hm.com, with the main storefront served from www2.hm.com. As a data source it behaves like a numeric index rather than a catalogue. Product pages carry no keyword slug at all: the pattern is https://www2.hm.com/{locale}/productpage.{articleNumber}.html, for example productpage.1223910004.html. The 10-digit article number holds the identity. Its last three digits are the colour variant code and the leading digits are the shared product code - the same split H&M uses in its own published articles.csv, where article_id is the product code plus a 3-digit colour. Every colourway is a separate URL and a separate row, and the product code is what pulls those rows back into one style.
Locale sits in the path as {lang}_{country}, such as en_us, en_gb or en_in, but it is not a clean country map: grouped regional locales like en_asia3 cover several markets under a single path. Listing pages (PLP) follow an AEM-style structure, /{locale}/{division}/{shop-by-product}/{category}.html, with view-all variants, across divisions including ladies or women, men, Divided, kids, baby, sport, beauty and H&M HOME. Segment naming is not stable between markets - en_gb uses /ladies/ where en_us uses /women/ - so category maps are built per locale, not translated. The grid itself loads progressively instead of paging, so one HTML fetch of a category returns the first batch only.
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
Fast fashion competes on price and speed, and H&M is a reference point for most of that market. The cases we build for are specific.
Competitor price tracking. Pricing teams at other high-street and online retailers match H&M at style level, using the shared product code to compare a garment across all of its colourways instead of treating each article number as an unrelated item.
Assortment and range analysis. Counting live articles by division and category, per locale, shows what H&M is actually carrying this season: how deep the Divided range runs, how much H&M HOME a market gets, which categories are being widened or cut.
Cross-brand benchmarking. The same crawl design covers Zara, ASOS, Uniqlo and the other H&M Group fascias - COS, ARKET, Weekday, Monki, & Other Stories - so a competitor set arrives in one shared schema instead of four shapes.
Product and sourcing intelligence. Composition, care and sustainability labelling read across a whole division tells private-label and manufacturing teams how the materials mix moves by category and market.
Marketplace and resale listings. Sellers who relist H&M stock need current prices, live sizes and image renders keyed to the article number.
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 scraping agency. Nothing is installed or maintained on your side: we build the crawler, run it, watch it and repair it when a storefront shifts. Fashion retail is a large part of our work, so the awkward parts here - per-locale category maps, colourway explosion, size-level stock, two different edges in front of the same brand - are handled as routine engineering rather than discovered mid-project. Scope, fields and cadence are agreed up front, with a sample before you commit.
We are not lawyers and this is not legal advice. In practice we read only pages any visitor can see: product pages, category pages and the store locator. We do not create accounts, do not sign in, do not touch checkout, and collect no personal data about customers or staff. Prices, article numbers and compositions are factual product attributes rather than creative work. Most clients treat H&M data the way they treat any public market observation and take their own counsel where their jurisdiction or intended use calls for it.
hm.com, www.hm.com and www2.hm.com sit behind Akamai Bot Manager. Requests from datacenter address space are answered with an HTTP 403 'Access Denied' page carrying an errors.edgesuite.net reference ID, including requests for /robots.txt and including requests that send a complete, correct Chrome header set. The decision is driven by IP reputation and TLS fingerprint rather than by headers, so copying headers out of a browser does not change the result. H&M also runs more than one front door: newer market deployments sit on country subdomains on a different stack, and th.hm.com resolves into AWS CloudFront and returns the CloudFront 'Request blocked' page instead. A crawler has to recognise and handle both edges. We treat this as an infrastructure and pacing problem, run conservatively, and monitor both edges for change.
One crawl per locale. Price, currency and tax presentation are set by the locale path, so the same 10-digit article number shows a different figure on en_us, en_gb and en_de, and no currency conversion reproduces that. Locale codes also do not map one-to-one to countries: alongside en_us and en_gb, H&M uses grouped regional locales such as en_asia3 that serve several markets from a single path. We agree the locale list with you, crawl each one separately, and stamp every row with its locale and currency so markets stay separable in the output.
Yes. Size-level availability is held per article and per size and is rendered from the embedded JSON state, not written into the visible HTML body, so it is read out of the __NEXT_DATA__ payload rather than scraped from markup. It also moves during the day, which makes cadence matter more here than in most verticals. Daily is the usual baseline for a full catalogue run, while a price and stock subset can be refreshed several times a day. The practical limit is the size of the URL set and how politely requests have to be paced, so we size the schedule with you before the first run.
There is no official public H&M product API. Every JSON endpoint in circulation is an internal storefront or mobile-app endpoint found by observing the site, so its contract can change without notice or a deprecation window. That is why we maintain crawlers instead of selling you an endpoint: the instability stays on our side. Delivery is what we keep stable - CSV, JSON, XLSX or a REST API against a schema agreed in advance. The same pipeline can carry Zara, ASOS, Uniqlo or H&M Group labels such as COS and ARKET in one normalised feed, so a competitor set arrives aligned rather than in four different shapes.
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
