---
title: "Dock for SEO: content audit and redirect workflows with consent gates"
excerpt: "The site itself is the source of truth for content. Dock holds the per-URL audit row (keep, update, merge, redirect, retire) the agent recommends, the reviewer decision, and the dual-keyed handshake before any redirect rule ships."
author: mei
category: Use Cases
date: "2026-05-30"
---

A content audit in Dock works like this: the agent crawls the live site, scores every URL against traffic, backlinks, freshness, and intent fit, then writes one decision row per URL into a Dock table. The reviewer (a human SEO lead, or another agent with explicit scope) marks each row keep, update, merge, redirect, or retire. Redirect rows do not ship until a two-key handshake fires. The site stays the source of truth for what is published. Dock stores what the agent decided about it and who signed off.

Screaming Frog, Ahrefs, Google Search Console, and the CMS stay the system of record for raw signal: crawl results, backlink graphs, ranking data, and the page bodies themselves. Dock is the system of record for what the agent interprets from that data, namely the prioritized fix list, the redirect map, the merge plan, and the retire-and-410 set. Each Dock row carries a pointer back to the platform record (a `screaming_frog_url_id`, an `ahrefs_backlink_id`, a `gsc_query_id`), the agent identity that drafted it, the reviewer decision, and the timestamp. When the agent needs current crawl state it re-runs the fetch. Dock holds the persistent interpretive layer that survives across sessions, so the next audit cycle starts from last quarter's decisions rather than from a blank sheet.

## The audit table

| url | crawl_source | organic_clicks_90d | backlinks | recommendation | reviewer_decision | redirect_target | gate_state |
|---|---|---|---|---|---|---|---|
| /blog/old-mcp-primer | screaming_frog#42118 | 14 | 3 | merge | approved | /blog/the-smallest-mcp-tool | armed, awaiting key 2 |
| /guides/legacy-pricing-2023 | screaming_frog#42119 | 2 | 0 | retire | approved | (410) | shipped |
| /blog/agent-identity | screaming_frog#42120 | 1,840 | 22 | update | approved | (same URL) | n/a |

Each row is a decision, not a draft document. The page body lives in the CMS. The crawl row lives in Screaming Frog. The decision and its provenance live here.

## A worked workflow

The agent runs the weekly crawl via the Screaming Frog MCP server, the same pattern described in [agent-run Screaming Frog audits](/blog/dock-screaming-frog-audits). It flags `/blog/old-mcp-primer` as a merge candidate: thin traffic, three backlinks worth preserving, near-duplicate intent against `/blog/the-smallest-mcp-tool`. The agent writes a row with `recommendation = merge` and proposed `redirect_target`. The SEO lead opens the row, agrees, marks `reviewer_decision = approved`. That alone does not deploy anything. The redirect rule is a dangerous operation under [Dock's dangerous-ops contract](/blog/dangerous-ops-contract), so the row enters `gate_state = armed, awaiting key 2`. The deploy agent (a separate identity, not the audit agent) presents the second key after re-reading the row. The redirect ships. The mechanics are the same dual-keyed pattern covered in [two-key handshakes for irreversible work](/blog/two-key-handshakes-irreversible). Following [Google's redirect guidance](https://developers.google.com/search/docs/crawling-indexing/301-redirects), the rule is a server-side 301 because the merge is permanent, and that fact is recorded on the row.

## Why this matters

Attribution survives. Six months from now, when traffic to `/blog/the-smallest-mcp-tool` either lifts or collapses, anyone can pull the row and see which agent recommended the merge, who approved it, what the pre-merge metrics were, and which crawl record fed the call. That is the same audit posture covered in [agent audit and compliance](/blog/agent-audit-and-compliance), applied to SEO work.

Audit cycles compound. The next quarterly pass reads last quarter's rows first, so the agent does not re-litigate decisions that already shipped. Recommendations that were rejected stay rejected, with the reviewer's reasoning attached, until the underlying data changes enough to flip the call. The methodology Ahrefs documents in [their content audit guide](https://ahrefs.com/blog/content-audit/) becomes a standing process rather than a one-off spreadsheet.

The SEO team's daily driver becomes the Dock table, not the crawler UI. The crawler is where they go to investigate. The table is where they decide. Pairing this with the technical-ops patterns in [Dock for SEO technical ops](/blog/seo-technical-ops) gives one workspace for both content decisions and infrastructure ones.

If you want the full picture of how the pillar fits together, the [Dock for SEO overview](/blog/dock-for-seo) is the map.

## FAQ

**Q: Does Dock replace Screaming Frog or Ahrefs?**
A: No. Those platforms remain the source of truth for crawl data, backlinks, and rankings. Dock stores the agent's recommendation, the reviewer's decision, and the deploy gate state, each row pointing back to the platform record by ID.

**Q: What stops the agent from shipping a bad redirect?**
A: The redirect rule is a dangerous operation. It requires a two-key handshake: one key from the auditing agent, one from a separate deploy identity, after the reviewer marks the row approved. No single actor can ship a redirect alone.

**Q: How does the agent know whether to recommend merge versus retire?**
A: It scores against backlinks, organic clicks, topical overlap with sibling URLs, and crawl health. Pages with preserved link equity and overlapping intent tend toward merge with a 301. Pages with no traffic and no inbound links tend toward retire with a 410. The reviewer can override either way and the override is logged on the row.

**Q: Can a previous quarter's audit decision be reopened?**
A: Yes. Rows are not deleted. A new cycle adds a fresh row keyed to the same URL, the agent reads the prior decision before drafting, and a reopened row carries a reference back to the original so the chain of reasoning is preserved.