TL;DR Most legacy scraping stacks are a stack in name only. They are a pile of proxy accounts, a fork of a headless browser, a queue of CAPTCHA workarounds, and a pager rotation to keep it alive. You can replace that whole pile with a handful of Browserbase primitives that share one API key. Fetch handles the pages that don't fight back, Proxies and Browsers handle the ones that do, Stagehand handles the pages that change shape on you, and Verified reaches the sites that block everything else. The point is to stop maintaining the part that breaks.

If you have run a scraping operation for more than a year, you know the shape of the problem. The scraper itself is a few hundred lines. Everything around it is the job. Someone owns the proxy pool and rotates it when a provider's IPs get burned. Someone patches the headless browser fork every time an upstream change leaks a new fingerprint. Someone keeps a folder of per-site hacks for the CAPTCHAs and the challenge pages. None of that is the data you actually wanted. It is the tax you pay to reach it.

That tax made sense when there was no other option. It doesn't anymore. The individual pieces of a scraping stack have become products you can call, and they interoperate because they were built to. This is an argument for deleting most of your stack and keeping the part that is genuinely yours, the logic that decides what to collect and what to do with it.

What a scraping stack actually is

Strip away the branding and every scraping stack is the same five layers. A way to fetch bytes over HTTP. A pool of IP addresses so you don't get rate-limited from one place. A real browser for the pages that only render with JavaScript. Something to read a page whose markup changes weekly. And a way to reach sites that actively refuse automated traffic. Teams build these separately, from five vendors and three internal repos, and then spend their week gluing them together.

Browserbase ships those five layers as one platform under a single API key. What follows is each layer, what it replaces, and the shortest path to using it. Treat it as a migration plan you can work through in order.

Start with Fetch for the pages that don't fight back

A large share of what teams point a full browser at is static HTML. Product pages, documentation, listings, anything server-rendered. Spinning up a browser for those is slow and wasteful. Fetch retrieves a URL through Browserbase's infrastructure with a real browser User-Agent and hands you back the content, no session to manage.

import Browserbase from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY! });

const response = await bb.fetchAPI.create({
  url: "https://httpbin.org/",
});

console.log(response.statusCode);
console.log(response.content);

Fetch doesn't execute JavaScript and caps at 5 MB per response, so it isn't for every page. When you want cleaner input for a downstream model, set format to markdown or json and Browserbase converts the page before returning it. Use Fetch first, and reach for a browser only when the page genuinely needs one. That single decision cuts most of the browser count out of a legacy stack.

Route the hard pages through Proxies

The reason your old stack has a proxy team is geolocation and rate limits. You need traffic to originate from the right place and from enough places that no single IP gets throttled. Browserbase has managed residential proxies built in. You turn them on with a flag, and the accounts and the burned-IP rotation stop being your problem.

import { Browserbase } from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY! });

const session = await bb.sessions.create({
  proxies: true,
});

Setting proxies: true makes a best-effort attempt to route through a US-based IP. If you need finer control, you can bring your own proxies or set routing rules that send different domains through different exits. Either way the pool stops being something a person babysits.

Use real Browsers for the JavaScript-heavy sites

For pages that only exist after JavaScript runs, you need an actual browser. The trap in a legacy stack is that you also need a fleet of them, kept warm, patched, and scaled with load, which is where most of the operational cost hides. Browserbase runs the fleet. You create a session over the API and drive it with the automation library you already know over CDP.

This is the layer people mean when they say a scraper works on a laptop and dies in production. Running one browser is trivial. Running a thousand of them reliably, each with a clean profile and a real fingerprint, is the actual product. The create-browser-session guide and the concurrency docs cover the session lifecycle and how to scale it.

Let Stagehand handle pages that change shape

The most brittle code in any scraping stack is the selectors. A site ships a redesign, a class name changes, and a job that ran for months breaks silently overnight. The traditional fix is a person who rewrites XPath. Stagehand is our automation framework that takes natural-language instructions and resolves them against the live page, so a wording-level instruction survives a markup-level change.

import { Stagehand } from "@browserbasehq/stagehand";

const stagehand = new Stagehand({ env: "BROWSERBASE" });
await stagehand.init();

const page = stagehand.context.pages()[0];
await page.goto("https://stagehand.dev");

const result = await stagehand.extract(
  "Extract the value proposition from the page.",
);
console.log(result);

await stagehand.close();

Stagehand gives you a few plain-language verbs. act performs an action, extract pulls structured data against a schema, and observe discovers what's on a page before you touch it. It runs against the same Browserbase session, so adopting it changes how you write the steps while leaving the rest of your setup in place.

Reach the sites that block everything with Verified

Every scraping team has a list of sites they simply cannot reach. The requests come back with a challenge page, the browser gets flagged, and no amount of proxy rotation fixes it. This is the layer that decides whether a stack is worth keeping, and it is the hardest one to build yourself.

Verified sessions use a purpose-built Chromium browser with real browser fingerprints that Browserbase's bot protection partners recognize. A Verified session carries an identity those partners already trust, which means far fewer challenges and reliable access to protected sites.

import Browserbase from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY! });

const session = await bb.sessions.create({
  browserSettings: {
    verified: true,
    os: "mac",
  },
  proxies: true,
});

Verified is available on the Scale plan, and it pairs with Proxies for the best results on protected sites. It sits inside a broader Agent Identity story, including Web Bot Auth through Cloudflare's Signed Agents program, where your automation proves it is an authorized participant rather than hiding that it is one. That is the difference that moves a blocked site into the reachable column.

Why teams actually make the switch

The feature list is the easy part. The reasons teams commit come down to three things, and they are worth naming plainly because they are the ones that survive a trial.

• You reach sites you couldn't before. The fastest way to evaluate this is to take the three sites your current stack is blocked on and try them. If they come back with data, the rest of the conversation is short.
• The platform is built for developers. One API key, primitives that compose, docs with runnable snippets, and libraries you already use. Adoption is measured in an afternoon.
• It just works. Reliability is the whole product. The point of moving the fleet, the proxies, and the fingerprints onto a platform is that you stop thinking about them. The scraper runs, and you go work on something else.

None of these is a benchmark you argue about. They are things you confirm in a trial and then stop worrying about. That is the honest test of whether a platform has replaced your stack or added to it.

How to run the migration

You don't rip out the old stack on day one. You migrate by category, easiest wins first, and let the maintenance savings compound.

1. Move static pages to Fetch. Anything that renders without JavaScript stops needing a browser. This alone shrinks your fleet.
2. Turn on managed Proxies. Retire the provider accounts and the rotation scripts for the traffic you route through Browserbase.
3. Point JavaScript-heavy jobs at Browsers. Connect your existing automation over CDP and delete the fleet-management code.
4. Rewrite the brittle selectors in Stagehand. Start with the jobs that break most often, where self-healing pays for itself first.
5. Move the blocked sites to Verified. This is the list you keep in your head. Clearing it is usually what justifies the whole move.

The shortest way to see whether this holds for your stack is to try it on the pages that give you the most trouble. Start with the quickstart, or if you're weighing a larger migration, contact sales and bring the three sites you're blocked on.

Last updated: August 24, 2026