Yandex Performance

Report how a property stands in Yandex search (which matters mainly for Russian, Turkish, Kazakh, Belarusian and Uzbek traffic) and end with recommendations. The user's request may contain a property name or URL, a date range, a device (desktop, mobile or tablet) or a focus hint ("indexing", "queries", "problems"); honor it by going deeper on that part while still producing the full report.

Workflow

1. Resolve the property. If the user's request or the conversation names a property, use it. Site URLs use GSC formats: sc-domain:example.com or https://www.example.com/. Otherwise call list_sites and pick the obvious match. If several plausible properties exist, ask the user which one before continuing. The Yandex tools take that same GSC siteUrl. Yandex Webmaster tracks whole hosts, so a URL-prefix property with a path (such as https://example.com/blog/) is matched to its host and every figure covers the whole host; the response then says so in limitations.

2. Confirm the Yandex side. Call list_yandex_sites (no arguments; the host list is cached for ten minutes, so a site verified a moment ago can take that long to show). sites[] rows carry hostId, url, unicodeUrl, verified and mainMirrorUrl, and an emptyBecause answer means the connected account holds no sites yet. Only a site added and verified in Yandex Webmaster itself reports data, so a host with verified: false needs the owner to verify it there, which can take a few days. When mainMirrorUrl differs from url, Yandex keeps the data on the main mirror; name it.

3. Read every notConfigured answer. Each Yandex tool answers notConfigured: true with a reason and a hint instead of an error. Tell the user what each reason means and what to do:

   • not_connected: no Yandex account is connected to the property owner's GSC Wizard account; connect Yandex in the app.
   • reauth: the owner must reconnect Yandex in the app, because Yandex rejected the connection or the grant predates the webmaster:verify scope.
   • host_not_found: the host is not in the connected Yandex Webmaster account; add and verify it there.
   • host_not_verified: the site is in the account but Yandex has not verified it; verify it in Yandex Webmaster and expect no data until then.
   • owner_only: the property is shared, and Yandex reads use the owner's connection, which is not shared; only the owner can run this report. A Yandex 429 comes back as a rate_limited error whose message gives the retry delay in seconds, taken from Yandex's own reset time: wait that long before one retry and never loop. When Yandex refuses only a secondary section (the problem list, pages in search, the appeared/removed series), the tool keeps what it read and returns that section as null with an entry in warnings when the host is not verified, or empty with a warning after a rate limit or timeout; report the rest and call that section unknown, never clean or zero. Whatever the reason, still run the Google anchor in step 7.

4. Site status. Call get_yandex_site_summary with siteUrl. Read sqi, pagesInSearch, excludedPages, problemCountsBySeverity and problems[] (each with code, severity and lastChangedAt, listed most severe first: FATAL, CRITICAL, POSSIBLE_PROBLEM, RECOMMENDATION). SQI is Yandex's own composite with no Google equivalent, the severities are Yandex's taxonomy, and Yandex serves no previous period, so report a single window and never compare SQI with a Google metric. An empty problems beside a warnings entry is an unread list, not a clean one; emptyBecause and nextStep say which case applies. Derive the excluded share as excludedPages over excludedPages plus pagesInSearch, and say it is derived.