Почему после HTTPS появляются несколько версий URL
У домена потенциально существуют четыре комбинации: HTTP и HTTPS, каждая с www и без www. Если несколько комбинаций возвращают 200, один и тот же контент доступен по разным адресам.
Как выглядит нормальная схема
| URL | Ожидаемый ответ |
|---|---|
| http://example.ru/page | 301 → https://example.ru/page |
| http://www.example.ru/page | 301 → https://example.ru/page |
| https://www.example.ru/page | 301 → https://example.ru/page |
| https://example.ru/page | 200 |
Почему браузера недостаточно
Браузер автоматически следует перенаправлению, поэтому человек не замечает, был ли ответ 301, 302 или цепочка из нескольких переходов. Проверяйте HTTP-заголовки через инструменты разработчика, curl или сервис проверки редиректов.
Уберите цепочки
Схема http://www.example.ru/page → http://example.ru/page → https://example.ru/page работает, но создает лишний промежуточный шаг. Каждая альтернативная версия должна вести сразу на финальный HTTPS-адрес.
Порядок настройки в Tilda
Tilda рекомендует подключить домен, дождаться обновления DNS, выпустить SSL-сертификат, затем включать переход с HTTP на HTTPS и выбирать схему www. Последовательность есть в справке по HTTPS.
Проверьте смешанный контент
HTTPS-страница может загружать изображения, скрипты или iframe по старому HTTP. Браузер способен блокировать такие ресурсы. В консоли ищите предупреждения о смешанном контенте и обновляйте внешние ссылки.
Согласуйте canonical и sitemap
Если конечный URL работает по HTTPS, но canonical или sitemap указывает на HTTP, поисковик получает конфликтующие сигналы. После миграции все источники URL должны использовать одну схему.
Диагностика, если редиректы выглядят правильно только в браузере
Браузер скрывает часть технической цепочки: он может помнить старое перенаправление, автоматически дописывать HTTPS и кэшировать результат. Поэтому при аудите мы проверяем ответы через вкладку Network или отдельный инструмент HTTP-заголовков в режиме без кэша. Для каждого тестового URL записываем первый код, промежуточные адреса и конечный ответ.
Отдельно стоит проверить не только главную, но и внутреннюю страницу. Нередко главная настроена правильно, а старые внутренние адреса проходят через две-три ступени. Google рекомендует использовать постоянные серверные перенаправления для окончательного переезда и избегать лишних цепочек. Подробности есть в Google Search Central.
Где искать источник цепочки
Чаще всего она появляется, когда одновременно действует перенаправление HTTP → HTTPS, www → без www и отдельное правило для измененного URL. Нужно свести их к одному конечному адресу. Для сайта на Tilda полезно сопоставить эту проверку с материалами про главное зеркало и про T223 и настоящий 301-редирект.
Проверка без браузерного кэша
Для точечной диагностики удобно посмотреть заголовки напрямую. Команда curl -I http://example.ru/page показывает первый ответ сервера, а curl -IL http://example.ru/page - всю цепочку до конечного URL. Это помогает отличить прямой 301 от нескольких промежуточных переходов.
Проверяйте не только главную. Ошибки часто остаются на старых внутренних адресах, которые пережили редизайн или смену структуры.
Финальная схема проверки HTTPS
Переход на HTTPS завершен, когда все старые варианты URL однозначно ведут на один конечный адрес, а внутренние ссылки и SEO-файлы используют ту же схему.
