Tilda к 2026 году остаётся в России конструктором номер один для лендингов, портфолио и небольших корпоративных сайтов, и вокруг неё сложилась странная ситуация. Одни маркетологи называют платформу непригодной для поискового продвижения в принципе, другие продают курсы про "SEO на Tilda" с обещаниями первой страницы выдачи за пару недель. Правда посередине: у конструктора есть жёсткие технические границы, но внутри них он закрывает задачи аккуратнее, чем принято думать. Разница между позициями почти всегда сводится к типу проекта, а не к самой платформе.
Ниже разбор по существу: что Tilda делает за владельца сайта автоматически, где проходят границы возможностей, какие метрики Core Web Vitals показывают реальные страницы, как настраиваются редиректы и мета-теги, что происходит с микроразметкой и каталогом, и главное, как понять до старта проекта, что платформа его закроет, а не станет тормозом.
Автоматические SEO возможности платформы которые работают сразу после публикации
Базовая техника у Tilda честная. Карта сайта sitemap.xml генерируется автоматически, robots.txt редактируется в настройках проекта, к каждой странице задаются собственные заголовок title, описание description, og-теги и адрес. Подключение собственного домена меняет адреса страниц, но технические файлы переезжают вместе с проектом без ручной работы. Сертификат и протокол HTTPS платформа выпускает сама, продление происходит автоматически.
Страница настраивается по-взрослому: адрес задаётся вручную, страницу можно скрыть от поисковых систем галочкой, к ошибке 404 привязывается собственная страница с навигацией вместо пустого ответа сервера. Редиректы 301 настраиваются прямо в панели проекта списком, без обращения в поддержку. Для конструктора это редкость, у части конкурентов список редиректов и вовсе спрятан за дорогим тарифом.
Заголовки внутри страницы управляются настройками блоков: владелец выбирает уровень h1, h2 или h3 для конкретного заголовка, подписи картинок получают alt-тексты, а вес изображений уменьшается при загрузке. Статика раздаётся с CDN платформы, картинки проходят через ресайз на стороне хранилища, поэтому браузер не качает оригинал в пять мегабайтов. Код страниц собирается из блоков платформы, без случайных плагинов и тем от третьих лиц, поэтому вёрстка предсказуемая.
Отдельный плюс для неспециалистов - единая панель. Один человек без разработчика ведёт сайт целиком: правит тексты, следит за редиректами, обновляет карту сайта после публикации новых страниц. В классической CMS за каждым пунктом этого списка прячется отдельный экран настроек, и именно на них проекты обычно и сыплются.
Технические границы Tilda на которых спотыкаются растущие проекты
Границы начинаются с адресов. Структура URL у платформы плоская: страницы живут на одном уровне, вложенность разделов из адресов, как в классических CMS, не собирается. Для лендинга это неважно, для контентного проекта из сотен страниц уже критично: без вложенных разделов перелинковка и логика навигации держатся исключительно на меню и ручных ссылках.
Дальше хуже. Штатной поддержки hreflang нет, языковые версии собирают как отдельные страницы или отдельные проекты с ручными ссылками, и для мультиязычных сайтов это сразу дорогая доработка вместо штатной функции. Логика рубрик у ленты публикаций скромная: полноценных архивных страниц со своей перелинковкой лента не создаёт. Тегов, авторских архивов и серверной пагинации в привычном виде тоже нет.
Самое серьёзное ограничение - отсутствие доступа к серверу. Ни настроек кэширования на уровне HTTP-заголовков, ни собственных правил перезаписи адресов, ни конфигурации веб-сервера. Всё, что в классических CMS делается файлом конфигурации, на Tilda либо решается галочкой, либо не решается вовсе.
Наконец, экосистема. Плагинов и сторонних расширений нет, любая нестандартная функция это заказная доработка с кодом, вставленным в head, либо интеграция внешнего сервиса. Экспорт проекта отдаёт статичную вёрстку для размещения на своём хостинге, но интерактивные блоки, формы и часть скриптов остаются завязанными на платформу, поэтому экспорт решает проблему владения кодом лишь частично.
Реальные метрики Core Web Vitals на страницах Tilda по замерам
Теперь о том, что показывают замеры, а не рекламные страницы. Типовая страница Tilda это статика, собранная из блоков: общие стили сетки, скрипты платформы, библиотека jQuery и картинки с CDN. Первый экран рендерится сразу, блоки ниже подгружаются лениво, по мере прокрутки. Замер простого лендинга из стандартных блоков в PageSpeed Insights обычно даёт LCP в коридоре от двух до трёх секунд на мобильной эмуляции и оценку выше восьмидесяти баллов. Полевые отчёты по таким сайтам в Google Search Console и отчёты Яндекс Вебмастера чаще показывают зелёную зону по всем трём метрикам.
Картинка портится вместе с дизайном. Страницы с пятью-шестью секциями Zero Block, несколькими шрифтовыми семействами и тяжёлыми фоновыми обложками легко уезжают на LCP в четыре-пять секунд и в лаборатории, и в поле. CLS у Tilda обычно невелик, в районе от 0.02 до 0.06: размеры блоков фиксированы, и содержимое не переезжает после загрузки картинок. INP у лендинга с парой форм почти всегда зелёный, интерактивного кода мало. Отдельная беда - мобильные сети: LCP в поле упирается в канал посетителя, и никакая оптимизация конструктора этого не отменяет.
Практические выводы простые. Первый экран собирать из лёгких блоков, фоновую обложку готовить заранее: сжатая картинка на двести килобайтов работает лучше, чем оригинал на два мегабайта. Шрифтов подключать один-два, кириллические наборы весят ощутимо. После релиза смотреть полевые отчёты, а не один лабораторный прогон: лаборатория одинакова для всех, поле показывает живых посетителей. Потолок скорости задан кодом платформы, критический CSS из HTML не вынести и порядок скриптов не переставить, но внутри потолка остаётся заметный запас для аккуратной работы.
Повседневная работа с редиректами и мета-тегами без доступа к серверу
Редиректы живут в отдельном разделе настроек сайта: пары из старого адреса и нового вносятся списком и начинают работать после публикации. Поддерживаются только точные адреса, масок и правил по шаблону нет, поэтому проект с тысячей переездов придётся вести партиями руками или сразу переносить на другую платформу. Зато типовые задачи - смена адреса страницы, склейка зеркал, обход устаревших ссылок - список закрывает с запасом.
Проверять склейку удобно одним запросом с показом заголовков ответа:
curl -I https://example.com/old-page/Статус 301 и адрес назначения в заголовке Location означают, что переадресация работает. Цепочки из двух и более шагов лучше разрывать до одного: каждая пересадка замедляет обход робота и размывает вес страницы. Внутренние ссылки правят до включения редиректа, а не после, иначе робот сначала найдёт битый адрес и только потом его исправление.
Мета-слой страницы задаётся в её настройках: title, description, og-теги и картинка для превью ссылки. Канонический адрес платформа проставляет автоматически, дублей по адресам со слэшем и без обычно не возникает. Страница закрывается от индексации одной галочкой, без правки robots.txt вручную. Чего нет: массового редактирования мета-тегов по списку страниц, отдельных правил для поисковых систем и управления HTTP-заголовками ответа. Для сайта из тридцати страниц это несущественно, для раздела из трёхсот уже ручная рутина.
У title и description есть практические пределы: заголовок ориентировочно до шестидесяти символов, описание до ста шестидесяти, дальше поисковые системы обрезают текст на своей стороне. Панель Tilda лимиты не подсвечивает, счётчик символов в настройках отсутствует, поэтому тексты готовят с оговоркой на обрезку. Проще держать таблицу с адресами, заголовками и описаниями и переносить её в панель после вычитки.
Микроразметка и товарный каталог внутри ограничений платформы
Со структурированными сниппетами картина такая. Часть разметки платформа добавляет сама, остальное вставляют вручную через код в head страницы. Типовой пример разметки организации:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Название компании",
"url": "https://example.com",
"logo": "https://example.com/logo.png"
}Перед вставкой проверяют, что уже выводит сама страница: дубли Organization или Product валидатор показывает мгновенно. Ответственность за разметку на конструкторе полностью на том, кто ведёт сайт, автоматических напоминаний о недостающей схеме платформа не присылает.
Каталог товаров живёт внутри тех же границ. Позиции загружаются из таблицы, у каждой карточки есть своя страница и базовые настройки, но массового управления мета-тегами, как в полноценных магазинных движках, нет: сотни товарных страниц заполняются руками или не заполняются вовсе. Фасетных фильтров с человекопонятными адресами под поисковый спрос не существует, пагинация каталога устроена максимально просто.
Отсюда практический потолок каталога на Tilda: примерно до пары сотен позиций платформа справляется, дальше каждый новый товар стоит дороже, чем приносит. Магазин с тысячами карточек, фильтрами и посадочными страницами под запросы на Tilda не переносится в принципе, это вопрос не навыков, а архитектуры.
Сценарии в которых Tilda не мешает поисковому продвижению
Область, где платформа честно сильна, описывается признаками проекта. Признаки того, что Tilda закроет задачу и не станет ограничением, такие:
- Сайт решает одну понятную задачу вроде презентации услуги, события или портфолио;
- Количество страниц не превышает нескольких десятков и растёт медленно;
- Основной трафик планируется из рекламы, рекомендаций и прямых заходов, поиск вторичен;
- Каталог товаров умещается в пару сотен позиций без сложных фильтров и посадочных страниц;
- Обновления редкие, их делает один человек без привлечения разработчика;
- Сроки и бюджет запуска важнее глубокой технической настройки.
Для таких проектов Tilda быстрее и дешевле самодельных решений. Лендинг запускается за считанные дни, технический фундамент не требует проверки: карта сайта, редиректы и HTTPS работают из коробки, а страница показывает приличную скорость. Поисковым системам всё равно, на чём собран сайт, если адреса чистые, контент уникальный и ответ приходит быстро.
Обратный список тоже очевиден. Контентный проект с еженедельными публикациями и стратегией под поисковый спрос, магазин с тысячей карточек, мультиязычная версия, каталог с фильтрами под частотные запросы. Здесь платформа не просто неудобна, она не позволяет собрать саму механику, и выбирать её по цене - значит закладывать переезд в бюджет через год.
Переезд с Tilda на другую платформу без потери адресов и позиций
Если проект перерос платформу, переезд планируется заранее, а не начинается после падения трафика. Технически задача решаемая: адреса страниц фиксируются один к одному, на старом проекте настраиваются редиректы, и поисковые системы переносят историю страниц на новое место за несколько недель обновления индекса.
Порядок отработан. Сначала карта адресов текущего сайта, потом новая структура с сохранением адресов либо с осмысленными переименованиями, затем публикация новой версии и настройка редиректов 301 со старых адресов. Проверять переезд удобно краулером вроде Screaming Frog: обход покажет цепочки редиректов, битые ссылки и страницы, вылетевшие из карты. Пока робот получает редирект, страница считается переехавшей, а не исчезнувшей.
Главная ловушка переезда - контент и вёрстка. Страницы Tilda собираются из блоков, и при переносе вручную часть оформления теряется, а экспортированная статика тащит за собой зависимости от CDN платформы. Поэтому переезд совмещают с редизайном: раз всё равно переносить контент, заодно пересобирают структуру и навигацию под задачи проекта, а не копируют старую вёрстку один к одному.
Итог по платформе честный: Tilda не для всех проектов, но своей нише она соответствует. Ответственный выбор выглядит не как спор "конструктор или CMS", а как список задач проекта. Если сайт про быстрый запуск и простой презентационный контент, спорить не о чем. Если в планах поисковый трафик как основной канал, считать ограничения надо до оплаты тарифа, а не после.