The saved copy shows the page version Yandex last indexed — full page or text only — along with the indexing date. It is reached from the result: the menu beside a page name in search results.
What it is genuinely useful for
It answers “what does Yandex actually hold for this page, and when did it last look?” — which settles arguments about whether a change has been picked up, and shows the text version the engine is working from rather than the version your browser renders.
Why it often looks broken, and why that is not a fault
The copy is served from yandexwebcache.net, not from your site. Any resource referenced with a relative path — /style.css — resolves against that cache domain and fails. So the saved copy may appear unstyled, partly empty, or even return a 404 while the live page answers 200 OK.
Yandex is explicit that this does not affect indexing; it is an artefact of how the copy is assembled. Using absolute URLs for stylesheets and scripts avoids it, which is worth doing for the sake of a presentable cached page rather than for any ranking reason.
Encoding
Text can appear corrupted in the saved copy when the site’s encoding cannot be reproduced. The remedy is UTF-8 — and again, this concerns the copy, not indexing. To confirm how a page really appears in results, search for it with the url: operator.
How we use it
As a second opinion when the page check and the live page disagree. The saved copy shows what was stored and when it was stored, which together explain most cases of results that seem to describe a page that no longer exists.
How we apply this
The relative-path caveat has saved us from at least one pointless investigation: a client’s cached page looked catastrophically broken and the live site was fine, and the entire cause was stylesheet paths resolving against the cache domain. We check the indexing date on the saved copy whenever someone asks why an old version is still showing — it usually turns out the robot has not been back yet.
Related services