Before rendering a JavaScript page, check whether the required data is already available through source HTML, embedded JSON or an authorized endpoint. A client-rendered interface does not mean every useful field requires a browser. If the data only exists in the permitted runtime view, use a bounded rendering workflow.
Inspect the source in a useful order
| Route | Evidence required | Boundary |
|---|---|---|
| Source HTML | The required text or field is actually present | Do not confuse navigation with the main body |
| Embedded JSON | A documented or inspected payload contains the required field | Treat the payload as data, not executable code |
| Authorized endpoint | The source permits this access and its contract is understood | Do not infer authorization from an exposed URL |
| Rendered DOM | The required runtime element is observable | Use a wait and deadline tied to that element |
Make the route selection reproducible
Retain a permitted source snapshot, identify the required field, and record which route produced it. Check the candidate value against its surrounding source context. A successful response or a script tag by itself is not evidence that the intended data was extracted.
For an owned fixture, place a known value in embedded JSON while leaving the visible shell empty. Confirm that the parser reads the intended JSON field without running arbitrary script contents. Create another fixture in which the field is absent and require an explicit missing result.
Escalate only for a demonstrated gap
This method chooses a route; it does not promise a way around every anti-bot system or replace site-specific browser automation.
- Choose standard extraction when the required source text is present.
- Choose rendering when a specific permitted runtime section is missing from the standard output.
- Record empty output, a missing field and denied access separately.
- Keep the selected route and validation result with the source record.
Reference documentation: www.searchcans.com — /reader-api.
