SEO Technical Audit: Finding the Nine Issues That Move Anything

What it does

• Crawl the site. The raw material — every issue in every class comes from the crawl data.
• Nine issue classes. The distilled list of things that actually matter: crawlability, canonicals/duplicates, index bloat, speed, internal linking depth, orphans, structured data, mobile, redirects.
• Search Console verification. Every candidate issue is confirmed against real impressions and clicks before it costs time — the anti-chase discipline.
• Impact × effort prioritization. Fixes are ranked by what they will move against what they cost to do.
• Prioritized fix list. The deliverable: a short list a developer can act on without re-reading the crawl.

When to use it

• Traffic is flat and content is good: Run this to find the structural cap — usually index bloat, canonicals, or depth.
• Before a big content push: Fixing the architecture first means the new content can actually get crawled and cited.
• After a migration or redesign: Redirects, orphans, and canonicals all break in migrations — verify the nine classes before launch day.
• As a monthly/quarterly check: Iterative runs take an hour and catch drift before it compounds.

The methodology

1. 1

   Crawl the site

   Run a full crawl with Screaming Frog or SE Ranking. Export the raw data; you are not reading it yet — you are loading the classes.

   1 hour for most sitesScreaming FrogSE Ranking
2. 2

   Triage the nine issue classes

   Work through the nine: crawlability (blocked/soft-404 pages), canonical conflicts and duplicate content, index bloat (thin or useless pages being indexed), page speed, internal linking depth, orphan pages, structured data errors, mobile issues, and redirect chains/loops. For each class, note the candidates from the crawl.

   1–2 hours
3. 3

   Verify against Search Console

   For every candidate, check whether the affected pages actually receive impressions and clicks. An issue on a page nobody lands on is not an issue. This is where the 400 collapses to the nine — and the nine collapse to the ones that matter.

   1 hour
4. 4

   Score impact × effort

   Rank the survivors: impact (what the fix should move — crawl coverage, clicks, speed) by effort (dev time, risk, dependencies). Fixes that are high impact and low effort go first; everything else is scheduled or dropped.

   30 minutes
5. 5

   Write the fix list

   Produce the prioritized list: issue, evidence, expected effect, and effort. One page. A developer can execute from it without reading the crawl.

   30 minutes

Common mistakes

• Fixing everything the crawler flags — The 400-issue approach spends weeks on things that move nothing and delays the nine that do. The Search Console verification step exists to prevent exactly this.
• Chasing the checklist consensus — Generic SEO checklists push low-value fixes. The nine classes are the filter — everything else is noise until evidence says otherwise.
• Ignoring index bloat — Thin pages dilute crawl budget and dilute topical authority. For most content-heavy sites this is the single biggest cap.
• No baseline before fixing — Without pre-fix metrics you cannot prove the fixes worked, which means you cannot defend the time spent.

Output

A one-page prioritized fix list: the issues that matter, the evidence they are real, the expected effect, and the effort each costs.

Next steps

After the fixes land, run can-ai-find-you to see what the answer engines now find, then seranking-dataforseo to build the calendar on a clean foundation.

Time & resources

Moderate — the crawl is easy; the triage discipline is what the skill trains.

Take it with you