Чек-лист запуска сайта на Tilda: что обязательно проверить перед публикацией

Сайт на Tilda нельзя считать готовым только потому, что дизайн собран, тексты согласованы и все хорошо выглядит в редакторе. Перед запуском нужно проверить опубликованный проект целиком: домен, HTTPS, ссылки, SEO, мобильную версию, формы, прием заявок, юридические документы, платежные сценарии и пользовательский код. Финальную приемку важно проводить именно на опубликованном сайте. Например, пользовательский код в блоке T123 в режиме редактирования и предпросмотра не выполняется как на готовой странице: для его работы страницу нужно опубликовать. После подключения или изменения ряда интеграций также требуется повторная публикация страницы.

Ниже — последовательность, по которой удобно проверять сайт перед передачей заказчику, запуском рекламы или открытием для пользователей.

1. Публикация, домен и служебные настройки

Начните с базовой технической конфигурации проекта. Сначала опубликуйте актуальные версии всех страниц, которые должны быть доступны пользователям. Если менялись общие элементы сайта — например, меню или футер, — после изменений также нужно опубликовать страницы, на которых они используются. Для общего header и footer Tilda прямо рекомендует после назначения соответствующих страниц выполнить публикацию всех страниц проекта.

Если сайт многостраничный, проверьте, какая страница назначена главной: Настройки сайта → Главная страница. Именно выбранная там страница должна открываться непосредственно по основному адресу сайта, например site.ru, тогда как внутренние страницы получают собственные URL.

Дальше проверьте домен. В нашем рабочем стандарте основной вариант — домен без www, например:

https://site.ru

При этом важно понимать: отсутствие www не является обязательным требованием самой Tilda. Технически главное — выбрать одну основную версию сайта и настроить перенаправление второй версии на нее. Tilda отдельно предусматривает редиректы между WWW/non-WWW и HTTP/HTTPS в разделе Настройки сайта → SEO → WWW, HTTPS Redirects.

Если основной домен у нас site.ru, проверяем:

https://www.site.ru → https://site.ru
http://site.ru → https://site.ru

Сначала HTTPS должен нормально работать сам по себе, и только затем имеет смысл включать постоянное перенаправление HTTP → HTTPS. Для сайтов, размещенных непосредственно на Tilda, SSL настраивается через Настройки сайта → SEO → HTTPS settings; после подключения сертификата Tilda предлагает проверить HTTPS-версию и затем при необходимости включить соответствующий редирект.

Не ограничивайтесь просмотром переключателей в настройках. Введите разные варианты адреса вручную в браузере и убедитесь, что пользователь в итоге оказывается на одной основной HTTPS-версии сайта. Если домен не работает или Tilda сообщает о проблемах, проверьте Настройки сайта → Домен. Платформа показывает состояние подключения и рекомендует сверять DNS-записи с настройками у регистратора.

Здесь же проверьте URL всех страниц. Адреса вроде:

/page12345678.html
/test
/new-page-2
/copy

не должны оставаться на готовом сайте без осознанной причины. Для страницы можно задать собственный URL в Настройки страницы → Главное. Если адрес уже существовавшей страницы изменился и на старый URL могли вести внешние или внутренние ссылки, настройте 301-редирект: Настройки сайта → SEO → 301 redirects.

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

Обязательно сделайте собственную страницу 404. В Tilda сначала создается и публикуется обычная страница, после чего она назначается в Настройки сайта → Ещё → 404 Error Page. После назначения Tilda требует опубликовать все страницы. 404 должна не просто сообщать об ошибке, а помогать человеку продолжить работу: дать ссылку на главную, меню или основные разделы сайта.

После настройки проверьте ее вручную, открыв заведомо несуществующий адрес, например:

https://site.ru/test-404-xyz

И наконец, не забудьте favicon. Он настраивается через Настройки сайта → SEO → Favicons → Manage. После загрузки favicon перепубликуйте сайт и проверьте результат в браузере. Если продолжает отображаться старая иконка, учитывайте кеш браузера.

2. Навигация, ссылки, контакты и структура сайта

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

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

Проверьте:

логотип;
все пункты основного и мобильного меню;
кнопки первого экрана;
CTA внутри страницы;
ссылки в карточках;
якорные ссылки;
popup и кнопки внутри них;
ссылки в тексте;
социальные сети;
ссылки на документы;
ссылки в футере.

После ручного прохода обязательно запустите официальный Broken Link Checker Tilda:

https://tilda.cc/ru/broken-links/

Инструмент можно также открыть в Настройки сайта → SEO → Broken link checker. Он умеет анализировать отдельную страницу или весь сайт. Найденные ошибки нужно не просто посмотреть, а разобрать и исправить. При этом сама Tilda предупреждает, что автоматическая проверка иногда считает недоступной реально рабочую ссылку — например, если внешний сайт блокирует ботов или требует авторизацию. Поэтому правильный алгоритм такой: сервис нашел проблему → открываем ссылку вручную → убеждаемся, что она действительно не работает → исправляем → перепубликуем страницу → проверяем повторно.

Все опубликованные номера телефонов, по которым предполагается звонок, должны быть кликабельными. Для этого используются ссылки вида:

tel:+79991234567

Email — ссылки вида:

mailto:hello@example.ru

Это стандартные URL-схемы, поддерживаемые HTML-ссылками. Проверьте не только наличие ссылки в редакторе, но и фактическое действие на опубликованной странице: телефон должен открывать приложение звонков с правильным номером, email — почтовое приложение с правильным адресатом.

Отдельно проверьте юридические и вспомогательные документы: политику обработки персональных данных, согласия, оферту или условия пожертвования, пользовательские соглашения, правила оплаты и другие документы проекта. Если документ нужен пользователю во время заполнения формы или платежного сценария, логично открывать его в новой вкладке, чтобы человек мог ознакомиться с текстом и не потерять уже введенные данные. Это не универсальное правило для всех ссылок сайта, а практическое решение именно для вспомогательных документов. В HTML для открытия нового контекста используется target="_blank"; современные браузеры для таких ссылок также применяют защитное поведение, эквивалентное noopener.

Проверьте footer. На обычном публичном сайте в нем должны находиться те элементы, которые предусмотрены структурой проекта: основные ссылки, контакты, социальные сети, юридические документы, реквизиты и другие служебные данные. Если проект содержит отдельные пользовательские среды — например, личный кабинет, закрытую часть, специальный поток регистрации или другой интерфейс, — отдельно проверьте их header и footer. Полный публичный подвал там может быть не нужен, но отсутствие навигации должно быть осознанным решением, а не забытым этапом разработки.

3. SEO, метаданные и превью страниц

Перед запуском обязательно откройте встроенный SEO Assistant Tilda. Tilda описывает его как инструмент, который автоматически проверяет страницы на ошибки, влияющие на индексацию, и в качестве примеров прямо приводит отсутствие H1 и Description. Важно не просто нажать кнопку проверки, а пройти найденные замечания, исправить реальные проблемы, перепубликовать страницы и проверить проект повторно.

При этом SEO Assistant не отменяет ручную проверку структуры страницы. Не стоит приписывать ему функции, которых документация не обещает: например, нельзя считать, что один запуск автоматически подтверждает идеальную семантику всех H1—H6.

Для каждой значимой индексируемой страницы проверьте:

понятный URL;
Title;
Description;
основной H1;
логичную структуру H2/H3 там, где она нужна;
alt у содержательных изображений;
отсутствие случайного запрета индексации.

Tilda включает метатеги, H1—H6, alt, собственные URL, 404 и 301-редиректы в набор своих SEO-возможностей. Title и Description должны описывать конкретную страницу, а не повторяться одинаково по всему проекту.

Плохо:

Главная
Страница 2
О нас

Лучше:

Донорство крови — как стать донором | Название проекта

Не нужно искусственно набивать метаданные ключевыми словами. Их задача — понятно обозначить содержание страницы. Отдельно проверьте заголовки. H1 — это не просто самый крупный визуальный текст, а основной смысловой заголовок документа. Дальнейшие уровни должны помогать выстроить структуру материала, а не назначаться по принципу «этот текст немного меньше, значит H2».

Проверьте и изображения. Для содержательных <img> нужен осмысленный alt, передающий информацию изображения. Для чисто декоративных изображений корректным может быть пустой alt="": это отличается от ситуации, когда атрибут просто забыли.

Отдельный обязательный этап — превью страниц для мессенджеров и социальных сетей. В Tilda оно настраивается через Настройки страницы → Social Media → Customize social media preview. Там можно отдельно задать заголовок, описание и изображение. Если эти данные не заполнены, Tilda использует значения из других настроек страницы, а при отсутствии отдельного изображения может взять первое изображение со страницы. Именно поэтому полагаться на автоматический результат перед запуском не стоит.

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

После настройки отправьте каждую важную ссылку себе в используемый мессенджер. Проверяем реальное превью, а не только настройки в Tilda. И не забудьте проверить, что сайт или важные страницы случайно не остались закрытыми от индексации после разработки. Tilda позволяет управлять индексацией средствами SEO-настроек.

4. Адаптивность, контент и визуальная приемка

Предпросмотр в Tilda полезен, но финальная проверка не должна заканчиваться в редакторе. Tilda адаптирует стандартные блоки для разных типов устройств, а Zero Block позволяет отдельно настраивать адаптивные версии. Это не означает, что конкретный собранный дизайн автоматически будет идеальным на каждой ширине.

Проверьте сайт как минимум на:

широком desktop;
обычном ноутбуке;
планшетной ширине;
узком смартфоне;
более широком смартфоне.

И обязательно откройте его хотя бы на одном реальном телефоне. Особенно внимательно смотрите:

первый экран;
меню;
формы;
popup;
карточки;
таблицы;
длинные заголовки;
изображения;
кнопки;
фиксированные элементы;
футер;
Zero Block;
элементы с пользовательским CSS.

Не должно появляться неожиданного горизонтального скролла, обрезанного текста, перекрывающихся кнопок, элементов за пределами экрана или огромных пустых зон между блоками.

После технического просмотра прочитайте сайт целиком как редактор. До запуска нужно убрать:

Lorem ipsum;
тестовые подписи;
временные изображения;
старые цены;
старые даты;
неправильные телефоны и email;
черновые реквизиты;
тестовые ссылки;
разные варианты написания одного названия;
фразы вроде «текст будет позже».

Просмотрите изображения. Они должны нормально кадрироваться и не быть неоправданно тяжелыми. Tilda автоматически обрабатывает большие изображения и использует собственные механизмы адаптивной загрузки, но сама платформа все равно рекомендует при необходимости заранее оптимизировать исходники: автоматическая обработка не заменяет качественную подготовку изображения.

Финальный визуальный тест лучше проводить не блок за блоком, а целым пользовательским маршрутом. Например: человек пришел на главную → понял предложение → нашел нужный раздел → нажал CTA → заполнил форму → получил понятный результат. Именно так обнаруживаются несостыковки между хорошо сделанными по отдельности экранами.

5. Формы и прием заявок

Форму нельзя считать настроенной потому, что она красиво выглядит и после клика показывает сообщение «Спасибо». Каждую форму нужно реально отправить. Если на сайте есть форма в первом экране, popup, контактах и отдельная форма регистрации — тестируем все четыре, даже если визуально они одинаковые.

Для каждой формы проверьте:

понятны ли названия полей;
корректно ли работают обязательные поля;
выбран ли нужный приемщик данных;
что происходит после отправки;
дошла ли заявка до конечного приемщика;
передались ли все необходимые поля.

На Tilda приемщик сначала подключается в Настройки сайта → Формы, после чего его нужно выбрать в Content конкретного блока с формой. После подключения страницу необходимо перепубликовать.

Для рабочего сайта желательно, чтобы заявки попадали хотя бы в один постоянный приемщик, а не существовали только в интерфейсе формы. Если у заказчика нет собственной CRM, можно использовать Tilda CRM. Это встроенная система Tilda для работы с лидами; сама Tilda отдельно указывает, что, в отличие от обычного раздела Leads с ограниченным хранением, Tilda CRM позволяет хранить данные постоянно.

После тестовой отправки не останавливайтесь на сообщении «Данные отправлены». Откройте Tilda CRM, внешнюю CRM, таблицу, почту или другой подключенный приемщик и найдите конкретную тестовую заявку.

Сверьте:

имя;
телефон;
email;
комментарий;
выбранные ответы;
скрытые поля;
UTM и другие дополнительные параметры, если они предусмотрены.

Если форма должна переводить пользователя на отдельную страницу благодарности, Tilda позволяет указать ее URL в настройках формы; для обычной формы это делается через поле Success Page URL, а для формы в Zero Block — через настройки формы. После изменений страницу снова нужно опубликовать.

6. Персональные данные, cookies и юридические документы

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

Для российского проекта, который собирает персональные данные через сайт, прежде всего проверьте наличие опубликованной и доступной пользователю политики обработки персональных данных. Российский закон обязывает оператора обеспечить неограниченный доступ к документу, определяющему его политику в отношении обработки персональных данных.

Если конкретная обработка строится на согласии пользователя, согласие должно быть оформлено корректно. В действующей редакции статьи 9 Федерального закона № 152-ФЗ прямо указано, что оно должно быть конкретным, предметным, информированным, сознательным и однозначным, а также оформляться отдельно от другой информации и документов, которые подтверждает пользователь.

Поэтому не стоит объединять в одну формулировку:

«Я согласен с обработкой персональных данных, политикой, офертой и рекламной рассылкой».

Если для формы используется отдельный checkbox согласия, в нашем предпусковом стандарте он не должен быть отмечен заранее: действие должен совершить сам пользователь. Tilda поддерживает отдельный тип поля Checkbox и прямо приводит согласие с политикой конфиденциальности как один из сценариев его использования.

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

Отдельно напомните владельцу сайта про обязанности оператора персональных данных. По общему правилу статьи 22 оператор должен уведомить Роскомнадзор до начала обработки ПД, за исключением предусмотренных законом случаев. На портале Роскомнадзора доступны актуальные электронные формы уведомлений и реестр операторов.

Поэтому корректная формулировка при сдаче проекта выглядит так:

«На сайте осуществляется сбор персональных данных. Проверьте, выполнены ли применимые к организации обязанности оператора персональных данных, включая уведомление Роскомнадзора и актуальность сведений в реестре, если эта обязанность распространяется на вашу обработку».

Это точнее, чем просто говорить владельцу «зарегистрируйтесь в РКН»: разработчик сайта не должен без проверки конкретной ситуации подменять собой юриста.

Отдельно проверьте cookies и подключенные внешние сервисы. В Tilda есть блок T972 Cookies consent settings, который позволяет посетителю управлять категориями essential, analytics, advertising и custom cookies. Если cookie-уведомление должно работать на всем многостраничном сайте, Tilda рекомендует размещать такой блок в общем header или footer.

Здесь тоже не нужно устанавливать баннер формально «потому что так делают все». Сначала нужно понимать, какие системы реально используются на сайте и какие требования применяются к конкретному проекту.

Если на сайте принимается оплата или пожертвования, проверьте и документы, регулирующие соответствующий сценарий: например, публичную оферту, условия оказания услуги или условия пожертвования — в зависимости от юридической модели проекта. Точный набор документов не определяется Tilda и должен быть согласован владельцем проекта с юристом. Если принятие конкретного документа реализуется отдельным checkbox, он также не должен быть заранее активирован.

7. Оплата, пожертвования и финальный пользовательский сценарий

Если сайт принимает платежи, отдельной проверки требует не только форма заказа, но весь путь пользователя. Платежные системы подключаются в Настройки сайта → Платежные системы. Набор настроек и возможностей зависит от конкретного платежного провайдера, поэтому проверять интеграцию нужно одновременно по документации Tilda и документации самой платежной системы.

На опубликованном сайте пройдите реальный или предусмотренный провайдером тестовый сценарий:

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

Для корзины сама Tilda отдельно указывает, что платежную систему и службу доставки нужно тестировать именно на опубликованной странице, отправив настоящий тестовый заказ.

Если сайт принимает пожертвования, обязательно подготовьте понятный сценарий после успешной операции. Tilda позволяет указывать Thank You Page в настройках подключенной платежной системы.

Например:

Спасибо за ваше пожертвование
Платеж прошел успешно. Спасибо, что помогаете проекту.

Если используемая платежная интеграция позволяет отдельно обрабатывать неуспешную операцию, подготовьте и соответствующий сценарий:

Пожертвование не удалось завершить
Платеж не был выполнен. Попробуйте еще раз или выберите другой способ поддержки.

Здесь важно не приписывать Tilda универсальную настройку отдельного failure URL для любой платежной системы: возможности возврата после успешного или неуспешного платежа зависят от конкретной интеграции.

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

Для пожертвования: страница → сумма → необходимые условия → платеж → понятный результат → операция зафиксирована в используемой системе.

На этом базовую предпусковую проверку можно считать законченной. Такой аудит уже позволяет полноценно проверить обычный сайт на Tilda: от домена и SEO до форм, юридических сценариев и платежей. Но у проектов с Zero Block, пользовательским CSS, JavaScript и модификациями остается еще один уровень проверки.

Ниже разберем DevTools и простые команды Console, которые позволяют буквально спросить у опубликованной страницы: «Сколько здесь H1?», «Есть ли изображения без alt?», «Куда на самом деле ведут ссылки?», «Есть ли нужный элемент?», «Сколько элементов находит этот CSS-селектор?» и «Почему модификация не работает?». А в конце разберем, как привести пользовательский код в состояние, в котором его можно спокойно передать следующему специалисту. Эта часть доступна по подписке.

Техническая приемка сайта через DevTools и Console

8. Проверяем структуру страницы через браузер, а не на глаз

Для такой диагностики откройте опубликованную страницу и DevTools браузера. Основные вкладки: Elements — фактическая HTML-структура и CSS, Console — ошибки JavaScript и выполнение небольших диагностических команд, Network — загрузка файлов и сетевые запросы. Начнем с простых проверок, которые особенно полезны на длинных страницах.

Сколько на странице H1

document.querySelectorAll('h1').length

Метод querySelectorAll() действительно возвращает список элементов документа, соответствующих указанному CSS-селектору.

Посмотреть сами H1:

[...document.querySelectorAll('h1')].map(el => el.innerText.trim())

Если вы ожидали один главный заголовок, а получили несколько, не нужно сразу удалять их через код. Найдите эти элементы в Tilda и разберитесь, какие блоки создали такую структуру.

Посмотреть всю иерархию заголовков

[...document.querySelectorAll('h1,h2,h3,h4,h5,h6')].map(el => ({
    tag: el.tagName,
    text: el.innerText.trim()
}))

Так легче заметить случайный H1 в футере, неправильный H3 вместо основного заголовка или хаотичную структуру длинной статьи.

Найти изображения без `alt`

document.querySelectorAll('img:not([alt])')

Количество:

document.querySelectorAll('img:not([alt])').length

Отдельно можно посмотреть изображения с пустым alt:

document.querySelectorAll('img[alt=""]')

И здесь важно не путать две ситуации: отсутствующий alt и осознанный alt="" у декоративного изображения — не одно и то же.

Найти подозрительные ссылки

Ссылки без href:

document.querySelectorAll('a:not([href])')

Пустой href:

document.querySelectorAll('a[href=""]')

Ссылка вида #:

document.querySelectorAll('a[href="#"]')

Сам факт нахождения такого элемента еще не доказывает ошибку. Некоторые пользовательские сценарии могут обрабатывать клик JavaScript. Команда лишь показывает места, которые стоит проверить.

Получить удобный список всех ссылок:

[...document.querySelectorAll('a[href]')].map(a => ({
    text: a.innerText.trim(),
    href: a.href
}))

Это особенно удобно перед сдачей большого сайта: в одном списке становятся заметны старый домен, тестовый URL или неправильный документ.

Телефонные ссылки:

[...document.querySelectorAll('a[href^="tel:"]')].map(a => a.href)

Email:

[...document.querySelectorAll('a[href^="mailto:"]')].map(a => a.href)

Ссылки, открывающиеся в новой вкладке:

[...document.querySelectorAll('a[target="_blank"]')].map(a => ({
    text: a.innerText.trim(),
    href: a.href
}))

Эти команды не заменяют ручной проход сайта. Они помогают быстро найти то, что глазами легко пропустить.

9. Проверяем модификации, классы и область действия CSS

Одна из самых частых ситуаций при работе с модификациями Tilda: код написан, но ничего не происходит. Не начинайте сразу переписывать JavaScript. Сначала выясните, существует ли вообще элемент, который код пытается найти.

Например:

document.querySelector('.my-button')

querySelector() возвращает первый подходящий элемент, а если ничего не найдено — null. Если получили null, возможные причины уже становятся понятнее:

класс указан неправильно;
структура блока изменилась;
код смотрит не в тот блок;
элемента пока нет в DOM;
нужный элемент появляется позже;
модификация рассчитана на другую структуру.

Если элемент найден, проверьте количество:

document.querySelectorAll('.my-button').length

Предположим, вы хотели изменить одну кнопку, а получили:

Тогда проблема может быть не в том, что CSS «не работает», а наоборот: селектор слишком общий.

Для модификаций конкретных блоков часто полезно ограничивать область действия через #rec.... Например:

#rec123456789 .my-button {
    background: #000;
}

А через Console можно проверить:

document.querySelector('#rec123456789 .my-button')

или:

document.querySelectorAll('#rec123456789 .my-button').length

Но номер rec нельзя брать из чужой статьи или копировать из другого проекта. Он относится к конкретной записи страницы и должен быть взят с реальной опубликованной страницы.

Настоящие классы элементов также лучше не угадывать. Откройте Elements, включите инструмент выбора элемента и нажмите на нужную кнопку, текст или изображение. DevTools покажет фактический HTML. Для стандартных блоков Tilda это особенно важно: пользовательский код зависит от структуры блока, а Tilda прямо предупреждает, что сторонние решения и пользовательский код могут перестать работать в результате изменений сторонних сервисов или самой платформы. Именно поэтому модификация должна проверяться после публикации и после обновлений того блока, на структуру которого она опирается.

10. Ищем ошибки JavaScript и проблемы загрузки

Если модификация визуально не работает, откройте Console и перезагрузите страницу. Красные сообщения могут указывать на ошибки JavaScript, но важно не делать вывод: «Есть красная ошибка → сломан наш код». Источник может быть другим: расширением браузера, сторонним виджетом, аналитическим скриптом или другим пользовательским кодом.

Смотрите:

имя файла;
строку;
момент возникновения ошибки;
воспроизводится ли она после отключения конкретной модификации.

Очень полезный способ локализации — временно отключать подозрительные пользовательские фрагменты по одному. Если одновременно изменить пять скриптов, даже после исчезновения ошибки вы не поймете ее причину.

Отдельная проблема — момент запуска JavaScript. Например:

const button = document.querySelector('.my-button');

Если в момент выполнения скрипта элемента еще нет, переменная получит null. Событие DOMContentLoaded возникает после разбора HTML-документа и выполнения отложенных скриптов, но не ждет, например, полной загрузки изображений и всех асинхронных ресурсов. Поэтому одного универсального правила запуска для любых модификаций Tilda не существует: оно зависит от того, какой именно элемент или внешний сервис нужен вашему коду.

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

document.querySelector('.my-button')

Если сейчас элемент находится, а во время первоначального выполнения вашего скрипта не находился, момент запуска — одна из первых вещей, которые нужно исследовать.

Для проблем с файлами, внешними скриптами и API откройте Network. Там можно увидеть:

загружаются ли изображения;
пришел ли JS-файл;
выполняется ли запрос к внешнему сервису;
какой HTTP-статус вернулся.

Неудачный запрос уже дает гораздо больше информации, чем фраза «виджет почему-то не работает».

11. Готовим пользовательский код к передаче следующему специалисту

Техническая приемка заканчивается не в момент, когда код начал работать. Хороший проект должен оставаться понятным после передачи. Пишите пользовательский код так, будто через год его откроет другой специалист, который впервые видит этот сайт. Ему не должно требоваться проводить небольшое археологическое исследование, чтобы понять, зачем существует конкретный скрипт и что можно безопасно изменить.

У сложной модификации должен быть понятный комментарий. Например:

/* ==========================================
   КАРТОЧКИ ПРОЕКТОВ

   Изменяет оформление кнопок только
   внутри блока #rec123456789.

   Если блок будет заменен или скопирован,
   необходимо проверить ID и классы элементов.
   ========================================== */

Для JavaScript:

/**
 * Управляет раскрытием дополнительного текста
 * по кнопке «Подробнее».
 *
 * Работает только внутри блока #rec123456789.
 * Зависит от классов .project-card и .project-more.
 */

Не нужно пояснять каждую очевидную строчку. Комментарий:

// ищем кнопку
const button = document.querySelector('.button');

почти ничего не дает следующему разработчику. Полезнее:

// Кнопка находится внутри конкретного Zero Block.
// Если Zero Block будет пересобран, селектор нужно проверить.
const button = document.querySelector('#rec123456789 .button');

Если у модификации есть значения, которые потенциально будут менять, вынесите их в понятный блок настроек. Например:

/* НАСТРОЙКИ */
const targetBlock = '#rec123456789';
const animationDelay = 300;

Перед передачей проекта удалите:

временные console.log;
тестовые URL;
старые неиспользуемые версии кода;
закомментированные куски, которые уже никогда не понадобятся;
дублирующие стили;
временные обходные решения, если они больше не нужны.

И отдельно проверьте ключи внешних сервисов. Секреты нельзя бездумно помещать во frontend-код страницы: пользователь браузера может получить доступ к загружаемому клиентскому коду. Если сервис предусматривает публичный клиентский ключ, это должно быть прямо предусмотрено его документацией; секретный серверный ключ нельзя объявлять «безопасным для T123» только потому, что интеграция работает.

После приведения кода в порядок снова опубликуйте сайт и повторите критические сценарии:

модификация работает;
стандартная функция блока не сломалась;
страница работает после перезагрузки;
мобильная версия не пострадала;
форма продолжает отправляться;
popup и меню работают;
сторонние сервисы загружаются.

И только после этого пользовательский код действительно можно считать готовым к передаче.

Короткий финальный чек-лист

Перед окончательной сдачей сайта еще раз пройдите основные пункты:

Опубликованы актуальные версии всех нужных страниц.
Правильно назначена главная страница.
Работает основной домен.
Версия с www перенаправляется на основной домен.
HTTP перенаправляется на HTTPS.
SSL работает без ошибок.
Загружен favicon.
URL страниц приведены в порядок.
При необходимости настроены 301-редиректы.
Создана и проверена собственная 404.
Broken Link Checker пройден, реальные битые ссылки исправлены.
Все меню, кнопки, карточки и якоря проверены вручную.
Телефоны и email кликабельны.
Документы открываются корректно.
Проверены header и footer всех типов страниц.
SEO Assistant пройден и реальные замечания исправлены.
Проверены Title, Description, H1 и структура заголовков.
Проверены alt содержательных изображений.
У важных страниц настроено превью для социальных сетей и мессенджеров.
Сайт проверен на нескольких ширинах и на реальном телефоне.
Нет тестового контента, старых цен, дат и контактов.
Каждая форма реально отправлена.
У каждой формы подключен рабочий приемщик.
Тестовые заявки действительно найдены в CRM или другом приемщике.
Если собираются ПД, опубликованы необходимые документы и корректно реализованы согласия.
Владелец предупрежден о необходимости проверить обязанности оператора ПД и уведомление Роскомнадзора.
Проверены cookies и подключенные системы аналитики/рекламы.
При наличии оплаты проверены документы и весь платежный сценарий.
Для пожертвований предусмотрен понятный сценарий успешной операции и, где это поддерживается интеграцией, неуспешной.
Пользовательский код понятен, прокомментирован и очищен от тестовых фрагментов.
Модификации проверены именно на опубликованном сайте.

Главный принцип такой: сайт считается готовым не тогда, когда в редакторе больше нечего поправить, а когда основные пользовательские и технические сценарии действительно пройдены на опубликованной версии — от открытия домена до получения заявки или завершения платежа.