Как в CyrtoLat отключить автоподмену в XML sitemap и canonical URL

Если после включения CyrtoLat у вас начали меняться URL в XML sitemap или в canonical, это почти всегда приводит к лишним переобходам, дублям в индексе и странным сигналам для поисковиков. Проблема обычно не в самом sitemap, а в том, что автоподмена затрагивает данные, которые плагин SEO или тема уже формируют отдельно.

Ниже — практический сценарий: как понять, где именно происходит подмена, как отключить её только для sitemap и canonical, и как проверить, что после правки поисковый контур сайта не сломался.

Когда это действительно проблема

Симптомы обычно видны быстро:

• в sitemap.xml появляются URL с неожиданной латинизацией;
• в исходном коде страниц canonical указывает не на тот адрес, который реально открыт в браузере;
• после миграции часть страниц начинает конкурировать между собой в индексе;
• в Search Console растёт число «Просканировано, но не проиндексировано» для похожих URL.

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

Диагностика: где именно ломается URL

Сначала нужно понять, кто формирует проблемный адрес: CyrtoLat, SEO-плагин, тема или кастомный код. Не пытайтесь сразу править всё подряд — это обычно только усложняет отладку.

Проверка sitemap

Откройте XML-карту сайта и найдите несколько URL вручную. Если в sitemap уже есть латинизированные версии там, где вы ожидали исходные, проверьте:

• генерирует ли sitemap SEO-плагин;
• не подменяется ли URL через фильтры темы;
• не включена ли автоподмена для служебных URL в CyrtoLat.

Проверка canonical

Откройте страницу и посмотрите исходный код. Ищите тег:

<link rel="canonical" href="https://example.com/primer-stranicy/" />

Если canonical отличается от фактического URL страницы или от URL в sitemap, это уже не косметика, а конфликт генераторов.

Что проверить в первую очередь

• настройки автоподмены CyrtoLat для служебных сущностей;
• SEO-плагин, который отвечает за sitemap и canonical;
• кастомные фильтры в functions.php или в mu-plugin;
• кэш страницы и кэш XML-файлов, если они отдаются через прокси.

Как отключить автоподмену только для sitemap и canonical

Если в CyrtoLat есть настройка исключения для служебных URL, используйте её в первую очередь. Это безопаснее, чем отключать автоподмену целиком: записи и страницы продолжат работать, а служебные ссылки не будут переписываться повторно.

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

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

<?php
/**
 * Plugin Name: CyrtoLat service URL exclusions
 */

add_filter( 'home_url', function( $url, $path, $orig_scheme, $blog_id ) {
    if ( is_admin() ) {
        return $url;
    }

    if ( false !== strpos( current_filter(), 'home_url' ) ) {
        // Оставляем служебные URL без дополнительной обработки.
        if ( false !== strpos( $path, 'sitemap' ) || false !== strpos( $path, 'canonical' ) ) {
            return $url;
        }
    }

    return $url;
}, 10, 4 );

Этот пример не заменяет настройки CyrtoLat, а показывает принцип: служебные URL должны выходить из цепочки автоподмены раньше, чем попадут в sitemap или canonical. В реальном проекте лучше использовать штатные исключения плагина, если они доступны, а код оставлять только для нестандартных интеграций.

Пошаговое решение без поломки индексации

Шаг 1. Сделайте резервную копию настроек и базы

Перед изменениями сохраните текущие настройки CyrtoLat и SEO-плагина. Если у вас есть staging-копия, правьте сначала там. Для sitemap и canonical ошибка проявляется не сразу, а после следующего обхода поисковиком, поэтому откат должен быть быстрым.

Шаг 2. Отключите автоподмену для служебных URL

В CyrtoLat оставьте автоподмену для контента, но исключите:

• XML sitemap;
• canonical URL;
• служебные страницы, если они формируются отдельно;
• внутренние API-эндпоинты, если они участвуют в генерации метаданных.

Если у вас несколько SEO-инструментов, убедитесь, что только один из них отвечает за canonical. Дублирование этой функции почти всегда создаёт конфликт.

Шаг 3. Очистите кэш

После изменения настроек сбросьте:

• кэш страницы;
• объектный кэш, если он используется;
• кэш CDN или reverse proxy;
• кэш XML sitemap, если SEO-плагин его хранит отдельно.

Без этого вы можете смотреть на старую версию sitemap и ошибочно решить, что ничего не изменилось.

Шаг 4. Пересоберите sitemap

Если SEO-плагин умеет пересобирать карту сайта вручную, сделайте это сразу после правки. Так вы быстрее увидите, что именно попадает в XML и не тянется ли туда старый URL из базы или кэша.

Сравнение подходов

Как проверить, что всё сработало

Проверка должна быть не на глаз, а по конкретным признакам.

• Откройте XML sitemap и убедитесь, что URL совпадают с ожидаемыми адресами страниц.
• Проверьте несколько страниц в исходном коде: canonical должен указывать на тот же адрес, что и основная версия страницы.
• Сравните URL в sitemap и canonical для одной и той же записи — они не должны расходиться без причины.
• Откройте страницу через браузер в режиме инкогнито и убедитесь, что адрес не переписывается повторно.
• Если есть Search Console, отправьте sitemap на повторную обработку и посмотрите, не появляются ли новые дубли.

Хороший признак — когда sitemap, canonical и фактический URL страницы совпадают по логике и не создают альтернативных вариантов одного и того же документа.

Частые ошибки и как их исправить

Отключили автоподмену слишком широко

Такое бывает, когда исключают не только sitemap и canonical, но и весь контент. В результате сайт перестаёт использовать нужную латинизацию в URL. Исправление простое: верните глобальную обработку и оставьте исключения только для служебных сущностей.

Оставили два источника canonical

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

Не сбросили кэш после правки

Это самая частая причина ложной тревоги. XML sitemap и canonical часто кэшируются отдельно от обычных страниц. Пока кэш не очищен, вы видите старую версию и продолжаете искать несуществующую проблему.

Правили в теме вместо mu-plugin

Если исправление лежит в теме, оно исчезнет после обновления. Для точечных исключений безопаснее использовать mu-plugin или отдельный мини-плагин.

Практические советы по безопасности и производительности

Не держите в автоподмене то, что не должно индексироваться как контент. Sitemap, canonical, feed-адреса и API-эндпоинты должны быть предсказуемыми и стабильными. Чем меньше лишней логики в служебных URL, тем проще отлаживать индексацию и тем меньше риск получить дубли после обновления плагина или темы.

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

Если нужен дополнительный контроль над дублями и служебными ссылками, в экосистеме WPShop есть Clearfy Pro: он полезен как набор технических настроек для чистки сайта и удаления дублей. Смотрите только те функции, которые реально нужны проекту: Clearfy Pro.

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