Docs
Sign in
Documentation

Website Audit

Inth Website Audit visits your production website and records privacy-relevant runtime behavior. It identifies vendors and cookies, observes scripts, frames, network destinations, and browser storage keys, preserves supporting technical evidence, and highlights changes between comparable scans.

Inth records cookie attributes and storage key names, not their stored values. You do not need to install a snippet on the website.

Use Website Audit to answer questions such as:

  • Which vendors and third-party domains were observed?
  • Which first-party and third-party cookies were set?
  • Which detections could not be matched to a known vendor?
  • Which vendors are new or no longer detected since a comparable scan?
  • Which pages and scan conditions completed successfully?

Website Audit is a point-in-time observation of the pages it can reach. It is not proof that an unobserved vendor, cookie, or behavior does not exist.

Before you start

You need an Inth project and the full public URL of the production website. The site must be reachable without signing in.

Public policy pages are optional but recommended. Add pages such as your privacy policy, cookie policy, terms, or subprocessor list so the audit can preserve them as policy evidence.

Add a website

  1. In the Inth dashboard, open Audit.
  2. Open the project that owns the website.
  3. Under Websites, select Add website.
  4. Enter the production origin, including https://.
  5. Add any public policy pages.
  6. Choose which pages to scan and save the website.

Each website belongs to a project, so its runtime evidence can be reviewed alongside the related repository and policy context.

Inth saves the website origin rather than a single page path. Use URL rules to include or prioritize particular pages.

Choose pages to scan

Website Audit supports four crawl modes:

  • Sitemap and linked pages provides the broadest coverage and is the best default for most sites.
  • Linked pages only is useful when the sitemap is missing or out of date.
  • Sitemap only is faster but cannot discover pages omitted from the sitemap.
  • Only the URLs I list scans only the URLs configured in the website's URL rules.

You can refine a crawl with URL rules:

  • Start from seeds the crawl with important pages.
  • Limit to prevents the audit from leaving selected paths.
  • Never scan excludes sensitive or irrelevant paths such as /admin.
  • Scan first prioritizes pages that should be visited before the page limit is reached.

Rules can only target the website's own origin. A page limit can still prevent a listed URL from being visited, so check the completed coverage in every report.

Verify the domain

If Inth asks you to verify ownership, open Domain verification for the website. Depending on your DNS provider, you can:

  • use the available one-click connection
  • add the displayed DNS TXT record
  • serve the verification value from the displayed /.well-known/inth-verify.txt URL

After publishing the record or file, select Check verification. Keep the verification record in place because Inth rechecks it periodically.

Configure policy and vendor context

In the website's settings, keep policy-page URLs current and add URL rules when the default crawl is too broad or too narrow.

You can also add affiliated domains that your organization owns. Without that context, requests to your own secondary domains can appear as unidentified or third-party vendor evidence.

Scan conditions

Each audit runs under one or more scan conditions, and the report labels its evidence with the condition it was observed under. A condition combines:

  • A region profile. The scan browser adopts the locale and timezone of a region, and sends the Global Privacy Control signal where the profile calls for it. New websites scan under the Texas, United States baseline profile by default; UK GDPR, EU and EEA GDPR, and California CPRA profiles are also supported.
  • A consent scenario. In the default page state, the scan makes no consent choice and observes the page as a new visitor sees it. The UK GDPR, EU and EEA GDPR, and California CPRA profiles also run an accept-all scenario, where the scan attempts to activate a visible accept-all control before observing and the report records whether the attempt succeeded. The Texas baseline profile runs the default page state only, so websites on the default profile do not produce accept-all conditions.

The scan does not compare an accept path against a reject path, and an accept-all attempt can fail on banners without a recognizable accept control. Read each condition's label in the report before drawing conclusions from its evidence.

Run an audit

  1. Open the project Audit page.
  2. Find the website and select Run audit.
  3. Follow the active run from Audit → All audits.
  4. Open the completed run to review its results.

A Website Audit uses Inth Credits. Credits are reserved when the audit starts. If the balance is too low, the dashboard offers a top-up before retrying the same audit.

Only one audit can run for a website at a time. Crawl breadth, site size, and site performance affect how long the audit takes. Credits reserved for a failed or cancelled audit are released.

Schedule recurring audits

Organizations on the Startup plan can enable continuous monitoring for a website so audits run on a schedule. From the website's audit settings, turn on monitoring and choose a cadence: hourly, daily, weekly, every 2 weeks, or monthly. Weekly is the default.

Monitoring is billed differently from manual runs: it charges a flat monthly Credit amount per monitored region based on the cadence, and the individual scheduled runs are not billed separately. See Website Audit monitoring pricing for the amounts.

Scheduled reports appear in Audit → All audits alongside manual audits, labelled Scheduled. Recurring scans are what make vendor-change comparisons useful, because each run gives the next one a comparable baseline.

Review the results

The report has four views:

  • Overview shows coverage, unidentified detections, and vendor changes when a comparable scan exists.
  • Vendors lists identified vendors, their categories, where they were observed, and supporting evidence.
  • Cookies separates first-party and third-party cookies and links them to known vendors where possible.
  • Review contains detections that Inth could not confidently attribute to a vendor.

Open Technical evidence when you need the supporting page, request, script, cookie, or storage details.

Vendor changes are shown only when a prior scan has comparable configuration and completed coverage. Incomplete, blocked, page-limited, or truncated coverage must not be treated as proof that a vendor or cookie is absent.

Coverage and limitations

Website Audit scans public, same-origin pages that its browser can reach. Authentication, bot protection, navigation failures, crawl limits, and slow pages can reduce coverage.

When coverage drops, the report shows which pages completed. Check for bot protection or a firewall blocking the scan browser, a page limit below the site's size, and URL rules that exclude more than intended, then adjust and rerun. Vendor-change comparisons need completed coverage on both scans.

Scan conditions bound what a report can claim. A default-state condition observes the page without making a consent choice, and an accept-all condition, which only the opt-in and GPC region profiles produce, records a single accept attempt; the audit does not compare accept against reject or prove that consent enforcement works in every region and scenario. Treat the report as runtime evidence for review, not as a compliance certification.