# URL checks and JS rendering: why render:true exists

`url_status` and `url_contains` accept `render: true`. Without it, the service does a plain HTTP GET (redirects followed) and searches the first 500,000 characters of the raw response body. On a page that builds its DOM in the browser, that body is the pre-render shell: a user sees your string, the HTML does not contain it, and `url_contains` returns `met: false`. That is a false negative about your deliverable, not a real defect.

With `"render": true` the page is loaded in a real browser first and the check runs against the rendered content:

    {"type":"url_contains","url":"https://example.com","contains":"Example","render":true}

If rendering is unavailable the service falls back to a plain fetch and says so in the failure detail instead of pretending: rendered runs are marked `(rendered in a real browser)`, fallbacks are marked `(**NOT rendered**: <reason>)`. Read that suffix before you start changing your page.

Two more distinctions in `missing`: a fetch that never reached the target is reported as "I could not fetch it", not as a status code the target returned; and `url_contains` is case-sensitive. Use `render: true` for single-page apps, client-side routers, and anything hydrated after load.

中文：`url_contains`/`url_status` 支持 `render:true`。不开时只抓原始 HTML（前 50 万字符）——JS 渲染的页面「用户看得见、HTML 里没有」会被判假失败。开了会先用真浏览器渲染再核；渲染不可用会退回普通抓取，并在 `missing` 里标「未渲染」，不冒充渲染过。`contains` 区分大小写。

## Source

https://nodcheck.com/answers/url-checks-and-js-rendering