Ржанский Д.

Как перенести мобильную версию с m.site.ru на основной домен?

Как отказаться от мобильного поддомена, перенести его URL на адаптивную версию основного сайта, правильно настроить 301-редиректы, canonical и проверить результат.

Дмитрий Ржанский Дмитрий Ржанский 1 просмотров

Переезжать можно и, если основная версия уже полностью адаптивна под мобильные устройства, обычно имеет смысл. Корректная схема — каждый URL на m.site.ru постоянно перенаправить на соответствующий URL на site.ru, одновременно отключив старую логику, которая отправляет мобильных пользователей с основного домена обратно на m.. Google прямо описывает эту схему для отказа от отдельных мобильных URL.

Что должно быть готово до переключения

Основной домен должен уже отдавать полноценную мобильную версию по тем же URL, что и десктопную. Нельзя сначала закрыть m.site.ru, а потом доделывать адаптив. На мобильном отображении site.ru должны сохраниться основной контент, метаданные, структурированные данные, изображения, видео и внутренние ссылки, которые нужны для поиска и пользователей. Для mobile-first indexing Google использует мобильное представление страницы, поэтому потеря значимого контента при переносе — отдельный риск, не связанный с самим редиректом.

Перед запуском соберите соответствие старых и новых адресов:

https://m.site.ru/catalog/item/https://site.ru/catalog/item/

https://m.site.ru/articles/example/https://site.ru/articles/example/

Если пути совпадают, правило часто можно реализовать на уровне сервера для всего поддомена. Если структура различается, нужна явная карта URL. Массово отправлять все старые мобильные страницы на главную нельзя: Google предупреждает, что нерелевантные перенаправления могут восприниматься как soft 404, а Яндекс также рекомендует вести старые страницы на соответствующие новые.

Как переключить сайт

  1. Уберите перенаправления site.ru → m.site.ru, зависящие от User-Agent, размера экрана или другой мобильной логики. Если заголовок Vary: User-Agent использовался только для отдельной мобильной версии, его также следует убрать. Иначе легко получить цикл: мобильный пользователь открывает site.ru/page/, сервер отправляет его на m.site.ru/page/, а m. тут же возвращает его на site.ru/page/. Google отдельно требует убрать мобильную конфигурацию такого типа при переходе с m. на адаптивный сайт.

  2. Настройте серверный 301 Moved Permanently с каждого старого мобильного URL непосредственно на его основную версию. Для постоянного переезда Google поддерживает и 301, и 308, но для обычных GET-страниц 301 остаётся простым вариантом, соответствующим также рекомендациям Яндекса. По стандарту HTTP код 301 означает, что ресурс получил новый постоянный URI.

Пример ожидаемого ответа:

HTTP/1.1 301 Moved Permanently
Location: https://site.ru/catalog/item/
  1. На страницах site.ru оставьте self-referencing canonical, то есть rel="canonical" на сам основной URL:
<link rel="canonical" href="https://site.ru/catalog/item/">

Ссылки rel="alternate" на m.site.ru, которые раньше связывали десктопную и мобильную версии, после отказа от m. больше не нужны. Если в hreflang, структурированных данных, шаблонах, меню или других внутренних ссылках остались адреса m.site.ru, замените их на основные URL. Google рекомендует при миграциях обновлять canonical, hreflang и внутренние ссылки на конечные адреса.

  1. В основном XML Sitemap должны находиться конечные URL site.ru. Старые мобильные URL не следует продолжать публиковать как актуальные страницы сайта. Во время миграции старый Sitemap можно временно использовать для наблюдения за обработкой старых адресов в Search Console, однако актуальный Sitemap должен содержать конечные URL.

  2. Не закрывайте m.site.ru в robots.txt и не выключайте хост сразу после настройки перенаправлений. Поисковому роботу нужно иметь возможность запросить старые URL и увидеть 301. Google указывает, что для завершения миграции роботу необходимо посетить старые и новые URL, а Яндекс также требует доступности адресов для робота при переносе.

Нужен ли инструмент «Изменение адреса» в Search Console

Основной механизм здесь — серверные редиректы, а не кнопка в панели вебмастера. Специализированная инструкция Google по переходу с m. на адаптивный сайт требует поадресных 301, отключения мобильной конфигурации и self-canonical на основном сайте.

При этом актуальная общая документация Google по миграциям рекомендует Change of Address при переходе с одного домена или поддомена на другой. Поэтому для подтверждённых свойств m.site.ru и site.ru инструмент следует использовать после запуска редиректов, если Search Console позволяет выбрать соответствующие свойства. Он сообщает Google о переносе, но не заменяет карту URL и 301.

Для Яндекса критично то же соответствие старых и новых страниц. Его документация при смене URL рекомендует серверный 301 со старой страницы на соответствующую новую и проверку конечной страницы с ответом 200 OK.

Сколько держать редиректы

Google рекомендует сохранять редиректы после миграции как можно дольше и как минимум один год, чтобы системы успели повторно просканировать старые URL и переназначить связанные с ними сигналы. Для пользователей Google предлагает рассмотреть сохранение редиректов бессрочно.

Удалять DNS-запись поддомена через несколько недель только потому, что мобильные URL исчезли из выдачи, не стоит. На m.site.ru могут годами оставаться внешние ссылки, закладки и другие обращения.

Как проверить переезд

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

Для старого адреса:

curl -I https://m.site.ru/catalog/item/

Ожидаемый результат — один 301 непосредственно на https://site.ru/catalog/item/.

Для конечного адреса:

curl -I https://site.ru/catalog/item/

Ожидаемый результат — 200 OK, без обратного перенаправления на m. даже при мобильном User-Agent.

Дальше проверьте:

  • нет ли цепочек m. → www → без www → конечный URL;
  • нет ли циклов между основной и мобильной версиями;
  • все ли старые URL ведут на релевантные аналоги, а не на главную;
  • возвращают ли конечные страницы 200 OK;
  • указывают ли canonical, hreflang и внутренние ссылки только на актуальные URL;
  • исчезают ли старые мобильные URL из отчётов индексирования, а основные страницы остаются доступными;
  • не растут ли 404, soft 404 и ошибки перенаправлений после запуска.

Google рекомендует тестировать редиректы, отслеживать старые и новые URL через Search Console и серверные журналы и избегать цепочек перенаправлений.

Временные колебания видимости при миграции возможны, пока поисковые системы переобходят старые и новые адреса. Сам по себе корректный постоянный редирект Google не описывает как потерю PageRank, но это не означает гарантированного сохранения трафика: одновременно меняется мобильная реализация сайта, и ошибки в контенте, шаблоне, внутренних ссылках или рендеринге способны повлиять на результат.

Разобрать проблему на вашем сайте

Опишите проблему — найду вероятную причину и предложу понятный план исправлений без лишних работ.

Связаться