Headless mode: up to this many tabs run at once — Playwright context.new_page() plus an asyncio semaphore. Each keyword gets its own page in the same site profile, sharing cookies/login while loading in parallel.

Visible browser mode (show_browser=true): tabs always run one at a time regardless of this setting. Running multiple context.new_page() calls simultaneously in non-headless Chromium opens separate windows instead of tabs — so the worker serialises them to keep exactly one window on screen.

Batch / resume mode on: At most this many (site, keyword) pairs are picked per site per cycle.

Batch mode off: Every keyword still runs, but only this many pages are open at a time — the rest wait until a tab finishes.

More tabs use more CPU/RAM and look busier to the site; combine with max_concurrent_browsers for multiple sites in parallel.

Simple idea: Instead of hammering every keyword on every site on every engine cycle, the worker keeps an active “round” in the database: one row per (site, keyword) with status pending → in_progress → done (or back to pending if it needs another try).

Each cycle it only picks pending pairs — up to max_tabs_per_site per site — scrapes them, then saves progress. When all rows in the round are finished, the round closes. That spreads work over time and makes restart-safe progress (unfinished rows are not forgotten).

Same engine path as “Resume after restart”: In code, batching turns on if keyword_batch_enabled or resume_round_enabled is on. So with Resume already checked (default), you already get this round-based behavior — use this toggle if you want batching explicitly on while tuning Resume, or to match how you read the logs.

If both are off: No round queue — each cycle tries all keywords on all sites again (parallelism still limited by tabs / browsers).