Domain Scans

OptinStack discovers trackers by loading pages on your registered hostname and recording scripts, storage, and related resources. Register the public hostname visitors actually use. If your site is served through a reverse proxy, that usually means the proxy hostname, not the private origin behind it.

This page summarizes product behavior. The binding disclosure is published at Domain scan disclosure on our marketing site.

Page limits by plan

These limits define how many discovered pages are included in each scan and the default minimum time between scans for that hostname.

Which hostname should I register?

Register the exact hostname visitors see in the browser address bar (after redirects):

• Use example.com or www.example.com when that is the host that serves traffic—not both unless each is a separate production property you license.
• Prefer the host that remains in the address bar after HTTPS redirects (if everyone lands on www., register www.).
• Use the custom production hostname when Webflow, Framer, or another platform serves your site on a connected domain.
• Use the reverse-proxy hostname when traffic reaches your site through a proxy or edge layer.
• Do not register a private origin hostname unless visitors also load the site directly from that hostname.

Business rules

OptinStack stores platform-detected hostnames and user-confirmed hostnames separately. Staging hostnames stay available for testing. Production scans, billing, consent records, and published runtime configuration use the configured public production hostname.

Reverse proxies and custom hostnames

Reverse proxies are supported when the public hostname is reachable over HTTPS and returns the pages visitors see. The scanner follows the public site, not your private origin infrastructure. There is no separate “origin hostname” mapping: the public host is the commercial and runtime identity.

If site.com reverse proxies to project.webflow.io, register site.com as the production hostname. Keep the platform hostname as a staging or detected hostname for preview testing. Billing applies to the public production hostname, because that is the property where visitors use OptinStack.

If you serve two different public domains, register and license each one. OptinStack does not treat cross-domain reverse-proxy pairs as a single licensed site.

Path prefixes

If visitors open the site at a subdirectory (common with reverse proxies), include that path when you register the production URL. Example: https://example.com/landing stores hostname example.com and path prefix /landing.

• Tracker scans start at the prefix (homepage, sitemap, and crawl stay under that mount).
• Consent records, runtime identity, and billing stay on the hostname.
• Banner page targeting is written against the site's own paths. A rule for /pricing matches https://example.com/landing/pricing for visitors, and matches /pricing on the builder hostname.
• Enter the site mount, not a single page such as /about. Prefixes are limited to two path segments.

During onboarding, the public production URL field accepts this prefix. The confirmation step shows the hostname separately from the scan mount, with links to the public homepage and {prefix}/sitemap.xml so you can check that the proxy is routing before locking the site in. After setup, review or edit the prefix anytime under Settings → Scanning & publishing. The licensed hostname stays the same; only the scan mount changes.

Editing the prefix republishes your configuration and refreshes the CDN, so the change reaches visitors without a manual Publish. Because the prefix is not part of the site identity, consent already collected stays valid. Changing the hostname is different: consent, license, and scan history all key on the hostname, so a new hostname starts fresh.

One project per public hostname

A public hostname belongs to exactly one OptinStack site. Registering a hostname that another site already holds fails with a conflict instead of creating a second, silently inactive copy. Remove the hostname from the other site first, or register a different hostname.

Staging and builder hostnames ignore the prefix

Prefixes describe how a reverse proxy serves your production site. Webflow and Framer hostnames, and any hostname stored as staging, serve the site at their own root, so OptinStack never applies a mount there. That is why the same published configuration works on project.webflow.io and on example.com/landing at the same time: the runtime removes the mount only on the public hostnames that are actually proxied.

Two public domains

Consent is stored in a first-party cookie, which the browser scopes to one registrable domain (example.com, not example.co.uk/site). If you register hostnames on two different registrable domains, consent cannot carry between them and a visitor who uses both may be asked twice. The dashboard warns when a project's hostnames span more than one registrable domain. example.com and www.example.com share a registrable domain and are unaffected.

Framer and Webflow staging vs production

Embedded platforms often expose a staging hostname before a custom production domain exists. OptinStack treats these differently:

• Development hostname: a Webflow or Framer hostname used before the production domain is ready. It follows the same Free or paid assignment rules as every other hostname.
• Free hostname: a production-capable Free assignment on an eligible registered hostname (unlimited Free hostnames by default), with a 25-page scan cap and 12-hour cooldown by default.
• Platform production hostname: detected from the platform and confirmable as your production hostname.
• Custom production hostname: entered by you when visitors use a public domain that differs from the platform hostname, such as a reverse-proxy or connected domain.

If you start setup with only a staging hostname, you can finish onboarding and test the banner. When a production hostname is added later, confirm it in OptinStack before using it for production scans, billing, and runtime configuration.

Scanner access and WAFs

The scanner needs to load your public pages over HTTPS. Results may be incomplete or fail when a firewall, bot protection rule, authentication wall, geo rule, or rate limit blocks automated browsing.

If a scan fails on a reachable public site, allow OptinStack-Bot through your WAF or bot protection (see OptinStack-Bot for user agent and Web Bot Auth details), then run the scan again. OptinStack does not scan logged-in areas or private origins that are not publicly accessible.

How URLs are chosen

1. Discover: Read https://{hostname}{prefix}/sitemap.xml when available (including child sitemaps when the root file is a sitemap index); otherwise crawl HTTPS links from https://{hostname}{prefix}/. Without a prefix, both are the host root.
2. Stay on the mount: With a prefix, URLs elsewhere on the host are skipped. Sitemap entries that point at the platform hostname behind the proxy (for example project.webflow.io/pricing) are rewritten to their public form (example.com/landing/pricing) so they can be scanned.
3. Respect robots.txt: {prefix}/robots.txt is read first, and the host-root file is the fallback. Rules are matched against paths relative to wherever the file was found.
4. Normalize: Dedupe URLs (same path variants, bare root vs trailing slash).
5. Order: Pin the homepage first when present; then common privacy and legal-information paths (privacy, cookie policy, terms, contact, and similar when present); then stable locale-aware alphabetical order for the rest. Ranking looks at the path within your site, so a prefix does not change the order.
6. Select: Take the first N URLs for your plan (N = scan limit).

Higher plans scan a longer prefix of the same ordered list. Free’s first 25 pages are always the first 25 pages a higher plan would scan for the same discovery result, when at least 25 URLs exist.

Consistency

For a fixed sitemap or homepage link set:

• Repeated scans on the same plan should target the same URLs.
• Activating a higher plan adds pages at the end of that ordered list; it does not reshuffle Free’s selection.

When counts can still change

Even with the same URLs, tracker totals may vary because of:

• Site or tag-manager changes between scans
• Conditional loading (consent state, geography, experiments)
• Timeouts or blocked third-party resources during automated loads
• Pages not in the discovered set (login-only areas, unscanned URLs beyond your plan cap)

Large sitemaps

Sites with thousands of sitemap entries (for example multi-location brands) only scan up to the plan cap. Unscanned URLs are not represented in that run's tracker list.

Sitemap indexes

If the root sitemap.xml is a sitemap index, we fetch child sitemap documents and merge page URLs (subject to fetch and discovery caps). Child sitemaps on your public hostname and on the platform hostname behind a proxy are both followed. Flat urlsets list all page URLs in one file.

What happens if my site has more pages than my plan?

We scan up to your plan limit from the ordered list above. The dashboard may show scanned vs discovered counts (for example, 25 / 2,775). Trackers on unscanned pages are not included until you upgrade, run again with a higher page limit, or add them manually.

Will two scans pick the same pages?

Yes, when the discovered URL set is unchanged and you use the same plan. Changing your sitemap, homepage links, or plan can change which pages are selected.

Why is my tracker count different between scans?

The same pages can still report different trackers when tags load conditionally, resources time out, or you changed scripts between runs. A different page set also changes totals.

Related

• Domain scan disclosure, customer-facing legal FAQ