The same URL, eleven minutes apart, refused and then served. That is the useful finding here: blocking is intermittent, so a retry is worth more than a workaround. The less comfortable finding is that the row we did get is not a product row, and this page explains why before you build on it.
This is the finding worth having. On 3 July 2026 we submitted one product URL at 03:43 and got blocked (needs residential proxy); we submitted the identical URL at 03:54 and got ok. Eleven minutes. Nothing else changed. Wherever else in this catalogue a block looks permanent, here it demonstrably is not - which makes a retry the right response rather than a substitute source.
We would rather flag this than let it slip past. That ok row filled five fields and left ten empty - no identifier, no brand, no description, no stock, no image. Its name is the URL slug, hyphens and all, rather than a product title. A row that names itself after its own address is a row that did not find a product, and this page treats it that way.
We checked, and the explanation is clean. That address does not serve a product page at all: it answers with a permanent redirect to a search results page for the same slug. The destination is a listing of many products - which is why the row has a slug for a name and why nine of its columns are empty. The figure in its price column appears on that search page; it is not established to be the price of the machine the slug names, and we do not present it as one.
The site's robots.txt read cleanly for us and carries no blanket exclusion for general crawlers. But checked with a proper matcher, the product path is allowed while the search path is disallowed - and the allowed URL redirects onto the disallowed one. The example input recorded in our own service catalogue is that same search URL. We are flagging the mismatch rather than repeating the example as a recommendation.
Two of our four rows came back reading blocked (intermittent - retry) - the service telling you what to do rather than only what happened. Combined with the eleven-minute experiment above, that is a coherent picture: a block here is a moment, not a verdict. Count blocked rows per run, retry them, and reconcile on status rather than on row count.
Billing follows rows actually returned, which makes the retry advice cheap to act on: three of our four runs produced nothing and would have cost nothing. That is also why this page does not open with a signup button. One row that turned out to describe a search page is not a result we are going to sell.
Read from a real export, in sheet order. Where this says a column carried a value, it is describing the single row that returned ok - a row we have reason to distrust, for the reason set out in the note below.
url and nothing resolved to a product.sku_code.ok once, blocked (needs residential proxy) once, and blocked (intermittent - retry) twice. The last of those is an instruction, and the eleven-minute experiment above says it is a good one.Seventeen columns per row · CSV, JSON or Excel
The single most useful thing on this page is a warning about its own data. Our one successful row carries a name that is the URL slug, a price, a currency - and ten empty columns. We checked why, and the answer is that the address we submitted is not a product page: it answers with a permanent redirect to a search results page for the same slug. A search page has no single product title, which is why the name fell back to the slug, and no single identifier, description, brand, stock value or image, which is why those columns are empty. The price figure does appear on that search page, but a search page lists many products, so nothing establishes it as the price of the machine the slug names - and this page therefore never presents it as one. There is a second, related caution: the site's robots.txt allows the product path and disallows the search path, so the URL you are permitted to fetch redirects onto one you are asked not to crawl. The example input recorded in our own service catalogue is that search URL. Submit real product URLs, read status first, and retry anything blocked.
The eleven-minute result is the practical takeaway. A block here is a moment rather than a verdict, so build a retry into the schedule and count blocked rows per run. Retries cost nothing when they fail, because billing follows rows returned.
If a returned name looks like a URL slug - lowercase, hyphenated, matching the address - the run did not reach a product. That is a one-line check worth putting in your importer, and on this service it would have caught our own best row.
An address that permanently redirects to a search page will return search-page data, and the site's own robots.txt asks general crawlers to stay off that search path. Resolve your input URLs before you queue them rather than after you read the results.
If the question is what industrial and facility supplies cost rather than what this retailer specifically charges, our Uline, Gemplers and Fastenal services cover that ground on the same seventeen columns, and those pages report real fill counts from real runs.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned, which is what makes the retry advice on this page cheap: three of our four runs produced nothing and would have cost nothing.
Credits do not expire on a monthly cycle, so a schedule built around retries does not quietly drain anything between attempts.
LIVESCRAPER10 at checkout.The opposite result on the identical schema: fifteen of seventeen columns filled, and every value confirmed against the live listing.
One category URL returned 99 priced rows with nothing blocked - the clearest working example in this family.
The other page in this catalogue that documents intermittent blocking honestly - two runs refused on a day when others returned two dozen priced rows.
The full catalogue, including every other supplier we cover on this schema.
Prices and item numbers on a public catalogue page are ordinary commercial facts. What deserves care here is not permission in general but one specific path, and a redirect that crosses it.
A price, a product name and a catalogue number are facts about goods offered for sale, read from a page served to any visitor. Nothing in the seventeen 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, blocking, which is real and demonstrably intermittent: the same URL was refused and then served eleven minutes later, and two of our rows carry a status that literally advises a retry. We surface a block in the status column and stop there rather than working around it, and we would rather you scheduled a second attempt than assumed the source was closed. Second, and more careful: the site's robots.txt read cleanly for us and carries no blanket exclusion, but its general group disallows the search path while allowing product paths - and the product URL we submitted answers with a permanent redirect onto that search path. An address you are permitted to request can therefore land somewhere you have been asked not to crawl. We are reporting that rather than treating the redirect as permission, and we would suggest resolving your input URLs before you queue them. The example input recorded in our own service catalogue is that search URL, which is exactly why we are pointing it out instead of repeating it.
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. Billing follows rows returned, so a blocked attempt is not a charge.
ok - and the blocked one and the successful one submitted the same URL, eleven minutes apart on 3 July 2026. So the block is a moment, not a verdict. Two of the blocked rows even carry a status reading blocked (intermittent - retry).name is the URL slug rather than a product title. That is what a run looks like when it does not reach a product page.status rather than on row count. Billing follows rows actually returned, so the attempts that fail cost nothing - which is what makes a retry schedule the cheap answer here.Blocking here is intermittent - the same URL failed and then worked eleven minutes later - so a second attempt is worth more than a workaround. Just make sure the URL resolves to a product, because ours did not. A blocked run bills nothing.
GlobalIndustrial sells industrial, material-handling and facility equipment, and our export for it holds four runs - one that succeeded and three that were blocked. The single most useful thing in that small dataset is a timing coincidence that turns out not to be one. On 3 July 2026 we submitted a product-style URL at 03:43 and the run came back blocked, needing a residential proxy. We submitted the identical URL at 03:54 and it came back successful. Eleven minutes, nothing else changed. Two of our other rows carry a status that reads, in as many words, that the block is intermittent and the request should be retried. Taken together that is a coherent and actionable picture: on this site a block is a moment rather than a verdict, and a retry schedule beats a workaround.
The less comfortable half of the story is the successful row itself, and we would rather lead with the problem than bury it. That row filled five of seventeen fields - the submitted address, the address again, a price, a currency, and a name - and left ten empty. There was no identifier, no brand, no description, no stock value and no image. And the name is not a product title: it is the URL slug, lowercase and hyphenated, identical to the tail of the address we submitted. A row that names itself after its own URL is a row that never found a product.
We checked why, and the explanation is clean. On 12 August 2026 that address did not serve a product page at all. It answered with a permanent redirect to a search results page for the same slug - a listing of many products, half a megabyte of markup, the search term appearing dozens of times. That accounts for every oddity in the row: a search page has no single title, so the name fell back to the slug; no single identifier, brand, description, stock value or image, so those columns are empty. The price figure does appear on that search page. But a page listing many products does not establish which one a figure belongs to, so we do not reproduce it anywhere on this page as the price of the machine the slug names. If you take one thing from this page into your own importer, let it be the check: a name that looks like a URL slug means the run did not reach a product.
One more thing deserves stating rather than glossing. The site's robots.txt read cleanly for us and carries no blanket exclusion for general crawlers - but read with a proper group matcher it allows the product path and disallows the search path, and the product-style URL we submitted redirects onto that search path. An address you are permitted to fetch can therefore land on one you have been asked not to crawl, which is a good reason to resolve input URLs before queuing them rather than after reading the results. The example input recorded in our own service catalogue for this scraper happens to be that search URL, which is precisely why we are flagging the mismatch instead of reproducing it as a recommendation. Billing follows rows actually returned, so both the blocked attempts and the retries cost nothing when they fail. Publicly available pages only, 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.