How to run a technical SEO launch review on data and sources

What to take away

A technical SEO launch review is a structured check of a site's crawl, index and rendering setup at go-live, judged against named data sources rather than tool dashboards alone.

Assess crawl behaviour, status codes, indexability, canonical signals and accessibility conformance. Leave rankings, conversion and content quality to separate reviews.
Treat vendor scores as claims, not evidence. Log the source of every number in a dated column.
Keep a written note of what was not checked, so the next reviewer does not assume coverage.
Record who owns the review, the handover and any follow-up.

Scope: what gets assessed and what does not

A launch review covers the mechanics a search engine must complete before it can rank anything. That means robots directives, HTTP status handling, canonical tags, sitemap accuracy, internal linking depth and render behaviour.

It does not cover keyword targeting, copy quality, backlink profile or commercial performance. Those need their own method and their own owner.

Write the exclusions into the report. A reviewer who stays silent on scope invites the reader to assume the whole site was cleared.

Source hierarchy for the review

Order sources by independence. Server logs and response headers come first because they record what happened, not what a tool inferred.

Source hierarchy by independence

Server logs & headers

Records: What happened
Verifiability: Highest
Use for: Interpret logs
Order: First

Standards & statistics

Records: Published context
Verifiability: High
Use for: Size audience
Order: Second

Vendor dashboards

Records: Tool inference
Verifiability: Lowest
Use for: Fast checks
Order: Last

Google Search Central's “HTTP status codes, and network and DNS errors” and its crawling and indexing documentation explain why a soft 404 or a 5xx during launch can affect crawling and indexing. Use this guidance to interpret log entries, not to replace them.

Standards provide criteria rather than site-specific evidence. W3C's “What's New in WCAG 2.2” summary points to the current standard; use the published WCAG 2.2 success criteria themselves for accessibility checks.

Vendor dashboards and crawl scores are useful for discovery, but they are the least independent layer: results depend on settings and should be checked against logs, headers and search-engine data.

For site crawls, use Screaming Frog SEO Spider or Sitebulb, recording the crawl settings and scope. Google Search Console's URL Inspection and Crawl Stats reports, alongside Bing Webmaster Tools, provide search-engine-side checks; compare these with the crawl rather than treating any one view as complete.

Use Screaming Frog Log File Analyser or GoAccess to inspect server logs, crawler requests and response codes. For rendering, use Google Search Console's URL Inspection live test and Lighthouse; Google's Rich Results Test checks structured-data eligibility, not general indexability.

Separating vendor claims from evidence

Every commercial tool makes claims about coverage, crawl volume and accuracy. None of that is evidence about your site.

Record each claim with the date it was made and the version tested. Then record what you independently confirmed. Two columns, one page.

Where a claim cannot be checked, mark it unverified rather than repeating it. This is editorial judgement, not a test result, and the report should say so plainly.

Claim log fields

Use a fixed set of fields so entries stay comparable across launches: claim, vendor, date, version, independent check, outcome, reviewer.

Evidence grading

Grade each finding A, B or C. A means confirmed from logs or headers. B means confirmed from two independent sources. C means single-source or unverified. Publish the grades alongside the findings.

The launch checklist

Confirm robots.txt and meta directives allow the intended paths.
Crawl key templates with Screaming Frog SEO Spider or Sitebulb. Check status codes and record any 5xx or soft 404 responses.
Verify canonical tags point to the intended URL on every template.
Compare the XML sitemap against a full crawl and note gaps.
Inspect key URLs in Google Search Console's URL Inspection; review Crawl Stats for crawl patterns and compare with Bing Webmaster Tools.
Analyse server logs with Screaming Frog Log File Analyser or GoAccess, and check crawler requests against response headers.
Check rendered HTML using the URL Inspection live test and Lighthouse. Use Google's Rich Results Test for structured-data eligibility, not as a general indexability test.
Check WCAG 2.2 success criteria 2.4.11 (Focus Not Obscured (Minimum)), 2.5.7 (Dragging Movements), 3.3.7 (Redundant Entry) and 3.3.8 (Accessible Authentication (Minimum)). Test keyboard focus visibility, alternatives to dragging, reuse of previously entered information and accessible authentication.
Record every source, date and grade in the claim log.

Reviewing the review

A launch review is only as good as its ownership. Someone must sign the scope, the exclusions and the grades before publication.

Assign the reviewer, delivery owner and log maintainer before sign-off. The delivery owner signs the scope and exclusions; the reviewer records the evidence and grades, with approval documented.

Set a recheck date. Launch conditions change within weeks, and an undated review quietly becomes a historical document.

Common questions

How long should a launch review take?

For a mid-sized site, allow two to three working days from log access to signed report. The crawl itself is quick; grading and scope sign-off take longer.

Can a tool score replace the review?

No. A score is a vendor claim about its own crawl. It can seed the checklist, but logs and headers must confirm each finding.

What if a source disagrees with the tool?

Log both, grade the independent source higher, and note the conflict in the report. Do not average the two.

Who signs off the exclusions?

The delivery owner, not the reviewer. Exclusions define risk appetite, and that sits with the person accountable for the launch.