Website QA Agent
A website quality console that crawls a site in a real Chromium browser and turns SEO, accessibility, performance, frontend, network, security and privacy problems into organized, evidence-backed findings with suggested fixes.

15
checks ready to run, in a grid of 24
6
audit areas, plus privacy and tracking checks
Live
progress with ETA, coverage and navigation steps
2
run modes: local SQLite or a BullMQ + Redis queue
Inside the product
See it working
Real screens and a recorded run, captured from the working product.
Animated welcome intro, the description typing itself out.
01 / 10My role
Sole engineer: the scan engine, the worker and queue, the dashboard and the security model.
The problem
Checking a website properly means juggling separate tools for SEO, accessibility, performance, console errors, network failures and security headers, and none of them crawl the site the way a real visitor's browser does. Teams get scattered reports with no single place to triage what to fix first.
What I built
A Turborepo monorepo with a Next.js "Run Center" dashboard and a Playwright scan worker. A scan is configured with a target URL, a scan mode, crawl depth, page, request and time budgets, request rate and retries, plus a grid of 24 checks (15 available today) across discovery, experience, devices, quality, and security and APIs. Profiles can be saved and reused.
While a scan runs, the dashboard shows status, elapsed time, ETA, pages scanned, queued and failed URLs, blocked and skipped pages, API endpoints, feature-check progress, the latest worker events and live navigation steps, with a Stop button. Results are grouped by page, severity, status and technical area, with evidence, suggested fixes and triage.
Architecture
The engine audits each page in a real Chromium browser: title and meta quality, heading structure, canonical conflicts, JSON-LD validity and status codes; alt text, heading order and small text; LCP, CLS, TBT, transfer size and oversized JavaScript; console errors; failed and duplicate requests; missing security headers and exposed source maps; trackers without consent and PII or secrets in URLs (redacted before storage); overflow, broken media, duplicate IDs and RTL or language mismatches. Scans run through a local polling worker on SQLite, or through BullMQ and Redis with a scheduler for distributed execution. Contracts between the dashboard and the worker are Zod schemas.
Challenges
A crawler that follows links on someone else's site can be turned against your own network or can trigger destructive actions. Every target and every in-page request therefore passes an SSRF guard that resolves DNS and rejects private, loopback, link-local and cloud-metadata addresses, and logout or destructive URLs are never followed.
Key engineering decisions
Real-browser crawling instead of raw HTTP so runtime errors, layout problems and performance metrics match what visitors see. Budgets on pages, depth, requests and minutes so a scan always ends. Stored credentials encrypted with AES-256-GCM and operator authentication required in production.
Results & impact
A complete scan workflow from configuration to triaged findings: Standard, Deep and Custom modes, 15 working checks across SEO, accessibility, performance, frontend, network, security and privacy, live progress without refreshing, reusable profiles, and a results workspace that ties every finding to its page, evidence and suggested fix. The interface ships in English and Arabic with dark and light themes.
Highlights
- Run Center with scan modes, budgets and a grid of selectable checks
- Live run progress with ETA, coverage counters, events and navigation steps
- Crawl policy: include and exclude patterns, query-parameter rules, subdomain and external-domain policies
- SSRF-safe target and request validation, destructive-action and logout protection
- Secret and PII redaction before anything is stored
- English and Arabic (RTL), dark and light themes, animated welcome intro

