Миграция сайта и смена URL

Миграция сайта — смена адресов существующих страниц: переход с HTTP на HTTPS, смена домена или поддомена, объединение сайтов, изменение путей. Google подаёт её как процесс, который можно провести без больших потерь, если подготовиться. Главные идеи руководства: менять что-то одно за раз, подготовить соответствие старых и новых адресов, включить серверные постоянные перенаправления, следить за обоими сайтами и не торопиться. Ниже — этапы по документации и отдельно то, что в уроке является практикой автора, а не правилом Google.

Основа — руководство Google о переезде сайта со сменой URL и отдельное руководство о смене хостинга, когда адреса не меняются.

Какой это случай

• Адреса меняются (HTTP на HTTPS, новый домен, объединение доменов, новые пути): нужно руководство о переезде со сменой URL;
• Адреса остаются, меняется хостинг или подключается CDN: отдельное руководство. Переезд начинается с переключения DNS, а старую инфраструктуру выключают, когда убедились, что все пользователи, включая Googlebot, получают контент с новой. Тестовый сайт закрывают от индексирования правилом noindex.

Принципы: меняйте одно за раз

• Одно изменение за раз. Если хотите сменить домен, систему управления и оформление, делайте их по очереди: сначала домен, потом оформление. Самый опасный вариант — новый дизайн, новая CMS, новые URL и чистка контента в одном релизе — прямо противоречит этому совету;
• Время с низким трафиком. По возможности выбирайте периоды спада, чтобы затронуть меньше людей и дать серверу больше ресурсов для Googlebot;
• Сразу или частями. Малым и средним сайтам рекомендуется переезжать целиком одновременно: это помогает пользователям и ускоряет распознавание переезда. Большие сайты можно переносить по разделам; для пробы берут раздел, который меняется реже;
• Терпение. Для сайта среднего размера нужно несколько недель или больше, чтобы Google постепенно начал показывать новые URL вместо старых, для больших — дольше. Переезд идёт по каждому URL отдельно и считается завершённым, когда Googlebot побывал на каждом адресе старого и нового сайта хотя бы раз. Фиксированной частоты обхода нет.

Подготовка нового сайта

1. Список старых URL. Начните с важных: карты сайта, самые посещаемые адреса по логам или аналитике, страницы со ссылками из отчёта Search Console, список из CMS. Добавьте URL изображений, видео, JavaScript и CSS: их переносят так же, как остальное;
2. Соответствие старых и новых адресов. Для каждого старого URL определите, куда он ведёт. Для смены домена может хватить правила для всего домена;
3. Настроить новую систему. Предпочтительно ту же CMS, что на старом сайте; перенести изображения и файлы для скачивания. См. урок про выбор CMS;
4. robots.txt и noindex. Многие закрывают сайт во время разработки. Заранее подготовьте, как должен выглядеть файл на момент переезда, и список страниц, с которых надо будет снять noindex. См. урок про robots.txt и meta robots;
5. Удалённый контент. Адреса, которые не переносите, должны на новом сайте отдавать код 404 или 410;
6. Аннотации на новом сайте. Каждому новому URL — самоссылающийся canonical; если есть hreflang, обновите его на новые адреса; внутренние ссылки замените на новые. См. тег canonical;
7. Search Console. Подтвердите оба сайта, все варианты (www и без, HTTPS и HTTP). Убедитесь, что метод подтверждения продолжит работать на новом сайте; проверьте настройки старого сайта, например файл отклонённых ссылок;
8. Мощности сервера. После переезда Google временно обходит новый сайт интенсивнее: к обычным обходам добавляются обходы старых адресов с перенаправлением. Убедитесь, что нового хватит.

Сохраните две вещи для финала: карту сайта с новыми адресами из соответствия и список сайтов, ссылающихся на старые адреса.

Перенаправления

Используйте серверные постоянные перенаправления (301 или 308); клиентские — только если иначе нельзя. Избегайте цепочек: Googlebot проходит до 10 звеньев, но лучше вести сразу на конечный адрес; если нельзя — в идеале не больше 3 и меньше 5. И не отправляйте много старых адресов на один нерелевантный, например на главную: это может быть воспринято как soft 404. Исключение — объединение нескольких страниц в одну. Подробнее — в уроке про редиректы. Хорошая новость: 301 и другие постоянные перенаправления не приводят к потере PageRank.

Запуск

1. Включите перенаправления.
2. Проверьте, что canonical на новом сайте указывает на новые адреса, а временные noindex сняты.
3. Протестируйте перенаправления: для отдельных адресов проверка URL, для многих — скрипты или проверка редиректов.
4. Если меняется домен или поддомен, отправьте в Search Console заявку о смене адреса. Для HTTP на HTTPS, для www и без www и для смены путей внутри домена она не нужна. При смене домена подайте её для всех подтверждённых вариантов старого.
5. Храните перенаправления как можно дольше, обычно не менее года.
6. Отправьте новую карту сайта; старую можно убрать. См. урок про XML-карты.
7. Сразу обновите ссылки: внутренние, внешние (попросите владельцев сайтов из списка), профили в соцсетях, рекламные кампании.

Мониторинг

• Карты сайта. Отправьте обе: старую и новую. Сначала в новой будет ноль проиндексированных страниц, а в старой много; со временем это зеркально меняется. Предупреждения о перенаправлениях в старой карте нормальны и их можно игнорировать. Следить за этим удобно через мониторинг карты сайта;
• Индексирование и запросы. Отчёт об индексировании покажет спад на старом и рост на новом сайте; в отчёте по запросам начнут появляться адреса нового сайта. Следите за неожиданными ошибками обхода, например «не найдено», и за адресами, которые по ошибке ведут на несуществующие. Массово проверять статусы — аудит URL; 404 — органические 404;
• Логи и аналитика. Смотрите на обходы Googlebot, адреса с неожиданными ошибками и обычный трафик. На старом сайте трафик должен падать, на новом расти.

Типичные ошибки по документации

• Остались noindex или блокировки в robots.txt, нужные только на время миграции. Если robots.txt нет, он должен отдавать 404;
• Неправильные перенаправления: на несуществующие адреса нового сайта;
• старые canonical и hreflang, указывающие на старые адреса;
• забытые изображения, файлы и ресурсы.

Практика автора: паритет контента и первые 72 часа

Дальше — не требования Google, а рабочие приёмы. Паритет контента: если у страницы после редизайна пропали таблицы, FAQ или важные заголовки, она отвечает на запрос хуже, даже если адрес и перенаправление правильные. Сверяйте основной смысл и блоки, а мобильную версию проверяйте отдельно: Google в основном индексирует мобильную версию контента. Первые 72 часа: убедиться, что на рабочем сайте снят noindex; прогнать пачки старых адресов; проверить, что новые адреса отдают 200 и canonical на себя; что карта сайта содержит только итоговые адреса; что внутренние ссылки не ведут через перенаправления. Обойти сайт можно краулером. Документация приводит и свой набор проверок, он выше.

Чек-лист

1. Меняется одно за раз; выбрано время с низким трафиком.
2. Есть список старых URL с изображениями и ресурсами и соответствие новым.
3. На новом сайте самоссылающиеся canonical, обновлены hreflang и внутренние ссылки.
4. Перенаправления серверные постоянные, без цепочек и без массового ухода на главную.
5. Снято всё, что блокировало индексирование на время разработки.
6. Подана заявка о смене адреса, если меняется домен или поддомен.
7. Новая карта сайта отправлена; перенаправления хранятся не менее года.
8. Идёт мониторинг обоих сайтов.

Ошибки

• Менять всё в одном релизе.
• Подавать заявку о смене адреса при переходе на HTTPS.
• Оставлять noindex и блокировки с тестового сайта.
• Снимать перенаправления через пару месяцев.
• Считать переезд завершённым в день запуска.

Что дальше

Правила адресов, на которых строится любой переезд, — в уроке про структуру URL и домены и поддомены.