A technical SEO audit that fits in an afternoon

A technical audit is not a completeness exercise. Ninety per cent of the traffic loss on a normal site comes from a handful of defects that are individually boring and collectively fatal, and almost none of them show up as an error anywhere. The order below is the order in which things cost money.

Layer 1: can it be indexed at all

Everything else is pointless if the answer here is no. Take five representative URLs — homepage, a category, a product or service page, an article, a page you recently added — and check each one:

1. Does it return 200? A page that 301s to a near-equivalent is fine; a page that 302s in a loop, or 200s with an error message in the body, is a soft 404.
2. Is there a robots meta or X-Robots-Tag header with noindex on it? This is the single most common catastrophic defect, and it is usually a staging setting that shipped.
3. Is the path allowed in robots.txt? Remember robots.txt is most-specific-match, not first-match, so a narrow Allow beats a broad Disallow regardless of order.
4. Does the canonical point at this URL, or at a different one? A page canonicalising to another page is a page asking to be dropped.
5. Is it linked from anywhere on the site? An orphan is discoverable only through the sitemap, and crawlers weight sitemap-only URLs lower.

Layer 2: the three quiet killers

A canonical pointing at the wrong URL

Templated canonicals go wrong in predictable places: paginated pages all canonicalising to page 1 (which deindexes pages 2+ and everything only linked from them), filtered pages canonicalising to a filter that no longer exists, and localised pages canonicalising to the English version — which asks the engine to drop every translation you paid for.

The rule: every indexable page canonicalises to itself, at the URL you actually want indexed, with consistent casing, protocol, trailing slash and no tracking parameters.

Redirects that fire for crawlers

Language or country redirects based on IP or Accept-Language are the most damaging thing an international site does to itself. The crawler arrives at the canonical it was told to index, gets bounced to a different URL, and concludes the canonical is unusable. If you detect language for humans, exempt crawlers explicitly and never redirect away from a URL that is somebody's canonical.

Content that does not exist at crawl time

If the main content, the internal links or the metadata are injected by client-side JavaScript after load, treat them as absent. Rendering happens, but late and not guaranteed. View the raw HTML response: if the h1, the body copy and the navigation links are not in it, that is what you are asking to be ranked on.

Layer 3: structure

• One h1 per page that states what the page is about in the words a person would use.
• Heading levels that nest properly — no jumping from h2 to h4 because of how it looked.
• Descriptive, stable URLs. Renaming a URL costs you every link and every ranking it had; do it only with a 301 and a good reason.
• Internal links with anchor text that describes the destination. "Read more" transfers a topic to no one.
• A breadcrumb trail that matches the URL structure, and BreadcrumbList markup that matches the visible trail.
• Unique title and meta description per page. Duplicates across a template are the usual cause, and they are usually in the ten most trafficked pages.
• An XML sitemap containing every indexable page and no others — no redirects, no noindexed URLs, no 404s. Wrong entries teach the crawler to trust the file less.

Layer 4: duplication and waste

Most sites have several addresses for the same content and never notice. Check that exactly one of each pair resolves and the other redirects: with and without www, http and https, with and without a trailing slash, upper and lower case, and index.html versus the bare directory.

Then look at parameters. Tracking parameters (utm, fbclid, gclid) should never produce a separately indexable page — the self-referencing canonical handles this, which is why layer 2 comes first. Filter and sort parameters need a deliberate decision: canonicalise to the clean URL, except for the specific combinations people genuinely search for.

Layer 5: structured data

An hour here changes how your result looks, which changes click-through at every position you already hold. Validate the important templates and confirm:

• Organization on the homepage, with a square logo the crawler is allowed to fetch and sameAs links to the profiles you actually run.
• Product with price, currency and availability on commerce pages.
• Article or BlogPosting on editorial pages, with a real published and modified date.
• FAQPage only where the questions and answers are visible on the page — invisible FAQ markup is a policy violation, not a shortcut.
• BreadcrumbList matching what the user sees.
• No orphan or contradictory nodes: one entity per page, linked by @id back to the site-wide Organization rather than redeclared each time.

Also check that anything referenced from your schema — logo, images, the OG image — is not blocked by robots.txt. A blanket Disallow on an asset directory quietly breaks knowledge panels and link previews at the same time.

Layer 6: speed, honestly

Performance is a tiebreaker, not a lever. It matters most where it is worst — a mobile page taking six seconds to become usable loses conversions long before it loses rankings. Fix the obvious things and stop:

1. Serve images at display size, in a modern format, with width and height set so nothing shifts as they load.
2. Do not lazy-load the largest visible element. Lazy-loading the hero is the most common way a well-meant optimisation makes the score worse.
3. Audit third-party scripts. Chat widgets, analytics, pixels and A/B tools are usually most of the blocking time, and half of them are for a tool nobody uses any more.
4. Limit web fonts to two weights of one family, and let text render immediately rather than hiding it while the font loads.
5. Test on a mid-range Android over 4G. Your laptop on office wifi is not the device your traffic is on.

What to do with the output

An audit that produces a 200-row spreadsheet produces nothing. Convert it into three lists: things that block indexing (fix today), things that split or waste signals (fix this week), and things that improve the margin (schedule or drop). If a finding does not fit one of those three, it is not a finding.

Then re-run the same five URLs a week later. Technical defects regress silently with every theme update, plugin install and deploy — the value of an audit is entirely in it being repeated, not in it being thorough once.

Frequently asked questions