Audit coverage and scans
Understand what runs during a scan, how status changes, and how recurring scans work.
A scan is a staged workflow rather than a single request. Public pages are discovered and fetched first, a plan-limited subset may be browser-rendered or performance-tested, GEO prompts run against selected AI surfaces, and the stored evidence is then scored and prepared for the workspace.
Status and coverage explain what data is safe to interpret. A failed phase can leave earlier evidence available without producing a complete score, while plan caps can create intentionally partial render or performance coverage. Scheduling repeats this workflow only after ownership and plan requirements are satisfied.
When troubleshooting a scan, identify the last successful phase and inspect its preserved evidence before restarting. Network restrictions, robots behavior, rendering failures, model-provider degradation, and plan limits produce different symptoms and should not be grouped as one generic failure. Repeated retries without understanding the failed phase can consume time or credits without improving coverage.
- 1
Queued
The scan is stored and sent to the worker queue.
A short queue is normal, but prolonged waiting can indicate worker capacity, an unavailable dependency, or a previously active scan. Do not create repeated scans as a workaround without checking the current project state.
- 2
Crawling
Sight follows safe public URLs within the configured page cap and records fetch evidence.
Fetch results establish which URLs were reachable and eligible for later checks. Review redirects, status codes, robots behavior, canonical signals, and the page cap when expected content is missing from coverage.
- 3
Rendering and performance
A plan-limited subset runs in a browser and through performance measurement.
Rendered and performance-tested pages are subsets selected within plan limits. Confirm which templates and priority pages were included before applying a browser or performance result to the entire website.
- 4
GEO probes
Selected prompts run across allowed AI surfaces. Responses and sources are stored.
Each active prompt is combined with the allowed model and sample configuration. Provider failures or exhausted budgets can reduce the completed answer population, so review probe status and counts before comparing visibility.
- 5
Scoring and reporting
Checks and GEO evidence become category scores, workspace data, and report inputs.
Scores summarize completed evidence after collection. Check for missing categories or degraded probes, then inspect the records behind a score before generating a report or alert from the result.
- 6
Succeeded or failed
Finished scans expose scores and detail. Failures preserve the phase and error context.
Success means the required workflow completed, not that every optional probe produced data. A failure should preserve its phase and error context. Use that information to decide whether to retry, change configuration, or resolve an external dependency.
Scheduling
Starter and Pro plans can enable daily recurring scans after the site is verified. The free plan cannot schedule scans.
A schedule creates repeated snapshots with the project configuration available at each run. Monitor failures and credit availability so a scheduled project does not silently become stale. Changes to prompts, model selection, crawl scope, or plan limits can affect comparability even when the calendar cadence stays the same.
One scan at a time
The API rejects a new scan with a conflict response when the same site already has a queued or running scan.
Store the active scan identifier and continue polling it. Automation should handle the conflict as an existing workflow, not as a signal to create another concurrent request.