Run your first audit

An audit is a full crawl of your domain followed by automated checks across every page found. VisibilityIQ runs two crawl passes: one fetching raw HTML the way a bot without JavaScript would, and one using a headless browser to capture the fully rendered DOM. The two are compared (the render-parity diff).

What you’ll need

• A project already created for your domain (Add your first project)
• The site live and publicly reachable — the crawler only fetches public, unauthenticated URLs
• A few minutes; a first crawl of a few hundred pages typically finishes in 5–15 minutes

Connecting Google Search Console before you run is optional but recommended — it lets this very first audit reconcile your declarations against what Google actually indexed.

Trigger a crawl

1. Open your dashboard and select the project you want to audit.
2. Click Run audit at the top of the project view.
3. The button switches to an In progress state and a progress indicator appears, showing pages discovered, fetched, and audited as the run proceeds.

You don’t have to stay on the page — the crawl runs in the background, and findings populate as it goes. To set up recurring runs instead of triggering each one by hand, open Settings → Crawl schedule and pick a cadence.

The first crawl crawls the full domain. Subsequent audits are incremental by default — only changed pages are re-crawled unless you trigger a full crawl manually.

What you’ll see while it runs

The progress panel updates roughly every 30 seconds. A healthy crawl shows the discovered-pages count climbing, then the fetched and audited counts catching up to it. If the page count stalls at 0 or near it, the crawl was likely blocked — check yourdomain.com/robots.txt for a Disallow rule and see Crawl not completing.

What gets checked

Every page that the crawler finds is checked across these categories:

• Indexation and canonicals — noindex conflicts, canonical loops, soft 404s
• Crawlability — robots.txt blocking, orphan pages, broken internal links, crawl depth
• AI crawler access — which AI bots are blocked, llms.txt presence and validity
• Render parity — differences between raw HTML and rendered output for title, description, canonical, robots, and main content
• Structured data — JSON-LD validity, required properties, visible-text mismatches
• Performance — Core Web Vitals via CrUX field data, render-blocking resources
• Security — HTTPS, HSTS, Content-Security-Policy, X-Frame-Options

What success looks like

The crawl is done when the project status leaves In progress and the audit overview populates with issue counts by severity. A successful first run shows a realistic page count for your site (not 0, and not a single page) and a spread of findings across the severity buckets. Even a healthy site carries entries in the Info and Low buckets — those are observations, not failures, so an audit that lands there is working as intended, not empty.

If the run finishes with 0 or only a handful of pages, treat the result as incomplete rather than clean: the crawler was almost certainly blocked or the site sits behind authentication. Work through Audit shows no issues or empty results before drawing conclusions.

Reading results

Once the crawl completes, go to Audit → Issues. Issues are sorted by severity (Critical → High → Medium → Low → Info). Start at the top — Critical findings block indexation or crawling and carry the most weight. Click any issue to open its detail panel, where you’ll see:

• The specific pages affected (template-scoped findings show the pattern plus every page that matches it)
• The evidence that triggered the finding — the exact tag, header, or raw-vs-rendered diff
• Step-by-step remediation guidance written as concrete actions
• A generated fix artifact (robots.txt edit, canonical tag, JSON-LD block) where applicable, ready to download or open as a pull request

See Reading your audit results → for a full walkthrough of the finding detail panel and severity model.