Scanner core
8 check families
Meta tags, performance, images, links, SSL/HTTPS, content depth, mobile viewport and technical robots/noindex checks are executed as separate issue sources.
Live motion layer · QA telemetry
Technical SEO & Deploy QA
Crawls, browser checks, issue scoring and release evidence
Use case · Real build pattern, generalised
Technical SEO scanner and deploy QA automation
Turn launch checks into a repeatable system: crawl the site, score issues, record what changed, then verify the live deploy with browser evidence before calling it done.
Based on real implementation patterns from the ManchesterAI build archive, generalised for public explanation. This is not a named client claim, not a ranking guarantee and not a replacement for human SEO judgement.
8 scanner check families12 implemented issue types8-table scan/report data model
Problem pattern
Most launch mistakes are boring, repeatable and preventable
Small sites often break in the same places: missing titles, noindex tags, thin pages, placeholder links, missing image alt text, weak mobile setup, slow media and untested live redirects.
A useful QA system does not pretend to “solve SEO”. It gives the operator a release gate: what was crawled, what failed, how severe it is, what changed, and what still needs a human decision.
Implementation proof
A scan-to-report system, not a one-off checklist
The source pattern combines a Next.js dashboard, Supabase data model and a Puppeteer/Lighthouse scanner so every run can produce structured issue records and a reviewable report.
Issue model
12 implemented issue types
Examples include missing title, title too long, missing description, missing/multiple H1, slow load, missing alt text, placeholder links, missing SSL, thin content, missing viewport and noindex.
Data model
8 database tables
Users, sites, scans, issues, issue templates, scan comparisons, payments and scan queue tables make the report auditable instead of a disposable text file.
Workflow state
Pending → crawling → analyzing → completed
Scan status and failed-state handling make the system suitable for background jobs, retries, monitoring and later comparison views.
Deploy QA gate
The same pattern applies after every site change
For a static or Netlify site, the useful release gate combines machine checks with a narrow browser pass. It should prove the live domain is serving the intended artifact.
Sitemap and route crawl
Check every sitemap URL returns 200, maps to the expected canonical page and has title, H1, robots and working first-party assets.
Structured data and indexability
Parse JSON-LD, inspect canonical/robots/noindex, verify special files such as sitemap.xml, robots.txt and llms.txt, and keep private preview hosts noindexed.
Risk and leakage sweep
Scan rendered output for private repo paths, credentials, client names, unsupported metrics and internal build language before publishing public proof.
Mobile browser evidence
Use live browser checks for horizontal overflow, console/network errors, broken images, video assets and real screenshot review on narrow screens.
Boundaries
Honest automation is explicit about its limits
The source scanner is a strong architecture proof, but the public promise should stay practical: a maintained QA workflow, not magic rankings.
No ranking guarantee
Passing technical checks improves launch hygiene, but content quality, links, intent fit and brand trust still need human work.
Homepage-only source scanner
The source implementation notes that the initial scanner handles the homepage first; full production deployments should add multi-page crawling and sitemap validation.
Human release owner
Automation can flag noindex, broken links and missing metadata, but someone still decides which pages should exist, redirect or stay private.
Evidence over vibes
Every “done” claim should include crawl counts, route checks, console/network status, screenshots and the final deploy ID or live URL.
Public-safe proof: this describes a real scanner/reporting architecture and the release discipline used around small sites. It avoids private repo names, credentials, client identities and invented SEO results.
Define the release gate
Choose the routes, special files, schema blocks, assets and browser states that must pass before publish.
Run automated checks
Crawl URLs, parse metadata/schema, classify issues, assign severity and store the result.
Review the report
Fix critical blockers first: noindex, broken routes, missing canonical/schema, private leakage, form or CTA failures.
Verify live after deploy
Check the custom domain, console/network, mobile overflow, screenshots and final sitemap state before handoff.
Next step
Want fewer “it looked fine locally” launches?
Send one site or release process. We will design a practical crawl, report and browser-QA gate around the way you already publish.