SiteCheck guide

This free preview inspects supplied HTML in your browser. The separate local browser runner checks rendered accessibility, viewport layout and runtime behavior. Neither covers complete user journeys or replaces a release review.

Open workspace

Report files

JSON reports are limited to 8 MiB (shown as 8 MB). Small downloads are formatted for reading; larger reports use compact JSON so the exported file still fits the same import limit. This changes whitespace only and retains every validated finding. The local audit command uses the same rule. Reports that cannot fit are rejected before creating a saved report folder. Keep the original source and review private evidence before sharing.

Inspect HTML

1. Paste a complete HTML document or choose a UTF-8 .html/.htm file, up to 1 MB. “Example” loads a small page with intentional issues.
2. Optionally enter the page URL. This is used to resolve relative URLs and identify mixed content; the website does not fetch it.
3. Select Inspect HTML. Filter the report, open findings and export JSON, CSV or text. Clear the workspace when finished.

Source checks

Document type, language, title, description, canonical URL, viewport and zoom settings, charset, headings, duplicate IDs, image alt attributes, form labels, button/link names, fragment targets, insecure active resources, indexing directives, Open Graph presence and structured-data JSON syntax.

Rules check specific conditions. For example, an alt attribute can be present but poorly written. A valid JSON-LD document can contain incorrect claims. A noindex directive can be correct for a private app page. Review findings are context-dependent and are not automatically defects.

Finding statuses

• Failed: the checked condition produced evidence of a problem.
• Needs review: context or manual judgment is required.
• Passed: this rule found no issue within the tested scope.
• Not run: the input or execution mode cannot establish the result.

SiteCheck does not invent a single readiness grade from these counts. Static checks never claim to have measured contrast, executed scripts or followed links. Each rule includes at most 100 affected examples. Very large or deeply nested documents are rejected to keep processing bounded.

Browser audit workflow

The browser runner is currently available in the development repository. Hosted URL scanning, user accounts, scheduling and paid plans are not enabled in this preview. The runner requires Node 24, the project's pinned dependencies and its Chromium browser.

npm ci
npx playwright install chromium
npm run audit -- url https://your-site.com/ --authorized
npm run audit -- html ./index.html https://your-site.com/

Run browser checks only on sites you control or have permission to test. The authorized flag is a local operator assertion; it is not hosted account verification. Hosted scanning is being built around an account-bound proof file at /.well-known/sitecheck.txt, authenticated quotas and isolated workers.

Browser reports contain desktop axe-core WCAG 2/2.1 A/AA findings, horizontal overflow checks at 1440×900 and 390×844, console/runtime observations, requested resource HTTP responses and a synthetic DOMContentLoaded measurement. Desktop/mobile viewport screenshots and a private HTML review are saved beside the report. Cross-origin frames, logged-in flows, form submissions and full end-to-end journeys are not covered. Optional navigation and visual checks are described below.

The request policy allows HTTPS on port 443 to public domain names. Each DNS result is checked and pinned before connection. Private/reserved addresses, credentials, write requests and WebSockets are blocked. Only the target origin loads by default; approved public asset origins can be listed after the authorized flag. No cookies or authorization headers are forwarded. Blocked dependencies appear in the report because they can affect what rendered.

The browser has a 45-second deadline, 80-request budget, 2 MB per-response limit and 16 MB total response budget. Page scripts are executed only in browser audits, not in local HTML inspection. A hardened, isolated hosting environment is required before accepting untrusted public browser jobs.

Link checks

npm run audit -- url https://your-site.com/ --authorized --check-links

At most 200 anchors from the loaded desktop document are sampled, with up to 25 unique same-origin destinations attempted. HEAD is used first; HTTP 405/501 falls back to a GET limited to 256 KiB. Up to five same-origin redirects are followed. These requests share the overall 80-request, 16 MiB and 45-second audit budgets. Broken HTTP responses, unverified destinations and excluded links have separate coverage evidence.

External origins, query-bearing links, downloads, current-page fragments and obvious action/account paths are excluded. No cookies, authorization or form submissions are used. This is not a recursive crawl or proof that destination content and fragments work. GET and HEAD behavior is controlled by the target server; audit only authorized sites and review the scope.

Compare viewport screenshots

npm run audit -- url https://your-site.com/ --authorized --check-links
# Review that run, then use its directory as the baseline:
npm run audit -- url https://your-site.com/ --authorized --check-links --baseline reports/your-reviewed-run --max-diff-ratio 0.01 --pixel-threshold 24

Open the new report.html for baseline, current and magenta difference images. The baseline directory is never overwritten. A screenshot manifest checks image hashes, fixed dimensions and audit identity. Comparisons require the same full requested and final URL fingerprints, allowed origins, browser/platform, capture settings and link option. A stale or mismatched baseline produces no visual pass; the new report remains available.

Captures use light theme, en-US/UTC, one device pixel per CSS pixel, reduced motion, hidden caret and disabled CSS animations. Two captures 100 ms apart are checked for matching pixels; a changing pair requires review even if the baseline comparison has zero changed pixels. These settings do not stop all JavaScript, video, lazy loading or time-dependent content. Desktop and mobile sizes use desktop Chromium, not real devices.

A pixel changes when any 8-bit RGBA channel differs by more than the threshold (24 by default). The default allowed changed-pixel ratio is 0.01, or 1%. Tolerance is configurable and recorded. Differences are observations, not automatic proof of a regression; a small but important change can be below the chosen threshold. Capture scope is limited to the viewport. Add --fail-on-findings for exit code 2 when a report has failed checks. Setup or execution errors return 1; invalid or mismatched visual comparisons return 1 or 2 depending on when validation fails. Review-only findings do not fail that flag.

Import and compare reports

Open a version 1 JSON report (up to 8 MB) in the workspace. Imported reports are explicitly labeled as supplied files and are not rerun or independently verified by the website. JSON preserves the structured findings; CSV supports issue tracking; text is convenient for review. CSV formula-like cells are prefixed with an apostrophe.

Choose a baseline report to compare the same URL and audit mode, or the same local filename when neither report has a URL. New browser reports also require matching audit-scope fingerprints, including visual baseline images and tolerances when used. Rerun older browser reports if they lack scope metadata. Comparison matches rule, status, selector and evidence. Changed wording or page structure can produce a new observation. “No longer reported” is not proof that a defect has been resolved.

Before release

Review keyboard navigation, screen-reader flow, real devices, content accuracy and complete customer tasks. Inspect account, payment and integration lifecycles separately. Re-run representative lab tests and use field data for performance conclusions. Reports may contain private page text; inspect them before sharing.

Privacy and storage