The Technical SEO Checklist That Actually Matters
Most checklists give eighty items equal weight, which is how people spend a month on image alt text while a stray noindex quietly hides half the site. This one is ordered by consequence.
Technical SEO has a strict order of importance: a page must be crawlable, then indexable, then understandable, then fast. Work above you in that list makes work below it worthless, so fix crawling and indexation before touching anything else. Most technical SEO problems live in the first two layers.
Why Order Matters More Than Coverage
A checklist that treats every item equally is worse than no checklist, because it lets you finish forty low-value tasks and report progress while the one thing suppressing the site sits untouched. Technical SEO is a dependency chain, not a list.
The chain runs: crawlable, then indexable, then understandable, then fast. If Google cannot fetch a page, nothing about that page's title, schema or load time has any effect — the work is real and the result is zero. If it can fetch but will not index, the same applies one layer down.
This is why audits so often produce dramatic early results. Finding a single directive that was hiding a section of the site recovers more traffic in a week than months of on-page polish, because the ranking was being suppressed rather than merely unearned.
Work the layers in order. Within a layer, fix the items that affect the most pages first — a template problem on two hundred pages outranks a content problem on one.
The Four Layers, In Order
Each layer assumes the one above it is clean. Do not start a layer until the previous one is genuinely finished, however tempting the more visible work below looks.
- 01
Crawlable — can Google fetch it at all?
Check robots.txt is not blocking anything important. Confirm the server returns 200 for pages that should exist and 404 for those that should not. Look for redirect chains and loops. Make sure every page you care about is linked from somewhere — a page with no internal links and no sitemap entry is effectively invisible however good it is.
- 02
Indexable — will Google keep it?
Look for stray noindex tags, especially any that survived a staging environment. Check canonical tags point where you intend. Confirm the sitemap lists real, canonical, indexable URLs and nothing else. Then read the Pages report in Search Console, which tells you directly which pages were excluded and why.
- 03
Understandable — does Google know what it is?
One clear H1 per page. A heading hierarchy that reflects the actual structure rather than font sizes. Descriptive titles and meta descriptions that differ page to page. Structured data where a page has a type worth declaring. Internal links using text that describes the destination.
- 04
Fast — is the experience good enough not to count against you?
Core Web Vitals in the good band, mobile layout that works at 360px wide, images sized and compressed properly. This layer is real but it is a tiebreaker, not a lever — which is exactly why it should not be the first thing you do.
Symptom to Cause
Most technical problems present as one of these four symptoms. The mapping is reliable enough to start from and saves a great deal of undirected auditing.
| Usual cause | Where to look | |
|---|---|---|
| Pages not in Google at all | Blocked by robots.txt, a noindex tag, or simply never discovered | Search Console → Pages, then the URL Inspection tool on a specific page |
| Indexed but ranking nowhere | Content does not match the query, or a stronger page on your own site competes with it | Search Console → Performance, filtered by page, to see what it actually gets impressions for |
| Wrong page ranking for a term | Keyword cannibalisation, or internal links pointing at the weaker page | Site search for the term, then compare internal link counts to each candidate |
| Traffic dropped suddenly | A deploy changed URLs, added a directive, or broke rendering | Compare the deploy date against the drop, then crawl and diff against a previous export |
The Failures That Never Announce Themselves
These cause serious damage and produce no error, no warning and no visible change on the site. They are found by looking for them deliberately, which is most of what an audit is for.
A noindex that shipped from staging
The single most expensive line in SEO. Staging environments are correctly blocked from indexing, and the block travels to production more often than anyone admits. Check it on every launch, and check it again a week later.
Canonical tags all pointing at the homepage
A template bug that tells Google every page is a duplicate of one page. The site looks perfect to a visitor and collapses to a single indexed URL. Trivially checked by viewing source on three unrelated pages.
Pagination that hides most of your catalogue
If page two onward is only reachable by JavaScript that Google does not execute, the majority of a large catalogue may never be discovered. Confirm deeper pages are reachable through plain links.
Two URLs for every page
With and without a trailing slash, http and https, www and apex, or parameter variants. Each doubles your crawl footprint and splits ranking signals between duplicates. Pick one form and redirect the rest.
A sitemap full of URLs that redirect
A sitemap is a statement about your canonical, indexable pages. Filling it with redirects and 404s makes Google trust it less, which slows discovery of the pages that are genuinely new.
Common Questions
What people ask when starting a technical audit.
How often should a technical audit run?
A full audit once or twice a year, plus a short check after every significant deploy. The post-deploy check matters more: most technical problems are introduced by a change, so catching them within days is far cheaper than finding them at the next scheduled audit.
Do I need paid tools?
Not to start. Google Search Console is free and reports the things that matter most — indexation status, coverage errors and actual query data. A crawler helps for sites beyond a few dozen pages, and free tiers cover small sites comfortably.
Is technical SEO a one-time fix?
The big structural fixes largely are, and they hold until something changes them. The recurring work is watching for regressions, because every deploy, plugin update and template change is an opportunity to reintroduce a problem that was already solved.
My site is small. Does any of this apply?
The first two layers do, and they are quick on a small site — an afternoon to confirm everything is crawlable and indexable. Small sites rarely have crawl budget problems, but they have exactly the same exposure to a stray noindex or a broken canonical.