BrowserAct’s stealth browser passed a bot-detection check that flagged Playwright’s default headless run as a bot, even though both scripts completed the same login flow. The contrast shows why an agent-based approach can be safer when you need to interact with sites that guard against automation.

Why the test matters

Automation tools power testing, data collection, and account management. Most developers reach for selector-driven frameworks like Playwright because they let you write precise instructions—“click the button with this CSS selector”—and verify outcomes quickly. Modern sites, however, embed scripts that sniff for headless browsers: a generic user-agent string, the webdriver property, or missing human-like interaction patterns. When those signals appear, the site blocks the request or serves a CAPTCHA, effectively neutering the script.

Agent browsers try to mimic a human user without relying on pre-written selectors. They treat a page as a collection of actionable elements, picking one by its position in an internal index rather than by a CSS path. The test compared the two approaches on a JavaScript-rendered login page and a site that deliberately checks for bots.

The experiment

I wrote two scripts that performed the same steps: load the login page, enter credentials, submit, and reach the inventory page. One script used Playwright in its default headless mode; the other used BrowserAct’s stealth browser, which masks the fingerprints that trigger bot detection.

Both scripts authenticated against a sandbox site, proving the core login flow works regardless of the tool. The divergence appeared when the scripts visited a dedicated bot-detection page that returns a JSON flag isBot. Playwright reported isBot: true, tripping five separate detection checks. BrowserAct returned isBot: false, indicating the page treated it as a regular human visitor.

I traced the difference to two technical details. Playwright’s default configuration sends a generic user-agent string and leaves the webdriver flag exposed—both easy for a detection script to spot. BrowserAct’s stealth mode rewrites the user-agent, removes the webdriver property, and aligns its fingerprint with that of a typical desktop browser.

How the tools differ under the hood

Aspect Playwright (default) BrowserAct (stealth)
Interaction model Selector-driven, deterministic Agent-driven, index-based
Need for pre-written selectors Mandatory; script must know the exact DOM structure Not required; agent discovers actionable elements at runtime
Handling of layout changes Breaks if selectors shift Continues as long as element positions stay within the indexed list
Exposure to bot checks User-agent and webdriver left untouched Fingerprints deliberately masked
Typical use case Internal sites, stable UI, rapid test cycles Public sites with anti-automation measures, constantly changing pages

The table captures the practical trade-offs. Playwright shines when you control the site and can guarantee stable element identifiers. An agent browser shines when you cannot predict the page structure or when the site actively tries to block scripts.

Who benefits and who is at risk

Developers building regression suites for their own applications can keep costs low and test speed high by staying with Playwright. Its deterministic nature points failures directly to code regressions, and the lack of extra stealth layers reduces complexity.

Conversely, teams that scrape data, automate account creation, or monitor competitor sites often hit roadblocks because target pages change frequently or embed aggressive bot detection. In those scenarios, an agent browser avoids the immediate “you are a bot” dead-end and continues to the data they need.

The hidden costs of “it worked”

I warn that a successful exit code does not guarantee the automation behaved as intended. In the Playwright run, the script finished without throwing an error, yet the page still considered the request a bot. The result was a hidden failure: downstream steps that rely on human-only content never received the expected data.

こうしたサイレントな失敗を明らかにするには、実行ごとにスクロール位置、ドキュメントの高さ、ネットワークコールなどのページの証拠を調査してください。DOMが人間が見るものと異なっている場合、あるいはネットワークトラフィックに検証チャレンジへの予期しないリダイレクトが含まれている場合、その自動化は目的を果たせていない可能性が高いといえます。

結論

サイトを所有しており、安定したセレクターに対してスクリプトを作成できるのであれば、Playwrightは引き続き現実的な選択肢です。高速で、低コストであり、CIパイプラインへの統合も容易です。未知のレイアウト、強力なアンチオートメーション防御、あるいは頻繁なUIの変更に直面する場合は、BrowserActのようなエージェントブラウザの方が、よりレジリエンスの高い手段となります。実行が成功したからといって盲信せず、ページが人間と同じように動作したかを確認した上で、対象サイトのリスクプロファイルに合致するツールを選択してください。