Переезжать можно и, если основная версия уже полностью адаптивна под мобильные устройства, обычно имеет смысл. Корректная схема — каждый 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, а Яндекс также рекомендует вести старые страницы на соответствующие новые.
Как переключить сайт
-
Уберите перенаправления
site.ru → m.site.ru, зависящие от User-Agent, размера экрана или другой мобильной логики. Если заголовокVary: User-Agentиспользовался только для отдельной мобильной версии, его также следует убрать. Иначе легко получить цикл: мобильный пользователь открываетsite.ru/page/, сервер отправляет его наm.site.ru/page/, аm.тут же возвращает его наsite.ru/page/. Google отдельно требует убрать мобильную конфигурацию такого типа при переходе сm.на адаптивный сайт. -
Настройте серверный
301 Moved Permanentlyс каждого старого мобильного URL непосредственно на его основную версию. Для постоянного переезда Google поддерживает и301, и308, но для обычных GET-страниц301остаётся простым вариантом, соответствующим также рекомендациям Яндекса. По стандарту HTTP код301означает, что ресурс получил новый постоянный URI.
Пример ожидаемого ответа:
HTTP/1.1 301 Moved Permanently
Location: https://site.ru/catalog/item/
- На страницах
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 и внутренние ссылки на конечные адреса.
-
В основном XML Sitemap должны находиться конечные URL
site.ru. Старые мобильные URL не следует продолжать публиковать как актуальные страницы сайта. Во время миграции старый Sitemap можно временно использовать для наблюдения за обработкой старых адресов в Search Console, однако актуальный Sitemap должен содержать конечные URL. -
Не закрывайте
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, но это не означает гарантированного сохранения трафика: одновременно меняется мобильная реализация сайта, и ошибки в контенте, шаблоне, внутренних ссылках или рендеринге способны повлиять на результат.