What the web refuses to an agent that does not hide
What a dated test showed out of reach for an unauthenticated agent, why Dinoer does not try to force it, and whether it concerns your targets.
Used with its defaults (a pause between actions, limits on pages and actions per call, no attempt to get round a block), Dinoer and the SearXNG search it relies on meet sites and search engines that do not answer an unauthenticated agent that does not hide what it is.
What a dated test found
In the reputation campaign of 14 August 2026, two pages, a profile on a code-hosting platform and a video channel, were fetched but held only cookie-banner and sign-in text. The light collection does not run JavaScript, and the browser was not called because the pages did return text. The case →
A professional social network is harder still: reading it at all takes an account and a session that an unauthenticated agent does not have, and Dinoer does not treat that as something to get round. What Dinoer does not do better →
No block rate has been measured for Dinoer. The observations above come from one campaign, not from a panel of sites.
Not a defect to fix
A site has every right to close its door.
Dinoer does not try to get round a site’s protection against automated
visits. Expect dead ends on large commercial platforms, and treat a block
signal (respect.waf_bloquants) as information: sending the same request
again does not change the answer.
Verification screens
A verification screen that never resolves offers nothing to act on: no box, no question. Getting past it would mean rotating addresses or faking a browser fingerprint. Dinoer does neither.
Does it concern your targets
If your targets are your own infrastructure, or sites without hardened protection against automated visits, little of this applies. If they are large commercial platforms or professional networks that require an account, expect these refusals before writing a manifest.