Technical SEO checklist: inventory, discovery, responses, rendering, release, and monitoring

What to take away

Cover six areas in orderinventory and discovery, responses and controls, canonical and rendering, page data, release, and monitoring.
Score every item pass, fail, unknown, or not applicable, with a sample URL, evidence, owner, impact, action, and review date.
Verify against the live HTTP response and a crawler's view of the rendered page, not a staging screenshot.
Re-run the affected sections after template, crawl-policy, data-model, or migration changes.
A completed pass documents agreed state. It never guarantees indexing, ranking, or customer value.

Six sections in the order you run them

A checklist that opens with title tags tests the wrong layer. Inventory decides which URLs exist, and every later check scores an item from that list.

Six sections in order

Section	Sample items	Evidence to keep
Inventory and discovery	URL inventory, orphan pages, crawl depth, internal links	Crawl export reconciled with server logs
Responses and controls	Status codes, redirects, robots.txt, meta robots	Raw response headers and bodies
Canonical and rendering	Canonical tags, hreflang, rendered HTML	Source HTML beside the rendered DOM
Page data	Titles, headings, structured data	Rendered output plus validator result
Release	URL mappings, rollback criteria, capacity	Deploy record and test output
Monitoring	Errors, availability, key actions	Dashboard snapshot and alert config

Page-level items go faster in a fixed sequence, and the on-page SEO checklist walkthrough shows how that order avoids repeat work.

Inventory and discovery

Reconcile the XML sitemap against a crawl export and against server logs. A URL in one source and missing from another is the finding.
List orphan pageslive URLs with no internal link pointing to them.
Record crawl depth for money templates. More than four clicks from the home page is a distribution problem.
Count internal links per destination and map pagination and filter patterns.

Filters and facets create near-duplicate URLs that soak up crawl capacity, a trap set out in the faceted search overview. Crawlers spend a finite request budget, explained in the web crawler description.

Inventory and discovery checks

Page typesowners, rules, stable URLs
Crawlable internal links reach destinations
Find orphan, parameter, duplicate, staging URLs
Sitemapsabsolute canonical URLs, truthful dates

Responses and controls

Test what each URL returns, and whether crawlers may fetch it.

Request every template and record the status line, Location header, and cache headers.
Compare the response to intent200 live, 301 permanent move, 410 retired, 5xx for real faults.
Fetch robots.txt per host and environment. Test one allowed path and one blocked path.
Inspect meta robots and X-Robots-Tag in the raw response and on the rendered page.
Follow each redirect to its final URL and count the hops.

Keep redirect chains to one hop where the template allows it.

Is a finding a defect or normal noise? The technical SEO benchmarks comparison puts inventory, rendering, and recovery figures side by side, so the call is defensible.

Canonical, rendering, and page data

Canonical tag present, absolute, and self-referencing on unique pages.
One canonical per page, matching the sitemap entry.
hreflang pairs reciprocal for en-US and fr-CA.
Rendered HTML matches source HTML for canonical and robots directives.
JSON-LD parses and describes content visible on the page.

JavaScript templates often inject the canonical after load. If the source HTML carries a different one, search engines may read the wrong signal. The hreflang attribute reference covers the return-link rule that bilingual Canadian sites break most often.

A blocked resource hides directives from crawlers, a case covered in the technical SEO mistakes review.

Canonical, rendering, page data

Links, redirects, canonicals converge on one URL
Source and rendered HTML match essentials
Structured data matches visible fields
Localized versionsstable URLs, language signals

Scoring, evidence, and the release gate

Scoring and release gate

Checklist state	Required record	Next action
Pass	Live sample, timestamp, expectation, reviewer	Monitor at the defined trigger
Fail	Impact, scope, cause, dependency, owner	Correct or accept with named authority
Unknown	Missing data, access, or judgment	Assign investigation and due date
Not applicable	Reason, scope, approving owner	Revisit after material change
Released	Production verification and outcome window	Confirm, revise, or reverse

Block a release when a failure causes broad missing content, false responses, a broken transaction, an access exposure, or uncontrolled migration risk. Everything else gets an owner and a date.

Example: one pass and one fail record

A pricing page passes: 200 response, self-referencing canonical, one H1, valid Product schema. Evidence is a dated header dump and a saved rendered DOM. Owner is the platform team, with review set at the next template change.

Fail: /collections/sale?page=3 returns 200 and declares itself canonical. Impact: consolidation splits across the facet set. Owner: search team. Action: canonical to the parent category, then re-crawl. Review: 14 days after the fix ships.

Recheck triggers and monitoring

Track availability, error rate, and the key customer action per page type and device. Automated tests cover critical routes, canonicals, sitemaps, and rendered content. Those tests fail loudly and early, which is the point.

A migration adds URL mappings, capacity checks, rollback criteria, and old-to-new monitoring. When a check fails, naming the broken stage is faster than re-reading the list, which the guide to improving technical SEO works through.

Recheck the changed sections after any template, policy, or data-model change. Sample errors, redirects, localized pages, and JavaScript routes. Close a finding only when the live response, crawler view, monitoring, and customer path all match intent.

Common questions

What belongs in the first section of a technical SEO checklist?

Inventory and discovery. Reconcile sitemaps, crawls, and server logs, then list orphans, crawl depth, internal links, and filter patterns before scoring anything else.

How should each item be scored?

Pass, fail, unknown, or not applicable, with a sample URL, evidence, owner, impact, action, and review date. A percentage hides one high-impact open failure.

Which failures should block a release?

Those causing broad missing content, false responses, broken transactions, exposure of restricted material, or uncontrolled migration risk.

How often should the checklist be re-run?

After every deployment that touches templates, crawl policy, or data models, and on a set calendar for monitoring items. Full passes belong before migrations.