Technical SEO Checklist: Checks to Run Before and After Launch

A good technical SEO checklist is short enough to finish and specific enough that two people get the same answer. Each line here names one thing, one quick way to test it and what a pass looks like. There are 40 checks in six groups, ordered so that the failures that block everything else come first.

Use it in two moments. Before a launch or migration, run it on the staging site and again on the live site on launch day. After launch, rerun it after any release that changes templates, redirects, robots rules or hosting. It is a reference list: for a guided process with a findings sheet, see Technical SEO Audit Step by Step: A Repeatable 8-Step Process.

Short answer: A technical SEO checklist covers access (robots.txt, noindex, firewalls), status codes and redirects, indexing and canonicals, sitemaps and links, mobile rendering, and speed with security and markup. Test one example page from each template, record pass or fail with evidence, and fix blockers first.

Before you begin

You need Search Console access, a browser, and optionally a terminal with curl. List the page templates (home, category, article or product, search, contact) and pick one real URL for each. Checking a sample from each template is faster than checking every page and finds the same template-level faults.

Plan an hour. Checking is read-only; the risk is in the fixes, so keep a copy of robots.txt, your redirect rules and your sitemap first. If a check says "in Search Console", you need a verified property; see Set Up Google Search Console: Complete Website Owner Checklist. Record results in a sheet with columns for check number, URL, result and evidence. Nothing here promises indexing or rankings; the list removes technical obstacles only.

Step-by-step instructions

Step 1: Pick your sample URLs and note the preferred address

Choose the preferred form of the site address, for example https://www.example.com/, and one URL per template. Every later check uses these. What success looks like: a list of 5 to 10 URLs and one agreed preferred address.

Step 2: Run the access checks (1 to 8)

Google's technical requirements say Googlebot must be able to access the page, the page must work, and it must have indexable content. These checks cover the first requirement. Do them first, because a blocked page cannot be fixed by any later change.

#	Check	One-minute test	A pass looks like
1	robots.txt is reachable	Open `/robots.txt` or `curl -I` it	A 200 response with plain-text rules
2	No sitewide block	Read the file for `Disallow: /`	No blanket disallow on production
3	Rendering files not blocked	Check rules against script, style and image folders	Resources pages need to render are allowed
4	Important pages are public	Open in a private window	No login wall in front of content you want found
5	No stray noindex in HTML	View source, search `robots`	No `noindex` on wanted pages
6	No stray noindex in headers	`curl -I`, look for `X-Robots-Tag`	Header absent or not `noindex`
7	noindex pages are crawlable	Compare noindex URLs with robots rules	A page you want de-indexed is not also blocked
8	Googlebot is not firewalled	URL Inspection, Test live URL	"URL is available to Google"

Check 7 matters because Google can only see a noindex rule if it can crawl the page. If robots.txt blocks the URL, the rule is never read. Google also says robots.txt is not a mechanism for keeping a page out of results. See Meta Robots Directives Explained: noindex, nofollow, nosnippet and Cloudflare Blocking Googlebot or Bingbot: How to Diagnose.

Step 3: Run the status code and redirect checks (9 to 15)

Google ignores content from 4xx responses and, over time, removes previously indexed URLs that keep returning them. Persistent 5xx errors slow crawling and can lead to URLs being dropped. Google follows up to 10 redirect hops, and treats 301 and 308 as strong signals and 302, 303 and 307 as weak ones.

#	Check	One-minute test	A pass looks like
9	Pages return 200	`curl -sIL` each sample URL	Final status 200
10	One host version wins	Request all four http/https and www/non-www forms	Three redirect to the fourth
11	Permanent moves use 301 or 308	Inspect redirect status codes	Permanent redirects, not temporary ones, for moved pages
12	No chains	Count hops in `curl` output	One hop from old to final URL
13	No loops	Look for "too many redirects"	Every redirect ends in a 200
14	Missing pages return 404 or 410	Request a made-up URL	A real error status, not 200
15	No 5xx on templates	Page indexing report, Server error (5xx)	Zero affected sample URLs

For check 14, a page that shows an error message with a 200 status is a soft 404; see Redirect Chains, Loops, and Incorrect HTTP Status Codes.

Step 4: Run the indexing and canonical checks (16 to 22)

#	Check	One-minute test	A pass looks like
16	Key pages are indexed	URL Inspection, Overall page status	"URL is on Google" for key pages
17	Not-indexed reasons reviewed	Page indexing report	Each reason marked expected or fix
18	One canonical per page	View source, search `canonical`	One absolute URL
19	Canonical target works	Request the canonical URL	200, indexable, not redirected
20	Signals agree	Compare canonical, redirect, sitemap	All name the same URL
21	Duplicates consolidated	Try parameter, trailing-slash and case variants	One version serves, others redirect or canonicalize
22	Titles are unique	Compare titles across templates	Each page has its own clear title

"URL is on Google" confirms a URL is in the index, but Google says searching for the URL is the definitive check for appearing in results. Google treats canonical methods as hints and says they should not conflict. See Fix Duplicate URLs and Incorrect Canonical Tags and Page Indexing Report Explained: Every Status and What to Do.

Step 5: Run the sitemap and internal link checks (23 to 29)

#	Check	One-minute test	A pass looks like
23	Sitemap exists	Open `/sitemap.xml` or the declared path	Valid XML, absolute URLs
24	Within limits	Check file size and URL count	At most 50 MB uncompressed and 50,000 URLs per file
25	Only wanted URLs	Sample 20 entries	Each is 200, indexable and canonical
26	Submitted	Search Console, Sitemaps	Status "Success"
27	`lastmod` honest	Compare dates with real edits	Accurate, or left out
28	Links are real links	View source of navigation	`<a>` elements with `href`
29	No orphans	Compare sitemap URLs with a crawl's linked URLs	Every wanted page has at least one internal link

Google ignores priority and changefreq, and uses lastmod only if it is consistently accurate, so set it only when a page really changed. Submitting a sitemap is a hint, not a promise to crawl. See How to Create an XML Sitemap: Format, Limits and Submission.

Step 6: Run the mobile and rendering checks (30 to 34)

#	Check	One-minute test	A pass looks like
30	Viewport is set	View source, search `viewport`	A viewport meta tag
31	Mobile content matches	Compare mobile and desktop headings and text	Same primary content
32	Mobile metadata matches	Compare titles, descriptions, robots tags	Equivalent on both
33	Content is in rendered HTML	URL Inspection, View crawled page	Main text and links present
34	Client routing uses real URLs	Click through the app	Distinct paths, not `#` fragments

Google indexes the mobile version, and warns that a mobile page with less content may lose traffic. It advises against URL fragments for loading different content and against changing noindex with JavaScript. See Mobile-First Indexing Checklist: Make the Mobile Version Complete and JavaScript SEO: Server Rendering, Client Rendering and Crawlers.

Step 7: Run the speed, security and markup checks (35 to 40)

#	Check	One-minute test	A pass looks like
35	Field data reviewed	PageSpeed Insights, real-user block	LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less at the 75th percentile
36	Slowest element known	Lighthouse LCP element	The element is named and has a plan
37	Media has dimensions	View source of images and iframes	Width and height or an aspect ratio set
38	Certificate is valid	Open the site over HTTPS	No browser warning
39	Security Issues is clear	Search Console, Security Issues	No issues listed
40	Structured data is valid	Rich Results Test	JSON-LD parses, matches visible content

When field data is missing for a low-traffic page, PageSpeed Insights may fall back to origin-level data or show none. Valid markup is eligibility only; Google does not promise a rich result.

Final verification checklist

All 40 checks have a recorded result with evidence.
Access checks 1 to 8 pass on every sample template before anything else is worked on.
One preferred host version exists, with single-hop permanent redirects.
Canonical, redirect and sitemap signals agree.
The sitemap is submitted and reads "Success".
The rendered HTML shows main content and crawlable links on mobile.
Field data and the slowest element are recorded for each template.
The technical SEO checklist is rerun after the next release that touches templates or redirects.

Common mistakes to avoid

Ticking items without testing. "Probably fine" is not a result. Save the command output or screenshot.
Testing only the home page. Template faults hide on article, category and search pages.
Blocking a page and expecting noindex to work. Allow crawling so the tag can be read.
Listing every URL in the sitemap. Include only indexable, canonical 200 pages.
Treating a green Lighthouse run as the whole speed check. Read field data first.
Running the list once. Releases change robots rules and redirects without warning.

Frequently asked questions

What is on a technical SEO checklist?

Access for crawlers, status codes and redirects, indexing and canonical signals, sitemaps and internal links, mobile rendering, page speed, HTTPS and structured data. The six groups here follow the order in which failures block each other.

How often should I run a technical SEO checklist?

Run it fully before launch and after any migration. Run a lighter pass monthly or quarterly. The monthly maintenance routine in the related guides below shows where it fits.

Do I need a paid tool to work through it?

No. Search Console, the URL Inspection tool, PageSpeed Insights, the Rich Results Test, a browser and curl cover each check. Crawlers speed up the sitemap and link checks on big sites. Crawvix runs about 115 checks in ten areas, including reachability, robots, sitemaps and links, and you can compare its results with your own.

Does passing every check improve my rankings?

Not on its own. The list removes obstacles to crawling, indexing and loading. Rankings depend on far more than technical health.

Which checks should I do first?

Do the eight access checks first, then status codes. If Google cannot fetch a page or the page returns an error, nothing else on the list can help it.

Official references

Next step: Try the free website sample to see how your own site does on a few of these checks. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.