A technical SEO audit ordered by what actually breaks

Technical SEO has an unusually poor ratio of advice to impact. Most checklists are exhaustive lists of things that are true but rarely decisive, which leaves you auditing image alt text on a site that is serving two versions of every URL.

This one is ordered by how much damage the problem does when it is present. Work down it and stop when you run out of afternoon — the ordering is the useful part.

First: can it be indexed at all

Every other item is irrelevant until this one is clean. These are the failures that remove pages from search entirely, and they are usually invisible from the browser.

Contradictory crawl directives

The most common serious mistake, and it looks like caution rather than error. Blocking a URL in robots.txt while also serving a noindex tag does not doubly-remove the page — it prevents the crawler from ever reading the tag.

the contradiction

<!-- The contradiction that quietly de-indexes pages.
     A blocked URL is never fetched, so the noindex is never read —
     and Google may index the bare URL with no snippet instead. -->

# robots.txt
Disallow: /pricing

<!-- /pricing -->
<meta name="robots" content="noindex" />

<!-- Pick one: block it OR noindex it. Never both. -->

Decide which you want. noindex keeps the page crawlable so the directive is seen and link equity still flows through it. Disallow saves crawl budget on pages whose content is genuinely irrelevant. Use noindex unless you have a crawl budget problem, which almost nobody under 10,000 pages does.

A staging directive that shipped

A site-wide noindex added to protect a staging environment and deployed to production is the single most expensive one-line bug in this discipline. It is worth an automated check that fails the build.

Canonical tags that point somewhere else

A canonical is a strong hint about which URL should rank. Pointing every page at the homepage — a surprisingly common templating error — instructs Google to drop the entire site from the index except one page.

head

<!-- Self-referential canonical on every indexable page.
     Absolute URL, one per page, matching the URL you want ranked. -->
<link rel="canonical" href="https://example.com/pricing" />

Every indexable page should carry a self-referential canonical with the absolute URL. Check a few nested pages, not just the homepage; the template bug only shows up below the root.

Second: one URL per thing

Serving identical content at several addresses splits its ranking signals between them. The usual culprits are mechanical:

• Protocol and subdomain. http:// and https://, www and bare should resolve to one canonical form with a single redirect.
• Trailing slashes. /docs and /docs/ are different URLs. Pick one and redirect.
• Query parameters. Tracking and sort parameters generate infinite variants of the same page. Canonicalise to the clean URL.
• Pagination and filters. Faceted navigation can produce thousands of near-identical URLs. This is the one case where crawl budget genuinely matters.

redirects

# A chain costs a round trip per hop and dilutes link equity.
http://example.com/old   → 301 → https://example.com/old
https://example.com/old  → 301 → https://example.com/new
https://example.com/new  → 200

# Collapse it. One hop, always.
http://example.com/old   → 301 → https://example.com/new

Collapse redirect chains while you are here. Each hop costs a round trip and loses a little signal, and chains accumulate silently across years of site restructures.

Third: what the crawler actually receives

Google renders JavaScript, but rendering is queued separately from crawling and can lag by days. Content that only exists after hydration is indexed late and sometimes incompletely.

The test that settles it: fetch the page with JavaScript disabled, or run curl against it, and read what comes back. If your headings and body copy are absent from the raw HTML, that is what the crawler sees first.

Server-render or statically generate anything you want ranked. Client rendering is fine for dashboards behind a login, which are not being indexed anyway.

Fourth: structure and internal links

• One h1 per page, describing that page specifically. Headings below it should nest in order — skipping from h2 to h4 is a small signal loss and an accessibility problem.
• Descriptive internal links. "Read more" tells a crawler nothing about the destination. The anchor text is one of the stronger signals about what the target page is about.
• No orphan pages. A page reachable only from the sitemap is a page Google considers unimportant. If it matters, link to it from somewhere in the navigation or the body of a related page.
• Depth under four clicks. Pages buried deeper are crawled less often and rank worse, roughly regardless of quality.

Fifth: structured data

Schema does not directly improve rankings. It determines whether your result gets a rich presentation — breadcrumbs instead of a bare URL, star ratings, FAQ dropdowns — which affects click-through rate, and it is increasingly how AI answer engines decide whether a page is attributable.

breadcrumbs.json

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home",
      "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Docs",
      "item": "https://example.com/docs" },
    { "@type": "ListItem", "position": 3, "name": "Install",
      "item": "https://example.com/docs/install" }
  ]
}

Worth adding, in order: BreadcrumbList on every nested page, Organization once on the site, Article on editorial content with a named author and a real dateModified. Validate with Google's Rich Results Test — invalid schema is ignored silently, which is indistinguishable from having none.

Last: Core Web Vitals

Deliberately last. Vitals are a tiebreaker between otherwise comparable results, and a site with the problems above will not reach the tie. What actually moves the score covers them properly, including why your lab score and your field data disagree.

How often to run this

The indexability checks belong in CI, because they are the ones that cause catastrophic, silent damage. The rest is a quarterly exercise unless you have shipped a restructure, in which case do it the week after.