Корень сайта на Тильде - это не папка на сервере, к которой можно подключиться по FTP и закинуть файл верификации. Тильда - облачный конструктор: сайт живёт на инфраструктуре сервиса, а домен клиента просто указывает туда через DNS. Когда очередной сервис - Google Search Console, Яндекс.Вебмастер, платёжный шлюз с поддержкой Apple Pay - просит разместить файл по адресу вида site.ru/google123.html или site.ru/.well-known/что-то, у владельца сайта на Тильде возникает закономерный вопрос: куда его класть, если панели с файловым менеджером попросту нет. Ниже - рабочие способы подтвердить права на сайт без доступа к файлам и отдельно про случаи, когда без файла в корне обойтись не получится.
По теме статьи
Готовое решение
Автоматическая конвертация валюты на Tilda
Цены товаров в нужной валюте по актуальному курсу ЦБ — автоматически и в реальном времени.
от6 000 ₽
Сайт / Tilda
От лендинга до интернет-магазина
Разработка сайтов на Tilda с нестандартным функционалом. Кастомные формы, калькуляторы, интеграции с CRM — всё, что нужно для запуска бизнеса.
от30 000 ₽
Почему на Тильде нет привычного корня с файлами
Тильда - SaaS-платформа: ты не арендуешь сервер, а пользуешься готовой функциональностью - блоками, шаблонами, формами, интеграциями. За хостинг, CDN и раздачу статики отвечает сама Tilda, и файловой системы, куда можно было бы что-то докинуть руками, в панели нет ни на одном тарифе, включая Business.
Подключение своего домена - это только DNS-запись: A‑запись или CNAME на серверы Tilda через панель регистратора вроде reg.ru или timeweb. Дальше весь трафик обрабатывает инфраструктура сервиса - генерирует html из блоков, отдаёт картинки с CDN, применяет настройки SEO. Такая архитектура защищает и сам конструктор, и клиентов: никто случайно не положит в корень вредоносный скрипт и не сломает раздачу статики. Обратная сторона этой защиты - невозможность вручную положить файл туда, куда его просит сторонний сервис.
Какие файлы верификации обычно просят положить в корень
На практике с этой проблемой сталкиваешься в нескольких типовых ситуациях.
- Google Search Console при добавлении сайта способом «файл HTML» просит закинуть в корень файл вида google1a2b3c4d5e.html
- Яндекс.Вебмастер предлагает похожий вариант - yandex_1a2b3c4d.html
- Платёжные интеграции с поддержкой Apple Pay, в том числе через T‑Bank Acquiring, требуют файл apple-developer-merchantid-domain-association без расширения по пути /.well-known/
- Рекламные кабинеты и некоторые партнёрские программы тоже иногда просят подтвердить владение доменом именно файлом, а не мета-тегом
Логика у всех этих сервисов одна: они хотят убедиться, что человек, который просит доступ к аналитике или платёжным данным сайта, действительно им управляет. Файл в корне - самый старый способ доказать контроль над доменом, из времён, когда у всех по умолчанию был FTP-доступ к серверу. robots.txt и sitemap.xml сюда не относятся - Tilda генерирует их сама на лету, и никакого файла для них класть тоже не нужно.
Как подтвердить сайт в Google Search Console и Яндекс.Вебмастере без файлового доступа
Для обоих сервисов есть метод подтверждения через мета-тег, и на Tilda он работает без проблем. В Google Search Console при добавлении ресурса выбираешь способ «HTML-тег» вместо «HTML-файл» - сервис выдаёт строку вида:
<meta name="google-site-verification" content="ABCDEF1234567890G" />Копируешь значение content и вставляешь код в Tilda: Настройки сайта -> Ещё -> поле для кода в <head>. Публикуешь сайт заново и жмёшь «Подтвердить» в Google Search Console - проверка обычно проходит за одну-две минуты, потому что Tilda публикует изменения почти сразу.
С Яндекс.Вебмастером то же самое: выбираешь способ подтверждения «Мета-тег», получаешь строку с content, вставляешь в тот же код head. Если нужно подтвердить домен целиком, а не отдельный URL-префикс (актуально, если сайт на Tilda отвечает и на www, и без www, или есть несколько поддоменов), оба сервиса предлагают DNS-подтверждение - добавляешь TXT-запись в панели управления доменом у регистратора. Запись применяется от 15 минут до нескольких часов, в редких случаях до суток - зависит от TTL записи и скорости обновления кэширующих DNS-серверов.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Apple Pay и .well-known: когда сервис требует именно файл, а не мета-тег
С Apple Pay мета-тегом не отделаешься. Apple проверяет домен строго через файл по фиксированному пути /.well-known/apple-developer-merchantid-domain-association - без расширения, с точным содержимым, без редиректов и без обёртки в html. Это требование протокола, а не прихоть конкретного банка, поэтому обойти его нельзя ни через настройки Tilda, ни через мета-теги, ни через robots.txt.
Чаще всего с этим сталкиваются, когда настраивают приём платежей через T‑Bank Acquiring и хотят, чтобы кнопка Apple Pay появлялась прямо на кастомной странице оплаты внутри сайта на Tilda, а не на отдельной странице банка. Здесь два рабочих варианта.
Первый, самый простой: использовать готовую платёжную форму T‑Bank или другого эквайера - она открывается на домене банка, который уже верифицирован для Apple Pay на их стороне, и от владельца сайта ничего дополнительно не требуется. Теряется немного бесшовности оформления заказа, зато не нужно ничего настраивать руками.
Второй вариант - поставить перед Tilda прокси-слой, например Cloudflare Worker, который перехватывает запросы к /.well-known/apple-developer-merchantid-domain-association и отдаёт нужный файл с правильными заголовками, а весь остальной трафик прозрачно пробрасывает на серверы Tilda. Работает, но это уже не настройка в панели, а кастомная интеграция для Tilda с DNS, кэшем и обработкой ошибок. Такие задачи я оцениваю от 40 000 ₽ именно потому, что ошибка в конфиге прокси может уронить весь сайт целиком, а не только форму оплаты - тестировать приходится не только сам файл, но и кэширование, редиректы и то, что поисковики по-прежнему нормально видят остальные страницы.
Мета-тег, DNS TXT-запись и файл в корне: что выбирать
По умолчанию я всегда пробую мета-тег - это минимум телодвижений и ноль риска для остального сайта. DNS TXT-запись беру, когда сервис просит подтвердить домен целиком или мета-тег недоступен как вариант. Прокси ради одного файла - крайняя мера, которую стоит городить только если Apple Pay или похожая интеграция реально нужна бизнесу, а не «на всякий случай».
Таблица показывает разницу между способами:
| Способ подтверждения | Где настраивается | Для каких сервисов подходит | Время на применение |
|---|---|---|---|
| Мета-тег | Код head в настройках Tilda | Google Search Console, Яндекс.Вебмастер (подтверждение по URL) | 1-5 минут после публикации |
| DNS TXT-запись | Панель управления доменом у регистратора | Подтверждение домена целиком, рекламные кабинеты, почтовые сервисы | От 15 минут до суток |
| Файл по фиксированному пути | Не поддерживается штатными средствами Tilda | Apple Pay и похожие платёжные интеграции | Требует прокси-слоя или отдельного поддомена |
Условия и возможности Тильды меняются, поэтому перед запуском я уточняю их у самого сервиса.
Частые вопросы
Можно ли вообще получить файловый доступ к сайту на Тильде?
Нет, ни через FTP, ни через SSH, ни через файловый менеджер в панели - такой функции нет ни на одном тарифе, включая Business. Это архитектурное решение SaaS-платформы, а не ограничение конкретного плана, и оно не снимается доплатой.
Что делать, если сервис принимает подтверждение только файлом, а мета-тег не предлагает?
Сначала проверить, есть ли у сервиса DNS-подтверждение - оно есть почти у всех крупных платформ: Google, Yandex, Mail.ru, соцсетей. Если сервис жёстко требует файл по фиксированному пути, как Apple Pay, без прокси-слоя или переноса конкретной функции на отдельный домен обойтись не получится.
Пропадёт ли верификация, если убрать код мета-тега из настроек сайта?
Да, у большинства сервисов при повторной проверке (а Google и Яндекс её иногда повторяют) статус подтверждения может слететь, если мета-тег удалён. Я оставляю его в коде head даже после успешного подтверждения - лишним не будет, а риск потерять доступ к статистике сайта выше, чем неудобство от одной лишней строки кода.
Нужно ли отдельно упоминать /.well-known/ в robots.txt на Тильде?
Нет, к индексации это не относится. robots.txt на Tilda генерируется автоматически, и открывать или закрывать служебные пути вроде /.well-known/ отдельно не нужно - поисковики их не индексируют, это чисто технический механизм проверки владения доменом для конкретных сервисов.