Paste a Tesco grocery product URL, or a category or search URL, and the products come back as rows - name, price and currency, availability, brand, the identifier columns, rating and reviews, an image, a link and a description.
One input and one control. There is no proxy to configure on this one, so the whole job is a list of links and a number.
The limit is per query, so five category URLs with a limit of two hundred is two hundred products from each - not two hundred altogether.
A line can be a single product page or a category or search URL, and a category comes back expanded into its products, one row each. That is how a browse page becomes something you can sort by price or group by brand.
Some retailers on this shared pipeline need a residential exit of your own - the tool names Lowes, Grainger, Zalando and Fastenal. Tesco is not one of them. The run goes through our pool, and there is nothing for you to configure.
sku, mpn and gtin arrive as their own columns rather than buried in a title, and currency sits beside price instead of inside it. That is what makes an export joinable to a catalogue that is not Tesco's - where the page declares those fields at all.
Worth being straight about, because it changes how you should read the dictionary below.
The fifteen column names are solid: they are confirmed twice over, by the published column array for this service and by the header row of every workbook we hold from the shared pipeline behind it - identical on the populated one and the empty ones alike. Build a schema around those names with confidence.
What we cannot do is tell you what Tesco puts in them, because we have never run this against Tesco. Not one of the exports we hold is a Tesco run, and nobody on our side has matched these columns against real Tesco data. Almost all of the exports came back with a header and no rows, and the single populated one is a different retailer entirely. Rather than dress that up, this page prints no example values and no formats - with no Tesco run, we would be inventing them.
The good news is how cheaply that gets settled. Which of the thirteen declared columns Tesco actually publishes is a question one small run answers for good, and the first 500 rows cost nothing - so point it at a single category, look at what came back, and you will know more about this export than any page could honestly tell you in advance.
The names are exact and doubly confirmed. The descriptions say what each column is for - not what it will contain, because that is the retailer's decision rather than ours, and the note below explains why.
gtin, this is what makes an export joinable to a catalogue that is not Tesco's.Two things about the evidence behind this page. First, the mechanism: products are read from the JSON-LD a page publishes about itself - the structured data retailers embed for search engines. That sets a ceiling this page will not pretend past. Every column after service exists only if Tesco declares that field, so a blank means not published, not run failed. Second, the gap: we have never run this against Tesco. We hold forty-five exports from the shared pipeline behind this service and not one is a Tesco run - forty-four came back empty and the only populated one is a different retailer. That export is worth one honest data point about the tool rather than about Tesco: query and service filled on every row, because the scraper writes them itself - and six of the fifteen were empty on every single row. Expect gaps here too, expect them to fall differently because a different retailer publishes different structured data, and let your first free-tier run tell you which. That is also why this page prints no example values and no formats: with no Tesco run, we would be inventing them.
A list of URLs and a limit. No sort, no filter, no proxy field - on this retailer there is nothing else to set.
This scraper reads the structured data a product page publishes about itself - the JSON-LD block retailers embed so search engines can show a price and a stock status. That is why the columns read like they do: sku, mpn, gtin, brand, availability and currency are the standard vocabulary for describing a product, not names we invented.
The practical consequence is the one worth planning around. A column is only as good as the retailer's own markup. If a field is missing from the page's structured data it comes back blank, and no amount of re-running changes that - it is not a failure, it is an absence. In the one populated export we hold from this shared tool, six of the fifteen columns were blank on every row.
If you need something the markup does not carry, that is a different job - the Universal AI Scraper reads the page itself and returns the attributes you name, rather than only what was declared for search engines.
An uploaded file does not clear the box - the lines are appended to whatever you had already typed, and duplicates are not removed. Upload the same file twice and those URLs really will be fetched twice, and billed twice. That is specific to this pipeline: some of our other scrapers de-duplicate on upload and this one does not, so do not carry the habit across.
For a CSV or TXT the whole line is taken as one URL, so a spreadsheet with extra columns is not what you want here. Only an XLSX is read column by column, and there it takes column A.
The picker lists Parquet alongside CSV, XLSX and TXT, but it cannot actually read one in the browser and will tell you so - use one of the other three.
A few examples of what a grocery catalogue is worth once it is a table.
Hand it a category page and you get every product on it as a row, with the brand and identifier columns beside the name. Sorting a browse page by anything other than what the site offers is the whole point.
Because service is stamped on every row, one table can hold Tesco alongside the other retailers on this pipeline and still split cleanly. Where mpn or gtin are declared, the same item can be matched across suppliers.
The same category URL on a schedule gives you two comparable files. What appeared, what disappeared and what changed is a diff rather than an afternoon of clicking - and sku is the key to diff on where it is published.
No subscription, no minimum, no recurring bill. Your first 500 rows are on us - after that, pay-as-you-go at the same flat rate as every other scraper here.
Every new account, one-time. No credit card required. Per-query limits, file upload and every export format included - and on this retailer, no proxy to pay for either.
The same flat rate as every other scraper on the platform. The pre-flight estimator shows the row count and credit cost before a run starts - worth a glance here, because the limit is per query and a list of category URLs multiplies.
Volume pricing, dedicated workers and an SLA for tracking a catalogue on a schedule. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.Two siblings on the same shared tool, and one for when the structured data does not carry what you need.
The same fifteen columns and the same JSON-LD ceiling on a different catalogue - and, like this one, no proxy of your own. If you track both, service keeps the rows apart in a single file.
Same pipeline again, with one difference that matters: Lowes is one of the four retailers that needs a residential proxy of your own. Worth knowing before you assume every page in this family runs the same way.
When the field you want was never put in the structured data, this one reads the page itself and returns the attributes you name. Slower and less predictable than a fixed schema - but it is not limited to what was declared for search engines.
Short answer: this is public catalogue data with no personal data in it - and the structured data is published to be read by machines in the first place.
Everything in these fifteen columns is shown on a public Tesco product page to any visitor, signed in or not. No login is used, no paywall is crossed and no account is touched, and the run goes through our proxy pool rather than your own IP. The particular thing being read is the JSON-LD block - structured data a retailer embeds precisely so that automated readers can pick up the name, the price and the availability.
No person is named anywhere in this export. There is no customer, no reviewer and no seller column - reviews is a count, not review text, so not even a review body comes back. It is products and prices, which puts it at the lighter end of the range for data-protection purposes.
Tesco's own terms govern automated collection from their site, so read them before you scale rather than relying on the pages being public. And if you republish product descriptions or images, remember those are somebody else's copy and photography - collecting them for analysis is one question, publishing them is another. We run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
Your first 500 rows are free - no card, no subscription. After that it is $0.002 per row, flat.
The Tesco Products Scraper turns product and category pages on tesco.com into rows. Paste a grocery product URL - the platform's own example is tesco.com/groceries/en-GB/products/305096546 - or a category or search URL, one per line, or upload a CSV, XLSX or TXT file, set a limit per query, and every product comes back as a record with the query it came from, the service that produced it, the name, price and currency, availability, brand, sku, mpn and gtin, a rating and review count, an image, a link and a description. Fifteen columns in the file and sixteen in the JSON, one row per product. Unlike some retailers on this shared pipeline - the tool names Lowes, Grainger, Zalando and Fastenal - Tesco needs no residential proxy of your own, so there is nothing to configure beyond the list and the limit.
Two things are worth understanding before you build on this export, and both come down to where the data originates. Products are read from the JSON-LD a page publishes about itself - the structured data retailers embed so search engines can display a price and a stock status. That is why the columns carry the names they do: sku, mpn, gtin, brand, availability and currency are the standard vocabulary for describing a product. It also sets a ceiling: every column after service exists only if the retailer declared that field, so a blank cell means not published rather than run failed, and re-running will not fill it.
The second is that this page does not print example values, because we have never run it against Tesco. Of the forty-five exports we hold from the shared pipeline behind this service, not one is a Tesco run - forty-four returned a header and no rows, and the single populated one is a different retailer. That export is worth exactly one honest observation, and it is about the tool rather than about Tesco: query and service filled on every row because the scraper writes them itself, and six of the fifteen columns were blank on every row. Expect gaps here too, expect them to fall differently because a different retailer publishes different structured data, and let a small free-tier run tell you which - that is a question 500 free rows settles for good.
On the legal side this is among the lighter exports in our catalogue. Everything collected is shown on a public product page to any visitor, no login or paywall is involved, and no person is named anywhere in the fifteen columns - reviews is a count rather than review text, so not even a review body comes back. It is products and prices. Tesco's own terms still govern automated collection from their site, so read them before you scale, and remember that product descriptions and images are somebody else's copy and photography if you intend to republish them. Start free: your first 500 rows cost nothing and need no credit card, and after that it is $0.002 per row, flat.