Technical SEO ops on Dock works like this: the CMS, CDN, and edge runtime stay the source of truth for templates, headers, redirects, and rendered HTML. The agent watches Google Search Console, Lighthouse, and crawl output, then files a ticket into a Dock table whenever a regression crosses threshold. Every sitewide template change exits Dock through a dual-keyed handshake. One key from the agent that filed the ticket, one key from a human engineer who owns the template. No solo agent ship on anything that touches every page.
Google Search Console, Ahrefs, Semrush, Screaming Frog, and Clearscope remain the system of record for the raw data: rankings, backlinks, crawl results, the keyword corpus. Dock is the system of record for what the agent interprets from that data, namely the prioritized fix list, the redirect map, the keyword brief, the outreach decision. Each Dock row carries a pointer back to the platform record (gsc_query_id, lighthouse_run_id, crawl_issue_id), plus agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state. Dock holds the persistent interpretive layer that survives across sessions, so the next agent run starts from "what did we decide last week" rather than "let me re-crawl the site."
The technical-SEO ticket queue
One Dock table, tech_seo_tickets, with rows like this:
| ticket_id | issue_type | severity | url_pattern | metric | observed | threshold | source_ref | agent | proposed_fix | reviewer | dual_key_state |
|---|---|---|---|---|---|---|---|---|---|---|---|
| TSO-0418 | CWV regression | high | /products/* | LCP p75 | 3.8s | 2.5s | lighthouse_run_91244 | ved | preload hero image in product template | eng:darya | one_key |
| TSO-0419 | indexing | medium | /blog/2024/* | coverage | 412 noindex | 0 | gsc_query_8821 | ved | remove stale noindex from archive layout | eng:darya | awaiting_review |
| TSO-0420 | structured data | low | /pricing | Product schema | 3 errors | 0 | gsc_rich_results_5510 | ved | fix missing offers.priceCurrency | eng:darya | shipped |
Each row is small, typed, and pointer-rich. The dual_key_state column drives the publish gate.
A worked workflow
The agent runs a scheduled Core Web Vitals sweep, sees product-page LCP p75 climb to 3.8s, and files TSO-0418 with the Lighthouse run ID, the proposed template patch, and the expected delta. Darya, the engineer who owns the product template, opens the row in Dock, reads the pointer, pulls up Lighthouse herself, and concurs. She turns her key. The agent had already turned its key when it filed the row. With both keys turned the gate fires and the template patch lands behind the CDN. Without Darya's key the patch sits. The agent cannot self-approve a sitewide template change, by contract.
The same shape covers indexing fixes, redirect-map cutovers, hreflang corrections, and structured-data ships. The table is the queue. The handshake is the publish primitive. The platform tools stay authoritative for the underlying data.
Why this shape
Attribution. Every shipped change has an agent name, a reviewer name, a source platform ID, and a timestamp on the row. When a regression appears six weeks later the SEO team reads the row, not a Slack thread.
Audit. The dual_key_state history is append-only. A compliance reviewer can answer "who shipped the sitewide robots change on the fourteenth" in one query. The pairing pattern is the same primitive we use across irreversible ops.
Daily driver. The SEO team lives in Dock. Tickets sit next to the content audit, the Screaming Frog crawl rows, and the GSC pull. One workspace, one table per concern, one handshake on the way out. The agent does the watching. The engineer holds the second key.
Try the full pillar at Dock for SEO.
FAQ
Q: Does Dock replace Google Search Console or Lighthouse? No. GSC, Lighthouse, Screaming Frog, and the CDN remain authoritative. Dock holds the agent's ticket queue and the publish gate, with pointers back to those platforms.
Q: What exactly is the dual key? Two cryptographic approvals, one from the agent that proposed the change and one from the human engineer who owns the affected template. Both must be present before the CI step that touches the template runs.
Q: Can the agent fix a typo without a second key? A copy edit to a single page goes through the normal content path. Dual-keyed publish only fires on sitewide changes: templates, headers, robots, hreflang, redirect maps.
Q: How does this interact with on-call? The reviewer field on the ticket row maps to a rotation. If the named engineer is off, the ticket reassigns to the on-call backup and the gate waits for that key instead.