Google Shopping answers a search with the same item priced by a dozen merchants. This service takes the query and hands back that comparison as eight columns - title, price, store, rating, reviews, link and thumbnail - with the store named on every row, which is the column that turns a list into a comparison.
Ask for https://www.google.com/search?tbm=shop&q=laptop with a plain HTTP client and a browser user-agent and you get HTTP 302 and 246 bytes - a redirect to ?q=laptop&udm=28. The Shopping vertical moved off the legacy tbm=shop parameter onto udm=28, so a scraper written against the old address now follows a redirect before it sees anything at all.
store is a column rather than the row key, so the same item sold by five merchants arrives as five rows sharing a query. That is the shape you want for a comparison - group by title to collapse it, or leave it as it is and sort by price.
Our catalogue scrapers - BiggestBook, Vistaprint, Waxie, Otto - all share a seventeen-column product schema. This one does not, and should not: a shopping result is an offer with a merchant attached, not a catalogue entry. Expect a different importer for this service than for those.
The first column is query and it holds the search terms you submitted. There is no product URL to paste - you describe what you want priced and the vertical decides which offers answer it, exactly as it would for a person typing the same thing.
The order rows arrive in is the order the vertical returned them. It is influenced by things we cannot see - location, history, merchant standing - so treat position as a signal about the result set and not as a stable property of a product.
The two runs behind this page both returned an empty payload - a header row and nothing under it. So we can tell you the eight columns with certainty and nothing at all about the values, and this page does not pretend otherwise.
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.
store worth keeping.store, because a price without the merchant attached is not a comparison.Eight columns per row · CSV, JSON or Excel
Behind this page are two runs, from 14 and 15 July 2026, whose JSON payloads are byte-identical and empty - the literal two characters [], with no rows at all. What is not empty is the spreadsheet each run produced: both carry the same eight-column header, and a header row is a real header row whether or not anything sits under it. So we can name the columns and their order with certainty, and we can tell you nothing whatsoever about Google Shopping's values - no prices, no merchants, no ratings, no example offers. None appear anywhere on this page. Note also that these eight columns are deliberately unlike the seventeen-column schema our catalogue scrapers share: a shopping result is an offer with a merchant attached, not a catalogue entry.
Submit the search a customer would type and keep store, price and link. One row per offer means the comparison is already in the shape of a table - sort by price and the answer is the top row, with the merchant named beside it.
Group an export by store and count. Retailers appear in shopping results long before they appear on anyone's competitor list, and a query run on a schedule surfaces the ones that have started selling into your category.
Run the same query on a schedule and keep the run date. Because the row key is the offer, the series shows both movements in price and changes in who is offering at all - a merchant appearing or disappearing is often the more interesting signal.
Search the terms you expect to rank for and look for your own name in store. If it is absent, that is a merchant-feed question rather than a pricing one, and it is much easier to see in a table than by scrolling a results page.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned. With one row per offer, a broad query costs more than a narrow one - worth knowing before you schedule a thousand searches.
Credits do not expire on a monthly cycle. Run a price sweep in March and nothing until September if that is the shape of the work.
LIVESCRAPER10 at checkout.The ordinary web results for the same query, when you need the pages rather than the offers.
A separate service covering product reviews from Google Shopping. Different output from this one - reviews, not offers.
Where the merchant is a place rather than a website, this is the vertical that describes it.
A dated picture of a result beside the row. Useful when a price has to be evidenced rather than just recorded.
Prices and merchant names on a public results page are ordinary competitive information. The caveats worth naming are about what the results are, not about whether the facts can be read.
A price, a product title and the name of the shop selling it are facts about goods offered for sale. Reading them from a results page served to any visitor is the same activity a shopper performs by hand, at a useful speed. Nothing in the eight 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.
Two things are specific to a search vertical rather than a catalogue. First, results are personalised and provisional: what comes back depends on location, on time, and on signals we cannot see, so an export is a record of one query at one moment and not a statement about what a product costs. Treat a single run as a snapshot and a schedule of runs as the actual evidence. Second, the ranking and the assembly of those results are Google's work even though the underlying prices are the merchants' facts. Using an export internally to compare prices, find merchants or monitor a category is ordinary practice; republishing it as your own comparison service is a different question with a different answer.
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, title, price, store, rating, reviews, link and thumbnail. One row per offer returned for the search you submitted.[] - so no offers came back at all. What the runs do establish is the eight-column header their spreadsheets carry, and that is the only thing this page claims from them. You will find no example prices, merchants or ratings anywhere here.query and it holds the words you submitted - you describe what you want priced, the same way a shopper would type it, and the vertical decides which offers answer it.store is a column rather than the row key, so an item sold by five merchants arrives as five rows sharing one query. Group by title if you want it collapsed - but the uncollapsed form is what makes it a comparison.https://www.google.com/search?tbm=shop&q=laptop with an ordinary client returns HTTP 302 and 246 bytes, redirecting to ?q=laptop&udm=28 - the Shopping vertical is now behind udm=28 rather than the legacy tbm=shop. Anything written against the old parameter is following a redirect before it reads a single result.Title, price, store, rating, reviews, link and thumbnail for every offer a search returns. Your first 500 rows are free, then $0.002 each.
Google Shopping answers a search with offers rather than pages: the same item, priced by a series of merchants, each with its own title, rating and link. That is a different thing from a product catalogue, and the export reflects it. Eight columns - query, title, price, store, rating, reviews, link and thumbnail - with one row per offer, so an item sold by five shops arrives as five rows sharing a query. The column that matters most is store: without the merchant named beside the price, a list of prices is not a comparison.
The practical obstacle is that the vertical's address has moved. Requesting https://www.google.com/search?tbm=shop&q=laptop with an ordinary HTTP client and a browser user-agent returns HTTP 302 and 246 bytes - a redirect to https://www.google.com/search?q=laptop&udm=28. The legacy tbm=shop parameter no longer serves the results directly; the Shopping vertical now sits behind udm=28. Anything written against the old form is chasing a redirect before it reads anything, and a parameter that changed once can change again, which is the ordinary argument for letting a service track it rather than maintaining the address yourself.
It is worth being clear about the input as well. This service takes a search query, not a product URL - the first column is query and it carries the words you submitted. You describe what you want priced the way a shopper would type it, and the vertical decides which offers answer that. It also means an export is a record of one query at one moment: shopping results are personalised on location and other signals nobody outside Google can see, so a single run is a snapshot and a scheduled series is what turns it into evidence.
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 returned an empty payload - the literal two characters [], with no rows beneath the header. That establishes the schema, because a header row is a real header row whether or not anything sits under it, and it establishes nothing about Google Shopping's values. You will therefore find no sample prices, merchant names, ratings or offer counts anywhere on this page. Note also that these eight columns are unlike the seventeen-column schema our catalogue scrapers share, so plan on a separate importer. 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.