This is not a product-detail scraper. You give it a Best Buy search results page and it returns a row for every listing on it, each one carrying the rank it held - so you can read price, rating and shelf position from the same table.
/site/searchpage.jsp?st=….position is the listing's rank on the results page, running from 1 downward. Our runs returned positions 1 to 23. That column is what separates this from a product scraper: you are capturing a shelf as it was ordered on a given day, not a set of unrelated product pages, so the same query run weekly gives you a movement series rather than a snapshot.
If you have used our other retail catalogues you will be reaching for parsed_price, currency, availability and a status flag. None of them are here. This service returns query, name, sku, brand, model, price, rating, reviews, image, url and position - a search-results shape, not a product-detail one.
Best Buy's SKU is a plain number and every row carries it twice - once in sku and once inside url. Two URL shapes appeared in our export: 58 rows as /product/…/sku/<sku> and 27 as /site/-/<sku>.p?skuId=<sku>. Match on sku rather than on the address and both shapes reconcile to the same product.
On 85 of our 85 rows the brand value is a leading substring of name. That works when the title starts with the maker and gives you "HP" or "Dell"; it does not when the title starts with a size or a marketing phrase, and our export accordingly contains values like "Customer", "Latitude" and '15.6" 2K Touchscreen Laptop'. Treat it as the head of the title, and normalise before grouping by it.
Our seven runs all submitted the identical search URL and came back with 2, 3, 10, 14, 15, 18 and 23 rows. Positions always started at 1, so what changed was how far down the page the run got. Reconcile on sku and position, treat a short run as a short run rather than as products disappearing, and re-run when a series looks thin.
The seventeen-column catalogue services write a per-row status so a blocked fetch is visible. This schema has none - a run that returns nothing returns no rows at all. The vendor catalogue marks this service Partial with the note -blocked (needs residential proxy), which matches what we see: rows arrive, but depth is not guaranteed. Count rows per run and alert on a drop.
In export order. The counts come from our own seven runs, so where this says a column carried a value it is describing rows we actually hold.
url on every row. Seven SKUs turned up in more than one of our runs, which is how you follow a product across dates.name. Real makers appear, and so do fragments like "Customer" or a screen size. Normalise it before you group by it.reviews: 19 rows carry a rating of 0 alongside a review count of 0, which is a listing nobody has rated yet rather than a listing rated badly.rating, and the same caveat about zeros. Our run ranged from 0 up to 5,929./product/…/sku/<sku> on 58 rows and /site/-/<sku>.p?skuId=<sku> on 27. Both embed the SKU, so the address is a link rather than an identity.query and the date you ran it.Eleven columns per row · CSV, JSON or Excel
Two things to plan around. First, this schema is not the seventeen-column catalogue shape used by our distributor pages: there is no parsed_price, no currency, no availability, no description and - importantly - no per-row status. If you are writing one importer for several sources, this one needs its own branch. Second, depth is not fixed. Seven runs of the identical search URL returned 2, 3, 10, 14, 15, 18 and 23 rows, always starting at position 1. The vendor's own catalogue marks this service Partial with the note -blocked (needs residential proxy). Rows do arrive; how many is not something we will promise from seven runs, and we quote no success rate.
Run the same query on a schedule and keep query, sku, position and the date. Because seven of our SKUs appeared in more than one run, the join is straightforward: same SKU, different position, different day. That series is the thing a screenshot cannot give you.
Price arrived on 78 of our 85 rows. Strip the symbol once at import, store the number next to the SKU and the date, and a weekly sweep of a handful of search URLs becomes a price series across a whole category rather than a handful of products.
rating and reviews arrived together on 81 rows. Sorted by review count, a results page tells you which products have accumulated attention and which are new - provided you exclude the 0/0 rows, which mean unrated rather than poor.
There is no description column, so name is where the configuration lives. Parsing it across a full results page gives you a comparable spec table for a category - and model, on the 69 rows that carried it, is what lets you find the same unit in another retailer's catalogue.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned - which is the fair way round here, because one search URL can produce two rows or two dozen. Our 23-row run cost 23 rows; our 2-row run cost 2.
Credits do not expire on a monthly cycle. Track a category through the autumn and stop over the summer if that is the shape of the work.
LIVESCRAPER10 at checkout.The other ranked-results service here: one query in, one row per offer out. Run both on the same product and you can see the retailer's own shelf beside the open market.
The same hardware market from a different retailer. Worth reading the page before you plan a run - its story is the opposite of this one.
The business price for comparable hardware, on the seventeen-column schema. A category URL there fans out the way a search URL does here.
A dated image of the results page beside the ranked rows. When position is the evidence, the picture is what makes it arguable.
Prices, ratings and shelf order on a public search page are ordinary competitive information. The caveats worth naming are about rate, and about being straight where we could not check something.
A price, a product title, a rating and the order listings appear in are facts about goods offered for sale. Reading them from a page served to any visitor is what a shopper does by hand, at a useful speed. Nothing in the eleven 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 this site. First, rate. A search page is a heavier request than a product page and the depth we got back varied from two rows to twenty-three on the same query, so we run at a considerate pace and you should schedule accordingly rather than hammering one URL for a deeper page. The vendor's own catalogue marks this service Partial and notes that it needs a residential proxy, which is the same story from the other end. Second, and we would rather say this than gloss it: we could not read Best Buy's robots.txt. Three plain fetches from our machine on 12 August 2026 - the home page, the robots file and the search URL - timed out or had the connection reset, while an unrelated site answered normally in the same session. So this page quotes no robots.txt summary, because we have not seen the file.
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.
/site/searchpage.jsp?st=…, and each one returned a row per listing on that page with its rank in position. That is the shape this service is built around.query, name, sku, brand, model, price, rating, reviews, image, url, position. There is no parsed_price, no currency, no availability, no description and no per-row status.brand value is a leading substring of name, so a title that opens with the maker gives you "HP", and one that opens with a screen size gives you a screen size. Normalise it, or read the maker out of name yourself.sku. It arrived on all 85 rows, holds 70 distinct values, and also appears inside url on every row - including the 27 rows whose address uses the /site/-/<sku>.p?skuId= form rather than the /product/…/sku/ one. If you need to match against another retailer instead, use model, which arrived on 69 rows.price arrives as displayed, symbol included, on 78 of our 85 rows, and there is no separate numeric or currency column in this schema. Strip the symbol at import if you plan to compute on it.One search URL, a row for every listing on it, with price, rating and the rank it held. Your first 500 rows are free, then $0.002 each.
Best Buy is a consumer electronics retailer, and the service on this page reads its search results rather than its product pages. That distinction runs through everything else. You submit a URL of the form /site/searchpage.jsp?st=…, and what comes back is a row for every listing on that page, carrying the rank it held in a position column. Our seven runs all submitted the same laptops query and produced eighty-five rows between them, with positions running from one to twenty-three. If what you want is one product's full detail page, this is the wrong shape; if what you want is the state of a category on a given day, it is exactly the right one.
The schema is eleven columns and it is not the seventeen-column form our distributor catalogues use. There is no computable price column, no currency, no availability, no description, and - the one most likely to bite - no per-row status flag. In the seventeen-column services a blocked fetch still produces a row that says so. Here a run that reaches less of the page simply returns fewer rows, and nothing in the file distinguishes a short shelf from a short run. Our own evidence for that is direct: seven runs of an identical query returned two, three, ten, fourteen, fifteen, eighteen and twenty-three rows, every one of them starting at position one. The vendor's catalogue marks this service Partial and records that it needs a residential proxy. Count rows per run, keep the count, and alert on a drop rather than assuming the category shrank.
Two columns repay a careful read. sku is Best Buy's own product number and the right thing to join on: it arrived on every row, held seventy distinct values across our eighty-five, and appears inside the row's own URL in both of the two address shapes we saw. brand is not what its name suggests. On all eighty-five rows it is a leading substring of the listing title, which yields a real manufacturer when the title starts with one and yields a screen size or a stray word when it does not - our export contains "HP" and "Dell" alongside "Customer" and a fragment of a product description. Normalise it before grouping. model, present on sixty-nine rows, is the sparser but more portable identifier, and it is what lets you find the same unit in another retailer's catalogue. Ratings and review counts arrived together on eighty-one rows, and nineteen of those carry zero in both, which means unrated rather than badly rated.
One thing we will not do is describe a file we could not read. On 12 August 2026 three plain fetches from our machine - the Best Buy home page, its robots.txt and the search URL itself - timed out or had their connection reset, while an unrelated retailer answered normally in the same session. So this page carries no summary of the site's robots.txt, because we have not seen it, and no success rate, because seven runs of one query cannot support one. What we do state is what our own export contains and how it was measured. Publicly available pages only, nothing behind a login, no third-party trackers on the data layer, exports auto-delete after 30 days, and your first 500 rows are free with no credit card.