In this guide · 8 parts
An SEO audit is only useful if it tells your team what to change next. Most audits stop one step short: they list hundreds of warnings at the same volume, and the team fixes the easy ones, or none at all.
This guide turns findings into a short, ordered list. Each issue gets a page group, a priority band, an honest effort estimate, an owner who can ship it and a check anyone can run. Each of the six steps below fills one column of the worksheet, so by the end you have a register your developers can work from.
Name the decision each finding affects
A finding without a page group is just a tool warning. Before you estimate impact, write down which pages the issue touches and what those pages are for: a category that should rank, a product page that should sell, a location page that should bring calls.
Then confirm the pattern exists. One broken canonical is an anecdote. The same canonical on 3,800 filtered URLs is an issue. Sample enough URLs to say how many pages share the problem, and on which template.
Keep three fields apart
Mixing them is how a guess becomes a fact by the next meeting. If the diagnosis turns out wrong, the observation still stands.
Sort issues into bands, not scores
Numeric scores look precise and start arguments about decimals. Three bands are easier to agree on and easier to act on. Every issue goes into exactly one.
Count the whole effort
Teams underestimate effort because they only count the build. Every fix has three parts, and the first and the last are often the longest.
Record dependencies before you set dates. A redirect fix that needs a routing change waits for the routing change, put both in the register and link them, so nobody promises a date that depends on another team.
Give every issue an owner who can ship it
The person who writes a finding is rarely the person who fixes it. Assign each issue to someone with the access and the authority to change it, and name a person, not a team. “Dev team” is not an owner.
| Kind of issue | Typical owner | Needs access to |
|---|---|---|
| Templates, redirects, rendering | Developer | Code repository, release pipeline |
| Titles, copy, internal links | Content editor | CMS |
| Robots rules, sitemaps, Search Console | SEO lead | Search Console, server config |
| Business profiles, listings, feeds | Marketing ops | Business Profile, Merchant Center |
Write acceptance checks anyone can run
An acceptance check is how you know the change shipped correctly. It has to be specific enough that someone who didn’t write it can run it and get the same answer.
canonical → /shoes/
no noindex in HTML or headersQA runs it on 10 sample URLs on release day.
Does your check name all four?
0 of 4 in your checkVerify the release first, then watch search
Release verification and search results are two different moments. Check the fix on representative URLs as soon as it ships. Search changes come later, and you can only read them against a baseline dated before the release.
- Phase 1Day 0-2Release check
- Run every acceptance check on the sample URLs
- Log pass or fail with the date in column F
- Reopen anything that fails, with what you saw
- Phase 2Weeks 2-8Search observation
- Compare against the baseline you dated before release
- Watch crawl stats, indexed pages and impressions for that page group
- Note other releases in the same window that could explain the change
Meeting the technical requirements makes a page eligible to be indexed. It doesn’t guarantee that it will be.
Paraphrased from Google Search Central [1]
That is why a passed check and a search result are recorded separately. The check proves the work was done. The search result tells you whether it was the right work.
In the worksheet: column F · Verified onExample: a three-issue register
Three rows from an ecommerce site, written the way they should reach a developer. The blocker ships first, even though the title fix is easier.
| Issue | Band | Owner | Acceptance check |
|---|---|---|---|
| Category pages carry noindex after the last releaseCategories · 240 URLs | Release blocker | Developer | GET 10 sample categories → 200, no noindex in HTML or headers |
| Filter URLs canonicalise to themselvesFilters · ~3,800 URLs | Next batch | Developer | GET 10 filter URLs → canonical points to the parent category |
| Product titles drop the model nameProducts · 1,200 URLs | Next batch | Content editor | 20 sample titles start with brand + model |
Put the guide into a scope
If your team has the time, the worksheet is enough. If you would rather start from a finished register, with evidence, tickets and a re-check after release, this is the work we do.
Download the blank Audit Triage Matrix CSV ↓
Get the Audit Triage Matrix
A blank CSV version is available above. Request help applying the worksheet here; additional formats and response dates are subject to confirmation.
Thanks. We’ll email you the Audit Triage Matrix within [X] business hours. What’s next →
Free. We email the worksheet, and the newsletter only if you tick the box. Privacy PolicyCommon questions
01How many issues should go into the first release?
As many as your team can finish and verify in one cycle. A short release that ships beats a long list that stalls.
02What if we can’t reproduce an issue?
Keep it in the register as unconfirmed, with what you tried. It can’t be a release blocker until it is confirmed.
03Should we start with the quick wins?
Only if they don’t jump the queue over blockers. A low-effort fix on a page group that doesn’t matter is still low priority.
04Who should run the acceptance check?
Ideally someone other than the person who made the change. This is why the check has to be written so anyone can run it.
Sources
- [1]Google Search Central, Google Search technical requirements. Accessed 8 Oct 2026.
- [2]Google Search Central, SEO Starter Guide. Accessed 8 Oct 2026.
What’s changed
- First published.
- [DATE][What changed and why, one line per update]
