Technical SEO Checklist: The Checks That Matter, in Order

TL;DR: A useful technical SEO checklist follows the order search engines depend on. First confirm Google can crawl your important pages (robots.txt, status codes, crawlable links). Next confirm it indexes the right version of each page (noindex, canonicals, redirects). Then check that the mobile page shows its content without user interaction, and only then tune Core Web Vitals and HTTPS. A failure in an earlier tier makes later fixes pointless.

Last reviewed: 29 October 2026

Most technical SEO checklists are long lists with no order. Every item looks equally urgent, so you cannot tell which one is quietly stopping Google from showing your pages. This technical SEO checklist puts the checks in the order that search engines depend on them. If Googlebot cannot fetch a page, its Core Web Vitals score does not matter. If the page is fetched but marked noindex, its schema markup does not matter either.

The guide is written by Janak Pokharel, an SEO practitioner and co-founder of Limi Creatives whose work is mostly organic SEO and AEO. It is built on Google’s own documentation rather than tool scores. Each tier explains what to check, how to test it with free tools and what breaks if you skip it. There is also a short list of checks most small and medium sites can safely ignore, because an hour spent on the wrong fix is an hour not spent on the right one.

What should a technical SEO checklist check first?

A technical SEO checklist should check crawling first, then indexing, then rendering, then page experience. Google lists three minimum requirements for a page to be eligible for Search: Googlebot is not blocked, the page returns an HTTP 200 status code, and the page has indexable content. Any check that does not protect those three comes later.

Those three conditions come from Google’s technical requirements for Search, which adds that meeting them does not mean a page will be indexed, because “indexing isn’t guaranteed.” The requirements are a floor, not a promise.

That is why order matters: each tier depends on the one before it.

Priority	Question the tier answers	Main checks	What fails if the tier breaks
1. Crawl	Can Googlebot reach and fetch the page?	robots.txt rules, HTTP status codes, crawlable links, XML sitemap	The page is never fetched
2. Index	Is Google storing the version you want?	noindex tags, canonical tags, redirects, duplicate URLs	The wrong URL appears, or none does
3. Render	Can Google see the content users see?	Mobile parity, JavaScript rendering, content hidden behind clicks	Google indexes a thin or empty page
4. Experience	Is the page fast, stable and secure?	Core Web Vitals, HTTPS	Usually a weaker result, rarely a missing one

One rule makes the checklist faster: check templates, not pages. One broken canonical in a template affects every page built on it, and one fix repairs them all.

Priority 1: Can Google crawl your important pages?

Google can crawl a page when robots.txt does not block it, the server returns a 200 status code, and other pages link to it with a standard HTML link. Crawl problems come first in any technical audit because a page Googlebot cannot fetch cannot be indexed or ranked, however good its content is.

1. robots.txt does not block important paths. Google’s introduction to robots.txt says the file manages crawler traffic and is not a way to keep a page out of Google. One easy mistake is a Disallow: / rule copied from a staging site to the live site. Our guide on what to block and allow in robots.txt covers the rules line by line.
2. Important URLs return 200. According to Google’s documentation on HTTP status codes, 5xx and 429 errors make Google’s crawlers slow down, and URLs that keep returning server errors are eventually dropped from the index. Google follows up to 10 redirect hops by default, so long redirect chains are worth removing.
3. Navigation uses real links. Google’s guidance on crawlable links says it can generally only crawl a link if it is an <a> element with an href attribute. Menus built from buttons without an href may not be followed reliably.
4. Every important page is linked from somewhere. A page with no internal links depends on the sitemap alone. Keep an XML sitemap as a backup, not a substitute; here is how to create an XML sitemap and submit it to Google.

How to test it: open your robots.txt in a browser, crawl the site for status codes and orphan pages, and run the URL Inspection live test on one URL per template.

Priority 2: Is Google indexing the right version of each page?

Google indexes the right version of a page when that URL is not marked noindex, every duplicate variant points to one canonical URL, and retired URLs use permanent redirects. Indexing checks come second because a page Google can crawl can still be excluded, or Google can pick a different URL from the one you want shown.

• No stray noindex tags. A leftover noindex directive removes a page from results; the Page indexing report shows it as “URL marked ‘noindex'”.
• One canonical URL per piece of content. HTTP and HTTPS, www and non-www, trailing slashes and URL parameters can all create copies of one page. Google’s guide to canonicalisation treats redirects and rel="canonical" as strong signals and sitemap inclusion as a weak one, and says not to use robots.txt for canonicalisation.
• All signals agree. Canonical tags, internal links, sitemap entries and redirects should point to the same URL. When they disagree, Google chooses for you, shown as “Duplicate, Google chose different canonical than user”.
• Permanent moves use permanent redirects. Google’s status code documentation treats a 301 or 308 as a strong signal that the redirect target should be processed, and a 302 or 307 as a weak one.

Do not panic about every excluded URL. Google’s Page indexing report documentation says the goal is to get the canonical version of every important page indexed, and that you should not expect all URLs on a site to be indexed.

Priority 3: Can Google render and understand the content?

Google can understand a page when the mobile version holds the same main content, structured data and metadata as the desktop version, and that content appears in the rendered HTML without a click or tap. Google uses the mobile version, crawled with its smartphone agent, for indexing and ranking.

Google’s mobile-first indexing best practices ask for the same content, the same structured data and equivalent titles and meta descriptions on both versions. The guidance also warns that “Google won’t load content that requires user interactions”, which matters for tabs and “load more” buttons that fetch content only after a click.

Google’s JavaScript SEO basics describes three phases (crawling, rendering and indexing) and calls server-side rendering or pre-rendering “still a great idea”, partly because not every bot can run JavaScript.

How to test it: run the URL Inspection live test on one URL per template and open the rendered HTML. If your main heading, body copy or internal links are missing from it, Google is not seeing them. Confirm each template also outputs a unique title and a meta description written to earn the click.

Server-side rendering is developer work, the kind of technical SEO implementation Nomor Technology, our software development company, handles.

Priority 4: How much do Core Web Vitals and HTTPS matter?

Core Web Vitals and HTTPS matter, but they sit fourth in this checklist because Google “always seeks to show the most relevant content, even if the page experience is sub-par.” Aim for Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1.

That quote comes from Google’s page experience guidance, which also says “there is no single signal” for page experience. Relevance comes first; speed and stability help a relevant page compete. Google’s Core Web Vitals documentation recommends good scores “for success with Search” and sets these targets:

Core Web Vital	What the metric measures	Good threshold
Largest Contentful Paint (LCP)	Loading performance	Within 2.5 seconds
Interaction to Next Paint (INP)	Responsiveness to user input	Less than 200 milliseconds
Cumulative Layout Shift (CLS)	Visual stability	Less than 0.1

Start with the Core Web Vitals report in Search Console and fix the slowest template first.

For HTTPS, the page experience guidance asks: “Are your pages served in a secure fashion?” Check that HTTP redirects permanently to HTTPS, the certificate covers www and non-www, and no page loads files over plain HTTP.

Which technical SEO checks can most sites skip?

Most small and medium sites can skip crawl budget optimisation, chasing 100% indexing, and fixes aimed at a “duplicate content penalty”. Google says its crawl budget guide is for sites with roughly a million or more pages, or 10,000 or more pages that change daily, and that not every URL on a site is meant to be indexed.

Common audit item	What Google says	Sensible priority
Crawl budget	The crawl budget guide targets sites with 1 million+ pages, or 10,000+ pages changing daily	Skip unless your site is that large
100% of URLs indexed	You should not expect all URLs to be indexed, only canonical pages	Skip; check important pages instead
Duplicate content “penalty”	Content reachable at several URLs is “fine; don’t fret about it”	Low; set canonicals for clean reporting
Headings out of order	It “doesn’t matter” for Google Search if headings are out of order	Low; fix for accessibility, not rankings
Word count warnings	“The length of the content alone doesn’t matter for ranking purposes”	Skip as a technical item

The last three rows come from the “things we believe you shouldn’t focus on” section of Google’s SEO starter guide. A warning that is easy for a tool to count is not automatically a problem for Google.

How do you run this checklist on a real site?

Run the checklist on templates, not individual URLs. Pick one live example of each page template, inspect it in Google Search Console’s URL Inspection tool, confirm crawl, index and render status in that order, then fix whatever fails first. After fixing, use the Page indexing report’s “Validate fix” button, which typically takes up to about two weeks.

1. List your templates and pick one example URL for each.
2. Inspect each URL in Search Console. Note whether it is indexed, which canonical Google selected and whether the rendered HTML contains the main content.
3. Open the Page indexing report, sort the reasons pages are not indexed by count, and map each reason to a tier using the table below.
4. Crawl the site to catch broken links, redirect chains, missing canonicals and orphan pages.
5. Fix by tier, starting with the highest-traffic template, then click “Validate fix”.
6. Wait before judging results. Google’s starter guide says some changes take effect in a few hours and others take several months.

Page indexing reason in Search Console	Checklist tier	First thing to check
Server error (5xx)	1. Crawl	Hosting capacity and server logs
Redirect error	1. Crawl	Loops or long chains in the redirect path
URL blocked by robots.txt	1. Crawl	The Disallow rule that matches the URL
Soft 404	1. Crawl	Empty or error-like pages that return a 200 code
URL marked ‘noindex’	2. Index	Leftover noindex tags in the template or CMS
Duplicate, Google chose different canonical than user	2. Index	Whether canonicals, links and sitemap agree
Crawled, currently not indexed	3. Render, then content	Rendered HTML, duplication and content value

The reason labels come from the Page indexing report help page. If you are weighing a paid audit against doing it yourself, this breakdown of what a technical SEO audit costs explains what different price levels usually include.

Conclusion

The checks that matter in technical SEO follow a chain: crawl, index, render, then experience. Fix the earliest broken link in that chain before you spend time further down. For most sites, that means confirming robots.txt, status codes, noindex tags and canonicals on every template before touching Core Web Vitals.

To see where your own site stands, the free SEO audit from Nomor AI Marketing crawls a sample of your pages and checks technical SEO, on-page SEO, structured data, AI search readiness, security and speed. It gives you a score and a downloadable PDF report, with no signup, so you can match each finding to a tier in this checklist and work through them in order.

Frequently asked questions

How often should you run a technical SEO audit?

Google does not set a schedule. A sensible routine is a full audit after any major change, such as a redesign, CMS switch or domain move, plus a monthly look at the Page indexing and Core Web Vitals reports in Search Console.

What is the difference between technical SEO and on-page SEO?

Technical SEO covers whether search engines can crawl, index and render a site: robots.txt, status codes, canonicals, redirects, mobile parity, JavaScript, speed and HTTPS. On-page SEO covers the content and HTML elements of individual pages, such as titles, headings, meta descriptions and internal links.

Do Core Web Vitals affect Google rankings?

Google recommends good Core Web Vitals for success with Search and says page experience aligns with what its ranking systems reward. Google also says it always tries to show the most relevant content, even when page experience is sub-par, so speed helps a relevant page compete rather than replacing relevance.

Can you do a technical SEO audit without paid tools?

Yes. Google Search Console covers the core checks for free: URL Inspection for crawl, index and rendering status, the Page indexing report for excluded URLs, and the Core Web Vitals report for speed. Free crawlers can then list status codes, redirects and missing tags.

Why is a page not indexed even though it passes every check?

Google says meeting its technical requirements does not guarantee indexing. A page marked “Crawled, currently not indexed” in Search Console was fetched but not added, and it may or may not be indexed later. If the technical checks pass, look next at whether the page duplicates another URL and whether its content adds enough value to be indexed.