Kaloko

All guides › By use case

By use case

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. Kaloko 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 Kaloko

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 Kaloko, so nothing can be changed on the way.

How it works

  1. 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. Kaloko's own public-pages scenario is a template.

  2. Run against production

    kaloko start --scenario qa/flows/public.yml --env production, kaloko walk, kaloko evaluate, kaloko share. The CLI refuses anything but GET on production and blocks the paths you list.

  3. Compare with yesterday

    kaloko compare or the *Compare* selector shows changed verdicts, evidence and pixels; the metadata table in the lightbox marks missing and duplicate tags.

  4. 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. Kaloko 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

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 Kaloko on its own public pages, refreshed daily. This is the canvas your team gets.

10 of 10 steps passed · 2026-09-29Open the run in Kaloko ↗

More guides

Accepting a task with an AI agent, in the pull requestRegression before a release: compare the run with the accepted baselineE-mail flows: capture the message next to the screen that sent itMobile apps: walk Android and iOS screens like web pages

Install once, then work through your agent

Kaloko runs where your code and your agent are. The service stores and versions the results, shows the canvas and collects approvals.

  1. Add the CLI to the project
    npm install --save-dev kaloko

    Needs Node 20 or newer. Update later with npm update kaloko.

  2. Create the config and install the skill
    npx kaloko init --agent claude --org <your-org>

    The skill is copied to .claude/skills/kaloko. npx kaloko doctor checks Chrome, the config and the token.

  3. Create your organization and a token

    Create an organization; you become its admin. The start page offers a tester token in one click, later under Settings → API tokens. Put it into the project .env:

    KALOKO_TOKEN=qwk_…
TYPESAFE_API_KEY=…   # optional: semantic evaluator

Then just ask your agent

The skill teaches your agent the whole loop: it writes the acceptance plan and the scenario from the task, walks the screens, evaluates, shares the canvas, reads what reviewers said and fixes it. You do not type the commands; you review the canvas.

What the agent runs (or run it yourself, e.g. in CI)

The same loop by hand:

npx kaloko start --scenario docs/tasks/TASK-123/qa/scenario.yml --env local
npx kaloko walk        # playwright steps; agent/manual steps: kaloko capture
npx kaloko evaluate
npx kaloko share --pr
npx kaloko feedback    # what reviewers said, with ids to answer