> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clickproof.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Web testing

> How a website project runs: a real hosted Chromium browser, driven from a plain-English test, with a video, a trace, and the browser's own console and network activity.

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.

<CardGroup cols={2}>
  <Card title="Sees the page two ways" icon="eye">
    A screenshot, plus the list of elements actually on screen and what each one
    is called.
  </Card>

  <Card title="Clicks the element" icon="mouse-pointer-click">
    Not a coordinate. A button that moves ten pixels, or down the page, is still
    the same button.
  </Card>

  <Card title="Handles tabs" icon="copy">
    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.
  </Card>

  <Card title="Watch it live" icon="wifi">
    The browser is streamed to the report while the run is in progress.
  </Card>
</CardGroup>

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="Write a test">
    Describe an outcome in plain English and say what proves it passed. See
    [Projects and tests](/essentials/projects) for what makes a good one.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  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.
</Note>

## 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:

|             | What it shows                                                 |
| ----------- | ------------------------------------------------------------- |
| **Console** | Errors and warnings the page logged while the agent was on it |
| **Network** | The requests it made, and how they came back                  |

That turns "checkout failed" into "checkout failed, and here is the 500 the page
got when it did." Both are on the run report.

<Warning>
  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.
</Warning>

## 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](/ci-cd/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](/ci-cd/pull-requests) for how a suite
behaves when the allowance runs short.