Page check

Page check answers, for a single URL, what the robot receives and what Yandex has decided about it. It is the tool that ends most arguments, because it replaces “the page looks fine” with the actual response.

What it reports

• The response code the bot receives. Anything other than 200 OK and the page may be excluded.
• How the content looks to the bot — the decisive check for anything rendered client-side.
• Page status: included in search, excluded, and why.
• Mobile adaptation for that page.

Choosing the bot

The check can be run as different Yandex robots, with the selected user agent shown beneath the field. This matters more than it sounds: a bot filter or CDN rule that allows the main indexing robot and blocks the mobile one produces a site that indexes normally and fails every mobile assessment. Testing one agent and assuming the rest is how that goes unnoticed for months.

The If-Modified-Since test

A field few people use and large sites should. Enter a date and check the server’s handling of conditional requests:

• Give the page’s actual last-modified date — the response should be 200 OK.
• Give a different date — the response should be 304 Not Modified.

A server that answers 200 with a full body to every conditional request forces the robot to re-download unchanged pages, which spends crawl capacity that new and updated pages need. On a large catalogue this is one of the few genuine crawl-budget levers that is entirely under your control.

JavaScript rendering

A separate beta tool, Indexing → JavaScript page rendering, checks pages whose content depends on scripts. Where the ordinary page check shows what the robot received, this shows what survives rendering — and the gap between the two is exactly where “the content is right there in my browser” arguments live.

Working habit

Run this on the exact URL in dispute, not on the home page, and before declaring anything fixed in site diagnostics — a premature fix claim costs a 30-day wait.