Every site audit hands you a list that treats your pages as equals. Your visitors do not. The order you fix things in matters more than the count.
The list is not wrong, and neither is the tool that produced it. An audit scores each finding by what kind of problem it is — a broken link, a missing title, an image without alternative text — because the kind of problem is all a crawler can see. What it cannot see is which of your pages carry the business. To the audit, your busiest landing page and a press release from four years ago are the same thing: a URL with some findings on it.
The difference shows up the moment money is involved. A broken link on the page that brings in your customers costs you something today — a visitor arrives ready to enquire and hits a dead end. A missing alt text on a page nobody visits costs nothing yet. Both sit on the same list, often with the visible problem ranked below the invisible one, and a diligent person working top to bottom can spend a week making no commercial difference at all.
Which pages should I fix first after a site audit?
Start with the pages that measurably bring in your visitors and customers, and fix the most severe problems on those pages first. Join the audit's findings with your own per-page clicks from Search Console, then work severity-first within traffic bands: a medium problem on the page that earns your enquiries routinely outranks a low problem anywhere else, while a critical problem stays at the top wherever it sits.
Picture a typical result: forty findings across twenty pages. Sorted by severity alone, the top of the list is whatever the scanner considered most serious, wherever it happens to live. Sorted by traffic alone, the top is your busiest page, even if its only finding is trivial. Neither ordering is the one you want. The useful ordering is both at once — take the pages people actually reach, and within them, take the worst problems first. The same forty findings, the same amount of work, a completely different week.
This is not a new idea; it is how anyone would triage if they could hold both lists in their head at the same time. The reason it rarely happens in practice is that the findings live in one tool and the traffic lives in another, and joining them by hand is tedious enough that most people fix in whatever order the audit printed.
Should I use estimated or measured traffic to prioritise fixes?
Measured. Your own Search Console and analytics record what actually happened on each page — real clicks and real impressions — while a third-party tool's traffic figure is a model's estimate, which for smaller sites can be off by multiples. The two are different kinds of numbers and should never be presented as one, because a fix list built on estimates can send a whole afternoon of work to the wrong pages.
The distinction is worth being pedantic about. An estimate is a model's guess at your traffic, built from ranking positions and industry averages; it exists so you can size up sites you do not own, and for that job it is fine. For your own site you hold something strictly better: the actual record. Search Console tells you how many times each page appeared in results and how many times someone clicked it. Analytics tells you what visitors did after arriving. Neither number needs modelling, because both were counted. If you are new to reading them, the Search Console numbers that matter walks through which columns mean what.
Estimates behave worst exactly where prioritisation matters most: small and mid-sized sites, where a model extrapolating from thin ranking data can land several times too high or too low on any given page. An ordering built on numbers like that can be confidently, precisely wrong. So a simple rule keeps the exercise honest: when a measured number exists, it wins, and when a tool shows you both kinds, they should be labelled as what they are — measured or estimated — never blended into one column.
What if a page has no traffic data at all?
A page without measurement data is unknown, not worthless. New pages, pages Google has not surfaced yet and pages waiting for their season all show an empty column, and the empty column means no data rather than no value. That is why traffic weight should only ever promote a page up the fix list — it must never demote a problem below the severity it would carry on its own.
The benign explanations for an empty column are the common ones. A page published last month has had no time to earn clicks. A page Google has crawled but not yet chosen to show gets impressions of zero, not because it is bad but because it is queued. A page about a December product looks dead every June. In every one of these cases the measurement is silent, and silence is not a verdict.
This is the same misreading that catches people with keyword data, where a blank search-volume column gets read as "nobody searches for this" when it actually means the data source declined to answer. The safe design, in both cases, is asymmetry: let the numbers argue a page up the list, and let the absence of numbers argue nothing at all. A page with strong measured traffic gets its problems promoted; a page with an empty column simply keeps the ordering its problems would have anyway. Deleting or ignoring pages because their column is empty is how sites quietly amputate next year's growth.
Does traffic weighting mean I can ignore low-traffic pages?
No. The weighting decides what you do first, not what you do at all. A critical problem is critical everywhere — a security issue or a page that will not load needs fixing regardless of who visits it — and every finding keeps its baseline severity. Traffic weight reorders the queue; it does not shorten it.
The distinction matters because the two failure modes of prioritisation are mirror images. One is fixing in audit order and polishing corners nobody sees. The other is fixing in traffic order and leaving a serious problem to age on a quiet page — where "quiet" may just mean "quiet so far". A page that exposes something it should not, or that returns an error to everyone who tries it, is a problem in itself, independent of this month's click count. Severity is about what the problem is; traffic is about where it hurts first. You need both, and neither overrules the other in the wrong direction.
The method, concretely
The whole approach fits in four steps, and none of them requires anything you do not already have.
- Take the findings list from whatever audit you run, with each finding attached to the page it was found on and the severity it carries.
- Join it with measured clicks per page from your own Search Console, and analytics if you have it. Pages with data get a traffic band — high, medium, low. Pages without data are marked unknown, not zero.
- Fix severity-first within traffic bands. Critical findings first wherever they are. Then work down the bands: the medium problem on the money page before the low problem anywhere else, and unknown pages ranked by severity alone.
- Revisit monthly. Measurement accrues. The page that was unknown in March has a real number by June, and the ordering should move with it. Prioritisation is a standing habit, not a one-off sort.
If the join sounds like spreadsheet work, it can be — a findings export and a Search Console export share a URL column, and one afternoon of matching produces the ordered list. The reason we built the join into TrustCtrl is simply that the ordering goes stale, and a list that re-sorts itself as the measurements come in is the version people actually keep using.
What the same afternoon buys
The payoff is not that you fix more. It is that the same afternoon of work lands where it counts. Repairing the broken link on the page your customers actually use moves revenue this week; the identical repair on an unvisited page moves nothing yet. When the ordering follows measured traffic, effort and effect finally line up — and because organic traffic has a price you would otherwise pay for ads, the effect can be put in money terms, as what your SEO is worth in kroner and pence lays out.
Just as valuable is the discipline the method enforces. Measured beats estimated: your own record outranks anyone's model. Unknown beats assumed-zero: an empty column promotes nothing and condemns nothing. Hold those two lines and the prioritisation stays honest even as the numbers change under it. Let either slip and you are back to guessing — just guessing with a spreadsheet.