Learn · Technical SEO · Beginner
Take a long list of audit findings and turn it into a few clear tickets with evidence and a test, so your developer can build each fix and you can check it worked.
By Dean Cruddace · 1 hour to do · Updated · Last reviewed
A site audit, often a crawl of the whole site, can produce thousands of rows. The hard part is not finding problems but getting them fixed. A list of rows is hard for a developer to act on, so it tends to sit unread.
This guide is a practical routine rather than a Google rule: group the rows by cause, write each cause as a small ticket with evidence and a test, and check the result after release. Everything you will check in Google's tools below comes from Google's own documentation.
Google describes technical issues as errors that can prevent it from crawling, indexing or serving your pages. It says they can affect a whole site or single pages, and gives a misplaced noindex tag as an example. See Debugging drops in Google Search traffic. A finding like that is worth fixing, but only if the person fixing it can see the evidence and know when it is done. Fixes do not promise any change in rankings or traffic.
Sort your export by the type of problem, then ask what is producing it: a page template, a plugin setting, a server rule. Thousands of addresses with the same fault usually share one cause. Hypothetical example: 6,800 pages have a title that is only the site name, and on inspection three templates are responsible. That is three tickets, and 6,800 is how you will measure the fix.
You will know it worked when Your long list has become a short list of causes, each with a count of affected addresses.
For each cause pick three or four example addresses from different sections. Capture the exact line of page source, or the crawl row, that shows the problem. Then inspect one example in Search Console: paste the full address into the inspection bar to see Google's indexed version and, for a noindex rule, the HTML Googlebot received. Google recommends the URL Inspection tool for checking that a noindex rule is visible. See Block search indexing with noindex and URL Inspection.
You will know it worked when Someone else can follow your notes and see the problem in two steps.
Link the Google documentation that covers the point, and keep to what it says. For example, for a noindex rule: Google says it drops the page entirely from its search results once it crawls and sees the rule. Do not promise a ranking effect.
You will know it worked when Each ticket has one sentence of reasoning with a documentation link, and no promise of traffic.
Describe the change specifically enough to build, without dictating how. Then write the test that proves it is done, using something observable. Hypothetical example: a re-crawl of the category section returns no noindex tags, and URL Inspection on the three examples no longer shows a noindex rule. Add the risk and who should review it before release, such as filtered pages that must keep their noindex.
You will know it worked when The ticket holds a title, location, evidence, reason, change, test, risk, priority, owner and date.
After release, re-run the same crawl on the affected section and compare it with the count in the ticket. Then live-test a few example addresses in URL Inspection. Google says that if you fixed all instances of an issue, you can run the live test on a few pages, then click Validate fix to tell Google. Remember that the indexed result shows the last crawled version, so it may lag behind the live page. Google also notes that, for noindex, it may take months to revisit a page, depending on its importance.
You will know it worked when The re-crawl matches the acceptance test, and live tests on the examples show the fixed page.
Give every ticket a status, an owner and a date, and review stuck ones regularly. Track how many are open and how long each takes to close. Use the Page indexing report to keep an eye on pages Google excludes; it can show pages from which Googlebot extracted a noindex rule. See Page indexing report.
You will know it worked when You can say how many findings are open, closed and stuck, and why.
Go deeper
Send Dean the findings and tell him who would build them. Specifying the SEO requirements and reviewing the result is one way Cultured Digital works with development teams.
