Каждое изменение адреса в Яндексе — новый домен, добавление или удаление www, переезд на HTTPS — сводится к одним и тем же трем техническим требованиям. Где они настраиваются, зависит от платформы: файлы сервера на хостинге с самостоятельным управлением, настройка администратора на хостинговой платформе.
Что должно быть настроено независимо от платформы
- Канонический адрес сайта, чтобы он генерировал внутренние ссылки и абсолютные URL последовательно на том адресе, который вы планируете сохранить.
- Редиректы со старого адреса на новый, со страницы на страницу.
- robots.txt, доступный и согласованный на обоих адресах, с обновленной директивой
Sitemap.
Где что находится
- Самостоятельный хостинг (Apache, nginx). Редиректы в
.htaccessили конфигурации сервера; адрес сайта в собственных настройках приложения. Полный контроль и ответственность за правильность правил перезаписи. - CMS-платформы. Большинство предоставляют настройку адреса сайта или базового URL, которую необходимо изменить а также редирект на уровне сервера. Изменение одного без другого приводит к тому, что сайт корректно перенаправляет, а затем на каждой странице ссылается внутри на старый адрес.
- Конструкторы на хостинге. Протокол и префикс обычно представляют собой переключатель, а редиректы обрабатываются платформой. Ограничение заключается в детализации: многие предлагают только общий редирект на главную страницу, что Яндекс прямо не рекомендует, так как это оставляет пользователей в тупике и замедляет индексацию нового сайта.
Проверка, которая выявляет большинство ошибок
После настройки запросите каждый вариант адреса — с wwwи без него, по HTTP и HTTPS — и убедитесь, что возвращается ровно один 200 а остальные перенаправляются на него за один переход. Затем убедитесь, что robots.txt доступен как на старом, так и на новом адресах и что оба файла совпадают. Обе проверки доступны в инструменте ответа сервера в консоли.
Тогда и только тогда
Отправьте переезд через Индексация → Переезд сайта. Инструмент фиксирует намерение; конфигурация — это то, что делает его реальностью, а отправка до того, как заработают редиректы, просто тратит впустую недели, которые требуются на распространение изменений.
Как мы это применяем
The failure we see most often on CMS platforms is a redirect done properly at the server while the application still has the old address in its settings, so every internal link points back at the address being retired. It costs nothing to check and it is invisible in a browser, because the redirect quietly rescues each click. We test all four address variants before submitting any move request.
Связанные услуги