A technical SEO checklist is an ordered set of checks, each with a pass condition and a tool, that confirms search and AI engines can crawl, render, index, and serve a site’s pages. This article covers what a technical SEO checklist covers, then the checks for crawl access, rendering, indexation and canonicalization, internal link depth, structured data, and speed and stability, followed by the full technical SEO checklist in repair order. It then shows the technical SEO checklist on holisticradar.com, places the checklist within technical SEO services, and closes with checklist frequency, tools, and site migrations.
What a technical SEO checklist covers
A technical SEO checklist covers six areas in a fixed order: crawl access, rendering, indexation and canonicalization, internal link depth, structured data, and speed and stability. The order follows the path a page takes through a search engine. Google’s guide to how Search works describes three stages, crawling, indexing, and serving results, and every check on the list belongs to one of them.
Two properties separate a checklist from a crawler report. Each check has a pass condition, a stated state that is either true or false, rather than a score or a warning count. And the checks run in order, because a failure early on the path hides everything after it: a page that returns a 404 cannot have a canonical problem worth fixing, and a page blocked in robots.txt cannot fail a structured data test that nobody can fetch.
The checklist is run against the pages that matter first. On a site built from a topical map, that set is the map: every URL that is meant to rank and be cited. URLs outside the map are checked for one thing only, which is whether they are kept out of the crawl and the index.
Crawl access checks
Crawl access checks pass when robots.txt allows every URL in the topical map, every map URL returns a 200 status, and the XML sitemap lists only those URLs. These three checks come first because a crawler that cannot fetch a page makes every other check irrelevant for it.
The robots.txt file itself must be reachable. Google treats a robots.txt that returns a server error as a signal to stop crawling the site temporarily, so a misconfigured server can halt crawling of every page at once. A missing file that returns 404 is acceptable and means no restrictions.
Status codes are checked across the whole crawl, not only the map. Map URLs return 200. Retired URLs return a 301 to the page that now owns their topic, or a real 404 or 410 when nothing replaces them. Internal links point at final URLs, so no crawl path passes through a redirect, and no redirect chain has more than one hop. Empty pages that return 200, which Google reports as soft 404s, are fixed by returning the correct status.
The XML sitemap lists only canonical, indexable URLs that return 200, with last-modified dates that change only when the content changes. A single sitemap file holds at most 50,000 URLs or 50 MB uncompressed, and larger sites use a sitemap index. A sitemap that includes redirects, noindexed URLs, or duplicates is a list the crawler learns to distrust.
Rendering checks
Rendering checks pass when every indexable fact and every internal link on a page is present in the initial HTML response, or at minimum in the rendered HTML that the URL Inspection tool shows. The check is run per template, because pages built from one template share their rendering behavior.
Three sub-checks complete it. No CSS or JavaScript file that the page needs is blocked in robots.txt, since Google does not render blocked resources. No page carries a noindex in its initial HTML that a script is expected to remove, since Google may skip rendering when it finds one. And every navigational link is an anchor element with an href attribute, since crawlers do not follow click handlers.
Indexation and canonicalization checks
Indexation checks pass when the number of indexed map URLs equals the number of map URLs, and canonicalization checks pass when the canonical each page declares matches the canonical Google selects. The first figure comes from the Page indexing report in Search Console, filtered to the map’s URLs. The second comes from URL Inspection, which shows the user-declared canonical and the Google-selected canonical side by side.
The supporting checks are about giving every topic exactly one indexable URL. The site resolves on one protocol and one host, with HTTPS and either the www or the bare domain, and every other combination returns a 301. Thin views, such as tag, date, search, and paginated archives, carry noindex, follow so they pass links without competing for the index. Parameter and filter URLs are kept out of internal links and declare the clean URL as canonical. Multilingual sites add one more check: hreflang annotations that are reciprocal between every language version.
A mismatch between declared and selected canonicals is diagnostic. It means Google found a stronger duplicate signal than the tag, usually internal links, sitemap entries, or redirects that point at a different version of the page.
Internal link depth checks
Internal link depth checks pass when every map page is reachable within three clicks of the homepage through crawlable links, and no map page is an orphan. Depth is measured with a crawler that starts at the homepage and records the shortest link path to each URL.
Orphans are found by comparison, not by crawling alone, because a crawler cannot discover a page nothing links to. The list of URLs in the sitemap is compared with the list the crawler discovered from the homepage, and any URL that appears only in the sitemap is an orphan. Breadcrumbs, hub pages, and contextual links between related pages are the usual fixes, and each one is added as a link the map already specifies rather than as a sitewide block of links.
Structured data checks
Structured data checks pass when each page outputs one valid JSON-LD graph, the graph states only what the visible text states, and each entity is defined once and referenced by its identifier everywhere else. Validity is tested with the Rich Results Test for features Google supports and the Schema Markup Validator for the full vocabulary.
Validation alone is not the pass condition. A graph can validate and still fail: two Organization nodes from two plugins, an author with no profile page, a price in the markup that differs from the price on the page. Each of these raises the cost of verifying the page’s claims, and the enhancement reports in Search Console show only the errors Google’s features care about, not these contradictions.
Speed and stability checks
Speed and stability checks pass when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less, at the 75th percentile of page loads on mobile and desktop. These are the Core Web Vitals thresholds published on web.dev, and the pass condition uses field data from real users, which the Core Web Vitals report in Search Console groups by similar URLs.
Lab tests in Lighthouse and PageSpeed Insights diagnose causes but do not decide the pass. The check is made per template, starting with the templates that carry the most search demand, because a fix in a template holds for every page built from it.
The technical SEO checklist in repair order
The technical SEO checklist in repair order has 15 checks, run from first to last, and a failure on important pages is repaired before the checks below it are trusted. The order follows the engine’s path from crawl to serve.
| # | Check | Pass condition | Tool |
|---|---|---|---|
| 1 | robots.txt | Returns 200 or 404, never a server error, and disallows no map URL | robots.txt report in Search Console |
| 2 | Status codes | Every map URL returns 200; retired URLs return 301, 404, or 410 | Site crawler |
| 3 | Redirects | No chains; every internal link points at a final URL | Site crawler |
| 4 | Soft 404s | None reported | Page indexing report |
| 5 | XML sitemap | Lists only 200, indexable, canonical map URLs | Sitemaps report; crawler in list mode |
| 6 | Initial HTML | Key facts and internal links present before scripts run | View source; URL Inspection live test |
| 7 | Blocked resources | No CSS or JavaScript needed for rendering is disallowed | URL Inspection page resources |
| 8 | Index coverage | Indexed map URLs equal total map URLs | Page indexing report filtered to the map |
| 9 | Canonicals | Declared canonical equals Google-selected canonical | URL Inspection |
| 10 | Thin views | Archives, search, and paginated listings carry noindex, follow | Site crawler |
| 11 | Protocol and host | One HTTPS host; every other variant returns 301 | Site crawler; HTTP header check |
| 12 | Click depth | Every map page within three clicks of the homepage | Crawler depth report |
| 13 | Orphans | Zero map pages without an internal link | Sitemap list compared with crawl list |
| 14 | Structured data | One valid graph per page that matches the visible text | Rich Results Test; Schema Markup Validator |
| 15 | Core Web Vitals | LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less at the 75th percentile | Core Web Vitals report; PageSpeed Insights |
Checks 1 to 11 belong to the technical layer of Holistic Radar’s repair order, checks 12 and 13 to the network layer, and check 14 to consistency, while check 15 is a technical condition measured last because it needs pages that are already indexed and visited. Each failing check produces one repair item, assigned to the template or rule that causes it, so a single fix can close the same failure on hundreds of URLs.
Technical SEO checklist on holisticradar.com
Holistic Radar runs the same 15 checks on holisticradar.com, and each pass condition is met by a rule in the theme rather than by page-by-page editing. The table shows the state of each area.
| Area | State on holisticradar.com |
|---|---|
| Sitemap | Generated by Rank Math and filtered by the theme to URLs that resolve with a 200; redirected URLs, old slugs, and taxonomy archives excluded |
| Redirects | Old article slugs return a 301 to the one live permalink; author archives return a 301 to the matching team profile; attachment pages return a 301 to their parent |
| Thin views | Category, tag, date, search, and author views, paginated listings, and 404 pages carry noindex, follow |
| Rendering | Content and links are server-rendered from PHP templates; scripts are deferred and carry no content |
| URLs | Distilled slugs such as /learn/semantic-seo/ rather than question-form slugs |
| Internal links | Five link types: hub to node, node to hub, lateral, contextual bridge, and forward, plus navigation and breadcrumbs |
| Structured data | One JSON-LD graph output by the theme, with the plugin’s schema output disabled |
| Speed and stability | Mobile performance 91, Total Blocking Time 0 ms, and Cumulative Layout Shift 0, measured in September 2026 with Lighthouse 13.5 on slow 4G; CSS combined into one file; logo served as a 6 KB WebP instead of a 31 to 39 KB PNG |
The sitemap filter is the clearest example of a check enforced by a rule. Check 5 fails on most WordPress sites because the sitemap plugin does not know which URLs the theme or a redirect plugin sends elsewhere. On holisticradar.com the sitemap is built from the same redirect map that issues the 301s, so the two cannot disagree.
The technical SEO checklist in technical SEO services
The technical SEO checklist is the diagnostic step inside technical SEO services, which add prioritization, repair, and monitoring to it. A checklist tells a site what is broken; it does not say which failure costs the most demand, which fix unblocks the others, or how to stop the same failure returning with the next plugin update.
Those are the decisions a technical SEO service adds to the checklist: ranking failures by the query clusters they affect and the conversion exposure behind them, assigning each fix to the template that causes it, and monitoring the pass conditions after the repair so that a regression is caught in days rather than at the next audit.
A reader who has run the 15 checks and found failures needs that prioritization and that monitoring more than another list.
→ Technical SEO services: how Holistic Radar ranks, repairs, and monitors technical failures by the demand they affect.
Technical SEO checklist frequency, tools, and site migrations
How often should a technical SEO checklist be run?
A full technical SEO checklist should be run every quarter and after every template, theme, plugin, or platform change, with checks 2, 4, 8, and 15 monitored weekly. The weekly checks catch the failures that appear without anyone changing the site, such as server errors, newly excluded pages, and slower templates after a third-party script update.
Which tools does the checklist need?
The checklist needs Google Search Console, a site crawler that reports status codes and click depth, PageSpeed Insights, the Rich Results Test, and access to server logs. Search Console supplies the engine’s view of indexing, canonicals, and field data, the crawler supplies the site’s own link graph, and logs show what every crawler, not only Google’s, actually requested.
How does the checklist change for a site migration?
A site migration runs the checklist three times: on the old site as a baseline, on the staging site before launch, and on the live site on launch day, with a one-to-one 301 map from every old URL to its new owner. After launch, a 404 monitor and the Page indexing report are checked daily until indexed map URLs return to the baseline. A move to a new domain also uses the Change of Address tool in Search Console.
Does a small site need the full checklist?
A small site needs the full checklist, although crawl budget, the reason checks 3, 5, and 10 carry the most weight on large sites, is rarely the constraint below a few hundred pages. Status codes, canonicals, rendering, structured data, and Core Web Vitals fail on small sites as often as on large ones, and with fewer pages each failure affects a larger share of the site.