How do we run a technical SEO audit and decide what to fix first?

This is a technical SEO question — the kind that usually shows up from kickoff, hiring loop, engineering planning. It rarely has a one-line answer, because the honest version of “How do we run a technical SEO audit and decide what to fix first” is a shortlist of rival explanations, not a single cause. The job is to work through that shortlist with evidence and stop as soon as one of them is confirmed — not to write a report that mentions all of them.

The rival explanations

Direct answer: A raw crawl report cannot tell you what to fix first — five distinct root causes (crawl waste, canonical conflicts, JS rendering gaps, Core Web Vitals concentration, and internal-link depth) each point to a different fix, and a 400-row export mixes all five together.

Treat these as competitors, not a checklist. The point of naming five up front is to stop the first plausible-sounding one from becoming the story before the others have been checked.

• Crawl waste or soft-404s are starving important URLs of budget.
• Canonical / duplicate / parameter rules split equity.
• JS rendering or blocked assets hide primary content from Google.
• CWV or mobile usability is concentrated on money templates.
• Internal-link depth buries high-intent pages.

What the evidence has to show

Direct answer: A full crawl with JS rendering, the GSC Coverage/Experience/Enhancement reports, a Googlebot log sample, PageSpeed/CrUX field data on the top revenue pages, and an internal-link depth map are what turn a generic crawl export into a ranked, defensible register.

None of the five above survives on a hunch. Here is what actually needs pulling before any of them can be ruled in or out:

• Full crawl (Screaming Frog/Sitebulb; JS render a sample) + last XML sitemap.
• GSC Coverage, Experience, CWV, and Enhancement reports.
• Log-file sample (7–28 days) of Googlebot hits by directory.
• PageSpeed / CrUX field data for the top 50 landing pages by revenue.
• Internal-link in-degree and click-depth vs organic sessions.

The decision rule

Direct answer: Score each cluster as Impact × Confidence ÷ Effort. Ship only items that protect or recover indexable, converting URLs. Cosmetic HTML and footer-link tidy-ups wait until crawl, index, and CWV on money templates are green.

What to tell the people around you

Direct answer: The audit is not done until it is a scored, capped list engineering can actually schedule — not a 200-row dump that reads as equally urgent everywhere.

The analysis is not finished until it produces something a non-specialist can act on. That means naming the situation, the cost of getting the first move wrong, and a specific ask — not a summary of the investigation.

• Situation — We have a crawl, not yet a queue. Engineering capacity is finite; the audit must become a ranked register, not a 200-row dump.
• So what — Unprioritised audits stall. The business risk sits in a handful of templates, not in every warning a crawler prints.
• The ask — Agree the scoring rule; cap the first sprint at the top 8 tickets; give SEO access to staging and logs.

SEO writes the register. Eng estimates effort. Product accepts the cap.

How to act on this

1. Run the full crawl (with a JS-rendered sample) and pull GSC Coverage, Experience, and Enhancement reports for the same period.
2. Cross-reference against a 7-28 day Googlebot log sample and PageSpeed/CrUX field data for the top revenue-driving templates.
3. Score every finding as Impact × Confidence ÷ Effort, using the internal-link depth map to weight impact on already-indexable, converting URLs.
4. Cap the first sprint at a fixed number of tickets (the sample plan below uses 8) so the register survives contact with real engineering capacity.
5. Defer cosmetic HTML/footer-link findings until crawl, index, and Core Web Vitals on money templates are confirmed green.

Frequently asked questions

What if the crawler finds hundreds of issues on day one?

Expect that — the scoring pass is what turns hundreds of findings into a short, ranked register. A 400-row crawl export is a starting inventory, not a to-do list.

Should JavaScript-rendering issues always rank above other findings?

Only if they hide primary content or links on money templates. A rendering gap on a low-traffic page scores lower than a Core Web Vitals failure on your top converting template — the formula, not the finding type, decides.

Do we need log-file access to run this audit at all?

You can start without it, but crawl-budget-related findings (soft-404s, parameter waste) cannot be confirmed without a real Googlebot log sample — treat 'no log access' itself as the first ticket to raise.

Who should own the register once it's scored?

SEO writes and maintains the register; engineering estimates each ticket's effort; product accepts the sprint cap so the list does not silently grow past what can ship.

How often should this audit repeat?

A full audit on this cadence is typically quarterly, with the log-based crawl-waste check and CWV field data reviewed monthly since both drift fastest between full audits.

Can this scoring method be gamed by inflating a ticket's stated impact?

It's a real risk if scoring is self-reported without evidence — that's why each score should trace back to one of the five evidence pulls (crawl, GSC reports, logs, PSI/CrUX, link-depth data) rather than a subjective estimate.

What if two findings tie on the Impact x Confidence / Effort score?

Break the tie by which one touches more money templates, or run both in the same sprint if capacity allows — the formula is a prioritization aid, not a rule requiring strict sequential execution.

Sources

1. SEO essentials — Search Central
2. Understanding Core Web Vitals and Google search results
3. Search engine optimization — Wikipedia
4. Site map — Wikipedia

Where nqzai fits

nqzai runs this same rival-hypothesis framework against your own connected Search Console, Analytics, and audit history, and returns a keep / change / stop decision with the evidence named — including which of the explanations above it could not test, and what to connect to close that gap. No extra cost for the analysis itself; it reads measurements already on file.

Ask nqzai: “How do we run a technical SEO audit and decide what to fix first?”