Смена названия компании, объединение проектов или переход на другой адрес могут потребовать нового домена. Для посетителя задача выглядит просто: открыть привычную ссылку и попасть на нужную страницу. Для команды это ещё проверка ссылок, поисковых настроек, форм и интеграций.
Ниже — рабочий план переезда существующего сайта. Он не гарантирует сохранение позиций: Google предупреждает о возможных колебаниях при повторном обходе и обработке страниц. Общий порядок описан в официальном руководстве по смене URL сайта. Здесь разберём, какие материалы подготовить и как принять результат со стороны бизнеса.
Определите границы переезда
Запишите, что именно меняется: только домен, адреса разделов, система управления или содержание страниц. Разделите обязательные изменения и задачи, которые можно выполнить после переезда. Когда одновременно меняются адреса, тексты и формы, сложнее установить причину ошибки.
Для небольшого корпоративного сайта полезен короткий план: ответственный за домены и сервер, исполнитель переноса, сотрудник для проверки заявок и человек, который отслеживает поиск. Назначьте время переключения, порядок связи при сбое и критерии возврата к предыдущему состоянию.
Сохраните копию сайта, конфигурации и списка адресов до начала работ. Проверьте, кто может восстановить эту копию. Само наличие архива без понятной процедуры восстановления не помогает быстро вернуть рабочую форму или страницу.
Составьте карту старых и новых адресов
Соберите страницы из sitemap, меню, каталога, аналитики и доступных журналов обращений к сайту. Отдельно отметьте посадочные страницы рекламы, документы для скачивания и ссылки, которые компания размещала в письмах или Telegram. Sitemap — полезная отправная точка, но в ней могут отсутствовать старые опубликованные адреса.
Для каждого адреса зафиксируйте новое назначение и ожидаемый результат. Условный пример: old.example/services/bot ведёт на new.example/services/bot. Если путь тоже меняется, запишите точную новую страницу. Добавьте ответственного за проверку и отметку о том, что на ней сохранён нужный смысл.
Страницу услуги следует сопоставлять с той же услугой. Для удалённого материала сначала решите, есть ли подходящая замена. Не подменяйте это решение одним правилом «всё отправлять на главную»: посетитель со ссылкой на конкретную инструкцию всё равно останется без ответа.
Настройте постоянные редиректы страниц
Для окончательного переноса страниц Google рекомендует серверные постоянные редиректы; к ним относятся HTTP-коды 301 и 308. Различия постоянных и временных перенаправлений разобраны в документации Google о редиректах. Конкретные правила зависят от сервера и системы управления сайтом.
Проверяйте результат по карте адресов. Лучше вести старую ссылку прямо на окончательную страницу, чем через несколько промежуточных вариантов. Посмотрите, не появился ли круг: старая страница отправляет на новую, а та — обратно.
Включите в проверку используемые варианты с www и без www, HTTP и HTTPS. Для старого HTTPS-адреса нужна работающая конфигурация защищённого соединения: посетитель должен получить перенаправление, а не предупреждение браузера. Доступ к старому домену и его обслуживанию остаётся частью проекта.
Редиректы не стоит снимать сразу после переключения. В руководстве по переезду Google рекомендует сохранять их как можно дольше, обычно не менее года. Для важных старых ссылок срок поддержки полезно определить отдельно и заложить в план технического сопровождения.
Согласуйте canonical, внутренние ссылки и sitemap
У перенесённых страниц проверьте канонический адрес: он должен соответствовать выбранной версии на новом домене. Меню, ссылки в текстах и sitemap также должны использовать согласованные новые адреса. Если эти элементы указывают на разные версии, настройки противоречат друг другу.
Google рассматривает canonical и другие способы канонизации как сигналы, а не как обещание показать конкретный URL в выдаче. Поэтому проверка одной строки canonical не заменяет сверку всего маршрута и содержимого страницы.
В региональных версиях сохраните соответствие услуг, страны, языка и валюты. Если используются hreflang-связи, обновите адреса связанных страниц. Не объединяйте разные условия для России и Беларуси только ради сокращения числа редиректов. Организацию таких разделов разобрали отдельно в статье о сайте для России и Беларуси.
Перед запуском проверьте, не остались ли ограничения тестовой копии. Правило noindex может находиться в HTML или HTTP-заголовке; его назначение объяснено в документации о запрете индексации. Уберите временные запреты только с тех страниц, которые действительно готовы к публичному доступу и поиску.
Проверьте формы и внешние системы
Поисковые настройки не подтверждают, что сайт продолжает принимать заявки. Составьте отдельный список: формы, CRM, Telegram-уведомления, оплата, авторизация, загрузка файлов и аналитика. Для каждого процесса отметьте адреса, настройки и доступы, которые зависят от домена.
Проверьте разрешённые адреса и обратные ссылки в подключённых сервисах. Не распространяйте правило редиректа страниц на обработчики форм и API без проверки их работы. Для каждого действия важен конечный результат: обращение дошло до сотрудника, вложение доступно, а клиент получил корректный статус.
Старые рекламные ссылки с метками тоже включите в приёмку. Сверьте, сохраняется ли нужный источник обращения. Для схемы, в которой посетитель переходит в бота, полезна статья об UTM-метках и источнике заявки. Состав подключений описан в материале об интеграции сайта с CRM и оплатой.
Проведите проверку до и после переключения
Согласуйте список контрольных страниц и действий до начала работ. Для каждой проверки фиксируйте адрес, время, фактический результат и замечание. Не ограничивайтесь скриншотом главной страницы.
- Откройте старую ссылку на услугу и убедитесь, что она приводит к соответствующей новой странице.
- Проверьте HTTP-ответ конечной страницы, её заголовок и содержание.
- Пройдите меню, внутренние ссылки, документы и изображения.
- Проверьте отображение и навигацию на телефоне.
- Отправьте согласованную тестовую заявку и найдите её в принимающей системе.
- Сверьте источник тестовой заявки и отсутствие лишней повторной карточки.
- Откройте заведомо отсутствующий адрес и проверьте обработку ошибки.
Успешный HTTP-ответ сам по себе не гарантирует индексацию. Google отдельно объясняет обработку HTTP-кодов: важны также полученное содержание и поисковые ограничения. Если вместо услуги открылась пустая страница, проверка доступности не считается завершённой.
Сообщите о смене домена в Search Console
После переноса и настройки редиректов проверьте доступ владельца к старому и новому ресурсам. Для подходящего переезда домена или субдомена используйте инструмент «Изменение адреса», соблюдая его требования. Он не предназначен для простой смены хостинга с прежними URL, перехода только с HTTP на HTTPS или перемещения отдельных страниц внутри сайта.
Добавьте актуальную карту нового сайта и проверьте выбранные страницы в Search Console. Сохраните дату переключения в журнале изменений, чтобы сопоставлять с ней последующие отчёты. Не считайте отправку sitemap подтверждением, что все новые адреса уже появились в поиске.
Наблюдайте за страницами и обращениями
После запуска проверяйте ошибки старых ссылок, доступность новых страниц, получение заявок и изменения поисковых отчётов. Разделяйте технический сбой и изменение спроса: спад обращений не всегда объясняется только доменом, но неработающая форма требует немедленного исправления.
Для обсуждения доработки или переноса сайта подготовьте оба домена, карту страниц, список интеграций и данные о важных посадочных страницах. Это позволит оценить состав работ без обещаний неизменных позиций и без одновременного переделывания всего проекта.