Staging website audit guide

Pre-launch QA is a final, evidence-based review of the pages and public behavior that can be checked before launch. A staging scan helps you catch issues early, then a separate production scan checks the live environment after deployment. Neither is a guarantee that every page or user flow is correct.

Choose the environment in the project settings. The selected environment controls production-specific launch checks; a staging-like hostname can suggest a default, but does not replace confirming the setting.

The crawl runs from a Launch Ready worker, not your browser, VPN, or local network. The starting URL must be reachable over HTTP(S) from the public internet.

• Use a public DNS name and allow the worker to fetch the site. Private-network, loopback, or reserved IP addresses are refused, and IP allowlists or network policies can make a site unreachable.
• For HTTP Basic Auth, save the credentials in the project's Staging HTTP auth settings. They are encrypted at rest and sent only to the configured host and port. Prefer HTTPS; HTTP credentials are sent only when the configured starting URL itself uses HTTP.
• Bot challenges are not bypassed. If protection, a firewall, DNS, TLS, or the origin blocks the worker, the report may show blocked or incomplete coverage rather than findings for pages it could not inspect.
• Basic Auth is not a browser login session. The scanner does not sign into an application, use a customer's cookies, submit forms, or test logged-in workflows.

How we scan

Run these checks before release, fix findings in your staging deployment, then scan production separately after it is live.

1. Create a project with the full public staging URL, including HTTPS where available.
2. Confirm the project environment is set to Staging; do not rely only on the hostname-based suggestion.
3. If the site uses Basic Auth, save it in the project's staging-auth settings. Do not put credentials in the URL.
4. Start a scan and wait for its report. If the site is blocked or only partly crawled, resolve access or review the reported coverage before relying on the results.
5. Review category findings and evidence, fix relevant issues, and re-scan. After deployment, create or update the production project and run a production scan.

The report groups checks into these categories. The linked rule modules show what is implemented; actual findings depend on reachable pages, scan coverage, and plan entitlements.

• Technical reliability

  Availability and HTTP status, internal and external links, redirects, loaded assets, and security-header signals.

  Rule evidence: technical.ts, headers.ts

• SEO / indexability

  Titles, descriptions, headings, canonical and robots signals, sitemaps, structured data, social previews, hreflang, and an optional llms.txt signal.

  Rule evidence: seo.ts, schema.ts, og.ts, hreflang.ts, ai-visibility.ts

• Analytics / marketing

  Recognized analytics and marketing tags, expected integrations where configured, and duplicate installations.

  Rule evidence: analytics.ts

• Content QA

  Placeholder or dummy content and, on production scans, links that still point to staging or preview hosts.

  Rule evidence: content.ts

• Forms / conversion

  Form markup, call-to-action details, and suspicious local or staging destinations. Forms are inspected, never submitted.

  Rule evidence: forms.ts

• Performance

  Page response timing and Lighthouse performance signals on the homepage only when the scan entitlement includes them.

  Rule evidence: performance.ts

• Accessibility

  Automated markup checks such as missing image text, unnamed controls, and heading order; this is not a full accessibility audit.

  Rule evidence: accessibility.ts

• Compliance signals

  Signals such as privacy/terms links, cookie notices, and analytics consent indicators; this is not legal advice or a compliance determination.

  Rule evidence: compliance.ts

See the report layout and sample findings: See an example report

The configured plan or Full Scan funding determines page limits and which checks run. These values come from the current code defaults and may be overridden by deployment configuration.

Free scans are limited to 25 pages by default. A larger site is sampled, not fully scanned. Pages missed because of access restrictions, crawl limits, rendering failures, or unavailable checks are not covered; review the report's coverage details.

A Full Scan credit is a separately funded one-off scan with its own 300-page, full-category and Lighthouse snapshot. It is not a subscription upgrade; an available credit and supported worker are required. A Full Scan still does not guarantee that every page is reachable or checked.