Integrating 1C-Bitrix with Yandex Webmaster

Integrating 1C-Bitrix with Yandex Webmaster

Yandex Webmaster is more than just a monitoring tool. Through its API you can automate re-indexing of changed pages, monitor crawler errors directly from the 1C-Bitrix administrative panel, and receive notifications when pages are removed from the index. Without automation this is manual work across two separate interfaces.

Integrating 1C-Bitrix with Yandex Webmaster

Yandex Webmaster API: capabilities

The API provides access to the data and actions of the Webmaster dashboard:

• Hosts API — list of verified sites
• Crawling API — crawl history, crawler errors
• Indexing API — request for forced URL re-indexing
• Sitemap API — sitemap management
• URL checking — URL status in the index
• Search queries — search queries (similar to Search Console)

Authorization via OAuth 2.0. The token is obtained in the Yandex ID dashboard.

Authorization and basic client

namespace YandexWebmaster;

class ApiClient
{
    private const BASE_URL = 'https://api.webmaster.yandex.net/v4';
    private string $token;
    private string $hostId; // site identifier in the format 'https:site.ru:443'

    public function __construct()
    {
        $this->token  = \Bitrix\Main\Config\Option::get('mymodule', 'ya_webmaster_token');
        $this->hostId = \Bitrix\Main\Config\Option::get('mymodule', 'ya_webmaster_host_id');
    }

    public function request(string $method, string $endpoint, array $data = []): array
    {
        $http = new \Bitrix\Main\Web\HttpClient([
            'disableSslVerification' => false,
        ]);
        $http->setHeader('Authorization', 'OAuth ' . $this->token);
        $http->setHeader('Content-Type', 'application/json');

        $url = self::BASE_URL . '/user/{user-id}' . $endpoint;

        if ($method === 'GET') {
            $http->get($url . ($data ? '?' . http_build_query($data) : ''));
        } else {
            $http->post($url, json_encode($data));
        }

        return json_decode($http->getResult(), true) ?? [];
    }
}

The user-id is obtained via a separate GET /v4/user/ request — it should be saved in the module settings rather than requested each time.

Forced re-indexing of changed pages

The primary automation goal: when a manager updates a product or article — send the URL for re-indexing to Yandex without manual action.

Event handler for iblock element updates:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'iblock',
    'OnAfterIBlockElementUpdate',
    function (array &$arFields): void {
        if (!in_array($arFields['IBLOCK_ID'], [CATALOG_IBLOCK_ID, ARTICLES_IBLOCK_ID])) {
            return;
        }

        $element = \CIBlockElement::GetByID($arFields['ID'])->GetNextElement();
        if (!$element) return;

        $url = \CHTTP::URN2URL($element->GetFields()['DETAIL_PAGE_URL']);
        if (!$url) return;

        // Add to queue (do not send immediately — API quota may be exceeded)
        \YandexWebmaster\ReindexQueue::push($url);
    }
);

The re-indexing queue — a separate b_ya_reindex_queue table:

CREATE TABLE b_ya_reindex_queue (
    ID       INT AUTO_INCREMENT PRIMARY KEY,
    URL      VARCHAR(2048) NOT NULL,
    ADDED    DATETIME DEFAULT NOW(),
    SENT     DATETIME NULL,
    STATUS   VARCHAR(20) DEFAULT 'pending'
);

An agent sends them in batches of 200 URLs (the API limit per request):

class ReindexAgent
{
    public static function run(): string
    {
        $connection = \Bitrix\Main\Application::getConnection();
        $urls = $connection->query(
            'SELECT ID, URL FROM b_ya_reindex_queue WHERE SENT IS NULL LIMIT 200'
        )->fetchAll();

        if (empty($urls)) return __CLASS__ . '::run();';

        $client = new \YandexWebmaster\ApiClient();
        $result = $client->request('POST', '/hosts/{host-id}/reindex/url/', [
            'url_list' => array_column($urls, 'URL'),
        ]);

        $ids = array_column($urls, 'ID');
        $connection->query(
            'UPDATE b_ya_reindex_queue SET SENT = NOW(), STATUS = "sent" ' .
            'WHERE ID IN (' . implode(',', $ids) . ')'
        );

        return __CLASS__ . '::run();';
    }
}

Monitoring crawler errors in 1C-Bitrix

Instead of logging into Yandex Webmaster to check errors, retrieve them via API and display them in the administrative panel:

// Fetch crawler errors for the past 7 days
$errors = $client->request('GET', '/hosts/{host-id}/crawl/stats/errors/', [
    'date_from' => date('Y-m-d', strtotime('-7 days')),
    'date_to'   => date('Y-m-d'),
]);

The response contains error types (HTTP_4XX, HTTP_5XX, TIMEOUT, EMPTY_CONTENT) and counts per day. This data can be displayed in the administrative panel dashboard using the standard bitrix:main.admin.list component.

Auto-updating Sitemap via API

After publishing new content — notify Yandex of the sitemap update:

// After regenerating sitemap.xml
$client->request('POST', '/hosts/{host-id}/sitemaps/', [
    'url' => 'https://site.ru/sitemap.xml',
]);

The API accepts the sitemap URL and queues it for processing. The processing status can be queried separately.

Storing settings

All parameters (token, user-id, host-id) are stored via \Bitrix\Main\Config\Option in the b_option table. The settings form is in the module's administrative section (/local/modules/mymodule/admin/settings.php).

API limitations

• Forced re-indexing: 200 URLs per request, no more than 20,000 URLs per day
• OAuth token is valid for 1 year; token refresh must be implemented
• Search query data is available with a 2–3 day delay

Timelines