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 the pages to audit. The homepage is always included.
6. Add any public policy pages, or leave the list empty and Inth adds the common ones it finds.
7. Save the website.

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

When you save a website with no policy pages listed, Inth reads the site's sitemap for pages named like a policy document, such as /legals/privacy-policy, ignoring blog and docs posts, then checks common paths such as /privacy, /legal/privacy, /cookie-policy, and /terms. Any that answer with a real policy page are added, one per kind, so the audit already has them. A path that returns the site's not-found page, even with a success status, is left out. This runs when the website is added, and once more for websites added before this existed on their next save. If the site was slow or unreachable at the time, the next save tries once more. A list you clear yourself stays empty. You can edit the list at any time.

Remove a website

Removing a website from a project stops its monitoring and takes it off the Websites list. Past audits stay in Audit → All audits, so their reports and evidence remain available.

Choose pages to audit

An audit visits exactly the pages you list, plus the homepage. There is no crawl and no sitemap discovery, so a run stays small and fast and you decide what it covers.

• The homepage is always audited.
• Add up to 20 more pages, such as a product page, a checkout, or a signup form. Paths such as /pricing resolve against the website's domain.
• Pages must be on the website's own origin.

Two or three well-chosen pages usually surface every vendor a site loads. Add more only when a page carries scripts the others do not.

Verify the domain

What a Website Audit can do depends on whether your organization has proved it controls the website's domain.

An unverified website gets a one-page preview so you can see what Inth detects. Verify ownership to unlock the full audit. A verified website can still run the preview when you want a quick look without a full crawl; choose One-page preview under Audit scope when starting the audit. The preview is one page in one region and costs 10 Credits, like any other page-region.

Open Domain verification for the website and choose a method:

• Work email. If your sign-in email is on the website's domain, for example name@example.com for example.com, and you are an owner or admin of the organization, select Verify now. Shared mailbox providers such as Gmail or Outlook cannot verify a domain this way.
• Google Search Console. Connect the Google account that owns the property in Search Console. Inth accepts properties where that account is a site owner. The link is personal to the member who makes it, and only the property list is read. Under Settings → Integrations you can connect your own Google account. Once it is connected, every website in the organization that the account owns in Search Console is verified for you, and properties the account owns that have no website yet are added as websites, ten per check, in your first project, with their common policy pages found. Only a domain property or a URL-prefix property at the root of the domain proves ownership; a property for a single subdomain or path does not verify the whole domain. Press the refresh button there after adding a property in Search Console. The page names the connected account and lists every domain Search Console knows about for the organization: verified, owned but not yet verified, in Search Console without ownership, or in Search Console with no website added yet. Organization admins can see which member's account listed each property and who proved each domain. This method is rolling out and may not be offered yet.
• DNS record. Add the displayed TXT record at your DNS provider, or use the one-click connection when your provider offers it.
• HTTPS file. Serve the verification value from the displayed /.well-known/inth-verify.txt URL.

After completing a method, select Check verification. Keep DNS records and files in place because Inth rechecks them daily. If a record goes missing, the website keeps full access for a week while you restore it, then drops back to the one-page preview until the record is back or the domain is verified another way. Email and Search Console verifications are not rechecked.

Enterprise organizations that audit websites on behalf of clients can ask Inth to enable third-party audits. That grants verified access without proving ownership of each domain, and every run is recorded against the organization.

Configure policy and vendor context

In the website's settings, keep policy-page URLs current and adjust the audited pages when a page starts or stops carrying its own scripts.

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, billed per page per audited region. Credits for the website's full page limit are reserved when the audit starts and settled for the pages actually visited. If the balance is too low, the dashboard offers a top-up before retrying the same audit. See Website Audit manual run pricing for the rate.

Only one audit can run for a website at a time. The number of pages listed 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 opens on Overview:

• A screenshot of the first page scanned. A full audit shows it before any consent choice, so you see the banner as a visitor does. A one-page preview shows it after accepting.
• When the audit finished, how long it took, and how the vendors changed since the last comparable scan.
• Pages scanned, listing each page and any that didn't load in every region.
• A summary card for each tab below. Select a card to open its tab.

The other views hold the detail:

• Checks shows the consent checks: banner, reject, accept, category choices, Global Privacy Control, Google Consent Mode and the IAB frameworks. Only full audits have checks. A one-page preview lists vendors and cookies.
• Vendors lists identified vendors with their category and the number of pages they appeared on. Select Evidence on a row to see the scripts, requests and cookies that identified it.
• Cookies lists each cookie with its vendor, duration and attributes.
• Review contains detections that Inth could not confidently attribute to a vendor.

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 and for a listed page that no longer exists, 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.