Bright Data Scraper Studio Test Results

Who this is for

Developers, AI builders and technical founders who are thinking about using Scraper Studio to collect public web pages for a RAG pipeline, a dataset or a monitoring job, and want to know where it can fool them before they rely on it. You do not need to have scraped a page before.

Recommended stack

• Scraper Studio's AI builder, to write the first version of a scraper from a URL and a sentence of instructions
• Quick view, to read a sample of the results after every run
• A source you trust for every field you care about, such as the site's own public API or the pages themselves, to compare against
• A check of your own that treats 0 records as a failure, because the run history may not say so
• The repair prompt, called Self-Healing, when a page layout or a field breaks

Last tested: 2 November 2026

The tests on this page were run on 2 November 2026, with one comparison run from 1 November, in a Bright Data account on the product as it was that day. I did not record a version number. Bright Data has said it is aware of the failures below and is working on the fix, so this behavior may change once Bright Data ships it. When Bright Data tells me a fix has shipped, I will rerun the three failing cases and update this page with the date and the result.

What I tested

I tested the AI scraper builder, not Bright Data's ready-made scrapers. Each of the five new scrapers got a URL and a plain-English instruction, was approved as the builder offered it, and had no hand-edited code. They covered a practice bookstore, a practice quotes page that only shows its content through JavaScript, 24 pages of this site's own hardware directory, the Hugging Face trending models list, and Wikipedia's list of large language models. I then pointed a working scraper at a page with a different layout and at a page that always returns a 503 error, and I used the repair prompt on two faults. I directed the tests, and Claude, an AI assistant, ran them in my Bright Data account through a logged-in browser. Before running on a real site I checked its robots file (where a site says what automated visitors may do) and its terms, and I did not test sites with bot protection.

What worked

Setup was quick. A URL and a sentence of instructions produced a working scraper in about 3 to 6 minutes, including one approval click. The practice bookstore scraper returned 1,000 records, the same as the number of books on the site, and the 100 rows I could read in Quick view matched the site exactly. The quotes scraper returned all 100 quotes exactly, with text, author and tags, from a page whose raw HTML holds none of them. On 24 pages of my own site, all 24 headings and paragraphs were correct. On Hugging Face the builder paged through exactly three list pages and read the page's embedded data instead of fragile page text. The limits: Quick view shows 100 rows at most, so I counted the other 900 books and did not compare them, and an optional memory field stayed blank on 8 of my 24 pages.

The repair tool worked both times

Self-Healing is not automatic. It is a prompt, titled "Refactor collector", where you describe what changed, and nothing is repaired until you ask. It worked well both times I used it. After a short note that the page layout had changed, it took 3 to 4 minutes and gave me a reviewable before-and-after of the code with a sample result. The repaired scraper returned all 100 of 100 quotes exactly, and it replaced a guessed next-page address with the real Next link. After a three-sentence note about a wrong field, it fixed all 90 licenses in about 2 minutes with the other fields intact. Accepting a repair saves a draft, and going live is a separate Save to production step, which keeps a person in control. I did not check whether the repaired quotes scraper still works on the old layout.

A failed run can look finished

I took a working scraper that reads a quotes page and ran it two ways. First I pointed it at a differently built version of the same practice site, as a stand-in for a site changing its layout. Then I pointed it at a test address that always answers with a 503 error, the code for "service unavailable". Each run made 6 attempts and ended with the status "done" and 0 records. Failed crawls (pages the scraper could not read) read 0, and the Errors tab said "No errors in this run". Only the 0 records and the 0% success rate showed that anything was wrong. The summary tile for that scraper read 90.00% average success while three of the five runs under it read 0.00%. A scheduled job could collect nothing with no error in the control panel. I did not check whether Scraper Studio sends an alert by email, so look for one before you rely on a schedule.

A clean run can hold a wrong field

On Hugging Face I asked for the first three pages of the trending models list: model id, task, downloads, likes and last updated date, then each model's license from its own page. The run reported 100% success and 0 failed crawls, and every row had text in every field. Id, task, downloads and last updated date were right on all 90 models, and likes were exact on most rows and within a few percent on the rest. But the license field was wrong on all 90 rows. It held a label from the page ("License:" on 64 rows, "arxiv:" on 23, nothing on 3) instead of the license, while Hugging Face's public API has a license for 86 of those models. I only caught it by comparing the output with that API. After a three-sentence repair note, a second run got all 90 right. Even then, 37 rows read "other", which is Hugging Face's own value for a custom license, and the API gives a more specific name for 32 of them. If the license matters to you, a correct-looking field still needs a second look.

What Bright Data has said

On 5 November 2026, Bright Data told me by email that it is aware of these three behaviors (a changed layout and a 503 each ending "done" with no records and no error, and a successful run with a wrong field) and is working on the fix. It did not give a date. That statement is everything I know. I do not know whether the three behaviors share one fix, or when any fix will ship, so do not assume they are fixed until this page says it was retested.

When the builder misses the brief

On Wikipedia's list of large language models I asked for every row of the main table, plus the first sentence of each model's own article. The approval screen showed an example row that looked right, with an article link and a first sentence for GPT-3. The run returned 27 records, 51 failed crawls and 35.44% success, and none of the data I asked for: no table rows, no first sentences and no article links. It returned 505 rows from other tables on 27 articles instead, forced into one set of fields, so a "developer" field can hold "Reasoning model". This failure was not quiet, because the 35.44% success rate showed that something had gone wrong. The 11 failed pages I could read all reported the error "(intermediate value).attr is not a function". That points to the code the builder wrote and not to Wikipedia refusing the pages, though that reading is mine and I did not try the repair prompt on this one. I used Wikipedia on a small scale, about 79 pages. Bright Data offered its pre-built Wikipedia scraper before I started, and I declined it to keep the test comparable, so this says nothing about that scraper.

Two smaller things to know

First, the approval preview is an example and not a test run. On Hugging Face the preview for one model showed downloads and likes about a thousand times smaller than the real figures, and a license that was not the value the run returned. Read the preview as a promise about the fields, not as proof of the values. Second, the bookstore scraper fixed its page count at 50 pages instead of following the Next link as I asked. It was correct that day and would silently miss pages if the catalogue grew, so read the generated code when you ask for pagination.

What I did not test

This is a small sample, so it shows what can happen, not how often. I did not test sites with bot protection, delivery options, the ready-made scrapers, recovery from a temporary failure, jobs beyond about 1,000 pages, or email alerts. Two third-party sites are not a success rate, which is why the advice here is to check every field and not to trust a percentage.

Practical recommendations

• Treat 0 records as a failure, whatever the status says. Open Quick view after every run and read the record count.
• Compare every field you care about with a source you trust, on a sample of rows: the site's own API, or the page itself. A filled-in field is not a correct field.
• Look for fields that repeat one or two values on every row, or that hold a label such as "License:" instead of a value. Those are signs the scraper read the wrong part of the page.
• Read the record count and a sample of rows, not only the success rate. A one-page run of mine that did return its record once showed 0 pages and 0.00%, so no single number is enough.
• Test a layout change on purpose before you schedule anything: point the scraper at a differently built page and see what the run history tells you.
• Use the repair prompt with a short, specific note, then check the sample result before you accept it and again before you Save to production.
• Start small: one URL, then a few pages, then more. Check each site's robots file and terms before you run anything on it.

Tradeoffs

The AI builder trades control for speed. You get a working scraper in minutes without writing code, but you also inherit code you did not write, and nothing in the run history reliably tells you when that code stops matching the page or reads the wrong part of it. Scraper Studio's own footer says "AI-enhanced results. Verify data accuracy before use." My tests agree with that line. For a small job you are watching, the speed is worth it. For anything scheduled, or anything that feeds an AI app, add your own check on record counts and fields. These findings come from a small sample, and they may change once Bright Data ships its fix.

Related links

FAQ

Sources