ИП Виноградов Д.В. 
Тендеры и лиды
Информация
Новый дизайн, удобная система управления и более быстрый сайт — отличный результат переезда на другую CMS. Но только в том случае, если вместе со старой платформой компания не потеряла поисковый трафик, привычные адреса страниц и заявки клиентов. Разбираемся, как этого избежать и почему технически успешный перенос ещё не означает успешную миграцию.
Смена системы управления сайтом обычно начинается с хороших намерений. Бизнесу становится неудобно работать с существующей платформой, функциональности не хватает, обновления требуют слишком много времени, а за каждую небольшую доработку приходится платить разработчику.
Решение кажется очевидным: выбрать другую CMS, перенести материалы, обновить дизайн и запустить сайт.
Однако через некоторое время после запуска иногда выясняется, что посещаемость снизилась, отдельные страницы исчезли из поиска, а привычные ссылки из рекламных материалов ведут на ошибку 404.
При этом новый сайт может выглядеть значительно лучше предыдущего.
Почему так происходит?
В веб-студии MiWix мы рассматриваем перенос сайта прежде всего как задачу сохранения уже созданного цифрового актива. За годы работы сайт накапливает не только тексты и изображения, но и поисковую историю, внешние ссылки, позиции по запросам, внутренние связи между страницами.
И всё это необходимо учитывать при переходе на другую платформу.
Этот материал будет полезен владельцам сайтов, SEO-специалистам и разработчикам, которые планируют сменить CMS или уже готовят миграцию.
Начнём с важного различия.
Предположим, компания использует WordPress и решает перейти на другую систему управления. Домен остаётся прежним, адреса страниц не меняются, тексты сохраняются, а пользователи получают обновлённый интерфейс.
Для поисковой системы такая смена может пройти относительно спокойно. Если структура, содержимое, доступность страниц и основные SEO-настройки сохранены, поводов для серьёзных изменений в поиске значительно меньше.
Совсем другая ситуация, когда одновременно со сменой CMS разработчики решают:
изменить адреса всех страниц;
полностью перестроить каталог;
объединить или удалить разделы;
переписать основные тексты;
заменить дизайн и логику навигации;
перенести сайт на другой домен.
Каждое из этих изменений может повлиять на индексацию и поисковую видимость.
Поэтому один из главных принципов безопасной миграции — не менять без необходимости то, что уже работает.
Если компании нужна только более удобная CMS, совершенно необязательно одновременно переделывать всю структуру сайта.
Это одна из наиболее распространённых проблем.
На старом сайте услуга находится по адресу:
site.ru/services/remont-kvartir/
После переноса на новую CMS она получает адрес:
site.ru/uslugi/remont/
Для посетителя разница практически незаметна: он открывает меню и переходит в нужный раздел.
Но поисковая система уже знает старый URL. На него могут ссылаться другие сайты, статьи, каталоги компаний и рекламные материалы.
Если старый адрес просто перестал существовать, поисковый робот получает ошибку 404. Человек, перешедший по сохранённой ссылке, видит то же самое.
Правильное решение — настроить постоянное перенаправление со старой страницы на новую с помощью HTTP-кода 301 или 308.
Но есть важный нюанс.
Перенаправлять все старые страницы на главную — плохая идея.
Если пользователь искал конкретную услугу, а вместо неё попал на главную страницу компании, его задача осталась нерешённой. Для поисковых систем такие массовые перенаправления тоже могут быть сигналом отсутствия подходящего содержимого.
Мы рекомендуем ещё до начала переноса создавать таблицу соответствия URL: старый адрес, новый адрес, назначение страницы и необходимость редиректа.
Если на старом сайте 500 страниц, такую таблицу нужно подготовить для всех значимых адресов, включая те, которые отсутствуют в основном меню.
Отдельное внимание стоит уделять страницам, получающим поисковый трафик и внешние ссылки.
Представим страницу, которая несколько лет продвигается по запросу «производство металлических лестниц на заказ».
У неё есть правильно составленный Title, основной заголовок H1, подробный текст, фотографии готовых работ, ссылки на другие услуги.
При переносе разработчик копирует видимое содержимое страницы. Текст и изображения на месте, всё выглядит нормально.
Но автоматически созданный Title теперь содержит только название компании. Description отсутствует. Заголовок H1 изменился. Внутренние ссылки ведут на старые адреса.
Внешне сайт практически не изменился, однако поисковая система получает документ с другими характеристиками.
Поэтому перенос контента должен включать не только видимую часть страницы.
Необходимо сохранять или осознанно пересматривать Title, Description, H1–H6, индексируемый текст, атрибуты изображений, canonical, структурированные данные и внутренние ссылки.
Особенно внимательно нужно относиться к коммерческим страницам.
На них важны не только ключевые слова, но и конкретные предложения: цены, условия, ассортимент, география работы, примеры выполненных проектов.
Если при редизайне половину полезной информации заменили красивым баннером и короткой фразой «Мы профессионалы своего дела», поисковая ценность страницы вполне может снизиться.
Хороший дизайн не должен достигаться за счёт исчезновения полезного содержимого.
Внутренние ссылки помогают посетителям перемещаться между разделами, а поисковым роботам — находить страницы и понимать связи между ними.
При смене CMS структура нередко пересобирается заново.
Например, раньше с главной страницы можно было перейти в каталог, оттуда — в определённую категорию, а затем — на страницу конкретного товара.
После переноса каталог работает, но ссылки на некоторые вложенные категории исчезают. Страницы физически существуют, однако добраться до них через обычную навигацию становится значительно труднее.
Это особенно критично для крупных каталогов, интернет-магазинов и сайтов услуг с десятками направлений.
Мы рекомендуем проверять не только наличие каждой страницы, но и её место в общей структуре.
Важно понимать, откуда на неё ведут ссылки, сколько переходов требуется пользователю и существуют ли логичные маршруты к связанным материалам.
Отдельно проверяются меню, хлебные крошки, блоки похожих товаров, связанные услуги и ссылки внутри текстов.
Иногда исправление перелинковки приносит больше пользы, чем очередное переписывание метатегов.
При переезде часто меняется не только система управления, но и шаблон сайта.
Появляются новые CSS-файлы, JavaScript-библиотеки, шрифты, изображения, компоненты интерфейса.
В результате сайт может стать тяжелее, чем был до обновления.
Сама по себе новая CMS не гарантирует высокую скорость загрузки. На результат влияют качество шаблона, серверная часть, количество запросов, размер ресурсов и поведение скриптов.
Особенно опасны ошибки, которые невозможно обнаружить обычным просмотром главной страницы.
Например, мобильное меню открывается только при определённой ширине экрана. Форма отправки работает на компьютере, но не работает на телефоне. После оптимизации JavaScript перестаёт открываться всплывающее окно заказа.
Есть и менее заметные проблемы.
Страница визуально открывается, но сервер возвращает неправильный HTTP-статус. В HTML случайно остался noindex. Canonical указывает на тестовый домен. Содержимое важного раздела появляется только после выполнения JavaScript, который поисковый робот не всегда может корректно обработать.
Такие ошибки способны повлиять на индексацию даже при полностью сохранённых текстах.
Поэтому после переноса необходим не только визуальный осмотр, но и технический аудит.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13829 тендеров
проведено за восемь лет работы нашего сайта.
У большинства CMS есть собственная логика формирования карты сайта и управления доступом поисковых роботов.
При смене платформы старые настройки могут перестать соответствовать новой структуре.
Допустим, на прежнем сайте были служебные адреса, которые запрещалось обходить роботам. На новом сайте они изменились, но файл robots.txt остался прежним.
Или другая ситуация: разработчики закрыли тестовую версию сайта от индексации и случайно перенесли эти ограничения на рабочий домен.
Результат может оказаться неприятным: поисковым роботам недоступны важные страницы.
Отдельная история — sitemap.xml.
Новая CMS может формировать карту сайта автоматически, но автоматическое создание файла ещё не гарантирует правильность его содержимого.
В карте могут оказаться служебные страницы, несуществующие адреса, дубли или URL с перенаправлениями.
Мы придерживаемся простого правила: автоматизация должна сопровождаться проверкой результата.
Карта сайта должна содержать актуальные канонические страницы, предназначенные для индексации. А правила robots.txt необходимо проверять с учётом реальной структуры проекта.
Самая важная работа начинается ещё до установки новой CMS.
Сначала необходимо зафиксировать исходное состояние существующего сайта.
Без этого невозможно объективно оценить результат.
Нужно понимать, сколько страниц находится в поиске, какие из них приносят посетителей, по каким запросам сайт получает показы, где расположены основные точки входа и какие материалы наиболее ценны.
Мы рекомендуем выгружать список URL не из одного источника, а из нескольких: карты сайта, результатов технического сканирования, аналитики и панелей вебмастеров.
Это позволяет обнаружить страницы, которые существуют, но уже давно отсутствуют в меню.
Затем стоит сохранить исходные SEO-настройки и структуру внутренних ссылок.
Отдельно фиксируются страницы с внешними ссылками и коммерчески важные разделы: услуги, категории каталога, карточки товаров и страницы контактов.
Если есть возможность, полезно сделать резервную копию не только файлов и базы данных, но и конфигурации сервера.
Тогда при обнаружении серьёзной проблемы будет проще восстановить предыдущую версию сайта.
И ещё один совет: не удаляйте старую рабочую систему сразу после запуска новой.
Переход должен предусматривать возможность отката, причём с учётом изменений данных, которые могли произойти после запуска.
Этот список можно использовать как основу технического задания при переносе с WordPress, Tilda, 1С-Битрикс, Joomla и других систем управления.
Адреса страниц. Все значимые старые URL должны сохраниться либо иметь корректное перенаправление на соответствующую страницу.
SEO-метатеги. Проверить Title, Description, H1 и другие важные элементы каждой продвигаемой страницы.
Контент. Убедиться, что тексты, изображения, таблицы, файлы и коммерческая информация перенесены полностью.
Внутренние ссылки. Проверить меню, хлебные крошки, категории, карточки товаров и ссылки внутри материалов.
HTTP-статусы. Рабочие страницы должны отдавать 200 OK, постоянные перенаправления — соответствующие коды 301 или 308, отсутствующие страницы — корректный 404 или 410.
Индексация. Проверить robots.txt, метатеги robots, HTTP-заголовки X-Robots-Tag и canonical.
Карта сайта. Пересоздать и проверить sitemap.xml, исключив ненужные адреса и дубли.
Адаптивность. Протестировать сайт на компьютерах, планшетах и смартфонах, включая работу меню и интерактивных элементов.
Скорость. Сравнить производительность до и после миграции, уделив внимание основным страницам и реальным условиям мобильного подключения.
Функциональность. Проверить формы, поиск, фильтры, корзину, оформление заказа и другие пользовательские сценарии.
Аналитика. Убедиться, что счётчики, цели, события и инструменты вебмастеров работают корректно.
Резервное копирование. Подготовить проверенную резервную копию и план восстановления на случай критических ошибок.
Самое важное — выполнять эту проверку до переключения основного домена на новую платформу.
Сегодня появляется всё больше инструментов, которые способны автоматически получать содержимое сайта, сохранять HTML, изображения, стили и скрипты.
Это полезное направление.
Ручной перенос большого количества страниц занимает много времени, а повторяющиеся действия повышают вероятность человеческих ошибок.
В MiWix мы тоже развиваем подобные инструменты. Одно из направлений — MiWix Constructor, инструмент для подготовки HTML-страниц и шаблонов для нашей CMS.
При разработке мы уделяем внимание сохранению локальных ресурсов, очистке лишних зависимостей, обработке HTML и формированию понятной структуры файлов.
Но здесь важно не путать техническую конвертацию сайта с полноценной SEO-миграцией.
Программа может помочь перенести содержимое страницы и необходимые ресурсы. Однако она не способна самостоятельно определить бизнес-ценность всех разделов, выбрать правильную стратегию изменения структуры или гарантировать сохранение поисковых позиций.
Например, инструмент может обнаружить, что одна страница исчезла, а другая появилась. Но решить, являются ли они действительно эквивалентными по смыслу, должен специалист.
Именно поэтому мы считаем правильным сочетать автоматизацию с контролем разработчика и SEO-специалиста.
Автоматизировать стоит рутинные операции. Решения, влияющие на структуру и поисковую видимость сайта, требуют отдельной проверки.
Допустим, новый сайт запущен. Все страницы открываются, меню работает, формы отправляются.
Можно ли считать работу завершённой?
С технической точки зрения — возможно. С точки зрения SEO — ещё рано.
Поисковым системам необходимо повторно обойти страницы, обработать изменения и обновить сведения в своей базе.
На это требуется время.
После запуска мы рекомендуем регулярно проверять Яндекс Вебмастер и Google Search Console.
Нужно отслеживать ошибки обхода, изменения количества индексируемых страниц, поисковые показы, клики и состояние перенаправлений.
При переезде на новый домен также необходимо использовать предусмотренные поисковыми системами инструменты смены адреса.
В первые дни особенно важно контролировать техническую доступность сайта. В последующие недели — сравнивать поисковую видимость с исходными показателями.
При этом не стоит делать выводы по одному дню статистики.
Посещаемость зависит от сезонности, спроса, рекламной активности и изменений поисковой выдачи. Поэтому сравнение должно учитывать не только общее количество визитов, но и источники трафика, группы запросов и конкретные посадочные страницы.
Если после переноса исчезли переходы на один раздел, проблему нужно искать именно в нём, а не начинать переписывать весь сайт.
В последние годы к привычным SEO-задачам добавился ещё один вопрос: насколько хорошо информация сайта воспринимается системами, которые формируют ответы с помощью искусственного интеллекта?
При смене CMS об этом тоже стоит подумать.
Здесь полезны те же базовые принципы качественного сайта: понятная структура, доступное содержимое, достоверные сведения о компании, логичные заголовки и корректная семантическая разметка.
Для коммерческих сайтов важно сохранять конкретику: какие услуги предоставляет компания, в каких регионах работает, какие условия предлагает, какие проекты реализовала.
Хорошая техническая основа облегчает обработку информации разными системами, но сама по себе не гарантирует попадание в нейросетевые ответы.
Поэтому мы не рассматриваем GEO как набор волшебных метатегов, которые достаточно добавить при переносе.
Гораздо важнее, чтобы новая платформа позволяла публиковать содержательные, структурированные и технически доступные материалы.
У каждой системы управления есть преимущества и ограничения.
WordPress предлагает большую экосистему расширений. 1С-Битрикс используется для многих корпоративных и коммерческих проектов. Tilda удобна для определённых задач визуальной разработки. Собственные CMS, включая MIWIX, позволяют развивать функциональность под конкретные требования.
Но название платформы само по себе не определяет успешность переезда.
Можно перенести сайт на дорогую систему и потерять половину полезных страниц. А можно выбрать более простое решение, аккуратно сохранить структуру, улучшить удобство и продолжить развитие проекта.
Всё зависит от качества подготовки, технической реализации и последующего контроля.
Мы в MiWix считаем, что хороший перенос сайта должен решать две задачи одновременно: давать бизнесу новые возможности и сохранять то, что уже было достигнуто.
Потому что сайт — это не просто набор HTML-страниц и картинок.
Это накопленная история работы компании в интернете, её репутация, поисковая видимость и один из каналов привлечения клиентов.
И при смене CMS эту историю важно не начинать с нуля, а грамотно продолжать.
Главный вывод: переезд на другую CMS должен начинаться не с выбора нового шаблона, а с аудита действующего сайта. Чем точнее разработчик понимает, что необходимо сохранить, тем меньше риск потерять результат многолетней работы над проектом.
Материал подготовлен веб-студией MiWix на основе подходов к разработке, техническому сопровождению и поисковой оптимизации сайтов.
