GSC Browser-Relay Options — Recommendation

Date: 2026-04-28

Goal: Bridge Cinder → Costa's logged-in Chrome → GSC URL Inspection ("Request Indexing") without violating the hard rule against mass sitemap operations.

Why a relay (not just an API)

Google's official Indexing API supports ONLY JobPosting + BroadcastEvent schemas. Generic page-indexing requests are NOT supported. The only reliable programmatic path is browser automation with a real authenticated session.

Costa hard rule: never mass-resubmit sitemaps (erases crawl history). Individual URL inspection ("Request Indexing") is the only allowed mechanism.

5 options evaluated

Option 1 — Playwright with Chrome user-data-dir ⭐ RECOMMENDED

Approach: Daemon on Mac mini runs Playwright pointed at Costa's actual Chrome profile (~/Library/Application Support/Google/Chrome/). Cookies, GSC auth, 2FA all carry over. Cinder posts URL via webhook → daemon opens GSC → inspects URL → clicks "Request Indexing" → screenshots verification.

Pros:

- Zero install — Playwright already in .venv from Mangools work.
- Uses real Chrome profile — passes Google's bot detection (the 09:04 SERP scrape failed with vanilla Playwright; profile-anchored Playwright is night-and-day different).
- No cost.
- Screenshot per submission = audit trail.

Cons:

- Mac mini Chrome must NOT be in active use during a relay run (Playwright takes the profile lock). Mitigated by running batches at 03:00 CT.
- Costa must stay signed into GSC (he is anyway).

Effort: ~3 hr build, ~30 min for first 5 URL test.

Option 2 — dev-browser MCP plugin (already installed)

Approach: ClaudeClaw plugin dev-browser:dev-browser already supports Chrome automation. Wire a slash command /gsc-submit <urls> that loads URL Inspection, clicks the button, captures success.

Pros:

- Already installed — zero new infra.
- Lives in Cinder's existing tool surface.
- Stateful — survives across Cinder turns.

Cons:

- Must be invoked manually (Cinder fires it; no daemon mode).
- ClaudeClaw turn-based; doesn't run unattended overnight without orchestration.
- Cinder is the operator, not Mac mini cron — uses Cinder API budget per submission.

Effort: ~1 hr to write the slash-command wrapper.

When this fits: Daytime ad-hoc submits (1-5 URLs after a fix). Not the right tool for nightly batches.

Option 3 — Custom Chrome extension

Approach: Costa installs a private extension that exposes a local HTTP endpoint. Cinder POSTs URLs → extension navigates GSC → submits. Like a homegrown Zapier.

Pros:

- Survives Chrome restarts.
- Doesn't need profile-lock.
- Could surface a UI badge ("3 indexings pending" in toolbar).

Cons:

- Build cost: 1-2 days (manifest v3, content script, native messaging).
- Costa has to install + grant permissions + keep enabled.
- Maintenance burden (Manifest v3 deprecates regularly).

Effort: 8-12 hr build.

When this fits: Long-term, if Option 1 hits friction. Skip for now.

Option 4 — AppleScript + JXA on Mac mini

Approach: Mac-native AppleScript drives Chrome via System Events ("click button containing 'Request Indexing'"). Hooked to a launchd cron that polls a queue file Cinder writes.

Pros:

- macOS native, no Python/Node deps.
- Survives any Chrome update that breaks Selenium-style approaches.

Cons:

- Brittle — Google A/B tests GSC UI; selectors break monthly.
- AppleScript debugging is slow.
- No cross-platform (won't survive a switch to a different Mac or VM).

Effort: 4-6 hr build + ongoing maintenance.

When this fits: Skip. Option 1 is strictly better.

Option 5 — Browserbase / Anchor / cloud browser service (paid)

Approach: Cloud browser-as-a-service (Browserbase, Anchor, or Hyperbrowser) hosts a persistent Chrome session with Costa's GSC auth. Cinder calls their API.

Pros:

- Truly cloud-native — no Mac mini dependency.
- Session persistence + visible debugging dashboard.
- Bot-detection more robust (real residential IPs).

Cons:

- $50-150/mo recurring cost depending on tier.
- Google session pinning — keeping Costa's GSC auth alive on a remote browser is fragile (session cookies expire, 2FA reverification).
- Adds an external dependency to the lead infrastructure.

Effort: 2-3 hr integration.

When this fits: If/when ITD scales to 500+ submissions/week and Mac mini availability becomes the bottleneck. Not now.

Recommendation

Build Option 1 (Playwright + Chrome user-data-dir) tonight. Plus Option 2 (dev-browser slash command) as a same-week add for ad-hoc daytime submits.

Rollout:

1. Tonight: Playwright daemon + queue file at data/gsc-submit-queue.jsonl. Cinder writes URLs to the queue; cron at 03:00 CT processes the queue (~5-10 sec/URL, 100/night cap to avoid Google rate limit).
2. Tomorrow: dev-browser slash command for daytime "fix this URL now" submits.
3. Audit trail: every submission gets a timestamped screenshot + DOM snapshot to data/gsc/submissions/<date>/<slug>.{png,html}.

Open question for Costa

Mac mini Chrome session — is the GSC login on your daily-driver Chrome profile (default profile) or a dedicated profile (e.g., "ITD")? Default-profile risks profile-lock contention if you happen to be using Chrome during a 03:00 batch (rare, but flag). If you have / can create a dedicated ITD profile signed into GSC only, Option 1 becomes friction-free.