SEO Audit-to-Ticket

SEO Audit-to-Ticket

You are running one execution of a recurring SEO audit. Your job is not to write a report. Your job is to crawl the site, score what you find, and leave the company's Issues board with the right tickets, on the right people, evidence attached — while never re-filing the same problem twice and never letting a risky fix ship without a second set of eyes.

This skill assumes you already have working access to your company's Paperclip coordination surface — whatever lets you list agents, create and search issues, post comments, and (if configured) request an approval. This document tells you what to do with those capabilities and how to decide, not which specific calls to make — your existing Paperclip access already knows that part. If any capability mentioned below isn't available to you (e.g. you can't request approvals), fall back to the nearest equivalent (post a comment tagging a human) and note the gap in your run summary.

Read this whole document once before your first run. After that, you're applying the same rules every time — that consistency is the entire point of automating this.

Files in this skill

• SKILL.md (this file) — the run procedure and the decisions you make every time.
• references/check-ids.md — the canonical checklist: every check_id, its exact detection criteria and thresholds, its default severity and trade, and the list of high-risk check_ids that must go through the review gate. This is the single source of truth the other files point back to.
• references/agent-routing.md — the full keyword-matching table, tie-break order, and fallback chain behind Section 4, plus a worked example.
• references/ticket-template.md — the exact title/body format for every ticket, including the Check-ID: line that makes de-duplication possible, and how to run the de-dupe search itself.
• references/run-summary-template.md — the recurrence/aging notation for tickets that keep coming back, and the exact end-of-run summary template.

Load the reference files as you reach the section that needs them — you don't need all four in front of you for every step.

1. What a run looks like, end to end

1. Resolve your routing map — find out who in the company can take technical fixes and who can take content fixes (Section 4). Do this once per run, not once per finding.
2. Crawl and check the site against the fixed checklist (Section 2).
3. Score every finding by severity (Section 3).
4. De-dupe against what's already open on the board (Section 5).
5. Open one ticket per genuinely new finding, assigned via your routing map, with evidence attached.
6. Flag high-risk findings for the review-gate treatment (Section 6) instead of a normal ticket.
7. Respect your budget (Section 7) — stop opening new tickets before you blow through it, and summarize what's left instead.
8. Post a run summary (Section 8) so a human can see what happened in one place without reading every ticket.

If you only do steps 2–3 and stop, you have produced exactly the kind of audit this skill exists to replace. Steps 4 through 8 are not optional cleanup — they are the reason this is a skill and not a report template.

2. The checklist

Run this identically every time. Consistency across runs is what makes month-over-month comparison possible — an agent that invents new checks each run cannot tell "regression" from "different lens."

The checks fall into five groups — indexability, link health, on-page, structured data, and Core Web Vitals performance. The exact detection criteria, numeric thresholds, and stable check_id for every single check live in references/check-ids.md — that file is what you actually work from, not the summary below. In short: