Переезд с Битрикса и OpenCart: как не потерять позиции при смене движка

# Переезд с Битрикса и OpenCart: как не потерять позиции при смене движка

Мне показывали однажды переписку, которая начиналась очень бодро. Подрядчик, который полтора месяца переносил интернет-магазин с 1С-Битрикса на новый движок, написал заказчику: «Миграция завершена, все товары на месте, сайт работает быстрее старого, поздравляю с обновлением». Заказчик обрадовался, разослал письмо команде, отпраздновал закрытие проекта. Прошёл месяц. Обычная рутина — заказы идут, сайт работает, никто специально не следит за позициями в выдаче, потому что вроде бы всё сделали, все довольны. А потом кто-то из отдела продаж заметил, что заявок стало заметно меньше, полез в Яндекс.Метрику и увидел график органического трафика, который в течение трёх недель после запуска нового сайта тихо просел на шестьдесят процентов. Не обвалился в один день с очевидной причиной — а именно тихо съехал вниз, как будто воздух медленно выходил из шарика, и заметили это только когда шарик почти сдулся.

Похожую историю, только с другими деталями, я наблюдал у магазина на OpenCart, который переезжал не потому, что искал что-то лучше, а потому что предыдущий разработчик пропал вместе с доступами, а следующего Специалиста по OpenCart найти оказалось почти невозможно — платформа в России последние годы теряет и без того небольшое сообщество. Там подрядчик был другой, но сценарий тот же: перенесли товары, категории, даже дизайн получился симпатичнее старого — а через месяц владелец обнаружил, что позиции по десяткам ключевых запросов, по которым магазин годами стоял в первой десятке, просто исчезли из выдачи. Не опустились на пару строк — исчезли, как будто страниц никогда не существовало. Оказалось, что старые адреса товаров строились через параметр `product_id` в query string, новые — через человекочитаемый slug, и никто не потрудился связать одно с другим ни единой записью редиректа.

Это одна из самых частых и самых обидных историй в моей практике, и я специально не называю здесь конкретную компанию, потому что видел вариации этого сценария у доброго десятка разных клиентов, переезжавших с разных платформ — с 1С-Битрикса, с OpenCart, изредка с самописных решений. Обидная она потому, что технически всё было сделано правильно: товары перенеслись, категории перенеслись, сайт стал быстрее и симпатичнее. Подрядчик выполнил именно то, что ему заказали — перенести сайт. Просто заказчик и подрядчик говорили о разных вещах, когда произносили слово «миграция». Для одного это означало «контент и функциональность окажутся на новой платформе». Для другого — молчаливо подразумевалось «и весь наработанный годами органический трафик тоже переедет вместе с контентом». А трафик и позиции в выдаче не переезжают сами по себе никогда. Они либо сохраняются целенаправленной, кропотливой работой с адресами страниц, либо теряются — и восстанавливать их потом кратно дороже и дольше, чем сохранить с самого начала.

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

Я хочу разобрать здесь по порядку, откуда берётся этот обвал, что реально нужно перенести при смене движка, почему главный инструмент спасения — это скучная, неэффектная карта редиректов, а не красивый новый дизайн, и что делать с теми старыми адресами, для которых на новом сайте попросту нет прямого аналога. Это не абстрактная теория — это то, с чем реально работает наш плагин COS WP Woo, когда к нам приходят клиенты с намерением сменить движок, и то, что мы годами настраивали и оттачивали на собственном крупном магазине, где адресов накопилось многие тысячи, а цена ошибки в редиректах измеряется вполне реальными процентами органического трафика.

Обвал органики — это не проклятие, это арифметика

Первое, что я говорю каждому клиенту, который планирует смену движка: страх обвала позиций абсолютно оправдан, и это не преувеличение консультантов, которые набивают себе цену. Смена CMS или движка интернет-магазина в подавляющем большинстве случаев означает смену системы формирования адресов страниц — и вот здесь начинается арифметика, которая работает против вас, если её не контролировать сознательно. Adres страницы товара на Битриксе может выглядеть как `/catalog/maslo-motornoe/element.php?ID=4521`, на OpenCart — как `/index.php?route=product/product&product_id=4521`, а на WooCommerce каноничный адрес будет чем-то вроде `/product/maslo-motornoe-shell-5w30/`. Три разных URL для одного и того же товара — три разных записи в индексе поисковика, три разных истории поведенческих факторов, три разных набора внешних ссылок, которые годами вели именно на этот конкретный адрес.

Поисковик — что Яндекс, что Google — оценивает не абстрактный «сайт» и не абстрактный «товар», он оценивает конкретный URL. Все накопленные годами сигналы — ссылки с других сайтов, клики из выдачи, время на странице, показатель отказов — привязаны намертво к конкретному адресу. Если новый движок генерирует другой адрес для того же самого товара и вы не говорите поисковику явно «вот этот старый адрес теперь живёт по новому адресу, это один и тот же документ», с точки зрения поисковика произошло ровно одно из двух: либо старая страница исчезла (что плохо само по себе — исчезновение проиндексированной страницы это сигнал нестабильности сайта), либо появилась совершенно новая страница без всякой истории, с которой нужно заново нарабатывать доверие поисковика с нуля. И вот этот процесс «заново нарабатывать доверие» — это не дни и не недели, это месяцы, а для конкурентных тематик — и не один квартал.

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

Я специально не привожу здесь конкретный процент падения трафика как универсальную статистику, потому что честно — эта цифра гуляет очень широко в зависимости от того, насколько небрежно сделан переезд. Видел переезды, где просадка составляла пятнадцать-двадцать процентов и восстанавливалась за месяц-полтора, потому что редиректы настроили аккуратно с первого дня. И видел переезды, где просадка достигала семидесяти-восьмидесяти процентов трафика и растягивалась на полгода восстановления, потому что редиректы либо не настроили вообще, либо настроили одним общим правилом «всё, что не найдено, редиректим на главную». Разброс огромный, и он определяется ровно одним фактором — насколько тщательно составлена карта соответствия старых адресов новым. Здесь нет никакой магии и никакого везения, есть только вопрос, сделали вы эту скучную техническую работу или понадеялись, что как-нибудь само образуется.

Есть здесь и более тонкий эффект, который редко обсуждают, но который лично меня заставил относиться к переездам ещё серьёзнее. Поисковики оценивают не только сам факт наличия или отсутствия страницы, но и стабильность сайта в целом как сигнал качества. Массовое одномоментное появление тысяч новых URL при одновременном исчезновении тысяч старых без единой связи между ними выглядит для алгоритма подозрительно похоже на признак низкокачественного сайта, который постоянно перестраивается, или даже на попытку манипуляции выдачей. Это не значит, что поисковик обязательно накажет вас пессимизацией — но осторожность в ранжировании нового, ещё не до конца понятного домену набора страниц в такой ситуации становится ещё выше, чем обычно после переезда, и восстановление растягивается на более долгий срок.

Кстати, о «само образуется» — есть распространённое заблуждение, что достаточно оставить старый сайт доступным ещё какое-то время, и поисковик сам разберётся, куда что переехало. Это не так. Поисковик не сопоставляет две независимо существующие версии сайта по смыслу контента — он видит два разных набора URL и должен получить явную команду о переезде через код ответа сервера, а не догадываться сам. Без явного 301-редиректа со старого адреса на новый два сайта в глазах поисковика — это просто два разных сайта, конкурирующих за одну и ту же тематику, и старый рано или поздно выпадает из индекса как заброшенный, а новый долго и трудно нарабатывает позиции с нуля.

Что реально переезжает, а что остаётся на бумаге

Прежде чем говорить про редиректы, стоит проговорить, что вообще подразумевается под «перенести магазин», потому что здесь тоже полно недосказанности между заказчиком и исполнителем. Полноценный переезд — это перенос товаров со всеми характеристиками, категорий с их иерархией, атрибутов и их значений, клиентской базы, истории заказов, отзывов покупателей и контентных страниц вроде «О компании» или «Доставка и оплата». Каждый из этих типов данных на Битриксе или OpenCart хранится в своей внутренней структуре, зачастую сильно отличающейся от того, как WooCommerce ожидает получать данные, и прямого «нажал кнопку — перенеслось» здесь по-честному не бывает ни у одной серьёзной платформы при переезде между принципиально разными системами.

Практический путь, который реально работает, — выгрузить данные из старой системы в максимально структурированном виде, обычно CSV или XML, и дальше нормализовать их под формат, который принимает импортирующий механизм на стороне WooCommerce. У нас в основе такого переноса лежит модуль каталожного импорта, спроектированный как источнико-независимое ядро: он не привязан жёстко к конкретной платформе-источнику, а принимает нормализованный набор полей — артикул, название, описание, короткое описание, цену, цену по акции, остаток, изображения, категории, атрибуты, бренд, штрихкод — и дальше берёт на себя всю рутину создания или обновления карточки товара в WooCommerce. Это значит, что честная механика переезда с Битрикса или с OpenCart — это, во-первых, аккуратная выгрузка каталога в этот нормализованный вид (что почти всегда требует ручной или полуавтоматической работы с маппингом полей, потому что структура характеристик у каждой платформы своя), а во-вторых, собственно импорт через этот механизм.

Здесь я хочу быть честным до конца, потому что не люблю, когда маркетинговый текст обещает больше, чем реально стоит за продуктом: готового «коннектора одной кнопкой» именно для Битрикса или OpenCart, который сам разберёт их внутреннюю структуру базы данных без единого шага ручного сопоставления полей, у нас нет — и я сильно сомневаюсь, что где-либо на рынке есть инструмент, который сделает это без единого касания руками, учитывая, насколько по-разному разные магазины на одной и той же платформе умудряются хранить одни и те же данные. У кого-то характеристики товара — это инфоблоки со своими свойствами, у кого-то — плоские текстовые поля в описании, у кого-то смешение того и другого вперемешку. Честный процесс — это выгрузка, нормализация под единый формат, и дальше уже автоматизированный, идемпотентный по артикулу импорт: если товар с таким SKU уже существует — обновляется, если нет — создаётся, с пробным сухим прогоном, который до фактической записи в базу показывает, что именно будет создано и что обновлено, чтобы вы увидели результат до того, как тысячи позиций окажутся в каталоге, а не после.

Важная деталь, которая напрямую касается темы этой статьи: при импорте новых товаров адрес страницы формируется транслитерацией названия на латиницу, потому что WordPress не делает этого сам, а кириллица в адресе страницы выглядит как процентная путаница и плохо ведёт себя при копировании ссылки. Но — и это принципиально — такая транслитерация применяется только к новым товарам, у которых ещё не было истории. Если товар уже существует в системе, его адрес никогда не трогается повторным импортом, потому что этот адрес уже мог накопить свою историю индексации, ссылок, поведенческих сигналов. Это тот самый принцип, который должен пронизывать весь процесс переезда от начала до конца: трогать URL можно только у того, у чего никакой истории ещё нет, а всё, что уже жило своей жизнью в старой системе, требует не «создания заново», а аккуратного связывания через редирект, к которому мы сейчас перейдём.

Отдельная больная тема — атрибуты и характеристики товаров, потому что именно здесь чаще всего происходит смысловая, а не только техническая потеря при переезде. На Битриксе характеристики обычно живут как свойства инфоблока со своей системой единиц измерения и допустимых значений, у OpenCart — как отдельная таблица опций, привязанная к конкретному товару почти без единой номенклатуры значений между разными карточками. При прямолинейном переносе «как есть» вы рискуете получить в WooCommerce россыпь несвязанных текстовых атрибутов вместо аккуратной таксономии, по которой на новом сайте можно строить фильтры и фасеты — то есть каталог визуально перенёсся, а инструмент навигации по нему на витрине не работает, потому что «Вязкость: 5W-30» у одного товара и «5W30 (вязкость)» у другого для системы фильтрации — два разных значения, которые никогда не схлопнутся в один пункт фильтра без ручной нормализации. Эта нормализация — обычно самая трудоёмкая часть подготовки данных к переезду, куда более трудоёмкая, чем собственно технический импорт, и именно на ней экономят в первую очередь, когда поджимают сроки, а потом расхлёбывают кривые фильтры на витрине уже после запуска.

Отдельно скажу про клиентскую базу и историю заказов — их тоже реально перенести, но это уже вопрос не столько SEO, сколько корректности данных и, чаще всего, требований 152-ФЗ по обработке персональных данных при передаче между системами. А вот отзывы покупателей — недооценённая часть переезда с точки зрения именно SEO: подлинные отзывы с датами и содержательным текстом — это один из немногих типов пользовательского контента, который поисковики особенно ценят на карточках товаров, и терять их при смене платформы просто потому, что «в новой системе отзывы работают по-другому» — значит добровольно выбрасывать наработанный годами актив.

Карта редиректов — единственное, что реально бережёт позиции

Вот мы подошли к сердцевине всей темы. Если есть один-единственный технический артефакт, ради которого стоит прочитать эту статью до конца, — это карта соответствия старых адресов новым, реализованная как явный постраничный 301-редирект, а не как один общий редирект «всё, что не найдено — на главную». Разница между этими двумя подходами — это разница между сохранённым и потерянным трафиком, и я хочу объяснить, почему общий редирект на главную настолько разрушителен, хотя на первый взгляд кажется разумным компромиссом — мол, лучше редирект хоть куда-то, чем 404.

Проблема общего редиректа на главную в том, что с точки зрения поискового робота это по сути мягкая ошибка — soft-404. Робот заходит по старому адресу конкретного товара, ожидая найти документ про этот товар, а получает главную страницу интернет-магазина, которая с этим товаром никак содержательно не связана. Поисковик достаточно умён, чтобы отличить осмысленный редирект «эта страница переехала вот сюда, там всё ещё про то же самое» от бессмысленного «а вот тебе главная страница, разбирайся сам». И весь накопленный вес старой страницы, который мог бы перетечь на её настоящего преемника, в случае редиректа на главную просто теряется, потому что поисковик справедливо считает такой редирект признаком того, что оригинальный документ пропал без замены.

Практически подготовка такой карты начинается не с нового сайта, а со старого — нужно получить полный список URL, которые реально проиндексированы поисковиками и реально получают трафик, а не просто список страниц, которые технически существуют в старой CMS. Источников для этого несколько, и разумно использовать все сразу: выгрузка списка проиндексированных страниц из обеих панелей вебмастеров, старая XML-карта сайта, если она сохранилась, отчёт по посадочным страницам из счётчика аналитики за последний год, и, если совсем не осталось других следов, — архивные снимки сайта из общедоступных веб-архивов. Причём именно отчёт по посадочным из аналитики я считаю самым ценным источником, потому что он показывает не теоретически существующие адреса, а те, что реально приводят живых посетителей — а значит, именно они и заслуживают первоочередного, самого аккуратного редиректа, тогда как какая-нибудь давно заброшенная технической страница с нулевым трафиком за год не критична, даже если формально существовала.

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

Отдельно нужно решить, как поступать с типами совпадения в самой карте редиректов, потому что не всегда разумно прописывать точное соответствие адрес-в-адрес для каждой единицы товара. Если у вас была категория `/catalog/motornye-masla/` со стабильной структурой пагинации `/catalog/motornye-masla/page-2/`, `/page-3/` и так далее, City гораздо практичнее один раз настроить редирект по префиксу — всё, что начиналось на старый адрес категории, ведёт на новый адрес той же категории, — чем прописывать вручную redirect для каждой отдельной страницы пагинации. А вот для карточек конкретных товаров точное совпадение обязательно, потому что каждая карточка — это уникальный документ со своей историей, и обобщающее правило по префиксу здесь неизбежно разведёт часть товаров не туда, куда нужно. Смешивать оба подхода в одной карте — это не костыль, а нормальная практика: точные правила для уникальных документов, префиксные — для предсказуемо структурированных множеств вроде пагинации или служебных параметров сортировки.

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

Надгробия и то, для чего аналога у старого адреса просто нет

Здесь начинается более тонкая часть работы, потому что реальный каталог никогда не переносится один в один. За годы работы старого магазина часть товаров снималась с продажи, часть категорий объединялась или переименовывалась, некоторые акционные страницы существовали разово и никакого постоянного аналога на новом сайте у них попросту нет и не должно быть. Что делать со старым URL, у которого нет прямого преемника? Это ровно та ситуация, ради которой мы в своё время встроили в модуль редиректов механизм автоматических «надгробий» — явной записи о том, что документ по этому адресу больше не существует как самостоятельная единица, но трафик по инерции на него всё ещё идёт, и его нужно куда-то направить осмысленно.

Правило здесь простое, хотя нарушается оно постоянно: фолбэк для адреса без прямого аналога должен вести на максимально релевантный доступный раздел — как правило, это категория, к которой относился снятый с продажи товар, — а не на общий каталожный хаб или тем более на главную страницу сайта. Мы на своём горьком опыте убедились, что редирект целой группы товарных URL на общий хаб каталога поисковик воспринимает точно так же, как редирект на главную — как мягкую ошибку, которая сжигает накопленный вес вместо того, чтобы его сохранить. Категория «Гидравлические масла» — куда более осмысленный адресат для не найденного конкретного товара из этой категории, чем общая страница «Каталог» со всеми тысячами позиций сразу — потому что категория хотя бы содержательно относится к тому, что искал посетитель, и хоть какой-то релевантный сигнал для поисковика в этом редиректе сохраняется.

Расскажу конкретный пример того, как это выглядит на практике у магазина смазочных материалов, который переезжал с Битрикса. В старом каталоге было около двухсот позиций, снятых с продажи за предыдущие годы, но всё ещё получавших стабильный трафик по низкочастотным запросам — старые артикулы, снятые с производства бренды, фасовки, которые поставщик больше не выпускает. Прямого аналога у этих товаров на новом сайте не было и не могло быть — продавать то, чего физически нет, бессмысленно. Вместо того чтобы бросить эти двести адресов на произвол судьбы или тем более редиректить их скопом на главную, для каждого определили категорию, к которой относился снятый с продажи товар — те же «Гидравлические масла» или «Антифризы» — и направили туда. Часть трафика по этим запросам ожидаемо просела, потому что человек, искавший конкретный снятый с производства продукт, не всегда готов удовлетвориться категорией с аналогами. Но просела не полностью, а частично — и позиции по самой категории, наоборот, укрепились за счёт дополнительного веса, который принесли эти двести редиректов, вместо того чтобы просто испариться в никуда.

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

Есть и обратная ошибка, которую я видел реже, но которая не менее разрушительна — избыточное усердие в создании фолбэков там, где честнее было бы признать, что подходящей замены попросту нет. Один клиент, стараясь не оставить ни одного визуально «пустого» редиректа, направил несколько десятков адресов очень специфичных, узкоспециализированных товаров на общую категорию с полутора тысячами позиций внутри — из соображений «пусть лучше куда-то, чем никуда». Эффект оказался тем же самым soft-404, о котором я говорил применительно к главной странице: категория с полутора тысячами товаров отвечает на запрос о конкретной узкой позиции ничуть не лучше, чем сама главная. Мораль здесь простая и слегка обескураживающая: не для каждого потерянного адреса обязательно должен существовать красивый релевантный фолбэк. Иногда честнее оставить закономерный 404 с аккуратной страницей «этот товар больше не продаётся, посмотрите похожие» и ссылкой на поиск по каталогу, чем городить искусственный редирект, который поисковик всё равно распознает как формальность.

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

Контроль после запуска — две панели, а не один взгляд

Прежде чем перейти к этапу после запуска, скажу два слова про сроки — потому что вопрос «сколько времени готовить карту редиректов» я слышу почти на каждой встрече о переезде. Ответ зависит от размера каталога, но порядок цифр такой: для магазина в пару тысяч товаров с относительно стабильной структурой категорий подготовка полноценной карты соответствия — это одна-две недели вдумчивой работы, включая сверку по всем источникам старых адресов, которые я перечислял выше. Для каталога в десятки тысяч позиций ручная работа над каждой строкой становится нереалистичной, и здесь помогает автоматизация по шаблону: если старый и новый адрес отличаются предсказуемым образом — скажем, старая система хранила артикул в URL, а новая формирует slug из транслитерированного названия, но сохраняет тот же артикул в параметре meta, — можно сгенерировать значительную часть карты программно, оставив ручную сверку только для нестандартных случаев. Именно так мы поступаем на своих проектах: automatic-часть карты закрывает восемьдесят-девяносто процентов адресов, а оставшиеся проценты — это ровно те нетривиальные случаи, ради которых и нужен человек, разбирающийся в конкретном каталоге.

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

Здесь принципиально важно смотреть не в одну панель, а в обе — и Google Search Console, и Яндекс.Вебмастер, потому что эти две системы дают разную, иногда прямо противоречащую друг другу картину по одному и тому же сайту. Google может уже частично переиндексировать новые адреса, пока Яндекс ещё держит в индексе преимущественно старые URL с пометкой об ошибке. Возможна и обратная ситуация. Ориентироваться только на одну панель — значит видеть половину правды и рисковать пропустить проблему, которая для второй поисковой системы уже критична. В обеих панелях стоит методично сверять список ошибок сканирования — какие адреса поисковик пытается посетить и получает ошибку, — и по каждому такому адресу проверять, есть ли для него редирект в карте соответствия, и если нет, оперативно добавлять.

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

Отдельный источник сигнала, который у нас встроен прямо в модуль редиректов, — журнал реальных обращений к несуществующим страницам, то есть живой лог 404-х ошибок с сайта, а не только то, что показывают внешние панели вебмастеров с задержкой в дни. Это важно, потому что реальные посетители и боты поисковиков ходят по старым ссылкам ещё очень долго после переезда — иногда месяцами, если на них ведут внешние ссылки с чужих сайтов, форумов, старых закладок в браузерах постоянных клиентов. Просматривая этот журнал регулярно в первые месяцы после запуска, можно поймать те самые адреса, для которых карта соответствия оказалась неполной, и закрыть их редиректом до того, как они успеют накопить достаточно ошибок, чтобы всерьёз повлиять на общую оценку качества сайта поисковиком. Плюс у каждой отдельной записи редиректа накапливается счётчик переходов, и это, по сути, готовый отчёт о том, какие именно старые страницы всё ещё приносят вам трафик спустя месяцы после переезда — обычно выясняется, что несколько десятков старых URL продолжают стабильно приводить посетителей даже через год, и без правильно настроенного редиректа этот трафик просто улетел бы в никуда.

Отдельно стоит проговорить, чего ждать по срокам восстановления даже при идеально настроенной карте редиректов, потому что нереалистичные ожидания сами по себе становятся источником паники и поспешных, часто вредных решений уже после запуска. Даже безупречно выполненный переезд с точными 301-редиректами почти никогда не проходит без вообще какой-либо просадки — краткосрочное колебание позиций в первые одну-две недели после смены URL является нормальной реакцией поисковика на техническое изменение сайта, и это не повод для паники и не повод срочно что-то менять в структуре редиректов. Тревожным сигналом является не сам факт колебания, а его длительность и глубина: если через месяц-полтора трафик не начал восстанавливаться хотя бы частично, это повод разбираться предметно — смотреть отчёты об ошибках сканирования, искать необработанные адреса в логе 404, а не ждать и надеяться, что «само пройдёт».

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

Если вы планируете переезд с 1С-Битрикса, OpenCart или любой другой платформы на WooCommerce — не откладывайте вопрос карты редиректов на «после запуска, разберёмся по ходу». Она должна быть готова раньше, чем откроется новый сайт, потому что каждый день без явного соответствия старых адресов новым — это ещё один шанс, что поисковик успеет решить, будто старые страницы пропали безвозвратно. Заодно, раз уж переезд обычно совпадает с наведением порядка в остальной инфраструктуре сайта, полезно свериться с тем, как у вас устроена синхронизация каталога с 1С — многие компании, уходящие с Битрикса, как раз в этот момент отказываются и от устаревшего обмена по CommerceML в пользу более современного протокола, а заодно проверить состояние карточек товаров через SEO-аудит, который находит проблемы автоматически — переезд отличный повод устранить накопившиеся огрехи в текстах и мета-тегах, только делать это стоит уже после стабилизации редиректов, а не одновременно с ними.

Хочу закончить мыслью, которая может показаться неожиданной после всего сказанного о рисках и сложностях: переезд с устаревшей платформы — это правильное и часто необходимое решение, и я не пытаюсь отговорить от него ни одного владельца магазина на Битриксе или OpenCart, у которого объективно заканчиваются возможности старой системы, растут расходы на лицензии или сокращается число специалистов, готовых её поддерживать. Проблема не в самом переезде, а в том, что его сплошь и рядом планируют как дизайнерский и технический проект, забывая, что для действующего магазина с историей это ещё и SEO-проект, причём зачастую самый рискованный из всех, что случались с сайтом за годы его существования. Разница между удачным и провальным переездом почти никогда не в качестве нового дизайна или скорости нового движка — она в том, была ли у команды по-настоящему полная и точная карта соответствия старых адресов новым ещё до дня запуска.

В COS WP Woo модуль редиректов и импорта каталога — часть единой системы, а не набор случайных плагинов, которые нужно вручную сводить воедино в разгар и без того нервного проекта переезда: карта соответствия URL с массовым импортом через CSV, автоматическая обработка адресов без прямого аналога, живой журнал 404-х и статистика переходов по каждому редиректу. Разница между спокойным переездом и письмом с извинениями клиентам через месяц после запуска обычно решается не бюджетом на дизайн нового сайта, а тем, сколько строк карты редиректов вы подготовили заранее.