Reading what Yandex says about a site needs a Yandex Webmaster OAuth token, and in Market4 that token is stored per app in the credential vault rather than in an environment variable or a shared setting. The reason is scope: a Yandex token answers only for the hosts it was issued for, so an organisation running three products on three domains genuinely has three different answers to the question of whether this site is verified. One shared slot cannot express three accounts at all.
The get_yandex_health tool answers with two halves, and the indexing half is the one worth leading on. Its summary carries a site quality index, a split between searchable and excluded pages, and a problem count graded by severity. That is a diagnosis rather than a traffic number: for most sites the interesting Yandex answer is why pages are excluded, not how many clicks arrived. The traffic half is there too, and it is the less useful of the two on a site that is not yet fully indexed.
A partial answer from Yandex is normal rather than an error. A site Yandex has not finished indexing refuses one section while serving the others, so a problem message can sit beside real numbers rather than instead of them. Treating that as a failure and retrying produces the same partial answer again; treating it as the answer, and saying which section is missing, is the honest report.
Yandex grades site problems by its own severities, and Market4 does not rename them. Their CRITICAL covers things like robots.txt and sitemap validity, while their FATAL means pages can be dropped from search altogether, which is not the ordering an English reader would guess. Translating those labels into our own vocabulary would make every count unverifiable against the Yandex screen the site owner can open themselves, and a number nobody can check against the source is a number nobody should act on.
An environment variable is one value for a whole deployment, and a Yandex Webmaster token is not one value for a whole deployment. The vault holds the token under the provider YANDEX_WEBMASTER with the label default, one slot per app, and the stored secret is the string itself with no JSON envelope around it. Bing's Webmaster Tools key sits beside it under the same arrangement and for the same reason: a Bing key answers only for the properties verified on its account.
Publishing a post sends two independent announcements. One IndexNow request reaches Bing, Yandex, Seznam, Naver and Yep. Google takes no part in IndexNow, so it is told by re-submitting the sitemap.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
The reasoning is worth separating from the PageSpeed key, which is also per app but for a different reason. A PageSpeed key is per app because it is a quota, and splitting the quota is the point. A Yandex token is per app because it is scoped to a site. An organisation whose properties all live on one Yandex account can paste the same string into three apps, which costs nothing; the reverse arrangement, one shared slot, cannot represent three accounts at all.
The Yandex token is pasted into a panel field and travels over the REST API, and no MCP tool accepts it. A secret typed into a chat window lives in that transcript, and in every log and context window the transcript passes through, for as long as any of them exist. This is a rule about which credentials, not a blanket one: one tool in this product does take an API key as an argument, add_buffer_account, and the webmaster credentials are deliberately not in that category.
Two practical consequences follow for anyone connecting Yandex. The token is created at the Yandex OAuth console as an application with the webmaster:hostinfo and webmaster:verify permissions, and issued to yourself from there. And Yandex tokens expire, so this is a paste you will make again — which is an argument for the panel field being the place it lives, rather than a deployment variable that needs a restart to change.
| Credential | Where it lives | What it lets you do |
|---|---|---|
| Yandex Webmaster token | The vault, one slot per app, pasted in the panel | Read Yandex's indexing diagnosis and search figures for that site |
| Bing Webmaster Tools key | The vault, one slot per app, pasted in the panel | Read Bing's query and page figures, which are a different index from Google's |
| IndexNow key | Minted by us and published as a file at your site root | Announce changed URLs; it is public by design, because publishing it is the ownership proof |
The IndexNow row is the one that surprises people, because IndexNow already reaches Yandex without any token at all. A publish announces the changed URLs to Bing, Yandex, Seznam, Naver and Yep in one request, and none of that needs a Yandex credential. The token is what lets you read the reply: what Yandex did with those URLs, how many pages are excluded, and why.
No. IndexNow announces changed URLs to Bing, Yandex, Seznam, Naver and Yep using a key file published at your own site root, and no account credential of any kind is involved. The Yandex Webmaster token is a separate thing entirely: it lets you read what Yandex says back about your site, including which pages are excluded from search and why. Announcing and reading are two different permissions.
Because a Yandex token is scoped to the hosts it was issued for. An organisation running three products on three domains has three genuinely different answers to whether a site is verified, and a single shared credential cannot express that. If all three domains sit on one Yandex account, pasting the same token into all three apps works and costs nothing, so the per-app arrangement covers both cases and the shared one does not.
It means Yandex served some sections and refused others, which is normal on a site it has not finished indexing. The report will carry real figures next to a message naming the section that could not be read. Report both: the numbers you have and the section you do not. A partial answer treated as a failure hides data that was returned, and treated as complete it implies coverage that was never there.
Most likely it expired. Yandex tokens have a lifetime and there is no renewal that happens without you, so a connection that worked for months and then refuses is the ordinary case rather than a fault. Issue a new token from the Yandex OAuth console with the same permissions and paste it into the same panel field; nothing else about the app's setup needs to change.
The bandwidth you save by blocking an AI crawler shows up in a log. The citations you lose do not show up anywhere, because nothing reports an answer that did not mention you.
Bing's index answers differently from Google's, and it is the one Copilot cites. Pulling its query data into your own panel is straightforward; reading it correctly means knowing two things about how Bing reports.
