Verification pending means some checks did not return authoritative evidence. Unanswered checks do not lower your security score and are never treated as clean. If your report asks you to act, follow these four steps to verify ownership and prepare narrow scanner access.
The shortest safe path
If the domain is not verified yet, verify it first. Already verified? Continue to the scanner IP shown in its domain card when the dedicated scan lane is active.
Prove ownership from the Domains screen.
Use only the address shown in the verified domain card.
Scope the allow rule to the verified hostname and keep every other protection enabled.
The new report shows what completed and what still needs attention.
Never expose private routes, remove authentication, or allow a shared cloud address just to complete a scan.
Open domains and scanner accessOne path, four steps
Add the domain to your account and verify it by DNS TXT, HTML file, or meta tag. Verification authorizes the additional owner-only checks; it does not mark unanswered checks as successful.
Open DomainsOpen the verified domain card to see UNPWNED's current dedicated IP and scanner identity. If your firewall, WAF or bot protection normally blocks automation, add the narrow provider-specific rule before scanning. Keep every other protection enabled.
Prepare a verified domainSelect the verified domain, choose Deep Scan, and confirm the limited active-testing scope. This attempts every check available to verified owners. Free includes one lifetime Deep Scan; paid plans include unlimited Deep Scans.
Start Deep ScanRe-run the same scan after access is configured. An official score and grade appear only when the required evidence completes. If verification remains pending, the new report identifies whether you need to act. Unanswered checks remain unknown and do not reduce your score.
Run scan againExplicit site policy
Public checks honor UNPWNED-Scanner Allow, Disallow, and Crawl-delay directives and use the wildcard group when no scanner-specific group exists. A scan backed by current exact domain verification and a recorded authorization treats crawler directives as advisory while keeping the fixed scanner rate, Retry-After, hostname scope, and non-destructive safety controls. The DNS-verified opt-out remains the authoritative way for a domain owner to block every UNPWNED scan.
Verify the domain in UNPWNED and accept the scan authorization. You do not need to weaken crawler rules for other bots.
Authorization never expands beyond the verified domain and its in-scope subdomains. Do not expose private or authenticated routes merely to satisfy a scan.
Public scans follow a valid Crawl-delay up to the 60-second safety ceiling. Authorized verified scans use UNPWNED's fixed low-volume rate and still honor HTTP rate-limit responses and Retry-After.
Run the same authorized scan again. The new report will show whether a firewall, bot challenge, or another access control still limits coverage.
Read scanner policyProvider shortcuts
Use the provider detected in your report and change access only when the report asks you to act. If no action is requested, keep your protection enabled; timeouts, upstream services, and UNPWNED failures can also leave verification pending. If you already know which protection layer serves your verified domain, you can prepare its narrow scanner rule before the first Deep Scan.
Verify ownership with TXT, HTML file, or meta tag. Eligible paid users can then connect Cloudflare and separately approve the managed account-level rule for UNPWNED's published dedicated scanner IP. Read the account-wide warning before accepting. Never add a shared cloud address to an IP Access Allow rule.
Confirm the gap came from Vercel system protection, then open /scanning-ips.json. Only when it reports egress: dedicated and allowlist_recommended: true may the verified domain owner manually add Vercel Firewall System Bypass for the single published dedicated IP and the exact domain. Never use a shared address or User-Agent. System Bypass does not override your custom rules, so keep them enabled. UNPWNED does not create Vercel firewall rules.
Railway protects its network edge but does not provide an application-layer WAF. Do not change Public Networking, DNS, ports, or expose a private service just for a scan. If Cloudflare proxies the custom domain, use the Cloudflare steps. Otherwise inspect your application logs and middleware. Only if your own IP, rate-limit, or bot rule rejects UNPWNED should you add a narrow server-side exception for the published dedicated IP and exact hostname. Keep authentication required.
Confirm the WAF caused the gap before changing it. If a one-time exception is required, scope it to the exact domain, methods, and scan window, monitor it, and remove it immediately after the scan. Use only the dedicated scanner IP published by UNPWNED. Shared scanner IPs are never suitable for an Allow rule.
Signed identity is active for eligible owner-authorized requests. Cloudflare Web Bot Auth recognition is pending approval, so signatures alone do not guarantee verified-bot treatment. UNPWNED publishes an IP only when the dedicated proxy is configured; shared cloud addresses must never receive a firewall Allow rule.
Verification unlocks owner-only checks. If you complete the documented setup, a provider or UNPWNED limitation will not lower your security score or count against your setup. An official grade still requires enough confirmed evidence.
If the verified domain uses a WAF or bot protection, prepare the narrow provider-specific rule with UNPWNED's published dedicated identity before the first Deep Scan. Never disable the wider protection.
The report identifies whether you need to act. If it says no action is needed, keep your protection enabled; the pending evidence does not reduce your score or replace the last official grade.
Once ownership, authorization and the documented scanner access are confirmed, your setup is complete. Any remaining provider or UNPWNED limitation is shown as pending evidence, not a security penalty.
