SEO and landing-page checks on production, read-only, every day

A read-only run of your public pages as a visitor: headings, metadata, hreflang, Open Graph, structured data, overflow, console. Shared, compared with yesterday, fixed before anyone else notices.

The landing page is the one screen everybody has an opinion about and nobody checks after Tuesday's deploy. QAwalk runs it as a visitor every day, in every language and viewport, and shows what moved.

The problem

Metadata breaks quietly: a description gets truncated, hreflang points at the wrong locale, a console error appears with a new script. We find out from a report weeks later.

What changes with QAwalk

A scenario of your public pages with countable criteria: exactly one H1, description at least 50 characters, hreflang for every language, no horizontal overflow, no console errors, terms linked. Plus a few questions for judgement: is the primary action clear, does the page say what happens after sign-up. Production is always read-only in QAwalk, so nothing can be changed on the way.

How it works

Describe the pages
a flow scenario with readonly: true, one step per public page, path per locale, deterministic checks for metadata and layout, semantic questions for clarity. QAwalk's own public-pages scenario is a template.
Run against production
qawalk start --scenario qa/flows/public.yml --env production, qawalk walk, qawalk evaluate, qawalk share. The CLI refuses anything but GET on production and blocks the paths you list.
Compare with yesterday
qawalk compare or the *Compare* selector shows changed verdicts, evidence and pixels; the metadata table in the lightbox marks missing and duplicate tags.
Schedule it
a small CI job runs the same four commands daily; a read-only token is enough to read results, a tester token to share them. QAwalk does exactly this to itself.

Skills and prompts

Write a read-only scenario for our public pages (home, pricing, sign-up, terms) in cs and en with SEO and layout criteria, run it on production and share it.

Expected outcome: qa/flows/public.yml with per-locale paths, a shared run, the summary line and a list of failing or unreviewed criteria with evidence.

Compare today's public-pages run with yesterday's and tell me only what changed in metadata or layout.

Expected outcome: a short list from the comparison; unchanged pages are named as unchanged.

What you get

Page metadata as a table per step: title, description, canonical, hreflang, Open Graph, JSON-LD, with the criteria that hit each row.
A daily history of your public pages you can scroll back through.
Findings with evidence, not a score.

FAQ

Is this a replacement for Search Console or Lighthouse?

No. It shows what is actually rendered on your pages and what changed; rankings and performance come from other tools. A performance and accessibility pack is on the roadmap.

Does the run store personal data?

Public pages as a visitor contain none by design; keep production scenarios to public pages and never sign in there.

What it looks like

A real run of QAwalk on its own public pages, refreshed daily. This is the canvas your team gets.

6 of 6 steps passed · 2026-09-24Open the run in QAwalk ↗

More guides

Accepting a task with an AI agent, in the pull request Regression before a release: compare the run with the accepted baseline E-mail flows: capture the message next to the screen that sent it