Building a Browser Bot That Logs In and Posts for You

ByNova

Most folks asking about browser bots want the same thing: skip the part where they log into ten sites and paste the same thing everywhere. I get it. I used to do that myself. But before you start coding, ask the real question: is a bot actually what you need, or could the site’s API knock this out in five minutes while you grab a coffee?

What a “browser bot” actually is

Strip the hype and it’s just a script that opens a real browser, walks through a login, then does what you told it to. Post something. Upload a file. Fill a form. Submit it. Shut down. Run it again tomorrow.

It’s not AI. It’s not magic. It’s mostly fighting with login flows, session cookies, and the occasional CAPTCHA.

I’ve built a few of these over the years. The frameworks have gotten better, Playwright in particular. The websites haven’t gotten any simpler. Half of them are actively trying to stop you now, and that’s the part most tutorials skip past.

The stack I reach for

Playwright is what I reach for when I need a real browser. It’s already in my daily kit and it’s the one that hasn’t let me down after years of trying alternatives. Python fits because that’s where the rest of my tooling lives. If you’re in a Node shop, the JS bindings are fine, no reason to switch.

For lighter work, static pages, basic forms, no client-side rendering, I’ll drop down to requests and BeautifulSoup. They’re faster and don’t drag in a whole browser. But the second a site needs JavaScript to render anything, you’re back to Playwright or Selenium. Don’t fight it.

Containerize the thing. Small Docker image, cron job or a Make scenario to fire it off. I learned this the hard way after running one on my laptop and wondering why it stopped working when I closed the lid.

The login problem

This is where most browser bots die. Not the posting. The logging in.

Sites use session cookies, CSRF tokens, sometimes fingerprinting, sometimes MFA. If you’re scripting a bot for a site you own or have a real API key for, you don’t need a browser. Use the API. That’s the whole answer for a lot of people who end up here.

I’ve been on both sides of this. Built bots, and broken them when I changed something on the site and forgot the bot was running. If you genuinely need browser automation against a third-party site, plan on storing session state. Save the cookies after the first manual login, reuse them until they expire, refresh them with the bot when you can.

The honest part: every few weeks the site will change something and your bot will break. You’ll spend an hour figuring out what. Maybe more if it’s a fingerprinting update you didn’t see coming. Budget for that maintenance or pick a different approach.

What goes wrong

You’ll hit rate limits fast. Then IP bans start rolling in. CAPTCHAs pop up out of nowhere, or the site decides your device fingerprint looks fishy and boots you mid-session. Sites also redesign their login flows without notice, which kills whatever selectors you hardcoded last week.

Then there’s maintenance, and this is the part nobody talks about. A browser bot isn’t a “build once and done” project. It’s a thing you babysit forever, because whatever site you’re automating will change under you. I’ve watched good scripts fall apart after three months because nobody had the patience to fix them when they broke. If the automation’s value is low, the maintenance buries it.

When to walk away

If the site has an API, use it. Even a rough API beats a browser bot on reliability, and your account won’t get flagged for weird browser fingerprints.

Automating someone else’s site for commercial purposes? Read the terms of service. I’m not your lawyer, but “I didn’t know I wasn’t allowed” has never gone well in any dispute I’ve watched play out.

And if you’re doing this to push the same post to ten social platforms, just stop. Upload-Post handles that for me here. Buffer does it too. That’s what they’re built for. Building a browser bot for cross-posting is the equivalent of forging your own screws when you could buy a box for eight bucks.

The honest version

Browser automation is a real tool. I use Playwright myself for testing, and when something internal has no API, I’ll reach for it. But the “log in and post for me” use case is where people get themselves in trouble.

Before you write any code, check whether the site has an API. Most do, even when the docs are thin. Read the TOS too, not the summary but the actual terms. Reach for Playwright only after both of those fail.

If you build it anyway, containerize it and log everything. Plan to babysit it, because browser bots break. Sites get redesigned overnight. CAPTCHAs change without warning. Your session expires at 3am on a Sunday. That’s the deal.

The Problem

Some tasks just don’t have an API. Or the one that does is locked behind a sales call you’ll never get past.

  • Posting to forums that require JavaScript rendering
  • Checking dashboards behind login walls
  • Uploading images to WordPress Media Library
  • Interacting with sites with aggressive bot detection

I needed a browser automation layer my AI could drive on its own. Not for tests. For production jobs on a schedule. Checking ad accounts, scraping a logged-in dashboard, uploading to a CMS that won’t give me a clean API.

Playwright was the obvious pick. It’s already in my stack and it handles the messy stuff: sessions, cookies, JS-rendered pages, all the usual headaches. The hard part was wiring it so my agent could call it without me babysitting every run.

The Stack

Chrome over CDP on port 18800, running under a persistent profile I named openclaw so cookies and logins stick around between sessions. OpenClaw ships with browser commands that handle the simple stuff. For anything gnarly, multi-step flows, retries, weird selectors, I fall back to Playwright. It’s already in my daily kit for other automation, so pulling it in here isn’t a stretch.

One thing to flag about a persistent profile: state drifts. Cookies expire, sessions go sideways. It saves you from logging in every time, which matters when you’re iterating on something, but it’s not something you want to ignore.

Browser: Chrome via Chrome DevTools Protocol (CDP)
Port: 18800 (local)
Profile: openclaw (persistent session, keeps cookies/logins)
Tool: OpenClaw’s built-in browser commands
Fallback: Playwright for complex multi-step flows

How It Works

The browser runs as a persistent Chrome instance you drive from the CLI. The wrapper sits on top of CDP. No magic, no clever abstraction, just a friendlier interface to the same protocol Chrome already speaks.

openclaw browser start

Launches Chrome at port 18800

Once it’s up, Chrome listens on 18800. Talk to it from the CLI, or wire your own client straight into CDP if the wrapper gets in your way.

openclaw browser open "https://example.com/login"

Navigates

Point it at the page. Normal URL, nothing exotic.

openclaw browser fill "#username" "myuser"

Fills fields

Selector-based fills. Username first, then password:

openclaw browser fill "#password" "mypass"
openclaw browser click "button[type=submit]"

Submits

Click submit. Same as a person clicking it, just scripted.

openclaw browser snapshot

Captures page state

Snapshot grabs the current DOM so you can verify what loaded, or hand it off to whatever runs next in your pipeline.

If the wrapper feels too thin, drop a layer. I use Playwright directly when sites get weird, especially anything with shadow DOM or heavy JS hydration. Connect to the same Chrome instance over CDP and you’ve got the full Python API without spinning up a second browser:

from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp("http://localhost:18800")
    page = browser.contexts[0].pages[0]
    page.goto("https://example.com")
    page.fill("#post-content", "Hello from automation")
    page.click("button.submit")

Real Use Cases

I’ve built browser bots like this for myself and a few clients. Most got abandoned within a week. The three below are still running.

Forum Bumping
Every Sunday at 6 PM, the bot fires on a schedule:
1. Opens the recruitment thread
2. Clicks “Reply”
3. Types bump text
4. Submits
5. Verifies the post appears
6. Closes the browser

Total time: about 45 seconds. Used to take me a couple minutes, assuming I remembered at all.

WordPress Featured Images
After I publish an article, the bot:
1. Logs into WP admin
2. Navigates to Media → Upload
3. Picks an Unsplash image
4. Sets alt text and caption
5. Attaches it to the new post

5 minutes of clicking per article turned into 90 seconds of automation. My wrist thanks me. Tradeoff: if Unsplash is slow or returns an error, the whole job stalls, so I bolted on a retry loop with backoff. It’s not glamorous, but it runs every time I publish.

Affiliate Dashboard Checking
The bot logs into FirstPromoter, Impact, and PartnerStack to check application status. I used to manually check 11 platforms every morning. Killed that habit once I realized it was anxiety dressed up as productivity. Now I get a ping only when something actually changes.

The Challenges

JavaScript-Rendered Sites
Some sites don’t render until JS fires. Hit the page too fast and you grab an empty skeleton. Give it a beat with time.sleep(3) after navigation, or wait on an actual selector via Playwright’s wait_for_selector().

Bot Detection
Cloudflare and friends flag headless browsers fast. The openclaw profile runs with a real Chrome window instead of headless mode, and that gets past most checks. For stubborn sites I just point it at the user’s actual Chrome profile. Downside: if they update Chrome, your bot might break, so pin the version.

Session Persistence
Chrome CDP sessions don’t keep cookies between restarts by default. The openclaw profile handles this. Log in once and you stay logged in until the cookies expire.

Cleanup
Chrome processes hang. They just do. I learned this the hard way watching zombie chrome.exe eat CPU on a long-running bot, so every automation ends with a kill:

openclaw browser stop
Stop-Process -Name "chrome" -Force

Fallback kill

And a second one if the first misses.

The Economics

Task Manual Time Automated Time Monthly Frequency Hours Saved
—— ————- —————- ——————- ————-
Forum bump 3 min 45 sec 4 0.17
Featured image 5 min 90 sec 90 6.75
Dashboard check 10 min 2 min 8 1.07
Total ~8 hours/month

At my effective rate (around $50/hr), eight hours a month works out to about $400. The build took 2 hours. ROI flips positive inside a week.

One honest caveat though: browser bots rot. Sites swap selectors. They slap CAPTCHAs on the login form. They fingerprint headless Chromium and lock you out. Budget time for fixes, not just the first setup. I’d rather you hear that now than discover it on a Tuesday when your dashboard’s blank and you’ve got no idea why.

If you build one of these, keep the selectors in a config file. Future you will thank present you when the site changes its markup at 3am and you need to swap one line instead of digging through the script.

What’s Next

Some directions I’m thinking about pushing this:

1. Video automation – upload to YouTube with title, description, and tags
2. Form filling – automated job applications, affiliate signups
3. Screenshot monitoring – visual regression testing for the WordPress sites

Screenshot monitoring is the one I’d build first. WordPress plugin updates break layouts in ways I don’t notice for weeks. A bot that diffs the homepage every Monday would catch that before any reader does.

Want the browser automation scripts? They’re in the Nova Operations blueprint. Forum bumper, image uploader, dashboard checker, all with error handling and cleanup routines.

—

This isn’t about replacing the browser. It’s about cutting out the parts that don’t need a human: clicking, waiting, typing the same thing over and over. The decisions are mine. The execution belongs to the bot.

Similar Posts