SEO

Technical crawl triage

Use when you have a raw crawl export and need to decide what to fix first.

technical-crawl-triage.md

Download .md

You are a technical SEO analyst triaging a site crawl. You are cautious and you never invent data.

Site: {{SITE_URL}}
Platform / CMS: {{CMS}}
Crawl export (paste rows or summary counts): {{CRAWL_DATA}}
Engineering capacity this sprint: {{DEV_CAPACITY}}

Task:
1. Group every issue into one of: Indexation, Duplication, Crawl waste, Response codes, Internal linking, Rendering, Speed.
2. Score each issue group on Impact (1-5), Confidence (1-5), Effort (1-5, where 5 is hardest).
3. Rank by (Impact x Confidence) / Effort, highest first.

Output a single table with these columns: Rank | Issue | Group | Affected URLs (count) | Why it matters | Fix (one sentence) | Owner (SEO / Dev / Content) | ICE score.

Below the table add a section headed "Fits in this sprint" listing only the items that fit {{DEV_CAPACITY}}.

Constraints:
- Use only counts present in the pasted data. If a count is missing, write "not in export" rather than estimating.
- Do not recommend generic advice such as "improve content quality" unless you can tie it to a specific URL set in the data.
- No em dashes. No opening paragraph setting the scene. Start with the table.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{SITE_URL}}
{{CMS}}
{{CRAWL_DATA}}
{{DEV_CAPACITY}}

Getting a better result

Paste the crawl summary counts rather than 5,000 rows - the ranking logic works better on aggregates.
Give a real capacity figure such as "8 dev hours" so the sprint section is honest.
Run it again after the fixes ship with the new crawl to see what actually moved.

Questions about this prompt

When should I run a crawl triage rather than just fixing what the crawler flagged?

When the crawler has given you more findings than you can ship. A crawl export will happily report thousands of issues, most of which change nothing. The point of triage is to sort them by what actually costs traffic against what your team can realistically build this sprint, which is a judgement the crawler does not make.

What do I need in front of me before running it?

A crawl export and an honest capacity figure. Paste the summary counts rather than thousands of rows, because the ranking logic works on aggregates and raw rows just consume the context window. Naming a real number such as eight developer hours is what makes the sprint section usable rather than a wish list.

What does it give me back?

An ordered fix list with reasoning, split into what fits your stated capacity now and what waits. The ordering matters more than the list: shipping the third-most-important fix first is how technical SEO work ends up looking ineffective.

How do I know the fixes worked?

Re-crawl after they ship and run the prompt again on the new export. Comparing two triage runs shows what actually moved, which is the part most teams skip. Without it you are assuming the fix worked because it was deployed.