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

# Web pull request testing

> How a change review finds the preview URL for a web application.

A web change review needs the URL where that pull request is deployed. QA.tech does not guess a production URL when a preview exists.

## Where the preview URL comes from

The review uses the first source that is ready:

1. A deployment your Git host reports for the pull request head. On GitHub, publish that URL as a [GitHub Deployment](/configuration/github-deployments) with status `success` and `environment_url` set. Map each deployment environment name to the QA.tech application when the project has more than one app.
2. A URL in a `@qa.tech` comment on the request. That URL is the preview, and the review does not wait for a deployment record.
3. A URL you pass from CI in `applications_config` (GitHub) or `applicationOverrides` (the change review API). Use this when the project has more than one application, or when the review must wait for a specific deploy job. See [GitHub](/pr-testing/github) and [API](/pr-testing/api).

If the preview is behind Vercel deployment protection, add the [Vercel preview bypass](/configuration/vercel-preview-protection) so the agent can load it.

<Note>
  A mobile review uses an uploaded build, not a preview URL. See
  [Mobile](/pr-testing/agents/mobile). An API review uses the API base URL. See
  [API](/pr-testing/agents/api).
</Note>