premium mode.
How Reader handles it
standard mode uses datacenter proxies, which many anti-bot systems detect and block. premium mode uses residential proxy IPs that are indistinguishable from real users, bypassing the common bot detection vendors.
For sites that are known to be hostile (Amazon, LinkedIn, booking sites, ticket resellers), use premium mode directly:
Detecting a block
Some blocks are subtle: the HTTP status code is 200 but the content isn’t what you’d see in a browser. Symptoms:metadata.statusCodeis 200 but the markdown is very short- The markdown contains phrases like “please enable JavaScript”, “checking your browser”, or “access denied”
- The same URL in a browser shows totally different content
premium when you see this.
Force premium explicitly
If standard mode is returning thin or challenge content, switch to premium:When premium doesn’t work either
If premium-mode scrapes also come back thin, the site is beyond Reader’s reach. Common offenders:- Sites with CAPTCHAs that require human interaction
- Sites using very new or custom bot detection that our premium mode hasn’t learned
- Sites that require a logged-in session
- Use the site’s official API if they have one
- Scrape with your own session (cookies, auth, manual CAPTCHA solving) and only use Reader for the public parts
- File an issue. Sometimes we can tune premium for a specific site
The waitForSelector trick
If a page loads a shell and then hydrates content client-side, even premium won’t give you the real markdown unless the page has finished hydrating. Combine premium with waitForSelector:
.product-price to appear before capturing, ensuring you see the fully-rendered post-hydration DOM.

