Нужно ли срочно уходить с Tilda из-за закона о персональных данных?

Зафиксируем главное: «срочной эвакуации» только из‑за формулировок закона нет, если требования к хранению и передаче данных настроены корректно.

Но тренд последних лет — ужесточение правил и рост рисков, связанных с зарубежной инфраструктурой SaaS. Поэтому разумно иметь понятный план миграции и понимать, куда переезжать, чтобы сохранить дизайн‑идею, получить удобную панель управления, развернуть проект в РФ и безболезненно развиваться.

Слушать в ИИ-подкасте «Digital’ная кухня»:

Почему все говорят о Tilda и 152‑ФЗ

Обсуждения на профильных форумах и в комьюнити‑пабликах вспыхнули из‑за сочетания факторов: с 1 марта 2023 действует предварительное уведомление о трансграничной передаче, а с 30 мая 2025 выросли «оборотные» штрафы; в правоприменении IP и cookie‑идентификаторы нередко трактуются как персональные данные; владельцам сайтов предписывают баннер согласия на cookie и отдельные согласия на передачу данных. На Tilda многие используют встроенные формы и интеграции (Google Sheets, Notion, Telegram, Zapier и др.), и в реальном мире именно они часто создают «скрытые» зарубежные маршруты для заявок — это то, о чём массово пишут на vc.ru/Хабре и в профсообществах.

Дополнительное топливо для дискуссий — сама архитектура платформы: в официальных ответах Tilda признаёт распределенную инфраструктуру с точками присутствия за пределами РФ, а также CDN и резервные копии. Даже при выборе «Russia only» часть статики может уходить на зарубежные узлы, что формально требует отдельного уведомления и согласия.

В связке с риском ограничений для иностранной SaaS‑инфраструктуры это превращается в системный фактор неопределенности; отсюда и повестка: готовить план миграции и контролировать, где реально текут данные.

Что заявляет сама Tilda

• О локализации для РФ
  В русскоязычном FAQ Tilda прямо указывает: если страной профиля является Россия, персональные данные собираются и хранятся на российских серверах партнеров (Selectel, «Яндекс Облако»). В уведомлении для Роскомнадзора рекомендуют указывать эти дата‑центры.
• О распределенной инфраструктуре
  В техдокументации подчеркнуто, что Tilda — распределённая система без «единой точки»: сервера партнеров размещены по миру; среди основных точек присутствия названы Германия и США.
• О CDN и статике
  Платформа ускоряет загрузку за счет CDN: важные ресурсы (JS, CSS, изображения) дублируются на серверах по всему миру, и отдаются с ближайшего узла к посетителю. Это значит, что медиаконтент может физически обслуживаться вне РФ, даже если проект создан для российского профиля.
• О сторонних интеграциях
  При подключении внешних сервисов (аналитика, формы, таблицы, мессенджеры, платежные провайдеры) персональные данные уходят и на их сервера. В справке Tilda рекомендует изучать политики этих сервисов и контролировать первичный сбор/обработку.

Фактические риски на сегодня

• Оборотные штрафы и правоприменение
  Для повторных нарушений статьи о защите ПД санкция может достигать десятков миллионов рублей и/или процента от выручки. На практике проверяют три вещи: есть ли уведомление о трансграничной передаче (если она возможна), корректно ли оформлены согласия, и совпадает ли это с фактической маршрутизацией трафика (включая IP и cookie). Поводом становятся жалобы пользователей, инциденты утечки, публикации в СМИ и выборочные проверки.
• Трансграничность «по умолчанию»
  Даже без форм ваш сайт может передавать данные за рубеж: через CDN‑узлы, шрифты, карты, онлайн‑чаты, виджеты видео/плееров, счетчики и пиксели. Типовые триггеры на Tilda — подключенные Google Fonts/внешние библиотеки, reCAPTCHA, встраивания YouTube/Vimeo, no‑code‑интеграции (Zapier/Make), отправка заявок в Google Sheets/Notion/Telegram. Любой из этих маршрутов способен формально превратить проект в «трансграничный».
• Зависимость от SaaS и контрактные риски
  Изменение публичной оферты, ограничения биллинга, отключение интеграций или деградация CDN приводят к простою либо потере функций без возможности «экстренного» переноса. Условия предоставления услуг и политика работы с аккаунтами могут меняться в одностороннем порядке.
• Операционные и репутационные последствия
  Сбой форм = потерянные лиды и некорректные метрики; некорректный баннер cookie и тексты согласий = претензии; инцидент с персональными данными = необходимость реагирования, уведомления регулятора и медиариски.
• Технический долг миграции
  Чем дольше тянете с переездом, тем больше «сросшихся» интеграций (виджеты, webhooks, внешние таблицы) придётся разрывать и переосмысливать. В пике это увеличивает сроки и бюджет миграции в 1,5–2 раза по сравнению с ранним переходом.
• Пятишаговая самопроверка за 1 день
  1. Скан внешних подключений (шрифты, CDN, скрипты).
  2. Карта маршрутов для всех форм и виджетов.
  3. Проверка баннера cookie и текстов согласий.
  4. Тест «региональности» статики (какие узлы отдают ресурсы).
  5. Сводная таблица интеграций для уведомления РКН и паспорта ПД.

Что делать бизнесу уже сейчас

1. Провести аудит точек сбора и передачи данных. Составьте карту всех форм и виджетов, инвентаризируйте внешние подключения (шрифты, карты, чаты, видео‑плееры, аналитика, пиксели), проверьте маршруты статики и загрузчиков изображений. Результат — сводная таблица интеграций и «паспорт ПДн» по каждому сценарию. Для отраслевой специфики можно опереться на статью о требованиях к сайтам медорганизаций с обязательным размещением серверов в РФ.
2. Актуализировать документы и процессы. Политика обработки, формы согласий (в т. ч. на трансграничную передачу, если она есть), реестр операций с ПДн, порядок хранения и доступа. Сверьте формулировки с фактическими маршрутами данных (формы, CDN, интеграции); приоритет — хранение и бэкапы в РФ.
3. Снизить внешние зависимости. Замените импортные виджеты и шрифты на локальные, отключите лишние скрипты, локализуйте аналитику/карты, используйте «чистые» формы вместо no‑code‑связок. Типовые доработки и замены можно провести в рамках сопровождения сайтов.
4. Подготовить план миграции. Выберите направление (CMS или фреймворк), опишите MVP и дорожную карту развития, оцените сроки/бюджеты. Для магазинов и каталогов — учтите готовые модули и интеграции с 1С.
5. Организовать мониторинг. Настройте контроль отправки форм (в т. ч. дубли на почту/CRM), алерты по ошибкам и скорости, периодическую проверку согласий/баннера cookie.
6. Сверить 1С/склад и обмены (для e‑commerce). Проверьте корректность синхронизации номенклатуры, цен, остатков и заказов; зафиксируйте регламент обмена и откат. Ориентиры по модулям и процессам — в гайде по интернет‑магазинам.
7. SEO и сохранность трафика. Составьте карту URL и редиректов, перенесите метаданные и микроразметку, проверьте индексацию после запуска; продумайте план стабилизации позиций.

Куда переезжать: CMS или Framework

Есть два базовых маршрута: CMS (когда важны редактура и готовые контентные процессы) и фреймворк (когда логика бизнеса выходит за рамки типового сайта). Ниже — три проверенных варианта после Tilda: MODX, 1С‑Битрикс и Laravel.

MODX (CMS)

MODX — гибкая CMS/CMF для индивидуальных сайтов и контентных проектов. Не навязывает шаблоны, позволяет описать собственные типы контента и связи. Дизайн реализуется «как в макетах», а панель управления настраивается под роли и процессы.

Когда выбирать

• Нужен уникальный бренд‑сайт «без компромиссов» к визуалу и поведению блоков.
• Много редакторской работы: новости, кейсы, мероприятия, объектные каталоги.
• Требуются интеграции «как в бизнесе»: CRM, 1С, онлайн‑оплата, калькуляторы, формы.

Чем выигрываете относительно Tilda

• Свобода структуры и дизайна, отсутствие «стеклянного потолка» конструктора.
• Панель управления с только нужными разделами и полями — меньше ошибок, быстрее публикация.
• Запас роста: от корпоративного сайта к кабинетам и сервисным сценариям без смены платформы.

Перенос с Tilda — на что обратить внимание

• Прямого «копирования» вёрстки нет: блоки Tilda проприетарные.
• Если есть дизайн‑система и адаптивные макеты — переверстка. Если их нет — новая индивидуальная разработка (сетки, типографика, состояния).

1С‑Битрикс (CMS)

1С-Битрикс — коробочная CMS для e‑commerce, B2B‑кабинетов и корпоративных порталов с широкой экосистемой модулей.

Когда выбирать

• Интернет‑магазины и каталоги с большим ассортиментом.
• B2B‑кабинеты, порталы с ролями и бизнес‑процессами.
• Используется 1С и важна «ровная» синхронизация товаров/цен/остатков/заказов.

Чем выигрываете относительно Tilda

• Готовность к продажам «из коробки»: корзина, оплата, доставка, промо, личные кабинеты.
• Портальная логика: роли, права, маршруты согласований без самодельных решений.
• Масштабирование без смены платформы: от пилота к зрелому порталу.

Варианты запуска

• Быстрый старт на Aspro‑решении — чтобы выйти в продажи быстрее.
• Индивидуальная разработка на ядре — если нужны уникальный визуал и особые сценарии.

Перенос с Tilda — на что обратить внимание

• Для точного соответствия бренду нужны макеты ключевых экранов.
• Панель управления насыщенная: заранее продумайте роли и инструкции редакторам.

Laravel (Framework)

Laravel подходит не только «для сложных», но и для компактных проектов, если нужна очень простая, своя панель управления и сценарии без лишних разделов.

Когда выбирать

• Нетиповые процессы, которые ограничивают любую CMS.
• Планируется эволюция: личные кабинеты, отчёты, партнёрские интеграции, API.
• Нужен контроль над логикой и темпом изменений.

Чем выигрываете относительно Tilda

• Полный контроль функционала: реализуем процессы «как в бизнесе», а не «как умеет платформа».
• Запас роста: от корпоративного сайта к сервису/платформе без смены стека.
• Прозрачное соответствие 152‑ФЗ: развёртывание на российском сервере и собственные регламенты хранения/доступа.

Перенос с Tilda — на что обратить внимание

• При наличии дизайн‑системы и адаптивных макетов быстро воспроизводится визуал и поведение; без них закладывается этап концепции (компоненты, сетки, состояния) во избежание «ломающейся» верстки.

Перенос дизайна с Tilda: как это работает

С чем реально работаем

• Дизайн переносится визуально, а не кодом: HTML/CSS Tilda — проприетарные компоненты.
• Перенос = воспроизведение макетов на выбранной платформе + настройка панели управления под ваши сущности (страницы, карточки, формы, ленты).

Что нужно на вход

• Исходники макетов (Figma/Sketch) с адаптивами: desktop / tablet / mobile.
• Базовая дизайн‑система: палитра, шрифты, сетки, отступы, состояния (hover / active / error), иконки.
• Экспорт ассетов: изображения, SVG, иллюстрации, видео, шрифты.
• Перечень сущностей контента: какие типы материалов будут редактироваться и кем.

Два сценария

1. Есть дизайн‑система и адаптивные макеты → переверстка:
   1. мэппинг блоков Tilda → компоненты/шаблоны CMS;
   2. настройка типовых сущностей (новости, кейсы, услуги, объекты и т. п.);
   3. перенос контента и медиа; проверка типографики и отступов;
   4. тестирование форм и сценариев (валидация, письма, интеграции).
2. Нет дизайн‑системы/адаптивов → индивидуальная разработка дизайна:
   1. собираем гайд (палитра, типографика, сетка, модули);
   2. отрисовываем ключевые экраны + мобильные/планшетные версии;
   3. согласуем состояния UI и паттерны (формы, карточки, модальные окна);
   4. затем выполняем верстку дизайн-макетов с нуля под все форматы экранов.

Почему копия «один в один» невозможна

• Автоматическая адаптивность конструктора ≠ продуманным макетам: поведение под разные форматы задается заново.
• Классы и сетки Tilda не совместимы с шаблонами CMS/фреймворка: повторяем поведение и визуал, а не HTML/CSS.

Критерии приемки

• Пиксель‑перфект на целевых брейкпоинтах, соответствие стилей и типографики.
• Корректная работа форм (валидация, письма, CRM), корректные тексты согласий/баннер cookie.
• Быстродействие (LCP/CLS в «зеленой» зоне по Web Vitals), отсутствие критических ошибок в консоли/валидаторах.
• Готовность панели управления: только нужные разделы и поля; роли/права редакторов настроены.

План миграции: пошагово

1. Подготовка и аудит (1–3 дня)
   Инвентаризация форм, виджетов и внешних скриптов; карта URL; проверка маршрутов статики; фиксация сценариев обработки ПД.
2. Установка CMS/фреймворка и базовая настройка
   Разворачиваем выбранную систему управления (MODX, 1С-Битрикс, Laravel или иную), настраиваем модули/плагины, подключаем базу данных, подготавливаем окружение для разработки и тестирования.
3. Дизайн и верстка макетов
   Верификация существующих макетов, при отсутствии — сбор дизайн‑системы и отрисовка ключевых экранов (desktop/tablet/mobile).
4. Архитектура контента и SEO‑перенос
   Проектирование типов материалов и панель управления; составление карты редиректов; перенос метаданных, микроразметки и медиа.
5. Интеграции и правовые настройки
   Подключение CRM/1С/оплаты/рассылки/телефонии; настройка баннеров согласия на cookie и Политику конфиденциальности; написание регламентовы хранения ПД.
6. Тестирование на стенде
   Тестирование функциональных сценариев (формы, поиск, корзина), кросс‑браузер/кросс‑девайс, производительность и базовая безопасность; UAT со стороны бизнеса.
7. Запуск без просадки трафика
   Запуск сайта и переключение DNS, проверка редиректов, мониторинг ошибок/скорости, контроль конверсий.
8. Пост‑поддержка (14–30 дней)
   Оперативный фикс неисправностей, наблюдение за индексом, обучаем редакторов.

Быстрый запуск на готовых решениях

BM (bmamonts.ru) — каталог отраслевых готовых сайтов на MODX для ускоренного выхода в онлайн. В типовой пакет входят установка и настройка MODX, адаптация шаблонов под фирменный стиль, первичное наполнение и базовые интеграции (например, 1С и онлайн‑оплата).

Заявленный срок запуска — от 7–10 дней. Модель оплаты без абонентки: единоразовая стоимость решения, а затем ежегодно — домен и хостинг. При необходимости структура, дизайн и функциональность расширяются сверх базовой комплектации.

Где уместно

• Быстрый старт с базовым функционалом и понятной панелью управления;
• ограниченный бюджет при необходимости развертывать сайт на российском сервере и выполнять требования 152‑ФЗ;
• потребность в типовых интеграциях (1С, онлайн‑оплата) без длительного проектирования.

Что важно понимать

• это готовая основа на MODX, поэтому проект можно развивать как «свой»: добавлять разделы, менять шаблоны, подключать CRM и кастомные модули без смены платформы;
• глубокая уникализация под сложный дизайн‑гайд и нетиповые сценарии возможна, но это уже индивидуальная доработка по срокам и бюджету;
• перед запуском проверьте юридические и технические пункты: российский хостинг, корректные тексты и механика согласия на cookie, работа форм и Политика конфиденциальности.

Полезные детали

• каталог тематик (медицина, недвижимость, строительство, услуги и др.), демо и стоимость на карточках решений;
• раздел FAQ о самостоятельной работе с панелью управления и доступной поддержке;
• возможность расширять функционал, подключать платежные системы и интеграции;
• отсутствие абонентской платы, только ежегодные платежи за домен и хостинг.

FAQ по типовым вопросам

• Можно ли не уходить с Tilda вообще?
  Да, если выполнены базовые условия:
  • хранение и бэкапы в РФ; корректные согласия (включая на трансграничную передачу — если она есть);
  • подано уведомление в РКН;
  • внешний трафик (CDN/шрифты/скрипты) локализован; формы и интеграции не уводят данные за рубеж.

  Стратегически всё равно держите план миграции.

• Кто отвечает перед регулятором: Tilda или владелец сайта?
  Оператор ПД — владелец сайта. Он отвечает за уведомления, согласия и фактические маршруты данных (включая сторонние виджеты/интеграции и e-mail-доставку заявок).
• Что считается трансграничной передачей на практике?
  • Не только отправка формы. Это также:
  • выдача статики через зарубежные CDN-узлы (картинки, шрифты, JS/CSS);
  • внешние шрифты и карты;
  • чаты/онлайн-запись/видео-плееры;
  • аналитика/пиксели и no-code-интеграции (Google Sheets, Notion, Zapier/Make);
  • резервные копии и репликации вне РФ.
• Режим Russia only в Tilda спасает?
  Снижает риски, но не исключает: часть статики и/или бэкапов может обслуживаться за пределами РФ. Если такие маршруты есть — нужно уведомление о трансграничной передаче и отдельное согласие.
• Нужен ли баннер cookie и отдельные согласия?
  Да, если используются нестрого необходимые cookie/скрипты (аналитика, маркетинг). Согласие на трансграничную передачу — отдельным пунктом, когда данные уходят на иностранные узлы.
• Нужно ли уведомлять РКН, если формы уходят в Tilda CRM и на почту?
  Да, если есть вероятность обработки/хранения за рубежом (CDN, бэкапы, интеграции) или если почтовый сервис/маршрут нероссийский. Иначе трансграничная передача будет нарушением.
• Как быстро проверить, «утекают» ли данные за рубеж?
  • Откройте вкладку Network в браузере и посмотрите домены загрузки статики.
  • Проинспектируйте виджеты/скрипты (карты, чаты, плееры, аналитика).
  • Проследите маршруты форм (куда отправляются заявки: CRM, почта, таблицы).
  • Уточните у платформы/хостинга локации бэкапов.
  • Если видите зарубежные домены-либо локализуйте, либо готовьте уведомление и согласие.
• Можно ли перенести дизайн с Tilda «один в один»?
  Код — нет (проприетарные блоки). Визуально и по поведению — да, при наличии дизайн-системы и адаптивных макетов (desktop/tablet/mobile). Без них перенос превращается в полноценную индивидуальную разработку.
• Как сохранить SEO при переезде?
  Карта URL и 301-редиректов; перенос метаданных и микроразметки; сохранение H-структуры и контента; проверка индексации/скорости; мониторинг в поисковых консолях 2-4 недели.
• Сколько занимает переезд c Tilda?
  По сути, это та же работа, что и создание сайта с нуля. Для корпоративных проектов стандартного объёма — в среднем 1-2 месяца. Для более крупных сайтов и интернет-магазинов — около 3-4 месяцев.
• Можно ли запуститься быстро без индивидуальной разработки?
  Да: BM (bmamonts.ru) — отраслевые готовые решения на MODX. Запуск от 7-10 дней; дальше проект развивается как «свой»: добавляете разделы, интеграции, меняете шаблоны без смены платформы.
• Какие документы и тексты должны быть на сайте?
  Политика обработки ПД; согласие на обработку ПД, согласие на cookie (при необходимости); согласие на трансграничную передачу (если есть такие маршруты), пользовательское соглашение (по модели бизнеса). Формулировки должны соответствовать фактическим сценариям.
• Что делать с аналитикой и маркетинг-пикселями?
  Локализовать, по возможности использовать российские альтернативы/прокси, грузить только после согласия, обновить политику и баннер cookie.
• Как организовать мониторинг после релиза?
  Трекинг отправки форм (включая дубли в почту/CRM), алерты по ошибкам/скорости, контроль баннера cookie и согласий, наблюдение за индексацией и конверсиями. Запланируйте «окно» быстрых фиксов 2-4 недели.

Итоги и выводы

• Срочной эвакуации нет, если уже выполнено: локальное хранение и бэкапы в РФ, актуальная Политика и согласия (в т. ч. на трансграничную передачу при её наличии), подано уведомление в РКН, внешние скрипты/статические ресурсы локализованы, формы и интеграции не уводят данные за рубеж.
• Стратегия на 6–12 месяцев: держать в фокусе план миграции. По срокам ориентир такой: для корпоративных проектов стандартного объёма — в среднем 1–2 месяца, для более крупных сайтов и интернет-магазинов — около 3–4 месяцев.
• Куда идти после Tilda:
  • MODX — индивидуальные сайты и контентные проекты с активной редактурой и уникальным дизайном.
  • 1С‑Битрикс — e‑commerce, B2B‑кабинеты и порталы; быстрый пилот на Aspro, далее — индивидуальная разработка.
  • Laravel — когда сайт фактически продукт: нестандартная логика, личные кабинеты, API и рост без смены стека.
• Быстрый старт: BM на MODX (bmamonts.ru) — если запустить сайт нужно «вчера», затем развивать проект как собственный.
• Риски откладывания: рост бюджета миграции на 1,5-2x из‑за накопившихся интеграций, юридические претензии при несогласованной трансграничной передаче, простой при ограничениях SaaS.