Stop 2 of 8 · Weekly
The crawl to a ticket list
A Screaming Frog export becomes issues grouped by fix, priced by traffic, written as tickets the agency can pick up.
Why the crawl file goes stale in a folder
Priya runs Screaming Frog once a month across all six clinic sections. The export has 4,000 rows and 60 columns, and every row is technically an issue. Reading it top to bottom produces a list nobody can schedule, so it sits in Drive until the quarterly audit.
The job is not to find issues. The crawler already did that. The job is to collapse thousands of rows into eight or nine fixes, put a traffic number next to each, and write them so the agency can start without a meeting.
Group by fix, not by issue
One duplicate title is a typo. Ninety duplicate titles across six clinic sections is one templating fix in WordPress. That distinction is the whole stop. Ask for groups where the fix is identical, and a 4,000 row file usually becomes:
- The location page template writes the same title for all six clinics
- Old service URLs redirect twice before landing
- Condition pages have no self-referencing canonical
- Blog category pages are indexable and thin
- Two clinics have no internal link from the services page
Each of those is one ticket. Under each ticket sit the URLs.
Try this
[upload the Screaming Frog internal HTML export and this month's Search Console page export] Group every issue in the crawl by the single fix that resolves it, not by issue type. For each group give me: the fix in one sentence, how many URLs it covers, the clicks those URLs got in the Search Console file, and three example URLs. Sort the groups by clicks at risk. Ignore anything on a noindex or non-indexable URL and say how many rows you dropped for that reason.
Take the top five groups from that table and write each as a ticket for a WordPress developer who has never seen our crawl. Each ticket: a title under 12 words, what is wrong, the exact URLs or the template file to change, how to tell it worked, and how urgent it is with the reason. No jargon a developer would have to look up.
Looking at those five tickets, tell me which ones you cannot fully judge from a crawl file alone, and exactly what I should check in Search Console, in the live page, or with the agency before I send them. Be specific about which fact is missing.
That third prompt is the one to keep. A crawl shows structure, not consequence. It cannot see whether a page is indexed, whether the redirect chain came from a migration nobody documented, or whether the agency is already mid-change on that template. Claude will tell you which tickets rest on an assumption if you ask it to.