The Technical SEO Checklist

Technical SEO gets talked about as though it were a set of tricks. It is closer to plumbing. You are not persuading a search engine to like you — you are removing the obstacles that stop it understanding what you already have.

The order below matters. Each layer depends on the one above it, and there is no point tuning your Largest Contentful Paint on a page that carries a canonical tag pointing somewhere else.

1. Can it be crawled?

Start at /robots.txt. The single most expensive mistake in technical SEO is a Disallow: / that survived a staging deployment, and it happens more often than anyone admits.

• Confirm robots.txt returns 200 and does not block anything you want indexed
• Make sure CSS and JavaScript are crawlable — blocking them stops the renderer seeing your page as users do
• Reference your sitemap from robots.txt with an absolute URL

One thing that trips people constantly: Disallow is not a way to remove a page from search results. It stops the crawl, not the indexing — a blocked URL can still appear, usually with no description under it. To remove a page you need noindex, and the crawler must be allowed to fetch the page to see that tag. Blocking and noindexing the same URL cancels itself out.

2. Can it be indexed?

Crawling is not indexing. A page can be fetched perfectly and still be excluded.

• Check for stray <meta name="robots" content="noindex"> tags left over from staging
• Check the X-Robots-Tag HTTP header too — it does the same job and is far easier to miss because it is invisible in the page source
• Confirm the page returns a real 200, not a 200 rendering a not-found message
• Watch for soft 404s: thin or empty pages that return 200 and get treated as missing anyway

3. Are the canonical signals right?

The canonical tag tells search engines which URL is authoritative when several show the same content. Get it wrong and you can suppress a page that is otherwise flawless.

<link rel="canonical" href="https://example.com/blog/technical-seo-checklist" />

• Use absolute URLs. Relative canonicals resolve unpredictably.
• Every indexable page should carry a self-referencing canonical.
• Pick one host and one scheme and stick to it — https://example.com and https://www.example.com are different sites as far as a crawler is concerned.
• Be consistent about trailing slashes.
• Never canonicalise a paginated page back to page one. Those are different pages with different content.

On pagination: rel="next" and rel="prev" are no longer used by Google as indexing signals. They were retired years ago. Plenty of checklists still list them — you can leave them in place for other consumers, but do not expect them to do anything.

4. Is the sitemap honest?

A sitemap is a list of URLs you are claiming are worth indexing. Its value collapses if that claim is unreliable.

That last row is the one that saves you. If the sitemap is derived from the same source as the pages themselves, it cannot drift.

5. Are the redirects clean?

Use 301 for anything permanent — that is the signal that transfers ranking. Use 302 only when the move genuinely is temporary.

• No chains. A → B → C should be rewritten as A → C. Chains waste crawl budget and each hop is a chance to lose the signal.
• No loops. Obvious, and they still happen after migrations.
• No redirects in the sitemap. Only final destinations belong there.
• Do not mass-redirect to the homepage. A removed page with no equivalent should return 410 or 404. Redirecting everything to / is treated as a soft 404 anyway, and it is worse for users.

6. Does the page render without JavaScript?

Google does execute JavaScript, but rendering is queued and deferred rather than instant. Content that only exists after hydration is content that gets indexed late, if at all — and other crawlers, including several that feed AI answer engines, are far less patient.

Test it properly: fetch the raw HTML with curl and search it for your main heading and body copy. If they are not in the response, they are not reliably in the index either. Server-side rendering or static generation solves this outright.

7. Is the structured data valid?

Structured data does not directly improve rankings. It improves how your result is displayed, and it makes your content easier for machines to parse — which increasingly matters for AI-generated answers as well as classic rich results.

• Organization on the homepage
• BreadcrumbList on anything nested
• FAQPage where you genuinely have questions and answers on the page
• Article or BlogPosting on editorial content
• Service or Product on commercial pages

One rule with no exceptions: the structured data must describe what is actually on the page. Marking up FAQs that a visitor cannot see is a manual-action risk, and it is not worth it.

8. Core Web Vitals

Last on the list deliberately. Speed is a real ranking factor and a very real conversion factor, but it is a tie-breaker between comparable results — it will not rescue a page that cannot be indexed.

INP replaced First Input Delay as a Core Web Vital, so any checklist still listing FID is out of date. LCP is usually the one costing you something — what actually makes LCP slow goes through the real causes.

The order to work in

1. 1Fix anything blocking crawling or indexing. Nothing else counts until this is done.
2. 2Fix canonical and duplicate-content signals.
3. 3Fix redirect chains and clean the sitemap.
4. 4Confirm content renders in the raw HTML.
5. 5Add structured data that reflects the page.
6. 6Then optimise Core Web Vitals.

Most audits do this backwards, because performance produces a satisfying number and indexing problems do not. The traffic is in the first three steps.