The problem with a long findings list
An audit usually ends with more items than anyone can finish: missing descriptions, slow pages, thin articles, broken links, confusing menus. A list like that can feel more discouraging than useful. The step between finding problems and fixing them is deciding what to do first, and this is where many reviews stall.
This article describes a simple way to turn raw findings into a ranked improvement list. It uses two judgments for each item, how much effort it takes and how much it is likely to help, and a few sanity checks. The ideas are approximate by design. You are making informed guesses, not calculating certainties.
Step 1: Clean and group the findings
Start by writing every finding as a short, specific line. “Site is slow” is too vague; “product images on the main category page are very large files” is something you can act on.
Then group related findings. Fifty broken links are one task, not fifty. Pages with the same missing element can usually be handled together. Grouping reduces a daunting list to a handful of work packages. It also reveals patterns: if many problems trace back to one template or setting, fixing that source is better than patching individual pages.
Discard or park items you cannot verify. If a tool flagged something and you cannot explain why it matters for your visitors, mark it as “check later” rather than letting it clog the list.
Step 2: Estimate effort
For each group, estimate effort in rough terms: small (minutes to an hour), medium (a day or so), or large (many days or outside help). Count more than just the hands-on time. Consider whether you need approval, whether a developer is involved, and whether testing is needed.
Be honest about your own skills. A task that is small for a developer may be large for you, and a risky change you do not fully understand deserves a higher effort rating because of the cost of mistakes.
Step 3: Estimate likely benefit
Next, judge how much each item could help. Ask questions such as:
- Does it block important pages from being found or used? Problems that stop pages loading or being indexed generally outweigh cosmetic ones.
- Does it affect pages that matter to your goals, or minor pages nobody visits?
- Does it affect many pages or one?
- Does it make the experience noticeably worse for real visitors?
Rate each group as low, medium or high. Remember that this is a judgment, and search engines do not tell us exactly what any single fix will do. Where you are unsure, rate conservatively.
The ideas covered in the article on fix prioritization overlap with this step. The approach here focuses on starting from audit output.
Step 4: Sort into four groups
Place each work package into one of four buckets:
- Quick wins: low effort, medium or high benefit. Do these first.
- Major projects: high effort, high benefit. Plan them, and schedule them once quick wins are done.
- Fill-ins: low effort, low benefit. Do these when convenient, especially if you are already editing the same pages.
- Question marks: high effort, low benefit. Usually leave these off the list unless something changes.
A hypothetical example may help. Suppose an audit of an imaginary small bakery site finds four things: the contact page is missing from the main menu, several pages have identical titles, a large set of old news posts are thin, and the whole site is on an outdated design. Adding the contact page to the menu is small effort and clearly useful for the goal of getting orders: a quick win. Rewriting duplicate titles is small to medium effort with moderate benefit: also near the top. Reviewing the old news posts is medium effort; some may be improved, some removed, so it is a project to schedule. The redesign is large effort and its benefit is uncertain, so it falls into the question-mark group for now. The numbers here are not real; the point is the reasoning.
Step 5: Check dependencies and risks
Some work has to come first. If you plan to restructure pages and also rewrite them, do the restructuring decision first so you do not rewrite pages that will be merged or removed. Pruning or merging weak pages before polishing them is one example of this ordering.
Flag any item that could cause harm if done badly, such as changing addresses or blocking pages from crawlers. These need a backup and careful testing beforehand, and they often belong later in the list, not because they matter less but because they need preparation.
Step 6: Turn the list into a schedule
Take the top items and give each a rough time slot. Limit work in progress; a short list finished beats a long list started. Many people find three to five items per month manageable, though this varies with available time.
Record the plan in your log, with an expected outcome and a date to recheck. Without this, you will not know whether the work helped, and the list will not improve over time.
Step 7: Revisit the ranking
Priorities change. New findings arrive, a fix turns out harder than expected, or a goal shifts. Review the list on a regular schedule, perhaps monthly, and re-sort it. Move finished items to a done list so you can see progress.
Pitfalls to avoid
- Treating every warning equally. Severity differs enormously.
- Always starting with the easiest tasks. Quick wins are good, but not if they distract from a blocking problem.
- Overconfidence in estimates. If a fix has been on the list for months because it was “quick,” you probably misjudged something.
- Never closing the loop. A ranked list is only useful if you act on it and check the result.
A ranked list will not guarantee better results, but it ensures your limited time goes to the problems most likely to matter.