Unsupported targets

Before removing a target

Unsupported targets are domains, paths or workflows WebRiskOps must not scan through the standard automated public-page flow. The product should stop before scope acceptance, billing, scan execution or report generation when the selected target is unsafe or outside the authorized public boundary. Use this page when a project, manual URL, discovered page group or access choice produces an unsupported scope warning. The right outcome is not to bypass the warning; the right outcome is to remove the unsafe target or move to the automated proof step when the target is actually eligible but not yet authorized.

Confirm why the target is unsupported

Follow the path `Projects → Project detail → Automation scope → Unsupported scope → Scan scope selection`.

1. Open /projects and choose the project that shows a scope or automation warning. Result: the project detail page shows an Automation scope card before scan acceptance.
2. Read the Automation scope card and each reason listed under it. Result: you know whether the project is stopped because the target is private, third-party, login-only, unsafe, unsupported by plan rules or missing the right access model.
3. Compare the blocked domain or path with the public same-domain pages you intended to scan. Result: eligible public pages are separated from admin areas, account areas, vendor domains and destructive actions.
4. Remove unsupported URLs or groups from Scan scope selection, or create a separate project for the correct public domain. Result: unsafe targets do not enter scanner input, billing or scope acceptance.
5. If the warning is about missing authorization rather than an unsupported target, continue to Ownership proof instead of forcing acceptance. Result: the account owner can complete the automated proof step.
6. Return to Supported scopes when only customer-owned public pages remain. Result: scope acceptance can proceed with an eligible boundary or the workflow stays stopped.

Remove unsafe targets from scan scope

Keep the scan boundary smaller and safer than the business website when needed.

• Remove private IPs, localhost, VPN-only hosts, staging environments and internal admin domains.
• Remove login-only pages, account dashboards, checkout completion steps, write actions and any path that changes user, order, payment or account state.
• Remove third-party payment, identity, analytics, SaaS admin and vendor domains unless a dedicated integration page says that workflow is supported.
• Remove unsupported plan/access combinations instead of assuming payment changes the scan boundary.
• Keep only customer-owned public pages that match the project domain and the plan page limit.

Blocked states

Unsupported means the standard automated workflow must stop for that target. Keep `UNSUPPORTED_SCOPE`, `UNSUPPORTED_TARGET` or `PRIVATE_NETWORK_UNSUPPORTED` visible so the customer understands why the workflow stopped.

• Private or internal host means stop; public self-service scans do not enter private networks.
• Third-party domain means remove the URL or create a separate authorized customer project only when that domain belongs to the same customer scope.
• Login-only or account page means exclude it unless a later authenticated-flow guide explicitly supports that access model.
• Destructive or write action means exclude the page; scanner input must not submit purchases, account changes or production writes.
• Package or access mismatch means choose a supported plan/access model before accepting scope.
• Manual URL rejected means use [Manual URLs and path rules](/docs/projects/manual-urls-and-path-rules) to keep the URL on the accepted host.

Return to supported scope

After removing unsupported targets, return to [Supported scopes](/docs/projects/supported-scopes). If the target is eligible but not yet authorized, continue to [Ownership proof](/docs/projects/ownership-proof). If the only issue is page budget, use [Public-page-only limits](/docs/projects/public-page-only-limits) before accepting scope.