What is a technical SEO checklist?

Short answer

A technical SEO checklist is a list of the things that let search engines crawl, render and index your site, and serve it quickly. The useful version is ordered: crawling, then rendering, then indexing, then performance. Checking items out of order is how teams spend weeks on speed for pages Google cannot reach.

Every technical checklist online contains roughly the same items. Most of them present the items as equals, often fifty or a hundred of them, which is not how they behave. Here is the checklist I actually work from, grouped by stage, with the items that most often matter at the top of each group.

Stage 1: crawling

robots.txt. Does it exist, does it return a 200, and does it block anything important? The HTTP Archive found robots.txt returns a 404 on 13% of sites. That is mostly harmless. Accidentally blocking a whole folder is not.
Status codes. Important pages return 200. Removed pages return 404 or 410, or redirect to a relevant replacement.
Redirects. No chains, no loops, and internal links pointing at final URLs rather than through redirects.
Internal links. Every important page reachable by clicking, within a few clicks of the homepage. No orphans.
XML sitemap. Lists only canonical, indexable URLs that return 200. Submitted in Search Console.
Crawl traps. Parameters, calendars, filters and session IDs creating endless URLs.

Stage 2: rendering

Content in the HTML. Is the main content present in the source, or only after JavaScript runs?
Links as real links. Navigation and internal links should be anchor tags with href attributes, not click handlers.
Rendered output. Use Search Console’s URL inspection tool to view the rendered page for each main template. Compare it with what users see.

Stage 3: indexing

Indexed versus expected. Compare Search Console’s indexed count with the number of pages you actually want indexed. Big gaps in either direction are findings.
noindex. Check no important templates carry it. The same research found only 2.4% of pages use noindex, so if yours is widespread, ask why.
Canonicals. Each page’s canonical points at itself or a deliberate preferred version, and internal links and the sitemap agree with it.
Duplicates. Parameter versions, http and https, www and non-www, trailing slashes, printer versions. One version should win.
Thin and soft 404 pages. Empty categories, expired listings, tag pages.

Stage 4: performance and experience

Core Web Vitals on real user data, by template, on mobile.
Mobile layout. Content and links the same on mobile as desktop.
HTTPS everywhere, with no mixed content.

The large-site extras

If the site has hundreds of thousands of URLs, add server log analysis to see what Googlebot actually requests, and a crawl budget review. Google’s guidance is that this matters for sites with roughly a million or more pages changing weekly, or ten thousand or more changing daily. For smaller sites, skip it.

What I leave off the list

Meta keywords, which Google does not use. Exact title length rules, since Google sets no limit and simply truncates display. Heading order as a ranking issue, which Google says does not matter for search, though it matters for screen readers. Text-to-HTML ratios. Most “warnings” about image file names. These appear on many checklists and almost never change rankings.

How to use a checklist properly

Work through it by template, not by page. Most sites have a handful of templates, and almost every technical problem lives in one and repeats across every page that uses it. Checking one representative page per template covers most of the site.

Stop at the first serious problem in each stage and fix it before moving on. A crawl blocker makes everything after it irrelevant.

And write down what you checked and when. A checklist done once is a snapshot. Sites change, plugins update, developers deploy, and the same checks are worth repeating after every significant release.

The findings that turn up most often

After running this list on a lot of sites, a handful of findings come up again and again, and they are worth checking first if you only have an hour.

Internal links that point at redirected URLs. Usually old header and footer links left over from a URL change. They are on every page, so a single fix removes thousands of redirect hops. I found forty of them on my own site, which I wrote up in the redirects nobody sees.

Important pages with almost no internal links. Service pages, categories and location pages reachable from the menu and nowhere else, while the blog links to itself in circles.

Sitemaps full of URLs that redirect, return errors or are set to noindex. A sitemap should be a list of pages you want indexed, and nothing else.

A template carrying a canonical that points somewhere unexpected, often the homepage or the first page of a paginated series.

And a noindex or a robots rule left over from a staging site. It is the most damaging finding on this list and the quickest to fix.

How often to run it

A full pass once a year on a stable site, and a quick pass on the crawling and indexing stages after every significant release, redesign, plugin update or platform change. Most of the serious technical problems I am asked to diagnose were introduced by a change that nobody checked afterwards.

If you would rather hand the checklist to someone who knows which items matter on your site, my technical SEO service works through it in this order and gives your developers specifications rather than warnings.