За несколько лет работы с Tilda насмотрелся на сайты, которые публикуют сразу после верстки, без единой проверки, а потом две недели тушат пожары: слетевшие формы, битые ссылки на мобильной версии, страница интернет-магазина в дублях у поисковика. Свой чек-лист проверки сайта на Тильде перед публикацией довел до состояния, когда прохожу его за 40-60 минут перед каждым релизом, и он реально ловит проблемы раньше, чем их увидит клиент или, что хуже, покупатель на чекауте.
По теме статьи
Готовое решение
Ограничение применения промокода в корзине Tilda
Промокод в Tilda не действует на выбранную категорию (например, «Распродажа»). Готовый скрипт + инструкция по подключению.
от6 000 ₽
Сайт / Tilda
От лендинга до интернет-магазина
Разработка сайтов на Tilda с нестандартным функционалом. Кастомные формы, калькуляторы, интеграции с CRM — всё, что нужно для запуска бизнеса.
от30 000 ₽
Скорость загрузки и вес страниц
Тильда сжимает изображения при загрузке, но эффективно это работает только если исходник не крупнее 2500 px по длинной стороне. Более тяжелые файлы платформа тоже ужмет, но рендер страницы станет заметно медленнее, особенно на блоках с галереей из 10-15 фотографий. Перед публикацией прогоняю главные страницы через PageSpeed Insights по мобильному профилю: у чистого лендинга без видео и карт обычно 75-85 баллов, у страницы с зерокодом, картой и виджетами доставки 55-65, и для Tilda это нормальный результат, гнаться до 90+ смысла нет.
Отдельно смотрю на видео-фоны в первом экране: они красиво смотрятся в браузере разработчика, но на мобильном интернете 3G-4G у части посетителей грузятся по 5-8 секунд и срывают показатель отказов. Кастомные шрифты, подключенные через @font-face в Zero Block, тоже стоит проверить: если шрифт грузится с внешнего CDN без preconnect, страница может мигать системным шрифтом на слабых соединениях.
Адаптивная верстка на разных экранах
Tilda работает с брейкпоинтами 320, 480, 768, 980 и 1200 px, и типичная ошибка - настроить desktop-версию идеально, а на 320 px не заглянуть вообще. Прохожу каждую посадочную страницу на этих пяти ширинах и отдельно смотрю три места: не наезжает ли sticky-меню на первый экран, не обрезается ли текст в кнопках на длинных заголовках, помещается ли форма заявки целиком без горизонтального скролла.
Часто ломается зерокод с калькулятором или картой покрытия: на десктопе виджет растягивается на всю ширину блока, а на телефоне сжимается так, что цифры становятся нечитаемыми. Если на сайте стоит подобный интерактивный блок, лучше проверить его на реальном телефоне, а не только в режиме эмуляции в браузере, потому что часть багов с тач-событиями эмулятор просто не показывает.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Метатеги, robots.txt и индексация
Перед публикацией прохожу по всем страницам сайта и проверяю title и description в настройках SEO каждой страницы отдельно, потому что Tilda по умолчанию может подставить одинаковый шаблон везде, и тогда в поиске все разделы выглядят одинаково. Проверяю og:image на страницах, которые будут шариться в мессенджерах: если картинка не задана, при пересылке ссылки в Telegram или WhatsApp подтянется случайный скриншот блока.
Sitemap.xml Tilda генерирует автоматически по адресу вида yourdomain.ru/sitemap.xml, но robots.txt при кастомных настройках приходится прописывать вручную через код в футере или отдельный Zero Block. Отдельно проверяю дубли: если у магазина товар доступен и по прямому адресу, и через фильтр каталога, на обеих версиях должен стоять canonical на основную страницу, иначе поисковик размажет вес между двумя URL. Если сайт переезжает со старого домена или с другого конструктора, обязательно настраиваю 301-редиректы со старых адресов, иначе теряется накопленный трафик из поиска.
Формы, эквайринг и Tilda-скрипты
Форму нельзя считать рабочей после проверки в конструкторе, ее нужно отправить вживую и убедиться, что заявка дошла туда, куда должна. Прогоняю тестовый заказ по полной цепочке: заполняю форму на сайте, смотрю письмо на почту, смотрю карточку в CRM, если подключен вебхук, и только после этого считаю блок готовым. Отдельно проверяю прием оплаты через Т‑Банк или другой эквайринг в тестовом режиме: бывает, что виджет оплаты подключен, но переключен на боевые ключи раньше времени, и первый же покупатель получает ошибку вместо чека.
Если на сайте кастомный калькулятор доставки СДЭК, а не встроенный виджет Tilda, отдельно тестирую граничные случаи: доставка в другой часовой пояс, город без пункта выдачи, ноль в поле веса. Если магазин к тому же возит часть заказов своим курьером, ограничение по зонам не пишу с нуля: в библиотеке лежит готовый скрипт ограничения доставки по зонам на карте в Tilda, у которого проверка адреса по полигонам уже обкатана на реальных заказах. Для уведомлений о новых заявках в Telegram часто ставлю бота на aiogram или связку с n8n, если источников заявок несколько и их нужно свести в одну CRM, и в этом случае проверяю не только сам факт доставки сообщения, но и то, что оно приходит с правильными полями, а не просто новая заявка без деталей.
По деньгам ориентир такой: точечная правка скрипта на сайте, например поправить валидацию поля или добавить проверку промокода, обычно стоит от 3 000 рублей, а комплексная интеграция с CRM, эквайрингом и расчетом доставки СДЭК, где скрипты завязаны друг на друга, от 40 000 рублей.
Юридические блоки и работа с персональными данными
На сайте с формами обязательна страница политики обработки персональных данных и чекбокс согласия рядом с кнопкой отправки, иначе сбор контактов формально идет с нарушением 152-ФЗ. Проверяю, что в футере указаны реквизиты ИП или ООО, а если сайт продает товары или услуги, отдельно нужна публичная оферта. Если стоит баннер про cookie, смотрю, что он реально блокирует загрузку счетчиков до согласия, а не просто показывает уведомление поверх уже запущенной аналитики.
Контакты клиентов и заявки с форм храню и передаю только на серверы в РФ: связка вида форма Tilda плюс таблица в зарубежном облаке для российского бизнеса с персональными данными это риск, который проще не создавать, чем потом объяснять.
Аналитика и защита форм от спама
Перед стартом рекламы проверяю, что счетчик Яндекс.Метрики стоит на всех страницах, включая те, что созданы отдельно от главного меню, и что цели на отправку форм и клик по кнопке оплаты настроены и реально фиксируются в тестовом визите. Отдельно смотрю на спам-защиту: если форма без капчи и без скрытого honeypot-поля, через месяц-два после публикации в CRM начинают падать десятки ботовых заявок с одинаковым текстом, и это не гипотеза, а то, что видел на нескольких проектах без защиты.
| Блок проверки | Что смотрю | Сколько времени уходит |
|---|---|---|
| Скорость и вес страниц | PageSpeed, сжатие картинок, видео-фон, шрифты | 10-15 минут |
| Адаптив | 320, 480, 768, 980, 1200 px, зерокоды | 10 минут |
| Формы и интеграции | Тестовая заявка, CRM, эквайринг, СДЭК | 15-20 минут |
| Метатеги и индексация | title, description, robots.txt, sitemap, canonical | 10 минут |
| Юридические блоки | Политика, оферта, реквизиты, cookie-баннер | 5 минут |
Такой чек-лист удобно держать под рукой в виде обычного текстового файла и вычеркивать пункты по ходу проверки, а не держать в голове, потому что на девятом сайте за месяц детали начинают путаться между проектами.
Частые вопросы
Сколько времени занимает полная проверка сайта на Тильде перед публикацией?
На среднем лендинге или сайте-визитке с двумя-тремя формами весь чек-лист занимает 40-60 минут. На интернет-магазине с калькулятором доставки, эквайрингом и интеграцией с CRM проверка растягивается до двух-трех часов, потому что тестовый заказ нужно провести по всей цепочке от корзины до уведомления в Telegram.
Нужно ли повторять проверку после каждого обновления Tilda?
Не всю целиком, но после крупных обновлений платформы стоит заново прогнать блоки со скоростью и адаптивом: Tilda периодически меняет способ рендера зерокодов, и то, что нормально выглядело на 768 px месяц назад, может съехать после обновления. Формы и вебхуки проверяю тестовой заявкой при любом изменении в настройках интеграции, даже если меняли только текст письма.
Как проверить, что формы на Тильде действительно отправляют заявки в CRM?
Единственный надежный способ - отправить реальную тестовую заявку с сайта и проверить, появилась ли карточка в CRM в течение минуты-двух. Если используется вебхук, дополнительно смотрю логи на стороне сервиса, куда он идет: часть Tilda-скриптов молча падает при смене формата данных на стороне CRM, и без логов эту ошибку не заметить до первой потерянной заявки от клиента.
Что делать, если сайт после публикации медленно грузится на мобильных?
Сначала проверяю вес самых тяжелых изображений на странице через PageSpeed Insights, в 80% случаев дело именно в них. Дальше смотрю на видео-фоны и количество подключенных сторонних скриптов вроде виджетов чатов и калькуляторов, каждый добавляет отдельный запрос к серверу. Если после чистки картинок и скриптов скорость все равно низкая, обычно причина в перегруженной верстке самой страницы, и здесь уже нужно упрощать структуру блоков, а не оптимизировать частности.