Как вернуть canonical URL категорий в Bitrix после обновления

Bitrix после обновления: как вернуть canonical категорий

Начните не с добавления нового тега, а с поиска прежнего генератора. Если одновременно включить вывод в шаблоне сайта, компоненте и SEO-модуле, вместо отсутствующего canonical можно получить несколько конфликтующих значений. Восстановление должно вернуть один согласованный механизм для каждого типа страниц.

Что означает canonical URL в Битрикс

Канонический URL — предпочтительный адрес среди одинаковых или существенно похожих страниц. В HTML его задают тегом <link rel="canonical" href="https://example.ru/catalog/telefony/"> внутри head.

Canonical помогает обозначить предпочтительный адрес дублей и объединить связанные с ними поисковые сигналы. Это рекомендация, а не обязательная команда: поисковая система может выбрать другой URL. Тег не заменяет редирект, не запрещает обход и не гарантирует исключение альтернативного адреса из индекса.

В каталоге важно различать дубль и самостоятельную страницу. Сортировка может менять только порядок товаров, а пагинация — сам набор товаров. Поэтому настройка rel canonical в каталоге должна опираться на содержимое страниц, а не только на наличие параметров в адресе.

Почему после обновления могли исчезнуть канонические ссылки

Совпадение по времени ещё не доказывает ошибку ядра. Сначала установите версии обновлённых модулей, время развёртывания шаблона и перечень изменённых файлов. Затем проверьте следующие гипотезы.

Сравните SEO-настройки разделов и код применения наследуемых свойств до и после обновления. Считать сброс настроек причиной можно только после обнаружения конкретного изменения. Само отсутствие тега не доказывает изменение логики наследования в Bitrix.

Если доработка находилась в обновляемом файле, проверьте diff: была ли удалена именно строка генерации canonical. Не возвращайте правку в ядро — перенесите её в поддерживаемое пользовательское расширение или шаблон, фактически используемый проектом.

Как проверить наличие и корректность canonical

Сопоставьте серверный HTML и DOM

1. Откройте категорию без авторизации и сохраните исходный HTML ответа.
2. Найдите элементы link с rel="canonical", учитывая разные кавычки и порядок атрибутов. Проверьте расположение внутри head.
3. Сравните исходный HTML с DOM после выполнения JavaScript.
4. Если разметка различается, найдите скрипт, который добавляет, удаляет или заменяет тег.
5. При необходимости изучите отрендеренную страницу в инструменте проверки URL Search Console.

Серверный ответ позволяет отделить ошибку PHP-шаблона от изменений в браузере. Для сопровождения проще формировать согласованный canonical на сервере и не менять его скриптами без необходимости.

Для отдельных адресов используйте проверку canonical, для ошибок структуры head — HTML-валидатор. Отдельно проверьте HTTP-заголовки: canonical может передаваться через Link.

Проверьте целевой URL

• В HTML присутствует один ожидаемый canonical без конфликтующих указаний.
• Используется абсолютный адрес с основным доменом и правильной схемой HTTPS.
• Целевая страница возвращает HTTP 200 непосредственно, без лишнего редиректа.
• Цель доступна для обхода и индексирования: отдельно проверьте robots.txt, meta robots и X-Robots-Tag. Запрет обхода и запрет индексирования — разные механизмы.
• Содержимое исходной и канонической страниц одинаковое либо существенно похожее.
• Формат пути, регистр и завершающий слеш соответствуют маршрутизации проекта.

Не удаляйте все параметры автоматически. Удалять следует только те, которые не меняют значимое содержимое в принятой модели каталога.

Пошаговое восстановление canonical в 1С-Битрикс

Шаг 1. Зафиксируйте состояние до очистки кеша

Сохраните HTML проблемных страниц, HTTP-заголовки, версии модулей и резервную копию файлов. Правки сначала выполните на тестовой копии. Очистка кеша до фиксации ответа может скрыть воспроизводимый симптом.

Шаг 2. Найдите действующий шаблон и источник адреса

В репозитории проекта выполните поиск по строкам canonical и rel=, а также по названию свойства, через которое проект передаёт канонический адрес. Затем проследите фактическую цепочку подключения: шаблон сайта → компонент каталога → шаблон раздела → подключаемые файлы.

Не определяйте активный шаблон только по названию каталога на диске. Подтвердите его использование на тестовой копии через отладчик или временное серверное логирование. Запишите фактические пути файлов: структура размещения пользовательского кода зависит от проекта.

Проверьте, откуда берутся ID раздела, его URL и основной домен. Не предполагайте наличие определённого ключа в результате компонента: изучите структуру данных именно в месте интеграции. Не выводите полный отладочный массив на рабочем сайте.

Шаг 3. Проверьте стандартные настройки и возможности решения

В установленном компоненте, готовом решении или SEO-модуле выясните, предусмотрен ли вывод canonical именно для категорий. Проверьте описание параметра и реализацию в вашей версии. Настройка карточек товаров не подтверждает наличие такого же механизма для разделов.

Если встроенный механизм подходит, восстановите его настройку и отключите дублирующую доработку. Если его нет, используйте пользовательскую реализацию. Установка произвольного свойства страницы сама по себе не подтверждает вывод тега: найдите код, который читает это свойство и формирует link.

Имена методов управления свойствами, кешем и отложенным выводом проверяйте по справке конкретного API и установленному коду. Обзорная страница документации не подтверждает сигнатуры методов или универсальный путь размещения шаблонов.

Шаг 4. Определите правила для параметров

Canonical не следует использовать вместо запрета индексирования. Если страница не является дублем, решайте вопрос её индексирования отдельно.

Пример PHP-кода для canonical базовой категории

Ниже — независимая от API Bitrix функция подготовки тега. Она не ищет раздел и не управляет кешем. Её задача — принять уже проверенный путь базовой категории и сформировать безопасную HTML-разметку. Это пример пользовательской логики, а не готовое универсальное подключение к компоненту.

Исходные условия: маршрутизатор проекта определил базовую категорию без фильтра и пагинации; её путь — /catalog/telefony/; основной адрес сайта задан конфигурацией. Для других типов страниц сначала рассчитайте отдельный целевой URL по согласованным правилам.

1. Подготовьте функцию формирования тега

<?php
function analitoCategoryCanonicalTag($origin, $sectionPath)
{
    // Основной адрес поступает из конфигурации, не из HTTP_HOST.
    $origin = rtrim((string) $origin, '/');
    $sectionPath = (string) $sectionPath;
    $base = parse_url($origin);

    if ($base === false
        || strtolower((string) ($base['scheme'] ?? '')) !== 'https'
        || empty($base['host'])
        || isset($base['user'])
        || isset($base['pass'])
        || isset($base['query'])
        || isset($base['fragment'])
        || !in_array((string) ($base['path'] ?? ''), ['', '/'], true)
    ) {
        return '';
    }

    // Только путь от корня: без домена, query и fragment.
    if ($sectionPath === ''
        || $sectionPath[0] !== '/'
        || substr($sectionPath, 0, 2) === '//'
        || strpbrk($sectionPath, "?#\\") !== false
        || preg_match('/[\x00-\x20\x7F]/', $sectionPath)
    ) {
        return '';
    }

    $url = $origin . $sectionPath;

    return '<link rel="canonical" href="'
        . htmlspecialchars($url, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8')
        . '">';
}

Функция намеренно не исправляет регистр, слеши и маршруты и не проверяет HTTP-статус цели. Она также не определяет, эквивалентны ли страницы по содержанию. Эти проверки выполняются при расчёте целевого адреса и тестировании.

2. Передайте путь из компонента каталога

В фактически используемой ветке категории получите путь через действующий генератор URL проекта. Проверьте соответствие текущему разделу и настройкам ЧПУ. Не собирайте путь простым соединением символьных кодов, если маршрутизация проекта устроена иначе.

Контрольный вызов функции на тестовой копии:

$tag = analitoCategoryCanonicalTag(
    'https://example.ru',
    '/catalog/telefony/'
);

// Ожидаемое значение:
// <link rel="canonical" href="https://example.ru/catalog/telefony/">

Если URL получается из настроек инфоблока, сопоставьте его с реальным маршрутом компонента: одинаковый раздел может отображаться через отличающийся шаблон адреса. Не устраняйте такое расхождение механическим добавлением слеша.

3. Подключите вывод с учётом порядка выполнения и кеша

Полученный тег нужно вывести внутри head, когда целевой адрес уже известен. Если шапка выполняется раньше компонента, обычный немедленный вывод в ней не получит рассчитанное позднее значение. Используйте проверенный для установленной версии механизм отложенного формирования head либо рассчитывайте адрес до его вывода.

Конкретную точку интеграции определяют после проверки жизненного цикла компонента. Зафиксируйте три условия:

1. При построении кеша рассчитан правильный адрес текущего раздела.
2. При выдаче кешированного результата адрес остаётся доступен механизму вывода.
3. Итоговый тег попадает в head ровно один раз при обычном и кешированном ответе.

Перед включением отключите конкурирующий генератор. Если на странице несколько компонентов, только назначенный источник должен задавать canonical: вспомогательный список товаров не должен перезаписывать адрес основной категории.

В многосайтовой установке выбирайте основной адрес из конфигурации текущего сайта. За обратным прокси отдельно проверьте HTTPS-редиректы и передачу схемы запроса. Явный домен в canonical не исправляет конфигурацию прокси.

Тестирование после исправления ошибки canonical

1. Холодный кеш. После адресной очистки запросите категорию и сохраните HTML.
2. Прогретый кеш. Повторите запрос без авторизации. Ожидаемый canonical должен сохраниться.
3. Композит и внешние слои. Проверьте ответ после формирования композитной страницы, затем через CDN или прокси, если они используются. Инкогнито само по себе не обходит серверный кеш.
4. Типы страниц. Пройдите категории разной вложенности, сортировки, вторую и последнюю страницы, индексируемые фильтры.
5. Цели canonical. Проверьте статус 200, отсутствие редиректа и запрета индексирования.
6. Согласованность. Сопоставьте адреса с Sitemap и внутренней перелинковкой.

Если после очистки тег появился, это подтверждает влияние кеша на ответ, но не объясняет, почему старая версия сохранилась. Повторная проверка нужна, чтобы исключить ошибку, возникающую при следующем прогреве.

Для расширенной проверки используйте SEO-аудит сайта: отберите категории без canonical, страницы с несколькими тегами и цели с ответами 3xx/4xx/5xx. Дополнительно сравните robots и title с состоянием до релиза.

В Search Console сопоставьте заявленный и выбранный Google канонический URL, если эти данные доступны для страницы. В Яндекс Вебмастере проверьте состояние важных страниц и доступные инструменты переобхода. Исправление HTML и изменение данных поискового индекса происходят не одновременно.

Как сохранить canonical при следующих обновлениях Bitrix

• Храните доработки в пользовательских файлах, а не в обновляемом ядре.
• В системе контроля версий фиксируйте генератор URL, место вывода тега и настройки маршрутов.
• Документируйте правила для пагинации, сортировок, фильтров и нескольких доменов.
• Добавьте автоматические проверки количества тегов, ожидаемого href и статуса целевой страницы.
• Запускайте тесты до релиза, после релиза и после прогрева кешей.
• Перед обновлением проверяйте на тестовом контуре совместимость собственной интеграции с новой версией компонентов.

Контрольная выборка помогает быстро обнаружить регрессию, но не доказывает корректность всего каталога. Например, для проекта со 120 категориями можно начать с 12 сценариев: шести базовых категорий, трёх страниц пагинации и трёх фильтров. После исправления проверьте обходом все доступные категории и значимые варианты URL.

Частые вопросы о canonical категорий после обновления

Где искать причину, если canonical пропал только у категорий?

Начните с фактически подключённого шаблона раздела: проверьте определение текущей категории, построение URL и передачу данных через кеш. Затем проверьте момент формирования head. Наличие адреса в переменной или свойстве без механизма вывода недостаточно.

Почему чтение свойства в шапке не возвращает canonical, рассчитанный компонентом?

Возможная причина — порядок выполнения: шапка читает значение раньше, чем компонент его устанавливает. Подтвердите это логированием на тестовой копии. Затем перенесите расчёт раньше либо подключите поддерживаемый механизм отложенного вывода. Повторите проверку после прогрева кеша.

Можно ли брать адрес из результата компонента?

Да, если проверено, что конкретный ключ существует в нужной точке выполнения, относится к текущему разделу и соответствует маршрутизации проекта. Структура результата не универсальна. Отдельно убедитесь, что значение доступно при выдаче страницы из кеша.

Нужно ли удалять PAGEN из canonical?

Не автоматически. У страниц пагинации различаются товары, поэтому обычно каждой задают собственный canonical. Номер страницы сохраняют в формате, который реально использует проект; имя параметра не обязательно равно PAGEN_1. Приведённый выше пример для базовой категории нельзя без адаптации применять к пагинации.

Что делать с двумя тегами canonical?

Найдите оба источника в шаблоне, компоненте, SEO-модуле или скрипте. Оставьте один согласованный механизм и проверьте также HTTP-заголовок Link, исходный HTML и DOM после JavaScript.

Гарантирует ли восстановленный canonical выбор нужного URL поисковиком?

Нет. Проверьте соответствие содержимого, редиректы, внутренние ссылки, Sitemap и доступность целевой страницы. Технически корректный тег — часть согласованных сигналов, а не гарантия выбора адреса.

Где проверять API и настройки установленной версии

• Документация 1С-Битрикс — отправная точка для поиска справки по конкретному API. Обзорная страница не подтверждает методы, структуру результата компонента и расположение пользовательских файлов: их необходимо сверять отдельно.
• Google Search Central — навигация по документации об обходе, индексировании, JavaScript SEO и Search Console.