Переезд сайта на новый домен или URL: как подготовить SEO-карту переноса
Переезд сайта на новый домен затрагивает не только главную страницу. В поиске, закладках, рекламе и чужих публикациях остаются старые адреса товаров, статей, изображений и документов. Если перенести дизайн, а соответствия страниц оставить на потом, посетитель может попасть в общий каталог вместо нужной инструкции или получить ошибку.
Для SEO основой переезда становится карта переноса: что существовало раньше, где находится теперь и какой ответ должен получить запрос к старому URL. Смена URL без потери трафика — желаемый результат, но гарантировать его нельзя. Практический план ниже помогает уменьшить управляемые риски и проверить результат по конкретным адресам.
1. Определите границы переезда до начала разработки
Запишите, что меняется: домен, поддомен, протокол, пути страниц или несколько элементов одновременно. Отдельно укажите, какие разделы остаются на прежних адресах. Перенос только блога и переезд всего магазина требуют разных карт; одна общая строка «перенести сайт» не задаёт разработчику проверяемый результат.
Google рекомендует разделять крупные изменения: смену домена, CMS и оформления лучше не совмещать без необходимости. Иначе падение показов трудно связать с конкретной причиной: адресами, содержанием, шаблонами или доступностью. Если объединение неизбежно, зафиксируйте все изменения и проверяйте каждую группу отдельно.
Определите владельца решения, исполнителя перенаправлений, редактора карты и человека, принимающего запуск. Согласуйте время, когда команда может наблюдать за сайтом и быстро исправлять ошибки. До переключения подготовьте критерии остановки: например, массовые неверные назначения, закрытые новые страницы или неработающий основной пользовательский сценарий.
Сохраните исходные показатели и версию содержимого. Сравнивать нужно не только общий трафик, но и группы страниц, которые действительно перемещаются. Если одновременно закончилась рекламная кампания или изменился ассортимент, это должно быть видно в журнале проекта.
2. Соберите старые URL из нескольких источников
Выгрузите адреса из CMS и sitemap, дополните их обходом сайта, данными аналитики, серверными журналами и ссылочными отчётами. Один источник не даёт полной картины: обход не найдёт страницу без внутренних ссылок, а аналитика может не показывать документ, который скачивают напрямую.
Для каждой записи сохраните полный URL, тип ресурса, текущий статус, canonical, название материала и идентификатор в CMS. Добавьте признаки приоритета: поисковые переходы, продажи, важные внешние ссылки, использование в рекламе. Приоритет определяет порядок ручной проверки, но не разрешает молча потерять остальные опубликованные страницы.
Не ограничивайтесь HTML. Проверьте изображения, PDF, инструкции, прайс-листы и другие файлы с отдельными адресами. Если PDF переезжает, новый ответ должен содержать нужный документ. Редирект с инструкции на карточку товара не всегда сохраняет назначение старой ссылки.
Разделите основные адреса, известные дубли и служебные состояния. Параметр товара может определять содержание, а рекламная метка — только источник перехода. Не отбрасывайте все параметры одним правилом до проверки. Сохраните и варианты старого хоста: ссылки могли вести на HTTPS, HTTP, www и другие реально использовавшиеся поддомены.
Полезная проверка полноты — сверить независимые списки. Если журнал содержит посещаемую страницу, которой нет в выгрузке CMS, выясните причину. Возможно, это забытая посадочная, файл из отдельного каталога или старый адрес, который уже перенаправляется и тоже требует обновлённого назначения.
3. Составьте карту редиректов при переезде
Для каждого старого адреса назначьте действие: сохранить, перенести на эквивалент, объединить с другими материалами или удалить без замены. Карта должна описывать смысловое соответствие, а не только замену домена в строке. Ниже — учебный пример переезда с example.com на example.net; все адреса вымышленные.
| Старый URL | Новый URL или решение | Ожидаемый результат |
|---|---|---|
https://example.com/ | https://example.net/ | 301 на новую главную |
https://example.com/catalog/lamps/ | https://example.net/lighting/desk-lamps/ | 301 на соответствующую категорию |
https://example.com/items/lamp-a.html | https://example.net/products/lamp-a/ | 301 на тот же товар |
https://example.com/help/charging-usb.html | https://example.net/guides/lamp-power/ | 301 на объединённое руководство |
https://example.com/help/battery-care.html | https://example.net/guides/lamp-power/ | 301 на то же объединённое руководство |
https://example.com/files/lamp-a.pdf | https://example.net/manuals/lamp-a.pdf | 301, затем нужный PDF |
https://example.com/promo/2019/ | Удалено, эквивалентной замены нет | 410 по старому адресу |
В рабочей таблице добавьте причину решения, ответственного, готовность нового материала и результат проверки. Пустая ячейка назначения должна означать нерешённый вопрос, а не разрешение перенаправить всё на главную. Правила для шаблонных адресов тоже проверяют на исключениях из карты.
В примере шесть старых адресов перенаправляются на пять уникальных новых назначений, а один возвращает 410. Такое различие в количестве нормально: две инструкции объединены. Само совпадение числа старых и новых строк не является критерием качества переноса; важнее объяснимость каждого соответствия и сохранение нужного содержания.
4. Разберите коллизии и объединение материалов
Несколько старых страниц могут вести на одну новую, когда содержание действительно объединено. В примере руководство о питании лампы должно сохранить полезную информацию и о зарядке, и об уходе за аккумулятором. Совпадение общей темы ещё не доказывает, что посетитель найдёт ответ на прежний вопрос.
Google предостерегает от массового перенаправления нерелевантных адресов на главную: такие ответы могут восприниматься как soft 404. Для удалённого содержания без замены предусмотрите настоящий 404 или 410. Обработка HTTP-статусов поисковыми системами Google отличается от простого отображения красивой страницы ошибки: ответ 200 с надписью «не найдено» не равнозначен 404.
Проверьте обратную группировку карты по новым URL. Большое число разных назначений, сошедшихся в одну категорию, требует ручного разбора. Проверьте и противоположную коллизию: один старый адрес не должен случайно получать разные назначения из нескольких правил. Задайте приоритет исключений и общий порядок обработки.
Отдельно определите поведение адреса, которого нет в карте. Неизвестный путь не должен автоматически открывать главную с ответом 200. При проверке используйте намеренно несуществующий учебный адрес и убедитесь, что общий шаблон перенаправлений не маскирует ошибки. Это помогает обнаружить опасное правило ещё до получения жалоб посетителей.
Если объединяются несколько самостоятельных сайтов, рассмотрите поочерёдный перенос с оценкой результата каждого этапа. Такой подход рекомендован в справке Change of Address. Это отличается от произвольного дробления любого небольшого сайта: границы этапов выбирают по архитектуре, объёму и возможности сохранять согласованные связи.
5. Подготовьте прямые постоянные перенаправления
Для постоянного изменения адресов Google поддерживает серверные редиректы 301 и 308. В учебной карте выбран 301. Это решение для окончательного переезда публичных страниц, а не универсальная настройка всех запросов приложения: обработку форм, API и других действий проектируют отдельно.
Старый адрес должен вести непосредственно на окончательный новый. Если раньше страница A перенаправлялась на B, а теперь нужен C, обновите управляемые правила так, чтобы A тоже вёл на C. Проверьте старые исключения, нормализацию www, протокола и завершающего слеша: именно их сочетание часто создаёт лишние переходы или цикл.
Сохраните работоспособность старого домена как точки входа. Для старых HTTPS-ссылок нужен действующий TLS с сертификатом для соответствующего имени. По правилам HTTPS в RFC 9110 проверка сертификата относится к устанавливаемому защищённому соединению. Новый исправный домен не устраняет ошибку соединения со старым, из-за которой клиент не получил редирект.
Не оценивайте настройку только по открытию главной. Проверьте глубокие пути, параметры, документы и ранее перенаправлявшиеся URL. Для каждого случая сохраните исходный ответ, значение Location и окончательный результат. Перенаправление считается правильным только при соответствии утверждённой карте.
6. Подтвердите ресурсы и применимость Change of Address
Подготовьте доступ владельца к старому и новому ресурсам Search Console. Подтверждение права собственности должно сохраняться после выпуска: не потеряйте DNS-запись, проверочный файл или другой используемый способ. Наличие доступа у подрядчика до переезда не доказывает, что подтверждение переживёт смену шаблона и адресов.
По инструкции Change of Address, инструмент применяют после переезда и настройки перенаправлений. Оба ресурса должны принадлежать одному используемому аккаунту Google с правами владельца. Он не заменяет карту URL и не выполняет технический перенос сайта.
| Изменение | Change of Address |
|---|---|
| Сайт переезжает между доменами или поддоменами | Применим при выполнении требований |
| Только HTTP меняется на HTTPS | Не используется |
| Только www меняется на вариант без www или обратно | Не используется |
| Меняются пути внутри того же домена | Не используется |
| Переносится только раздел, исходный ресурс задан путём | Для такого исходного ресурса неприменим |
Есть важное различие: переносить исходный ресурс уровня пути инструмент не позволяет, но целый домен можно перенести в раздел другого домена. Заявка для одного хоста не переносит его поддомены автоматически; учитывайте отдельные варианты, включая www. Предварительная проверка инструмента проверяет 301 на выборке страниц, поэтому её успешность не заменяет проверку всей карты.
Если переезжает только блог, а магазин остаётся, не подавайте заявку о переносе всего исходного хоста ради одного раздела: она относится ко всем его путям. Для раздела выполняют адресные перенаправления и обновление связанных сигналов. Область действия инструмента должна совпадать с реальным решением о переезде.
7. Обновите ссылки и SEO-разметку на новом сайте
Новые страницы должны ссылаться на новые адреса напрямую. Обновите меню, хлебные крошки, ссылки в тексте, подборках и шаблонах. Иначе сайт продолжит отправлять посетителей через старый домен, хотя основное содержимое уже переехало. Отдельно проверьте абсолютные URL, сохранённые в базе или настройках CMS.
Согласуйте canonical с выбранным основным адресом по рекомендациям по канонизации. Для перенесённой самостоятельной страницы это обычно новый собственный URL. Не оставляйте canonical на старом домене и не канонизируйте все карточки на новую главную. Содержательные решения о дублях остаются отдельными от замены хоста.
Если есть языковые версии, обновите hreflang-аннотации у всех участников соответствующей группы. При частичном переносе часть версий может оставаться на прежнем домене, поэтому механическая замена всех вхождений опасна. Сверяйте связи с фактической картой локалей.
Сформируйте sitemap с новыми основными адресами. Не включайте туда промежуточные редиректы и удалённые страницы. Также подготовьте обновление ссылок в управляемых рекламных кампаниях, профилях и важных внешних публикациях. Там, где чужую ссылку быстро изменить нельзя, посетителю поможет сохранённый редирект.
8. Проверьте готовность новых страниц к публикации
Составьте список ограничений, добавленных только для разработки: тестовый noindex, закрытие обхода, авторизация стенда, служебные настройки шаблона. В рабочем выпуске снимите временные ограничения с тех страниц, которые должны стать публичными. Это не инструкция открыть все разделы: административные и другие непубличные зоны сохраняют предусмотренную защиту.
Проверьте фактические ответы после применения рабочих настроек. Noindex может оставаться не только в HTML, но и в заголовке X-Robots-Tag. Удаление отметки в административной панели не доказывает, что кеш или сервер перестал отдавать запрет. Нужен ответ конкретной новой страницы.
Проведите проверку содержимого: заголовки, важный текст, изображения, документы и переходы к связанным материалам. Для магазина или сервиса добавьте безопасные проверки основных действий пользователя. Формально доступная карточка с неправильным товаром или неработающей заявкой не готова к переносу трафика.
Перед запуском закройте расхождения в карте. Неизвестное назначение важного URL, массовый запрет индексирования или отсутствующие файлы — причины отложить переключение соответствующей группы. Иначе исправлять придётся уже публичный переход, по которому идут реальные посетители.
9. Выполните перенос в согласованной последовательности
Зафиксируйте версию карты и момент, после которого изменения старого сайта учитываются отдельно. Если редакторы продолжают публиковать материалы, нужен процесс переноса новых записей, иначе утверждённый список устареет ещё до запуска. Сохраните прежние правила и подготовленную конфигурацию для восстановления.
- Опубликуйте и проверьте новые страницы с рабочими настройками доступа.
- Включите согласованные перенаправления и ответы для удалённых URL.
- Проверьте контрольную выборку сразу на старой и новой стороне.
- Подтвердите новые внутренние ссылки, canonical, hreflang и sitemap.
- При применимости отправьте Change of Address и новую sitemap в Search Console.
- Зафиксируйте время, результат проверок и ответственных за наблюдение.
Эта последовательность — схема координации, а не требование оставлять сайт надолго в промежуточном состоянии. Подготовленные изменения желательно выпускать согласованно. Если этап прерван, команда должна знать, какие группы уже обслуживаются по новой схеме и какие действия остаются невыполненными.
При поэтапном переносе заранее определите границы разделов, ссылки между ними и условие продолжения. Успешный пилот не доказывает корректности всех типов страниц. Перед следующим этапом добавьте в проверку шаблоны и исключения, которых в пилоте не было.
10. Примите результат по проверяемым критериям
Проверяйте карту целиком автоматизированным обходом в согласованном темпе, а критичные материалы дополнительно просматривайте вручную. Автоматическая проверка статуса не оценивает смысловую эквивалентность. Сравните карточку, документ или статью с тем, что обещал старый адрес.
- Переносимые старые URL ведут прямо на утверждённые назначения без циклов.
- Новые назначения доступны и содержат ожидаемый материал нужного типа.
- Удаление без замены возвращает согласованный 404 или 410.
- Новые страницы не содержат случайных тестовых запретов индексирования.
- Canonical, языковые связи, внутренние ссылки и sitemap согласованы.
- Старые HTTPS-входы доступны, важные документы и изображения сохранены.
Для ключевых URL используйте проверку в Search Console. Различайте текущую проверку и сведения из индекса: положительный live-тест не гарантирует индексирования и не предсказывает выбранный canonical. Отчёт инструмента дополняет собственные проверки карты.
В акте приёмки записывайте конкретные отклонения и масштаб. «Шесть PDF ведут на HTML-карточки» полезнее, чем «есть проблемы с переездом». После исправления повторите затронутую группу и контрольные случаи, на которые могло повлиять общее правило.
11. Наблюдайте за старой и новой стороной
После запуска сравнивайте обращения, ошибки и поисковые показатели обеих сторон. Снижение переходов на старые URL ожидаемо только вместе с пониманием того, куда они переместились. Разделите смену адреса, изменение общего спроса и потерю доступности конкретной группы страниц.
Отслеживайте неожиданные 404, серверные ошибки, неправильные назначения и старые адреса, отсутствующие в карте. Новая найденная ссылка — повод дополнить инвентаризацию. Аналитику проверьте отдельно: исчезновение событий после смены домена может быть ошибкой измерения, а не исчезновением посетителей.
В актуальном руководстве Google по переезду рекомендовано сохранять перенаправления как можно дольше, обычно не меньше года. Для действующих внешних ссылок полезно оставлять их и далее. Период действия уведомления Change of Address не является датой автоматического отключения старых входов.
Назначьте ответственного за продление необходимых компонентов старой точки входа и регулярную проверку её работоспособности. Не обещайте универсальный срок восстановления трафика: обработка происходит по адресам и зависит от обхода и состояния сайта. Оценивайте динамику за сопоставимые периоды, учитывая сезонность, рекламу и изменения содержания.
12. Подготовьте возврат и завершение проекта
План возврата должен различать исправление отдельного правила и отмену всего переезда. Ошибка нескольких назначений обычно требует адресного исправления. Массовая недоступность нового сайта может потребовать другого решения, но его принимает назначенный ответственный по заранее согласованным критериям.
Не переключайте направления постоянно вслед за краткими колебаниями поискового трафика. Если возврат необходим, сначала подтвердите работоспособность прежней версии и сохранность новых данных. Старый снимок не должен уничтожить заказы, обращения или публикации, появившиеся после запуска.
Отдельно пересмотрите редиректы, canonical, sitemap и уведомление Change of Address. Если новая сторона возвращает посетителей на старую, прежние правила не должны отправлять их обратно и создавать цикл. Отмена уведомления сама по себе не меняет серверные ответы; процедуру выполняют согласованно и затем проверяют обе стороны.
Учитывайте сохранённые клиентами перенаправления: ответ 301 допускает кеширование. Исправленная серверная схема не обязательно сразу меняет поведение посетителя, который уже открыл старую ссылку. Проверка возврата должна учитывать и такой сценарий.
Для самого Change of Address Google предусматривает отмену заявки в течение 180 дней. Это ограничение инструмента, а не обещание мгновенно вернуть прежнюю картину поиска. Не откладывайте решение о критическом дефекте только потому, что техническая отмена заявки ещё доступна.
Завершайте проект после подтверждения карты, пользовательских сценариев и плана дальнейшего наблюдения. Передайте владельцу актуальный реестр адресов, список исключений, результаты приёмки и ответственных за старые входы. Это позволяет поддерживать перенос после смены исполнителя.
Подключите SiteGuard для внешнего контроля HTTP-доступности сайта после переезда. SEO-разметку и соответствие новых адресов карте проверяйте отдельно.