A Technical SEO Audit You Can Actually Act On

You run a technical SEO tool against your site and it hands you 217 issues. Missing alt text, a meta description that is four characters too long, an H1 on one template that should be an H2, a redirect somewhere, a page that loads in 2.6 seconds instead of 2.1. They are all flagged in the same red, with the same little warning icon, in one long scrollable list. So you do what most people do with a 200-issue export: you skim it, feel vaguely bad, fix three easy ones, and close the tab. Nothing about your rankings changes, because the three you fixed were never the three that mattered.

The export is not the problem. The flat severity is. When everything is flagged at the same weight, the tool has quietly handed the entire prioritization job back to you, and prioritization is the hard part. A better audit is not a longer list. It is the same findings sorted into a strict order of impact, so you work top down and stop when the return drops off. Here is the order, and why it is the order.

Audit in priority order, not alphabetical

There is a natural hierarchy to technical SEO, and it is not a matter of taste. A page that cannot be indexed cannot rank, no matter how fast it loads or how clean its heading structure is. A page that gets indexed but buries its signals under redirect chains and duplicate parameter URLs ranks worse than it should. A page that indexes fine and keeps its signals tight but loads like molasses loses a little at the margin. Notice the shape: each tier only matters if the tier above it is already handled. That dependency is what gives you the order.

So you audit in three passes, in this sequence: what blocks indexing, what wastes crawl budget and dilutes signals, and what hurts the page experience. Then you note everything else and park it. You do not touch a Core Web Vitals number until you are certain the page is actually in the index, because optimizing the load time of a page Google refuses to index is the SEO equivalent of waxing a car with no engine.

Pass one: what blocks indexing

This pass answers one question for your important pages: can Google index this, yes or no? Everything here is binary and brutal. A stray noindex tag, a Disallow in robots.txt that covers more than you meant, a canonical that points at the wrong URL (or at a different page entirely), a sitemap that 404s or lists dead URLs, a page returning a 200 when it should 301 or a soft 404 that should be a real 404. Any one of these can silently erase a page, or a whole section, from search.

Check it directly. For your top templates and money pages, run them through the URL Inspection tool in Search Console and read what Google actually says: is it indexed, what canonical did Google pick, was it allowed to crawl. That is ground truth, not a guess from a third-party crawler. For status codes and canonical and noindex at scale, run a crawl (Screaming Frog, Sitebulb, or any crawler you like) and filter to the pages returning anything other than a 200, plus every page with a noindex or a canonical that does not point to itself. Pull your sitemap and confirm every URL in it returns 200 and is meant to be indexed. If pass one finds something, you stop and fix it before you look at anything else. This is the tier where a single bug outweighs the other 200 issues combined.

Pass two: crawl waste and diluted signals

Now the pages index fine. Pass two asks whether you are spending Google's attention well and keeping your ranking signals concentrated. This is where redirect chains live (a link that hops through three 301s before landing), where parameter duplication quietly creates five URLs for one page of content (?sort=, ?ref=, session IDs, tracking junk), where thin and orphan pages sit with no internal links pointing at them, and where your most important pages are buried six clicks deep instead of two.

None of this stops a page from ranking outright, the way pass one does. It bleeds you slowly. Crawl budget gets spent re-fetching near-duplicate parameter URLs instead of your new content. Link equity that should flow to a key page leaks through a redirect chain or never arrives because the page is orphaned. You find this in the same crawl you already ran: sort by redirect hop count, group by URL pattern to spot parameter duplication, list pages with zero inbound internal links, and look at crawl depth for the URLs you care about most. Fix the chains, canonicalize or block the parameter duplicates, link the orphans in or remove them, and pull the deep important pages closer to the home page.

Pass three: page experience (and field beats lab)

Only now do you look at speed and stability, because only now is it the thing standing between a properly indexed, well-linked page and a slightly better position. This is Core Web Vitals: Largest Contentful Paint (does the main content show up fast), Interaction to Next Paint (does the page respond promptly when tapped or clicked), and Cumulative Layout Shift (does stuff jump around as it loads).

The trap here is measuring it wrong. Lighthouse and the lab tools run one simulated load on a throttled connection and give you a score. That is useful for debugging, but it is not what Google uses for the page experience signal. Google uses field data: real Chrome users on real devices and real networks, aggregated in the Chrome User Experience Report (CrUX). A page can score 95 in Lighthouse and still fail CrUX in the field because your actual visitors are on mid-range phones and flaky mobile data. So read the field first. The Core Web Vitals report in Search Console is CrUX data grouped by URL pattern, and PageSpeed Insights shows you the CrUX field numbers up top and the Lighthouse lab numbers below. Diagnose with the lab, but judge pass-or-fail by the field.

Note the rest, then stop

Everything that did not make the three passes goes in a fourth bucket labeled "noted." Alt text, the slightly-too-long meta description, the occasional out-of-order heading, the image that could be 30KB smaller. These are real, and on a slow week they are fine cleanup work, but they are not why a page is or is not ranking. Write them down so they are not lost, then stop the audit. The discipline of parking the small stuff is what keeps the audit something you finish and act on instead of a 200-line list you skim and abandon.

A scaffold to run the passes

If you have a crawl export and Search Console access, you can have an AI walk the passes in order and refuse to jump ahead. Paste something like this and give it the data:

Audit this site's technical SEO in strict priority order. Do NOT
move to a later pass until the earlier one is reported.

PASS 1 (indexing): From the crawl + URL Inspection data, list every
important URL that is noindex, robots-blocked, canonicalized to a
different page, returns a non-200 status, or is missing from the
sitemap. These block ranking. Report these first, on their own.

PASS 2 (crawl waste): Then list redirect chains (2+ hops), parameter
duplicate URL groups, orphan pages (no internal inlinks), and key
pages deeper than 3 clicks.

PASS 3 (page experience): Then, using the CrUX FIELD data (not the
Lighthouse lab score), list URL groups failing LCP, INP, or CLS.

PASS 4 (noted): Everything else (alt text, meta length, minor
headings) goes in a short "noted, low priority" list. Do not pad it.

For each finding give the fix and the expected impact. Rank within
each pass by how many important URLs it affects.

The point of the scaffold is the same as the point of the method: it forces the indexing question to the front and keeps the cosmetic stuff in its place at the back, so what comes out the other end is a short ordered fix list instead of another export.

The method, packed

This technical audit is one of 31 skills in the SEO Skillpack. On a full-site audit the pack convenes a panel (technical, on-page, schema, and Core Web Vitals) and folds their findings into one client-ready deliverable, in priority order, and it reads your live Search Console data when you connect it so the indexing pass is checking ground truth instead of guessing from a crawl. That is the convenience the pack buys you. The prioritization method itself, indexing first, crawl waste second, page experience third, note the rest, is free to use whether you ever buy anything. Run your next audit in that order and it will be the first one you actually finish.