Перенос корпоративного сайта: как сохранить страницы и проверить результат
Перенос корпоративного сайта на другую CMS или хостинг начинается с инвентаризации действующих страниц, форм и интеграций. Если URL меняются, для каждой значимой старой страницы нужен новый релевантный адрес либо обоснованное решение о ее удалении. После запуска проверяют не только главную страницу, но и ответы сервера, формы, редиректы и отчеты поисковых систем.
Ни одна процедура не гарантирует отсутствие колебаний позиций и трафика. Google предупреждает, что перенос с изменением URL требует времени на обход и обработку сигналов. Этот план помогает снизить число технических ошибок и заранее определить, что делать, если после запуска что-то не работает.
Короткий ответ: сначала снимите состояние старого сайта и составьте таблицу
старый URL → новый URL. Затем подготовьте новый сайт на тестовом контуре, проверьте перенаправления и функции, сохраните возможность отката и только после этого переключайте трафик.
Скачайте рабочую карту URL: RU — XLSX · EN — XLSX. В файле есть лист для вашей карты и отдельные учебные примеры. Для каждого адреса предусмотрены решение, ожидаемые и фактические ответы сервера, конечный URL, canonical, ответственный и результат проверки.
Определите тип переноса
| Сценарий | Что меняется | Главный риск |
|---|---|---|
| Смена хостинга без смены URL | Сервер и окружение | Формы, интеграции, DNS и производительность |
| Смена CMS с сохранением URL | Код, шаблоны, админка | Потеря контента, метаданных, структурированных данных и функций |
| Редизайн со сменой URL | Страницы и адреса | Пропущенные редиректы, неравнозначные новые страницы, внутренние ссылки |
| Смена домена | Домен и обычно инфраструктура | Все перечисленное плюс обновление внешних сервисов и уведомление поисковых систем |
Если URL не меняются, не создавайте редиректы ради самого факта миграции. Сосредоточьтесь на совпадении содержания и работы функций. Если меняются и CMS, и структура, разделите технический переезд и изменения контента там, где это возможно: так легче найти причину последующей просадки.
Соберите исходные данные до разработки
Выгрузите URL из sitemap, CMS, поисковой аналитики и журнала сервера. Один sitemap может не содержать старые адреса с внешними ссылками или реально посещаемые страницы. Для каждого URL сохраните тип страницы, текущий ответ сервера, canonical, title, количество органических переходов и целевой адрес после переноса.
Отдельно перечислите формы, точки входа в CRM, телефонию, оплату, личные кабинеты, аналитические события и сторонние скрипты. Зафиксируйте рабочие сценарии до переключения. Это позволит после релиза сравнить результат с исходным состоянием, а не с памятью команды.
Сделайте резервную копию файлов и базы данных и проверьте, что ее можно восстановить в отдельном окружении. Копия без проверки восстановления не является надежным планом отката.
Составьте карту URL и редиректов
В таблице достаточно нескольких обязательных полей:
| Старый URL | Новый URL | Действие | Ответственный за проверку |
|---|---|---|---|
/services/old-name |
/services/new-name |
Постоянный редирект | SEO и разработчик |
/blog/topic-a |
/blog/topic-a |
Сохранить адрес | Редактор |
/catalog/old-item |
/catalog/new-item |
Редирект при равнозначном товаре | Владелец каталога |
/promo/expired |
— | Проверить, есть ли замена; при отсутствии оставить корректный ответ 404/410 | Владелец раздела |
Google рекомендует постоянные серверные редиректы для адресов, которые действительно переехали, и советует вести сразу к конечному URL, без длинных цепочек. Не отправляйте все старые страницы на главную: она редко отвечает на тот же вопрос. При удалении без релевантной замены нужен честный статус отсутствующей страницы.
Проверьте также внутренние ссылки, канонические адреса, hreflang для языковых версий и sitemap. Все они должны указывать на конечные доступные адреса, а не на промежуточные редиректы.
Как заполнить шаблон карты URL
На листе «Карта URL» внесите адреса своего сайта. Для реальной проверки используйте полные URL с протоколом и доменом; относительные пути на листе «Примеры» показывают только условные сценарии. Начальные статусы «Не проверено» означают, что проверки еще не проведены.
Сначала заполните план: старый и новый адрес, решение и его основание, ожидаемые ответы. Если адрес сохраняется, перенаправление не требуется только ради смены CMS. Для переехавшей страницы согласуйте постоянный редирект на релевантную замену. Для удаленного материала без замены отдельно согласуйте 404 или 410. Пример с 404 в файле не задает правило для всех удалений.
После настройки откройте старый URL и запишите его фактический ответ, конечный адрес и ответ целевой страницы. Проверьте, что новая страница содержит согласованный материал, а canonical указывает на нужный конечный URL. Совпадение кода 200 с планом само по себе не подтверждает сохранность содержания или появление страницы в поиске.
Заполните дату, ответственного и подтверждение проверки. Это может быть ссылка на обезличенный отчет обхода или запись о проверенном сценарии. Отмечайте «Пройдено», когда проверены решение, ответы, конечный адрес и содержание. При расхождении укажите «Требует исправления» и конкретную причину. «Не применимо» используйте с пояснением для отдельной проверки, которая не относится к выбранному решению.
Перед публикацией разберите строки с незаполненным решением. Затем повторите проверку на рабочем домене и сохраните отдельную копию результата: успешная проверка тестового контура не подтверждает правильную настройку публичного сайта.
Подготовьте и проверьте новый сайт до переключения
Тестовый контур нужен для приемки, но не должен становиться поисковой копией основного сайта. Ограничьте доступ к нему и проверьте, что запреты, используемые на тесте, не перейдут случайно на опубликованные страницы. Google отдельно напоминает снять noindex с нового сайта в момент запуска, если он был нужен до публикации.
Проверяйте не случайные страницы, а типы шаблонов: главную, услугу, категорию, карточку, статью, форму, поиск и языковую версию. Для каждого типа сравните содержание и метаданные с согласованным планом. Слепой перенос старых title и description не нужен, если их исправляли в рамках проекта; важно не потерять целевой интент страницы.
| Проверка | Приемочный результат |
|---|---|
| URL и ответы сервера | Страницы открываются по конечным адресам, старые маршруты ведут к нужным новым |
| Формы и CRM | Тестовая заявка дошла до нужного получателя с источником и согласием |
| Контент и изображения | Тексты, файлы и изображения доступны на всех типах страниц |
| SEO-шаблоны | Свой canonical, осмысленный title и H1, корректные внутренние ссылки |
| Индексация | На публичных страницах нет случайного noindex и блокировки обхода |
| Аналитика | События не дублируются и приходят в нужный счетчик |
| Мобильный сценарий | Меню, формы и ключевые действия работают на телефоне |
Для новой структуры корпоративного сайта полезно заранее согласовать обязательные разделы и маршруты пользователя. Если подрядчика еще выбирают, используйте чек-лист оценки исполнителя.
Как провести запуск с возможностью отката
Назначьте время переключения, ответственного за инфраструктуру и окно наблюдения. Перед запуском сохраните актуальную копию и список изменений DNS, прокси, сертификата и переменных окружения. План отката должен отвечать на три вопроса: при каком сбое возвращаем прежнюю версию, кто принимает решение и сколько времени занимает возврат.
После переключения пройдите короткий список приоритетных URL вручную и автоматической проверкой. Убедитесь, что 301/308 ведут на конечные адреса, нет 404 на ключевых страницах и не появились цепочки. Google использует постоянный редирект как сигнал выбора нового канонического URL; сам редирект не заменяет качество новой страницы.
Что наблюдать после переезда
В первые дни проверяйте ошибки сервера, формы, журнал посещений роботов и страницы, на которые ведут старые адреса. Затем сравнивайте поисковые показы и клики по группам страниц с сопоставимым периодом до запуска. Отдельно следите за страницами, которые ранее приносили заявки.
| Сигнал | Первая проверка |
|---|---|
| Резко выросло число 404 | Найти исходные ссылки и пропущенные URL в карте переноса |
| Новые страницы не появляются в поиске | Проверить ответ сервера, noindex, robots, canonical, sitemap и внутренние ссылки |
| Есть показы, но упали клики | Сравнить запросы, title и тип страницы; не менять все метаданные разом |
| Есть клики, но нет заявок | Проверить формы, телефонию, события и сценарий на мобильном |
Google отмечает, что переобход может занимать время и советует использовать доступные для обхода ссылки и актуальные данные sitemap. Отправка карты сайта помогает обнаружению, но не гарантирует сроки индексации или восстановления трафика.
Чек-лист перед приемкой проекта
- Есть таблица старых и новых URL, включая ранее посещаемые страницы вне sitemap.
- Резервная копия восстановлена на тестовом контуре.
- Редиректы ведут к релевантным страницам без лишних промежуточных адресов.
- Проверены формы, интеграции, аналитика и мобильные сценарии.
- На публичных страницах сняты тестовые ограничения индексации.
- Sitemap, canonical и внутренние ссылки указывают на конечные URL.
- Назначены ответственные за запуск, откат и наблюдение после него.
Если текущий сайт уже получает заявки, начните проект с аудита сайта и согласованной карты переноса. Это дает команде проверяемую исходную точку для разработки и приемки.
Разработка сложного веб-проекта
От идеи до масштабируемого кода. Оставьте заявку на предварительную оценку вашего проекта (смета и сроки).