Смена CMS с сохранением SEO: карта редиректов и тестовый сервер миграции

Дизайн нового сайта утверждён, макеты красивые, шаблоны вёрстаны. И вот тут выясняется неприятная вещь: поисковая выдача, чужие статьи, письма клиентам и закладки в браузерах продолжают вести на адреса прежней CMS. Адреса вроде /index.php?id=412, /catalog/item.html или /page/about-us/ не знают о вашем редизайне. Если новая система отвечает на них ошибкой 404, человек увидит не новый дизайн, а тупик.

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

Сначала инвентарь: что у вас вообще есть

Поисковики и люди приходят не на «разделы сайта» из презентации, а на конкретные URL. Часть из них вы знаете наизусть, часть забыта: старые акции, PDF-прайсы, страницы фильтров, версии для печати, адреса с параметрами, картинки, на которые ссылаются другие сайты. Новая CMS может не воспроизводить ничего из этого, если вы заранее об этом не подумали.

Документация Google по переезду сайта с изменением URL строит рекомендованный процесс вокруг подготовки нового сайта, сопоставления старых и новых адресов, перенаправлений и наблюдения за трафиком со старого и нового сайта (Google Search Central: Site move with URL changes). Первый шаг этой цепочки, сопоставление, невозможен без полного списка того, что сопоставлять.

Источников адресов обычно несколько, и ни один не полон сам по себе:

• Обход сайта краулером. Показывает то, что достижимо по внутренним ссылкам. Не увидит страницы-сироты, на которые ведут только внешние ссылки.
• Карта сайта и выгрузка из базы старой CMS. Покажут то, что система считает опубликованным, но не то, что реально отвечает кодом 200.
• Журналы веб-сервера. Лучший способ узнать, какие адреса запрашивают живые люди и роботы: по ним видно и забытые страницы, и устаревшие ссылки.
• Отчёты поисковых систем и веб-аналитики. Покажут адреса, которые приводят посетителей из поиска, и адреса с внешних ссылок.

Объедините выгрузки в одну таблицу, уберите дубли и добавьте для каждого адреса несколько колонок: код ответа сейчас, тип страницы, откуда он известен (журнал, краулер, аналитика), приблизительная ценность. Ценность не обязательно считать точно. Достаточно простой градации: приводит посетителей из поиска, на него есть внешние ссылки, нужен для сделок, не нужен ни для чего.

Ловушки в старых адресах

На этом этапе всплывают мелочи, которые потом дорого обходятся:

• один и тот же материал доступен с косой чертой на конце и без неё, с www и без, по http и https;
• регистр символов в пути: старый сервер мог не различать его, новый различает;
• параметры сортировки и сессий, создающие тысячи дубликатов;
• расширения .html и .php, которые новая CMS не воспроизводит;
• файлы: документы, архивы и изображения, лежавшие в папках загрузок.

Если у старой системы есть несколько вариантов одной страницы, в таблице каждому нужна отдельная строка. Дальше все они должны сходиться в один итоговый адрес, но решать это нужно осознанно, а не оставлять на волю шаблонов.

Карта соответствий: один к одному, многие к одному и «нет»

Теперь для каждой строки инвентаря нужно ответить на вопрос: где сейчас живёт это содержимое? Бывает три принципиально разных ответа.

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

Многие к одному. Вы решили объединить три тонкие статьи про доставку в одну полноценную. Старые три адреса должны вести на новую объединённую страницу. Здесь важно честно спросить себя: действительно ли содержимое новой страницы отвечает на то, что искал человек по каждому из старых адресов? Если да, перенаправление уместно. Если вы свалили всё в общий раздел, где нужного абзаца не найти, это уже не перенос, а потеря.

Нет соответствия. Некоторые страницы вы сознательно удаляете: снятый с продажи товар без аналогов, акция двухлетней давности, служебные страницы. Для них честный ответ сервера — «страница удалена» (код 404 или 410), желательно с полезной страницей ошибки, где есть поиск и ссылки на разделы. Привычка отправлять всё пропавшее на главную — плохое решение: человек, пришедший за конкретной вещью, попадает в место, где её нет, и воспринимает это как обман. Универсальным SEO-приёмом такая переадресация не является.

Пример фрагмента карты

Условный интернет-магазин садового инвентаря переезжает со старой самописной системы на новую платформу. Фрагмент карты может выглядеть так:

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

Редиректы без цепочек и без «всё на главную»

Когда карта готова, её нужно превратить в правила сервера или в настройки CMS. Здесь есть два типичных греха.

Первый — цепочки. Старый адрес ведёт на промежуточный, тот на ещё один, и только потом на итоговую страницу. Каждый шаг замедляет загрузку и повышает вероятность ошибки. Откуда они берутся? Накапливаются от предыдущих переездов: когда-то страницу перенесли, потом переименовали, потом сменили схему адресов. При очередной миграции новые правила наслаиваются на старые. Лечится это просто: в карте для каждого старого адреса указывайте итоговое место назначения, а не следующий шаг. Если в вашем инвентаре есть старые правила перенаправлений, прогоните их через ту же таблицу и пересчитайте, чтобы каждый исходный адрес вёл прямо на финальный.

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

Если схема адресов меняется закономерно (например, /catalog/item.php?id=N превращается в /catalog/…/slug/), правило-шаблон возможно только тогда, когда новый адрес можно вычислить из старого. Обычно слаг в новой системе так не получить, поэтому для товаров и статей надёжнее таблица соответствий, загруженная в CMS или в конфигурацию сервера, чем регулярное выражение. Шаблонами хорошо решаются другие задачи: единый вариант протокола и имени хоста, косая черта в конце, регистр.

Простой пример правила

Для сервера nginx точечный перенос одной страницы может выглядеть так:

location = /delivery.html {
    return 301 /info/dostavka-i-oplata/;
}

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

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

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

Канонический адрес. Тег rel="canonical" в разметке страницы указывает предпочтительный URL. Типичные ошибки после смены CMS: канонический адрес ведёт на старый домен или на тестовый стенд (шаблон скопировали вместе с настройками), на адрес без косой черты, когда сама страница отдаётся с ней, или на страницу, которая в свою очередь перенаправляет дальше. Каждый такой случай противоречит тому, что сообщает редирект.

Внутренние ссылки. Документация Google отдельно напоминает о проверке внутренних ссылок и адресов страниц на новом сайте (Google Search Central). Это важный нюанс: после миграции меню и шаблоны уже ведут на новые адреса, но статьи, перенесённые из старой системы, часто сохраняют старые ссылки внутри текста. Они продолжат работать за счёт редиректов, но каждая такая ссылка — лишний прыжок. Лучше заменить их при переносе содержимого, а не полагаться на перенаправления как на постоянное решение.

Доступность для роботов. Тестовый стенд обычно закрывают от индексации, и это правильно. Опасность в том, что запреты переезжают вместе с содержимым: файл robots.txt с полным запретом, тег noindex в шаблоне, защита паролем на уровне сервера. Запуск с таким наследием превращает аккуратную миграцию в исчезновение сайта из поиска. Поэтому в список проверок перед переключением входит отдельный пункт: на боевом домене нет запретов, оставшихся от стенда.

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

Репетиция на закрытом стенде

Всё перечисленное проще и безопаснее проверять не на живом домене, а на копии нового сайта, развёрнутой отдельно. О том, как настроить такую копию, мы писали в материале про staging-копию сайта; здесь важна не сама настройка, а то, что вы на ней репетируете.

Репетиция имеет смысл, когда на стенде воспроизведено поведение боевой среды: те же правила перенаправлений, то же содержимое, те же шаблоны. Различаться должно только имя хоста и закрытый доступ. Для такого стенда подойдёт отдельный VPS: root-доступ позволяет настроить веб-сервер и правила так же, как они будут на боевой площадке, а NVMe-диск ускоряет повторные прогоны краулера и импорт содержимого. По ресурсам ориентируйтесь на собственные замеры: стартовые тарифы MAATRIX (например, Ba с 1 vCPU и 2 ГБ RAM или Uab с 2 vCPU и 4 ГБ) годятся как отправная точка для небольшого сайта, но это не обещание ёмкости, и нагрузку краулера и импорта лучше оценить на деле. Если у вашей площадки есть требования к размещению, выбор локации (в публичном предложении названы UK, US, RU и FR) делайте с учётом аудитории и ваших правил, а наличие нужного образа проверьте в форме заказа.

Что гонять на стенде

1. Весь список старых адресов через карту. Скрипт или краулер в режиме списка запрашивает каждый старый URL и записывает код ответа и конечный адрес. Ожидание простое: один переход, код постоянного переноса, итоговая страница отвечает 200.
2. Поиск цепочек и петель. Любой маршрут длиннее одного шага — повод поправить карту.
3. Сверка канонических адресов. Для итоговых страниц canonical должен указывать на саму страницу и на тот домен, на котором сайт будет работать.
4. Внутренние ссылки. Обход нового сайта должен находить как можно меньше ссылок, ведущих на старые адреса или на сам стенд.
5. Доступность для роботов. Проверьте, как будут отдаваться robots.txt и теги индексации на боевой конфигурации, и что в них нет следов стенда.
6. Страницы ошибок. Несуществующий адрес должен отвечать кодом 404, а не 200 с красивой, но пустой страницей.

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

Выборка важных страниц и критерии переключения

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

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

Заранее сформулируйте критерии, при которых переключение допустимо. Пример условных критериев:

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

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

Одно изменение за раз

Google рекомендует по возможности менять по одной крупной составляющей: домен, CMS или дизайн (Google Search Central). Для вашей задачи это практический довод. Если одновременно сменить CMS, редизайн и домен, то при падении трафика вы не поймёте, что его вызвало. Если рамки проекта это допускают, разнесите изменения во времени. Если нет, хотя бы держите в уме, что причин у любого изменения будет несколько, и готовьте более тщательное наблюдение.

Переключение и план отступления

Репетиция заканчивается решением о запуске. Перед ним полезно продумать, что вы будете делать, если после переключения всё пойдёт не так, и как вернуться на старую CMS.

Возврат реален, только если старая система сохраняется в рабочем состоянии на время наблюдения: доступна копия файлов и базы, настроено её развёртывание, понятно, кто и как меняет указание домена обратно. Заранее решите, в каких случаях откат оправдан. Например, если ключевые страницы массово отвечают ошибками, форма заказа не работает или на боевом домене обнаружился запрет индексации. А вот колебания позиций в первые дни сами по себе не повод откатываться: они возможны при любом переезде, и откат туда-сюда добавит путаницы.

Сохраните также исходный список адресов и карту соответствий: они понадобятся после запуска, чтобы разбирать ошибки.

После запуска: что наблюдать и чего не обещать

Документация Google включает в рекомендованный процесс наблюдение за трафиком со старого и нового сайта. Практически это превращается в регулярные проверки в первые недели:

• Журналы сервера. Какие старые адреса продолжают запрашиваться и получают ли они перенос. Адреса, дающие 404, — кандидаты на дополнение карты, если за ними стоит реальное содержимое.
• Отчёты поисковых систем. Рост ошибок сканирования, исключённые страницы, неожиданные канонические адреса, выбранные поиском вместо ваших.
• Аналитика. Динамика переходов из поиска по группам страниц, а не только общий итог: падение одной категории скажет больше, чем средняя цифра.
• Внутренний обход. Повторный краулинг нового сайта через несколько дней и после каждой крупной правки содержимого, чтобы ловить новые битые ссылки.

Теперь о честности. Хорошо подготовленная карта переноса убирает технические причины потерь, но не гарантирует, что позиции сохранятся и сколько времени потребуется на стабилизацию. Поисковые системы переоценивают страницы по собственным правилам, а новый шаблон, структура и скорость тоже влияют на результат. Поэтому правильные формулировки для заказчика звучат так: мы устранили известные риски, будем следить за ошибками и реагировать, но не обещаем конкретных цифр. Остальное лучше называть наблюдением, а не гарантией.

Адреса, которые вы добавите в карту уже после запуска, не должны ломать принцип «один шаг». Каждое дополнение проверяйте так же, как на стенде, и храните карту в одном месте, где видна история правок.

Старая закладка

Хорошая миграция по большей части невидима. Человек, который три года назад сохранил в браузере адрес с расширением .html, открывает его через неделю после запуска нового сайта. Он ничего не знает о новой CMS, о таблицах соответствий и репетициях на стенде. Он просто нажимает на закладку, мгновенно попадает на ту же страницу с тем же содержимым, пусть и в новом оформлении, и продолжает читать, как будто ничего не изменилось. Ради этого мгновения и стоило заводить таблицу, где у каждого старого адреса есть понятный дальнейший путь.