Which pages matter most to the business?
An SEO audit that lists hundreds of issues in no particular order rarely leads to action. Start instead with the pages that bring enquiries, sales or product sign-ups. Export those URLs and group them by template: service, category, product, article, location. Location pages usually belong to local SEO and need checks of their own.
Add search performance from Search Console and conversion data where tracking is available. This shows where an issue costs the business something. A defect repeated across a high-value template deserves a different response from an isolated problem on an old article that hardly anyone reads. Note who is responsible for each template as well, because that tells you who will have to approve and carry out the fix.
Keep uncertain findings labelled as hypotheses until they have been checked. A confident recommendation built on a guess wastes development time and erodes trust in the whole audit.
What makes a finding actionable?
Each finding needs a reproducible example, the set of affected URLs, the proposed change and a person responsible. Without these, a developer receives a general complaint, not a task.
Note what has to happen first: content approval, a template release, a redirect map. Many SEO fixes depend on other work, and writing down the order of tasks prevents a fix from waiting for months on a dependency nobody mentioned.
Write findings in plain language. A product manager choosing between an SEO fix and a new feature needs to understand what is broken, which pages it affects and what is likely to change once it is fixed, without decoding crawler terminology.
Keep crawling, indexing and ranking apart. A URL found by your crawler is not necessarily in Google’s index, and an indexed page does not necessarily rank. Where the evidence is weak, schedule a short diagnostic task instead of prescribing a large rewrite.
You can see what such a finding looks like in our sample SEO audit report, based on a review of this website.
How will you know the fix worked?
A closed ticket is not the same as a verified improvement. Before the release, write down the technical check, the pages to inspect and the period over which you will measure.
Compare search data with a suitable baseline, and note other releases, seasonal changes and tracking changes during the same period, since any of them can explain a shift better than your fix. After deployment, review a sample of pages from every affected template, not just the one you tested. If a fix shows no visible effect, do not conclude straight away that it was wrong: first check that it reached every template and that enough time has passed for the pages to be recrawled.
Keep unresolved cases in the backlog together with their evidence and the decision still to be made. The next audit then starts from what you already know. Done this way, an audit becomes part of ongoing SEO services instead of a one-off report.
SEO finding record
A template to adapt to your own project.
| Field | What to record |
|---|---|
| Affected pages | Template, example URLs and approximate scope. |
| Evidence | Observed behaviour and a check anyone can reproduce. |
| Priority | Business importance, confidence and release dependencies. |
| Acceptance | Expected result, person responsible and follow-up date. |
Checklist: audit priorities
- List affected URLs and who is responsible for each template.
- Describe business impact, confidence and dependencies separately.
- Label unconfirmed findings as hypotheses.
- Attach a before-and-after verification method to each fix.
- Choose one achievable release and review its outcome.
Example: inconsistent canonical tags
Important category pages carry inconsistent canonical tags: some point to themselves, others to filtered versions. The first task is to confirm which URLs should be canonical and to inspect the rendered markup, because a script may change the tag after the page loads.
The release ticket then describes the template correction and lists representative categories to check after deployment. Writing extra text for these pages would not address this defect at all.
