Live-site checks

The live-site engine inspects the response from your URL and runs a registry of HTML checks and bounded HTTP probes. Some checks emit more than one result, and the exact registry changes as detectors are added or corrected. This page describes what the current checks can observe, including their limits.

For the engine architecture, see How a scan works. For the source-folder audit, see Source audit.

Categories at a glance

Category	What it covers
Security	Transport, response headers, cookies, cross-origin policy, exposed-path probes, DNS/email posture, and security-relevant HTML clues.
Performance	Response protocol and timing, compression, caching, page weight, resource hints, images, fonts, and blocking markup.
SEO	Metadata, canonical and robots signals, sitemap structure, structured data, links, redirects, and content heuristics.
Accessibility	Static markup checks for language, alternatives, headings, forms, focus, ARIA, and navigation, plus optional browser analysis.
Compliance	Privacy, consent, tracker, policy, and disclosure markers that require legal and runtime review.
Polish	Thirty editorial, visual, markup, framework-default, and deployment-review heuristics.
Config	Favicon, web manifest, custom 404, www behavior, analytics markers, deprecated markup, and other deployment clues.

A Health Web Scan runs the registered live-site categories and the polish phase. Focused scans are narrower: Security runs the security subset, Accessibility runs accessibility and compliance checks, and Polish runs only the 30 polish heuristics. Localhost targets also use pre-deploy checks where applicable.

How to read a finding

A finding reports an observation, not more than the detector measured. The confidence field distinguishes directly confirmed conditions from high-confidence interpretations and review-level heuristics. Evidence records the response, markup, status, sample, or threshold behind the result. A skipped result means the check could not reach a sound verdict or was not applicable.

Many checks inspect only the initial HTML response. They cannot see content added after rendering unless browser analysis is enabled. A passing presence or syntax check does not prove that a feature works for every browser, crawler, user, region, authentication state, or legal context.

Security

SiteCMD checks observable transport and response behavior, including:

• HTTPS and certificates. HTTP-to-HTTPS behavior, HSTS on the HTTPS response, and a dedicated certificate validity and expiry probe. It does not grade the server’s complete cipher-suite configuration.
• Response security policy. CSP, frame protection, MIME-sniffing protection, referrer and permissions policy, cross-origin isolation headers, cookie flags, and mixed-content references found in the response.
• Exposed paths. Bounded requests to conventional sensitive paths such as environment files, repository metadata, backups, and directory-listing candidates. A status alone is not treated as exposure when the body looks like a generic page or access response.
• CORS and redirects. The observed CORS headers, a foreign-origin reflection probe, and a bounded open-redirect probe. Wildcard policy without credential evidence remains a review item rather than a proven credential leak.
• DNS and email posture. SPF, DMARC, DKIM clues, MX, DNSSEC, CAA, dangling CNAME signals, and domain-expiry data when the resolver or registry can provide it.
• Markup clues. Subresource-integrity use, insecure form actions, server-version banners, recognizable vulnerable client-library versions, exposed email addresses, and credential/authentication/CSRF-like source patterns.

Header absence can be observed directly, but impact still depends on application behavior and defense layers. Source-pattern checks are intentionally more cautious because a string in HTML does not prove exploitability or reveal server-side controls.

Performance

The non-browser checks cover:

• Response behavior. Request timing, negotiated HTTP version, HTTP/3 advertisement, compression, caching headers, redirects, and response/page weight.
• Initial resource markup. Potentially blocking scripts and stylesheets, preload/preconnect hints, font-loading declarations, third-party script counts, unminified-looking references, and large inline CSS.
• Images and assets. Missing intrinsic dimensions, lazy-loading and format hints, plus a bounded sample of referenced assets. Static markup cannot prove rendered size, visual quality, or layout shift.
• Document size. DOM-element count and body-size thresholds. These are engineering heuristics, not direct user-experience measurements.

When browser analysis is enabled in the desktop app, SiteCMD can add rendered performance measurements such as Largest Contentful Paint, First Contentful Paint, Cumulative Layout Shift, and Time to First Byte. One lab run is a point-in-time measurement, not field data from real visitors.

SEO

The SEO registry includes:

• Page metadata. Title, description, canonical, viewport, charset, Open Graph, Twitter Card, hreflang, robots meta, and duplicate/conflicting declarations in the initial response.
• Canonical and redirect clues. Canonical URL comparison and temporary status codes on scheme or hostname canonicalization redirects. A canonical declaration does not prove that a search engine will select it.
• Structured data. JSON-LD parsing and basic document/type/property structure. SiteCMD does not replace a current schema validator or confirm rich-result eligibility.
• Robots and sitemap probes. Conventional and same-origin declared locations, robots syntax/directives, and sitemap XML root/entry structure. The sitemap check does not fetch every listed URL or prove crawling and indexing.
• Links. Bounded samples of anchors found in initial HTML. A destination counts as missing only after a GET request confirms HTTP 404 or 410; authentication failures, server errors, and network failures are inconclusive. Soft 404s, fragments, runtime-added links, and destination quality are not assessed.
• Content and sharing heuristics. Thin-text thresholds, URL-length hints, social-image availability, and optional GEO/AI-discovery signals such as llms.txt, crawler directives, citations, freshness markers, and organization identity.

Indexing intent is contextual. A noindex, missing sitemap, short page, or absent AI-discovery file can be deliberate, so review-level findings say what was observed without claiming the page should rank or be indexed.

Accessibility

The static pass checks bounded markup signals:

• Document language and headings. lang, heading order, H1 count, and empty headings. Numeric jumps or multiple H1 elements are review signals, not automatic WCAG failures; the intended content outline must be checked in context.
• Image alternatives. Whether non-hidden image elements have an alt attribute. An empty value is recorded as present, but the static check does not decide whether the image is decorative or whether alternative text is useful.
• Forms and frames. Detectable label relationships, iframe titles, and common markup gaps. Runtime-generated accessible names and the quality of a label still require rendered inspection.
• Keyboard and navigation clues. Skip-link markers, focus-outline resets, positive tabindex, autoplay markup, link text, and selected interactive-semantics patterns.
• ARIA and landmarks. A narrow set of detectable misuse patterns, such as focusable content hidden with aria-hidden or an empty aria-label. It is not a complete ARIA conformance parser.
• Contrast hints. The fallback notices a narrow co-occurrence of light inline colors. It does not pair computed foreground/background colors or calculate a contrast ratio.

When enabled, axe-core runs against the rendered DOM and supersedes overlapping static fallback findings. Even then, automated testing cannot establish full accessibility conformance; keyboard, screen-reader, zoom, content, and task-based review still matter.

Compliance

These checks surface evidence for review, not legal conclusions:

• Consent markers. Recognizable consent-manager scripts or banner markup, cookies set on the response, and tracker signatures. Static source cannot verify that a control is visible, records a valid choice, or gates storage and requests.
• Policies and terms. Links and bounded fetches for privacy-policy and terms pages, plus data-controller contact, CCPA notice, and accessibility-statement markers.
• Forms and disclosures. Page-wide privacy/consent markers around pages that collect email addresses. SiteCMD does not verify proximity or visibility, determine the applicable lawful basis, or decide whether a checkbox is required.
• Privacy signals. Consent Mode markers, cookie-expiration observations, Do Not Track handling clues, and third-party provider signatures.

Applicability varies by purpose, audience, jurisdiction, and runtime behavior. Compliance findings are prompts for product and legal review, never a substitute for it.

Polish

Polish runs 30 heuristics in six groups:

• CSS architecture. Inline-style density, utility-class density, and source-level organization clues.
• HTML quality. Container ratios, heading/form duplication signals, clickable non-interactive elements, and missing language markup.
• Copy and content. Repeated punctuation, buzzword/header phrase matches, framing patterns, emoji used as icon clues, and three-column repetition.
• Visual patterns. Gradient, glass, animation, radius, glow, and decorative-blob source signatures.
• Meta and infrastructure. Default titles/favicons, missing sharing metadata, absent page-level canonical/robots/sitemap markers, source-map references, and console-call strings.
• Framework defaults. Hosting subdomain, boilerplate, and default error-page signatures.

These signals do not identify who wrote a site and are not a statistically calibrated probability of AI authorship. They help a human review whether a pattern is intentional, appropriate, and finished. A source-map reference, for example, is not described as exposed source unless another probe actually confirms public access.

Config

Operational checks include:

• Site assets. Favicon declaration plus a bounded icon fetch, and web-app-manifest availability/basic structure.
• Error and hostname behavior. A generated missing path used to review custom 404 behavior, and a www/apex counterpart request used to observe canonical hostname handling.
• Discovery configuration. Whether robots.txt advertises a sitemap URL.
• Document clues. Analytics markers, deprecated HTML, print-specific source hints, responsive source hints, and internal trailing-slash consistency.

These probes do not enumerate every subdomain, CDN rule, legacy route, or deployment configuration.

Probe vs. parse checks

Internally, the engine has two kinds of checks:

• HTML parse checks inspect the fetched response headers and initial body in memory.
• Probe checks make bounded follow-up requests, such as fetching robots.txt, sitemap candidates, linked destinations, alternate URL forms, exposed-path candidates, or certificate data. Independent probes generally run concurrently, while redirect walks and fallback requests can be sequential by design.

For the engine internals, see How a scan works.

What gets skipped

Common reasons for a skipped verdict include:

• Local preview. A localhost target is treated as pre-deploy. Checks that only make sense at a public edge, such as certificate or CDN protocol behavior, skip while pre-deploy checks run.
• Not applicable. A TLS check has nothing to inspect on an HTTP response, or a form-specific check finds no relevant form.
• Inconclusive probe. A timeout, blocked request, authentication response, server error, parser limit, or unavailable resolver can prevent a defensible pass/fail result.
• Optional browser phase. Rendered axe-core and Core Web Vitals results exist only when browser analysis is enabled and available.

Skipped checks do not count as confirmed defects. Their evidence and reason remain available so you can decide whether to retry or inspect manually.