v0.0.66

A reliability release: honest reports when a site blocks the crawler, cloud audits back at full power, and you now hear about it when an audit fails.

Fixed

• Cloud audits ran without rendering and cloud checks. Audits triggered from the dashboard were silently locked out of browser rendering, technology detection, and the cloud checks. On sites with bot protection this often meant an empty, failed report. Dashboard audits now run with full capabilities.
• Blocked sites now say so. When bot protection, a firewall, an auth wall, or rate limiting refuses the crawler, the report is now marked blocked and explains what happened, with concrete next steps: allowlist the crawler, turn off the blocking rule for the audit, or run the CLI from a trusted network. Previously these audits published an empty report that could read like a clean pass. The agent-facing report formats carry the same signal, so your coding agent knows the audit was blocked instead of concluding your site has no issues.
• Failed audits no longer show "No issues found." A report with zero crawled pages renders its failure state instead of a success summary.

New

• Audit failure notifications. When an audit fails, you get a dashboard notification with the reason and a link to the affected website. Failures are also tracked on our side so we can spot problems before you report them.

Changed

• robots.txt is no longer enforced by default. Audits are run by site owners, so Disallow rules and Crawl-delay no longer apply to your own audit. robots.txt is still fetched and parsed for sitemap discovery and the robots audit rule. Opt back in with respect_robots = true in your config; when enforced, Crawl-delay is capped at 2 seconds so a slow directive can't stretch an audit into minutes of waiting.