A crawler such as Screaming Frog’s SEO Spider can turn one crawl into thousands of rows. An experienced person can read those rows and find real problems, and a few days later a document lands with the client. Months afterwards, most of its recommendations are still waiting. This is the most common failure in technical SEO, and it is seldom a failure of analysis. It is a failure of hand-over: the findings reach the people who have to act on them in a form they cannot act on.
Why audits stall
- Too many findings with the same weight. A report that lists two hundred issues treats a site-wide indexing fault the same as a missing alt attribute on one image. Readers cannot tell what matters, so they start with what is easiest.
- Organised by URL. Four thousand pages with the same problem are one problem. Presented as four thousand rows, they are impossible to ticket.
- No evidence. If a developer cannot reproduce the issue in two steps, it goes to the bottom of the pile or comes back as a question.
- No owner and no date. A recommendation that belongs to “the team” belongs to nobody.
- No definition of done. Without a test, nobody can say whether a fix worked, so nobody closes the item.
- Written for SEOs. The people implementing the change need a specific instruction in the language of their own work, not a description of a ranking factor.
Group by cause, not by URL
Almost every large-scale finding has a single cause: a template, a component, a plugin setting, a server rule. A missing meta description on four thousand product pages is usually one template field that is not populated. The fix is one change, not four thousand edits, and the number of affected URLs tells the reader how big the problem is, not how many problems there are.
A hypothetical example: a crawl shows 6,800 URLs with a page title that is just the site name. Grouped by cause, that might become three findings: the article template ignores the title field, the category template has no title rule at all, and a pagination rule overrides titles on page two onwards. Three changes, each with a precise scope, and the 6,800 is the measure of success.
What a good ticket contains
- A title that states the outcome, for example “Category pages are indexable”, not “Check robots settings”.
- Where it happens: the template or component, and three or four example URLs.
- Evidence: a screenshot, a crawl export row, or the exact page-source line, and how to reproduce it.
- Why it matters for search, in one sentence, linked to Google’s documentation where it covers the point.
- The change: specific enough to build, without dictating the implementation.
- The acceptance test: how both sides will know it is done, for example “a crawl of the category section returns no noindex tags”.
- Risk and review: what could go wrong and who should look at it before release.
- Priority and dependencies: where it sits relative to other work, and what has to happen first.
A worked ticket (hypothetical)
To make the structure concrete, here is a made-up finding written both ways.
The version that stalls: “Noindex found on category pages. Fix.”
The version that ships:
- Title: Category pages are indexable.
- Where: the category template. Examples: three category URLs from different sections.
- Evidence: the page source of each example contains a robots meta tag with noindex. A crawl of the category section shows the same tag on all of its URLs.
- Why it matters: Google cannot show a page it has been told not to index, so these pages cannot appear in search results.
- The change: remove the noindex from the category template, keeping it only on filtered and internal search URLs.
- Acceptance test: a re-crawl of the category section returns no noindex tags, and URL Inspection on the three examples shows the page as indexable.
- Risk: filtered URLs must keep their noindex. Review by the SEO before release.
The second version takes a developer a few minutes to read and nobody has to ask a question before starting. It also contains its own test, so the person who raised the ticket can close it without another conversation.
Different readers need different things
- Developers need the scope, the evidence, the exact change and the test. They do not need an explanation of ranking theory.
- Content teams need briefs: which pages, what is wrong, what a good version looks like, and how long it should take.
- Decision-makers need a short list: what is being done, what it will cost, what they are being asked to decide, and what the expected effect is.
An audit that serves all three at once serves none of them, so the same set of findings usually has to be written up three ways.
Two numbers worth tracking
Two simple measures show whether audits are working. The first is how many findings are open and how many are closed, over time. The second is how long a finding takes to close once it has been raised. If the first only ever grows and the second keeps lengthening, the problem is in the hand-over, not in the analysis.
Evidence beats opinion
Google’s guide to debugging traffic drops describes technical issues as errors that can prevent Google from crawling, indexing, or serving your pages
, and notes that they can be site-wide or affect single pages, such as a misplaced noindex tag. That is the sort of finding where evidence settles an argument. A page-source line showing the tag, plus the URL Inspection result for a sample page, takes a developer from “is this real?” to “where is it set?” in minutes.
Verify after release
“Done” means checked, not merely released. After a change goes live, re-crawl the affected section and compare the counts with the baseline in the ticket. Inspect a sample of URLs in Search Console to confirm what Google sees. Record the date, because crawling and reindexing take time and the evidence of improvement will arrive later than the release.
Keep the audit alive
An audit is not finished when the document is delivered. It is finished when its findings are closed. That needs a place where every finding has a status, an owner and a date, and a regular review that asks about the ones that are stuck. Items that stay open for weeks often have a missing dependency, an unclear instruction or a disagreement about priority, and each of those can be fixed once someone looks at it.
This hand-over is the part of the work that SEO Ops is built around: a Screaming Frog import for the technical data, and recommendations that become tasks.