Тильда редирект 301 - первое, что настраиваю после переноса сайта на этот конструктор: без него старые страницы выпадают из индекса, а трафик по ним обнуляется вместе с позициями. Проблема всплывает в двух сценариях: сайт переезжает на Тильду с WordPress, Bitrix или самописного движка, либо структура URL меняется внутри уже работающего проекта на Тильде, например при переименовании разделов каталога или смене slug у товаров. В обоих случаях старый адрес должен вести на новый с кодом ответа 301, а не просто показывать заглушку 404 или молча редиректить через JavaScript.
По теме статьи
Готовое решение
Автоматическая конвертация валюты на Tilda
Цены товаров в нужной валюте по актуальному курсу ЦБ — автоматически и в реальном времени.
от6 000 ₽
Сайт / Tilda
От лендинга до интернет-магазина
Разработка сайтов на Tilda с нестандартным функционалом. Кастомные формы, калькуляторы, интеграции с CRM — всё, что нужно для запуска бизнеса.
от30 000 ₽
Зачем нужен именно 301, а не 404 или JS-переадресация
Поисковик воспринимает 301 как сигнал «страница переехала навсегда» и постепенно переносит на новый адрес вес ссылок, историю индексации и позиции по запросам, под которые старая страница ранее ранжировалась. Код 404 говорит обратное: страницы больше нет, и робот со временем выкидывает её из индекса вместе с накопленным весом. Код 302 расценивается как временный переезд, поэтому поисковик может продолжать держать в индексе старый адрес и не спешить переносить сигналы на новый.
JS-редирект (meta refresh или скрипт, который меняет location после загрузки страницы) работает иначе: браузер пользователя перекинет на новый адрес, а вот поисковый робот сначала должен отрисовать страницу и выполнить скрипт, чтобы понять, куда вести дальше. На части краулов это происходит с задержкой или не происходит вовсе, поэтому передача веса получается слабее и медленнее, чем при серверном 301.
| Тип переадресации | Код ответа | Передача веса и позиций |
|---|---|---|
| 301 (постоянный) | 301 | Полная, поисковик переносит сигналы на новый адрес |
| 302 (временный) | 302 | Частичная, старый адрес долго остаётся в приоритете у робота |
| JS/meta refresh | 200 + скрипт | Слабая и с задержкой, зависит от того, как робот отрисовывает страницу |
Где в Тильде настраивается редирект 301
В Тильде это штатная функция, отдельный код на странице писать не нужно. Открываю Настройки сайта → SEO → Редиректы страниц (Code 301): там таблица из двух колонок, старый адрес и новый. Указываю адреса без домена, начиная со слэша, вида /staraya-stranica и /novaya-stranica, нажимаю «Добавить», а затем кнопку сохранения изменений. Ещё одно условие из справки: 301 редирект работает только с несуществующих страниц, а для переброски посетителей между существующими страницами вендор предлагает блок T223. Редирект работает на стороне сервера Тильды, а не через скрипт в браузере, поэтому это настоящий код 301, который корректно видит и поисковый робот, и обычный переход по ссылке.
Важный нюанс: таблица редиректов привязана к конкретному проекту и домену, который к нему подключён. Если меняется путь внутри одного и того же сайта, штатного инструмента достаточно. Если переезд идёт на совсем другой домен, редирект на уровне Тильды переносит путь внутри проекта, а сама привязка нового домена и настройка DNS делаются отдельно, до того как заниматься таблицей соответствий адресов.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Перенос сайта на Тильду со старого движка: как собрать карту адресов
Перед тем как вбивать пары в таблицу редиректов, нужен список всех старых URL, которые реально нужны поисковику и пользователям. Беру его из нескольких источников:
- sitemap.xml старого сайта, если он ещё доступен;
- выгрузка посещаемых страниц за последний год из Яндекс Метрики и Google Analytics, чтобы не упустить страницы с реальным трафиком;
- краулер вроде Screaming Frog, если движок старый и карты сайта уже нет.
Дальше сопоставляю каждый старый адрес с новым на Тильде и заношу пары в таблицу. На практике на интернет-магазине с полусотней товарных карточек, переезжавшем с WooCommerce, редиректы делались по SKU: адрес вида /product/tovar-123 вёл на новую карточку в Tilda Store с тем же артикулом в тексте страницы, чтобы не перепутать пары при ручной сверке.
Когда старых страниц не полсотни, а несколько сотен и больше, свести таблицу соответствий вручную долго. В таких случаях выгружаю списки старых и новых URL в таблицу и матчу их автоматически по ключевым словам в заголовке или по остаткам старой структуры категорий, а сценарий сборки таблицы собираю в n8n, чтобы не пересчитывать всё руками при каждой правке.
Смена структуры внутри уже работающего сайта на Тильде
Второй сценарий не связан с переездом с другого движка: сайт как был на Тильде, так и остаётся, но меняется структура. Переименовал раздел каталога, изменил slug у страницы услуги, объединил два похожих лендинга в один - в каждом из этих случаев старый адрес страницы перестаёт существовать, и его нужно явно завести в таблицу редиректов, иначе внешние ссылки и старая выдача начнут вести на 404.
Отдельно стоит день, когда меняется slug у товара в Tilda Store: карточка остаётся на месте, но адрес меняется, и старая ссылка из письма клиенту, каталога маркетплейса или закладки в браузере перестаёт работать без редиректа.
Когда штатного редиректа недостаточно
Таблица редиректов понимает маску по звёздочке, но не регулярные выражения. Правило вида /blog/* на /articles/ отправит на одну страницу любые несуществующие адреса, которые после домена начинаются с /blog/. Чего маска не делает, так это не переносит хвост пути: если у сайта была структура вида /catalog/category/product-name и каждой карточке нужен свой новый адрес, одной звёздочкой это не собрать, придётся заводить пару на каждую карточку.
На проектах, где таких страниц сотни и они группируются по понятной закономерности, я делаю кастомную доработку на Тильде: скрипт на стороне сайта разбирает входящий путь по маске и подставляет нужный новый адрес, либо автоматически генерирует и заливает весь список пар в таблицу редиректов, вместо того чтобы вносить их построчно.
Типичные ошибки, из-за которых редирект не спасает позиции
Чаще всего позиции проседают не из-за отсутствия редиректа, а из-за того, как он настроен:
- цепочки редиректов, когда старый адрес ведёт на ещё один устаревший, а тот уже на актуальный - каждое звено съедает часть веса и замедляет обход робота;
- внутренние ссылки в меню, футере и текстах страниц продолжают указывать на старые адреса, хотя формально редирект настроен;
- все старые страницы скопом редиректят на главную вместо релевантных разделов - для поисковика это выглядит как мягкий 404 и позиции по конкретным запросам не восстанавливаются;
- sitemap.xml не обновлён и продолжает содержать старые адреса, из-за чего робот дольше держит их в индексе;
- не учтены варианты с www и без www, с http и https - если старый сайт отвечал по нескольким вариантам домена, редирект нужен для каждого.
Как проверить, что редиректы работают и позиции не просели
После публикации проверяю код ответа напрямую, не полагаясь на визуальный переход в браузере:
curl -I https://example.ru/staraya-stranicaВ ответе должен быть заголовок HTTP/1.1 301 Moved Permanently и корректный Location с новым адресом. Дальше добавляю оба варианта сайта, старый и новый, в Яндекс Вебмастер и Google Search Console, слежу за разделом с ошибками обхода: если 404 по старым адресам продолжают появляться, значит какие-то пары в таблице редиректов пропущены. По моей практике позиции по старым запросам возвращаются в течение 2-4 недель, если редиректы расставлены точно на релевантные страницы, а не скопом на главную, и внутренние ссылки на сайте обновлены следом за таблицей редиректов.
Условия и возможности Тильды и Яндекс Директа меняются, поэтому перед запуском я уточняю их у самих сервисов.
Частые вопросы
Сколько времени занимает восстановление позиций после редиректа 301 на Тильде?
По моей практике заметное восстановление трафика по старым запросам видно через 2-4 недели после публикации редиректов, при условии что каждая старая страница ведёт на близкую по смыслу новую, а не на главную. Полный пересчёт позиций поисковиком может занимать дольше, особенно если страниц много и у них разная история индексации.
Можно ли редиректом 301 на Тильде перенаправить на другой домен?
Таблица редиректов в настройках сайта работает с путями внутри проекта. Если нужно перенаправить со старого домена целиком на новый, сначала настраивается переезд на уровне DNS и привязки домена к хостингу, а уже внутри самого проекта на Тильде таблица редиректов используется для того, чтобы старые пути корректно попадали на нужные новые страницы.
Что делать, если старых страниц несколько тысяч?
Вручную заносить тысячи пар в таблицу долго и легко ошибиться. Сначала собираю полный список старых адресов из sitemap.xml и статистики посещаемости, группирую их по закономерностям в структуре, а для больших объёмов заказываю автоматическую генерацию и загрузку списка редиректов вместо ручного ввода каждой строки.
Чем 301 отличается от JS-переадресации, которую иногда советуют на форумах?
JS-редирект перекидывает пользователя в браузере уже после того, как страница загрузилась и выполнился скрипт, а код ответа сервера при этом остаётся 200. Поисковому роботу сложнее и дольше считывать такой переход, поэтому вес и позиции переносятся слабее и медленнее, чем при серверном коде 301, который Тильда отдаёт сразу в заголовке ответа.