What should I fix first after an audit?

The site or a section of it returning errors, an expired certificate, a redirect loop, or a hostname that does not resolve.

A `noindex` or a robots.txt block on pages that should be indexed. These cost nothing today and everything over the following weeks.

A canonical tag pointing the whole site at one URL, which consolidates it into a single page in search results.

These are rarely numerous and they are usually a single configuration change each. Doing them first is not prioritisation so much as triage.

A site returning 5xx to crawlers while serving visitors normally belongs here too, because the damage accrues invisibly until pages start being dropped.

Findings that come from a template or a server configuration multiply by the number of pages, and fix by the same multiple.

Missing security headers, absent compression, no caching policy, a missing viewport tag, a missing `lang` attribute: each is one change at the root.

Duplicated titles or meta descriptions across a template are the same shape — the fix is in the template, not in 400 pages.

This tier usually produces the largest visible improvement for the least work, which is why it comes before anything requiring editorial effort.

Check whether the finding really is template-level before committing to it. A header missing on one route and present on the rest is a routing problem, not a configuration one.

Weight by traffic. A finding on your highest-traffic template matters more than the same finding on an archive nobody reaches.

Weight by journey. A broken form label on the checkout is not comparable to the same finding on a terms page.

Accessibility findings that block a task — an unreachable control, a focus trap, an unlabelled form field — belong here rather than in a general accessibility backlog.

Cross-reference the audit with your analytics before this tier. Without that, you are sorting findings by how the report presented them.

Informational findings, detected technologies, and items reported as not publicly verifiable. These are context, not work.

Findings on pages that are already excluded from search deliberately.

Cosmetic content issues — a slightly long title, a marginally low contrast ratio on a decorative element — which are real and rarely urgent.

Writing these down as deliberately deferred is worth more than leaving them in an undifferentiated backlog, because it stops them being re-discovered every quarter.

VeriFixScan reports each finding with an impact, an urgency and a difficulty, which is three sort keys rather than one severity label.

Its score lists the findings that cost the most points, worst first, which is a reasonable starting order for the first two tiers.

It damps duplicates: several findings on one subject are charged progressively less, so a single misconfiguration producing four related findings is not four separate priorities.

It reports coverage — the share of applicable checks it could actually verify — so a clean area with low coverage is visibly different from a clean area with high coverage.

None of that knows your traffic, so the third tier is still yours to order.

Fixing the easiest findings first because they clear quickly. It produces motion and leaves the expensive problems untouched.

Chasing the score. The number follows the findings; optimising for it optimises for one tool's weighting.

Treating every critical as equally urgent. A critical on a page with no traffic and no links is not an incident.

Shipping twenty fixes at once, which makes it impossible to attribute any improvement or regression afterwards.

Re-running the audit before the first tier is deployed, which produces a second report identical to the first and a sense that nothing works.

Deferring everything that needs a decision from someone else. Those items do not become cheaper by waiting, and they are usually the ones with the longest lead time.