Skip to main content
A website project tests a URL. There is no build to produce and nothing to install: you give clickproof an address, and each run opens a real browser there and works through your test the way a person would.

​
What actually runs

Every run gets its own hosted Chromium browser, in a desktop-sized window (1280x800). It is a real browser, not a headless emulation of one and not a recorded script being replayed: the agent looks at each screen, decides the next action, and takes it.

Sees the page two ways

A screenshot, plus the list of elements actually on screen and what each one is called.

Clicks the element

Not a coordinate. A button that moves ten pixels, or down the page, is still the same button.

Handles tabs

A link that opens a new tab does not silently strand the run. The agent can list the open tabs and switch to the right one.

Watch it live

The browser is streamed to the report while the run is in progress.
That second point is the practical difference from a selector-based suite. A recorded Playwright or Cypress test fails when the DOM moves under it, whether or not a user would have noticed. An agent reading the page fresh each turn does not, which is why these tests survive a redesign that would have broken a selector.

​
Setting one up

1

Create the project

Choose Website and give it a URL. That is the whole setup - you land on the Tests tab immediately, because there is nothing else to configure.
2

Write a test

Describe an outcome in plain English and say what proves it passed. See Projects and tests for what makes a good one.
3

Add credentials, if a flow needs a login

Store a test account on the project rather than writing it into a test. It is encrypted at rest and never appears in a report.
The URL has to be reachable from the public internet. localhost, a VPN-only host, or an IP-allowlisted staging environment will not load. Point the test at a deployed preview instead.

​
What a web run gives you back

Everything a mobile run does - verdict, reasoning, step trace with screenshots, and a full video recording - plus two things only a browser can offer: That turns “checkout failed” into “checkout failed, and here is the 500 the page got when it did.” Both are on the run report.
Console and network activity are visible to your team on the run page, but a shared /share/<token> link deliberately leaves them out. Request and response detail routinely contains tokens and personal data, and a share link is meant to be forwardable to someone without an account.

​
In CI

A website project needs no artifact configuration. Connect the repository on the project’s PR Testing tab and clickproof waits for a successful preview deployment - Vercel, Netlify, Cloudflare Pages, or anything else that reports one to GitHub - then tests that deployment and posts the verdict back to the pull request. Full detail: Testing pull requests.

​
Cost

Each test in a run counts once against your plan’s allowance, the same as an Android run. Only iOS counts double, because an iOS run is billed at twice the device rate. See Testing pull requests for how a suite behaves when the allowance runs short.