Как настроить sitemap при переезде сайта в 2026 году

Когда сайт переезжает на новый домен, новую CMS, другой хостинг или просто меняет структуру URL, sitemap начинает играть роль не «какого-то файла для галочки», а нормальной карты для поисковых роботов. Я у себя на проектах в 2026 году первым делом проверяю именно его: если sitemap собран криво, Google и Яндекс очень любят тратить краулинговый бюджет на мусор, а нужные страницы переезжают в индекс заметно медленнее.

И да, здесь хватает нюансов. На одном проекте после миграции с WordPress на Bitrix мы поймали ситуацию, когда sitemap ещё две недели отдавал старые URL, часть страниц шла с 302, а в robots.txt вообще остался путь к старой карте сайта. В результате просела индексация, а коммерческий трафик упал почти на 18% за месяц. На деле это не «мелкая техошибка», а вполне себе причина потерять деньги. Если переезд уже идёт, я бы параллельно смотрел не только sitemap, но и 301 редиректы после смены домена, а если нужен комплексный разбор — у нас есть доработка сайта и проверка сайта перед запуском.

Зачем sitemap важен при переезде сайта

Я обычно объясняю клиентам очень просто: sitemap — это не магия и не «ускоритель SEO», а официальный список страниц, которые вы хотите показать поисковику. Когда сайт переезжает, у роботов и так хватает работы: меняются URL, редиректы, canonical, внутренние ссылки, иногда ещё и структура разделов. Если sitemap не помогает им быстро понять, что у сайта теперь новая логика адресов, индексация начинает буксовать.

Особенно это заметно на сайтах с 5 000+ страниц, интернет-магазинах, каталогах услуг, мультирегиональных проектах и любых сайтах, где есть фильтры, пагинация, карточки товаров и дубляжи. У одного клиента на Laravel-проекте с MySQL 8.0 после переезда sitemap был собран из старого кэша. Робот видел и старые URL, и новые, а часть страниц вообще дублировалась по двум протоколам. Честно говоря, это был классический хаос. Мы поправили генерацию карты сайта, убрали мусор, и через 3 недели Google вернул прежний объём обхода.

Если хотите быстро понять, не развалился ли технический SEO-контур после миграции, я бы начал с аудита robots.txt и XML Sitemap, а затем проверил связку с причинами, почему сайт не индексируется. Это две статьи, которые реально экономят время, когда после переезда всё пошло не по плану.

Какой sitemap нужен после переезда: старый, новый или оба

Вот тут многие ошибаются. После переезда не надо просто «перенести старый sitemap как есть». Это плохая идея. Если у вас менялись домен, HTTPS, структура каталогов или CMS, карта сайта должна отражать уже новую реальность. В sitemap должны быть только те URL, которые вы хотите индексировать сейчас, а не месяц назад.

На моей практике чаще всего приходится выбирать один из трёх сценариев. Первый — смена домена: тогда старый sitemap больше не нужен, а новый должен быть привязан к новому домену и новой канонической структуре. Второй — переезд внутри того же домена, но со сменой структуры URL: здесь sitemap обновляется полностью, но старые страницы ещё какое-то время живут через 301 редиректы. Третий — миграция CMS без смены URL: тогда карты сайта тоже лучше пересобрать, потому что на новом движке часто меняются правила генерации, приоритеты и lastmod.

Если вы переезжаете, полезно держать под рукой ещё и статью как настроить 301 редиректы при смене URL и структуры сайта. sitemap и редиректы работают только в связке. По опыту, если одна часть сделана идеально, а вторая — «на коленке», весь эффект сдувается.

Пошаговая настройка sitemap при переезде

Я обычно делаю настройку в таком порядке. Сначала фиксирую новую структуру URL и проверяю, какие страницы вообще должны попасть в индекс. Потом настраиваю редиректы. И только после этого собираю sitemap. Если перепутать шаги, очень легко начать включать в карту старые адреса, которые уже не должны существовать как самостоятельные страницы.

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

1. Составить список всех новых канонических URL.
2. Удалить из генерации страницы с noindex, 404, 410, служебные и дубли.
3. Проверить, что все URL отдают 200 OK и соответствуют canonical.
4. Обновить robots.txt и указать актуальный sitemap.
5. Пересобрать карту сайта и отправить её в Google Search Console и Яндекс.Вебмастер.
6. Проверить отчёты по ошибкам сканирования через 3-7 дней.

Если сайт крупный, я ещё отдельно смотрю на sitemap по типам: страницы, товары, статьи, изображения, видео, мультирегиональные версии. У больших проектов, особенно на Bitrix, полезно разделять карту сайта на несколько файлов и делать index sitemap. Это помогает и поисковикам, и вам. Если карта одна на 50 000 URL, следить за ней становится неудобно, а одна ошибка в генераторе может поломать всё сразу.

Что обязательно исключить из sitemap

Из карты сайта я всегда выкидываю URL с параметрами сортировки, пагинацию, служебные страницы, корзину, поиск по сайту, личный кабинет и любые фильтры, если они не являются посадочными страницами под SEO. Иначе робот начинает лезть туда, куда не надо. А это уже прямой удар по индексации.

Ещё один типичный косяк — включать в sitemap страницы, закрытые через noindex. Это логически противоречиво. Либо вы хотите страницу в индексе, либо нет. Если она в sitemap, но при этом закрыта, поисковик получает смешанный сигнал. Грубо говоря, вы сами себе мешаете.

Как связать sitemap и robots.txt после миграции

После переезда robots.txt нужно проверять так же внимательно, как и редиректы. У меня был случай, когда у клиента всё было идеально настроено на уровне 301, но в robots.txt оставалась старая ссылка на sitemap старого поддомена. Формально сайт уже жил на новом домене, но поисковики продолжали время от времени ходить по старому адресу карты. Итог — лишние обходы и потеря времени.

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

User-agent: *
Disallow: /bitrix/admin/
Disallow: /search/
Disallow: /cart/
Disallow: /checkout/

Sitemap: https://example.com/sitemap_index.xml

Если вы переехали с HTTP на HTTPS или с www на без www, sitemap тоже должен содержать только финальный канонический хост. Не надо оставлять старую версию «на всякий случай». Это не помогает, а путает. Для такой миграции полезно ещё свериться со статьёй про редиректы с HTTP на HTTPS и WWW и про SSL для www и без www.

Генерация sitemap на WordPress, Bitrix и Laravel

На WordPress в 2026 году я чаще всего вижу два варианта: либо Yoast SEO, либо Rank Math. Оба умеют генерировать sitemap, но после переезда я не советую слепо доверять настройкам по умолчанию. У клиента на WooCommerce sitemap с товарами после смены структуры магазинов стал отдавать несколько сотен URL с параметрами. Пришлось вручную ограничивать типы записей и чистить кэш плагина.

На Bitrix всё чуть веселее. Стандартная карта сайта часто работает нормально, но если проект большой, с несколькими инфоблоками и мультирегионом, я обычно делаю доработку под задачу. Это как раз та ситуация, где доработка сайта реально оправдана: не потому что «хочется кодить», а потому что штатные механизмы часто не учитывают логику конкретного проекта. На Laravel же почти всегда удобнее собирать sitemap программно и отдавать его через контроллер либо команду cron.

Пример для Laravel: генерация sitemap через PHP

Ниже очень упрощённый вариант. В реальном проекте я добавляю кеширование, разбивку на чанки и выборку только опубликованных материалов.

<?php

use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Cache;

Route::get('/sitemap.xml', function () {
    $urls = Cache::remember('sitemap_urls', 3600, function () {
        return DB::table('pages')
            ->where('is_active', 1)
            ->whereNull('deleted_at')
            ->orderBy('updated_at', 'desc')
            ->get(['slug', 'updated_at']);
    });

    $xml = new SimpleXMLElement('<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"></urlset>');

    foreach ($urls as $row) {
        $url = $xml->addChild('url');
        $url->addChild('loc', htmlspecialchars(url($row->slug)));
        $url->addChild('lastmod', date('Y-m-d', strtotime($row->updated_at)));
    }

    return response($xml->asXML(), 200)
        ->header('Content-Type', 'application/xml; charset=UTF-8');
});

Если нужен WordPress-или Bitrix-уровень разбор с настройками и безопасным обновлением, посмотрите ещё safe update для сайта и настройку кеширования в Битрикс. После переезда кэш часто становится причиной того, что sitemap отстаёт от реальности на сутки или даже неделю.

Типичные ошибки в sitemap после переезда

Самая распространённая ошибка — оставить в карте сайта старые URL с редиректами. Это я вижу почти на каждом втором переезде, если его делали без техспециалиста. Вторая ошибка — не убрать дубли: www и без www, http и https, слэши и без слэшей, варианты с index.php, служебные параметры, UTM-хвосты. Третья — не обновить дату lastmod, хотя контент реально переписали.

Четвёртая ошибка особенно обидная: sitemap генератор берёт данные из базы, но после миграции на новый сервер MySQL 5.7/8.0 или после перевода на PHP 8.2/8.3 начинает работать иначе. На одном проекте после обновления PHP до 8.3 у плагина в WordPress поломалась выборка постов с кастомными полями, и в sitemap пропали важные страницы услуг. Проблему заметили только через неделю, когда просел трафик на брендовых запросах.

Пятая ошибка — забыть про медиа-sitemap, если у вас сильная зависимость от изображений или видео. Если, например, у вас каталог товаров, AVIF-картинки и нормальная оптимизация медиа уже настроены, имеет смысл проверить отдельную карту для изображений. Для этого у меня есть отдельная статья про sitemap для изображений и видео. На интернет-магазинах это иногда даёт дополнительный трафик из поиска по картинкам.

Как проверить sitemap после запуска переезда

После того как новый sitemap опубликован, я проверяю его не только глазами, но и через инструменты поисковиков, логи и обычный HTTP-запрос. Смотрю, что файл отдаёт 200 OK, корректный XML, правильную кодировку и в нем нет битых ссылок. Потом отправляю карту в Search Console и Яндекс.Вебмастер. И уже после этого смотрю, как поисковики начали её обходить.

Если сайт переехал с большим количеством URL, проверка должна идти в несколько этапов. Сначала выборка по top pages, потом по новым разделам, потом по низкочастотным страницам. У меня был случай на проекте с 40 000 URL: sitemap технически был идеален, но один шаблон карточки товара генерировал неправильный canonical. В итоге половина картинок и страниц была в индексе через старые адреса. Мы заметили это только через отчёт по индексации и сверку URL в логах.

Что я проверяю руками

• открывается ли sitemap без редиректов;
• нет ли 404/403/500 внутри карты;
• совпадает ли домен в sitemap с финальным доменом после переезда;
• нет ли URL с параметрами, дублей и служебных страниц;
• совпадают ли canonical, редиректы и URL в sitemap;
• видят ли карту поисковые системы в логах;
• не растёт ли число ошибок обхода после обновления карты.

Если хотите проверить проект целиком, а не только sitemap, я бы подключил ещё SEO-аудит сайта и 404-мониторинг. После переезда это нормальная рабочая связка. Sitemap говорит роботу, куда идти, а 404-мониторинг показывает, где он всё ещё натыкается на старые маршруты.

location = /sitemap.xml {
    try_files /sitemap.xml =404;
    add_header Content-Type application/xml;
    add_header Cache-Control "public, max-age=3600";
}

location = /sitemap_index.xml {
    try_files /sitemap_index.xml =404;
    add_header Content-Type application/xml;
    add_header Cache-Control "public, max-age=3600";
}

Как ускорить индексацию после переезда через sitemap

Sitemap сам по себе не гарантирует быструю индексацию, но он сильно помогает, если всё остальное сделано нормально. Я обычно стараюсь сразу обновить внутренние ссылки, убедиться, что главные разделы доступны за 2-3 клика, и только потом полировать карту сайта. Если у вас на новом сайте ещё и Core Web Vitals просели, поисковик будет ходить медленнее. Тут уже стоит смотреть и на скорость, и на Google PageSpeed Insights 2026, и на Core Web Vitals.

На практике самая полезная штука — не просто отправить sitemap, а связать его с датами изменений. Если у вас есть lastmod, и он реально обновляется по факту правок, робот быстрее понимает, какие страницы требуют повторного обхода. Это особенно актуально для новостников, блогов и каталогов услуг, где контент часто правится вручную.

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

Что делать на разных типах сайтов: интернет-магазин, корпоративный сайт, блог

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

На многостраничных проектах я иногда дополнительно делаю контрольные сверки по базе данных. Например, можно собрать список опубликованных страниц и сравнить его с sitemap SQL-запросом. Это помогает быстро увидеть пропуски. И да, это не занудство. Это нормальная страховка, когда переезд уже стоит денег.

SELECT COUNT(*) AS published_pages
FROM pages
WHERE is_active = 1
  AND deleted_at IS NULL;

SELECT COUNT(*) AS sitemap_pages
FROM sitemap_urls
WHERE http_code = 200
  AND is_indexable = 1;

Если цифры не сходятся — значит, где-то проблема в генераторе, фильтрации или логике CMS. У одного клиента в Битриксе после переезда из 12 480 опубликованных страниц в sitemap попали только 11 903. Разница оказалась в одном условии по свойству инфоблока. Вроде мелочь, но именно такие мелочи потом съедают трафик. Если нужна аккуратная настройка без сюрпризов, это уже зона, где разумно заказывать настройку силами специалиста и не играть в угадайку.

Что я советую делать в 2026 году

Если коротко, после переезда сайта sitemap нужно не «поправить», а пересобрать заново под новую структуру. Проверить редиректы, canonical, robots.txt, код ответа, кэширование и только потом отправлять карту в поисковые системы. Иначе вы получите красивый XML-файл, который просто документирует старые ошибки в новом месте.

Я на своей практике уже давно пришёл к простому выводу: sitemap при переезде — это не второстепенная задача, а часть миграции наравне с бэкапами, 301 редиректами и проверкой индексации. Если проект важный, крупный или деньги идут из SEO-трафика, тут лучше не экономить на технической части. Иногда достаточно пары часов грамотной доработки, чтобы не терять недели на восстановление видимости.

И если вы как раз сейчас переезжаете сайт, я бы не откладывал проверку на потом. Сначала техническая база, потом уже всё остальное. На сложных проектах я обычно комбинирую аудит, правки и контроль после запуска. В ряде случаев это дешевле, чем потом разгребать последствия через месяц. Для оценки объёма работ удобно использовать калькулятор стоимости сайта, а если нужен уже конкретный план действий — начинать стоит с проверки сайта и точечной доработки сайта.