Home → Learn → Browser automation

Browser automation without writing code

Most multi-account work is the same handful of steps repeated per account: open a page, log in, check something, fill a form, record the result. Doing that by hand across forty profiles is where the hours go — and where the mistakes come from.

What RPA means in a browser

Robotic process automation is a grand name for a simple thing: a list of steps a machine repeats the way a person would. In a browser those steps are the actions you already take — navigate, click, type, wait, read a value, extract text, upload a file — arranged in order and replayed.

The difference from a recorded macro is that a real process reacts. It waits for elements rather than sleeping a fixed time, branches when a page differs, loops over a list, and carries values between steps.

Selectors: the part that breaks

Every automation lives or dies on how it finds elements. A CSS selector like button.submit is readable and fast; XPath handles the cases CSS cannot, such as matching on visible text.

Also budget for waiting. Pages load progressively, so a step that acts the instant the document is ready will act before the element exists. Waiting for the element itself is both faster and more reliable than a fixed delay.

Variables, loops and conditions

Three constructs turn a linear list of clicks into something that handles real work:

• Variables — capture text from the page, or read a value from a spreadsheet, and reuse it in a later step
• Loops — repeat over a list of rows, a set of elements, or a fixed count, with the current item available to every step inside
• Conditions — branch on whether an element exists, whether text matches, or what a variable holds

Conditions matter more than they sound. The difference between an automation that survives a week and one that breaks daily is usually a check for "did the login actually succeed?" rather than assuming it did.

One process, many profiles

The multiplier is running the same process against a set of profiles, each with its own session, fingerprint and proxy — so forty accounts do the same task without sharing anything.

Two things to get right. Run in sequence, or in small batches, rather than launching forty browsers at once: each is a real Chromium instance with real memory cost, and forty simultaneous identical requests is its own pattern. And make the process profile-agnostic — anything account-specific should come from the profile or a data source, not be hardcoded.

Feeding it real data

Automations that matter usually read or write something outside the browser: a spreadsheet of inputs, a file of results, a note of what happened. A Google Sheet as the input list and the output log keeps the process itself generic — one process, different rows per run — and gives you a record you can read afterwards without digging through logs.

Scheduling

Once a process is reliable, the next question is when it runs. Scheduled runs handle the maintenance work that keeps accounts healthy — periodic logins, routine checks — without anyone remembering to start them.

Stagger them. Forty accounts all acting at exactly 09:00 every day is a stronger correlation signal than anything in the browser fingerprint, because real people are not that punctual.

Decide whether the run needs a window, too. Scheduled runs are normally headless, which is the right default for checks and fetches — but a headless browser is served a noticeably different page, and smooth scrolling does not work in one at all. If the point of the process is to look like somebody using the site, run it visibly.

Designing for failure

Automations fail; sites change, networks drop, logins expire. What matters is what happens next. Decide deliberately whether a failing step should stop the whole run or skip to the next profile — stopping everything because profile three hit a captcha wastes the other thirty-seven.

• Check, don't assume. Verify the expected element appeared before continuing.
• Log enough to diagnose. Which profile, which step, what the page showed.
• Test on one profile first. A broken process run across forty accounts does forty times the damage.

When to drop down to code

No-code covers most of it, but not everything. If you need loops over complex data structures, custom parsing, or to integrate with your own systems, drive the browser directly instead.

A local automation API can start a profile and hand back a real Chrome DevTools Protocol WebSocket endpoint, which Puppeteer, Playwright or anything else speaking CDP can attach to — keeping the profile's fingerprint and proxy while your own script does the work. See the automation API reference.