Тильда и поиск: robots, sitemap и подтверждение прав в Вебмастере

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

Сайт собрали на Тильде за две недели, опубликовали, а через месяц в поиске висит одна главная. Владелец идёт искать «тильда robots txt», попадает на десяток инструкций про WordPress с путями вроде /public_html/ и закрывает вкладку, потому что ничего этого в конструкторе нет. Тильда часть техничку закрывает сама, часть отдаёт в интерфейсе, а часть не отдаст никогда. Ниже: где лежат robots и sitemap, что в них реально меняется, как подтвердить права в Вебмастере и Search Console и на каком месте ограничения конструктора начинают стоить позиций.

У меня в обслуживании несколько сайтов на Тильде, и почти в каждом при приёмке находилась одна и та же пара проблем: галочка запрета индексации, оставшаяся с этапа сборки, и sitemap, в который не попала половина страниц, потому что их не переопубликовали. Обе чинятся за пять минут, если знать, куда смотреть.

Что Тильда делает сама, а что не отдаст никогда

Базовую техничку конструктор закрывает без вашего участия, и это честный плюс. Сами появляются robots.txt и sitemap.xml, сам включается https, страницы отдаются с CDN, canonical проставляется на адрес страницы, мобильная версия собирается из тех же блоков.

Дальше идёт зона, где вы что-то можете, но только через интерфейс: title и description на каждую страницу, alt у картинок, уровень заголовка в Zero Block, произвольный код внутри head, редиректы списком, запрет индексации отдельной страницы.

И есть третья зона, куда доступа нет в принципе. Ни .htaccess, ни конфига nginx, ни серверных логов, ни своего кэша, ни правил редиректов с масками, ни возможности отдать нестандартный код ответа или собственный HTTP-заголовок. Это не претензия к платформе, это плата за то, что вам не нужно думать про сервер. Просто границы полезно знать до того, как SEO-подрядчик принесёт список задач, половина которых здесь физически не выполняется. Отдельный разбор дырок конструктора я писал в статье про то, чего не хватает Тильде для SEO.

Задача	На Тильде	Как именно
robots.txt	да, с оговорками	генерируется сам, своё содержимое дописывается в настройках сайта
sitemap.xml	да	генерируется сам, обновляется при публикации
title и description	да	настройки страницы, вкладка с SEO и соцсетями
Свой код в head	да	настройки сайта и настройки конкретной страницы
Подтверждение прав в Вебмастере	да	метатег в head или запись в DNS
301-редиректы	частично	список пар адресов, без масок и регулярных выражений
Вложенные адреса второго уровня	нет	адреса плоские, у постов потока свой формат
Свой код ответа сервера	нет	доступа к серверу нет
IndexNow	нет	ключевой файл в корне разместить негде
Логи обращений робота	нет	смотреть только глазами Вебмастера

robots.txt на Тильде: где лежит и что там менять

Файл отдаётся по обычному адресу, https://вашдомен.ru/robots.txt, и существует ровно с того момента, как сайт опубликован на своём домене. Никакого файла в файловой системе, который можно открыть по FTP, нет: Тильда собирает содержимое на лету.

Посмотреть, что там сейчас, проще всего из консоли, не доверяя браузеру с его кэшем:

curl -s https://example.ru/robots.txt
curl -s https://example.ru/sitemap.xml | grep -c "<loc>"
curl -sI https://example.ru/stranica-kotoroy-net | head -n 1

Первая команда покажет живой robots, вторая посчитает, сколько адресов реально попало в карту сайта, третья проверит, что несуществующий адрес отдаёт 404, а не 200 с красивой страницей. Двухсотка на 404 это классическая мина: поиск начинает считать такие адреса нормальными страницами и тащит в индекс мусор.

Что там по умолчанию

В дефолтном файле Тильды обычно закрыты служебные пути и указана карта сайта, примерно в таком виде:

User-agent: *
Disallow: /cgi-bin
Disallow: /storage/
Disallow: /*?

Sitemap: https://example.ru/sitemap.xml

Точный список Disallow платформа периодически меняет, поэтому смотрите свой файл, а не мою выдержку. Если видите там директиву Host, не пугайтесь и не спешите чинить: Яндекс перестал её учитывать ещё в 2018 году, это просто наследие.

Что имеет смысл дописать

Своё содержимое задаётся в настройках сайта, в блоке с robots.txt (Тильда двигает его между вкладками SEO и «Еще» от редизайна к редизайну, ищите по слову robots). Из полезного для типового сайта услуг:

User-agent: *
Disallow: /search
Disallow: /*utm_
Disallow: /*from=
Clean-param: utm_source&utm_medium&utm_campaign&yclid&gclid

Sitemap: https://example.ru/sitemap.xml

Clean-param понимает только Яндекс, но именно он чаще всего и приносит трафик небольшому бизнесу в России. Смысл директивы: адрес с рекламной меткой и адрес без метки склеиваются в одну страницу, вес не размазывается по десятку копий одной посадочной. На сайте, куда льют контекст с utm, это заметная штука, потому что рекламные ссылки живут в чужих отчётах и на чужих площадках годами.

Ещё стоит закрыть технические копии, если вы их плодите сами: страницы-черновики с адресами вида /test2, /new-glavnaya, /lending-copy. Про них забывают, а поиск нет.

Чего robots.txt не сделает

Самое частое заблуждение, которое я слышу от владельцев: «закрыли в robots, значит из поиска пропадёт». Не пропадёт. Disallow запрещает обход, а не индексацию. Адрес, на который ведут внешние ссылки, спокойно попадёт в выдачу с текстом про то, что описание недоступно из-за ограничений в robots.txt.

Чтобы страница ушла из индекса, нужен метатег noindex, а для этого страница должна остаться открытой для обхода. На Тильде это делается галочкой запрета индексации в настройках конкретной страницы. Логика простая: сначала снимаете Disallow, ставите noindex, ждёте переобхода, и только потом при желании закрываете в robots.

Пример из практики: у клиента в robots были закрыты все страницы с параметром, а спасибо-страница после отправки формы при этом ловила внешние ссылки из рассылки. В выдаче по названию компании второй строкой висело «Спасибо, заявка отправлена». Сняли Disallow, поставили запрет индексации на самой странице, через полторы недели адрес выпал.

sitemap.xml: генерируется сам, но не всегда полный

Карта сайта живёт по адресу https://вашдомен.ru/sitemap.xml и собирается автоматически из опубликованных страниц. Общая логика карты сайта и того, зачем она поиску, разобрана в статье про карту сайта sitemap.xml, здесь только специфика конструктора.

Три момента, из-за которых карта оказывается неполной:

• Страница создана, но не опубликована. В редакторе она выглядит готовой, в карте её нет. Публикация страницы и сохранение страницы это разные кнопки, и путают их постоянно.
• У страницы не задан адрес. Тильда даст ей технический адрес, и в карту она попадёт в лучшем случае в нечитаемом виде.
• Правки внесли в настройки сайта, а страницы не переопубликовали. Всё, что живёт в общих настройках, включая код в head, приезжает на боевые страницы только после публикации всех страниц. Кнопка есть в списке страниц, и жать её надо каждый раз после изменения общих настроек.

Отдельная история с потоком (модуль «Поток», он же лента статей). Посты получают адреса вида /tpost/xxxxxxxxxx-nazvanie-stati, где префикс с идентификатором вам не принадлежит и не редактируется. Для поиска это не приговор, ранжируются такие адреса нормально, но выглядят они некрасиво и переехать с них потом без потерь сложнее, чем с человеческих URL.

Проверять карту стоит после каждого крупного изменения структуры. Открыли, посчитали число тегов loc, сравнили с числом страниц, которые считаете рабочими. Расхождение больше пары адресов означает, что где-то забыли публикацию.

Подтверждение прав в Вебмастере и Search Console

Из трёх способов подтверждения на Тильде реально работают два: метатег и запись в DNS. Файл в корень домена вы положить не можете, поэтому вариант с HTML-файлом отпадает сразу.

Через метатег

Порядок такой:

1. В Яндекс Вебмастере добавляете сайт, выбираете способ «Мета-тег», копируете строку вида <meta name="yandex-verification" content="a1b2c3d4e5f6g7h8" />.
2. В Тильде идёте в настройки сайта, в раздел с кодом для вставки внутрь head, и вставляете строку туда.
3. Публикуете все страницы. Не одну главную, а именно все. Без этого шага тег останется в настройках и не появится в исходном коде.
4. Проверяете, что тег доехал: curl -s https://example.ru/ | grep yandex-verification. Если пусто, значит публикация не прошла или тег вставили не в тот раздел.
5. Возвращаетесь в Вебмастер и жмёте кнопку проверки.

С Google Search Console последовательность идентичная, только тег называется google-site-verification. Оба тега спокойно живут в head одновременно, конфликта нет.

Через DNS

Если доступ к панели регистратора есть, TXT-запись надёжнее: она не зависит от публикации страниц и не слетит, когда кто-то почистит код в настройках. Минус один: запись расходится по DNS от пятнадцати минут до нескольких часов, и всё это время кнопка проверки будет ругаться. Не надо жать её каждые две минуты, подождите час.

Что делать сразу после подтверждения

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

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

Подробнее по разделам панели, что там смотреть и в каком порядке, есть отдельный материал: Вебмастер для новичков.

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

Метатеги, заголовки и канониклы в интерфейсе

Title и description задаются в настройках страницы, во вкладке с SEO и превью для соцсетей. Поле keywords там тоже есть, и его можно спокойно оставить пустым: ни Яндекс, ни Google его не учитывают больше десяти лет. Если поле пустое, Тильда подставит в title название страницы, и получится что-то вроде «Главная» в выдаче, что заметно хуже нормального заголовка со смыслом и городом.

С заголовками главная засада в Zero Block. Текст, нарисованный в нём мышкой, по умолчанию не является заголовком: это обычный элемент с оформлением. Уровень выставляется руками в свойствах элемента, там есть выбор тега от H1 до H6. Проверяется быстро, через исходный код страницы:

curl -s https://example.ru/uslugi | grep -o "<h1[^>]*>.*</h1>"

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

Canonical Тильда проставляет сама, на адрес самой страницы. Своя вторая canonical, вписанная кодом в head, не заменяет платформенную, а добавляется рядом, и поиск получает два взаимоисключающих указания. Итог непредсказуемый: может выбрать любую, может проигнорировать обе. Если задача требует нестандартного канонического адреса, сначала проверьте исходный код глазами и убедитесь, что тег там ровно один.

Alt у картинок задаётся в настройках блока с изображением, в Zero Block в свойствах элемента. Заполняется в среднем в одном случае из пяти. Для сайта услуг это упущенный трафик из поиска по картинкам, а для интернет-магазина иногда и заметная его доля.

Дубли, галочки и адреса: что ломается чаще всего

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

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

curl -s https://example.ru/ | grep -i "noindex"

Пустой ответ значит, что запрета нет. Любой вывод с noindex значит, что вы нашли причину, по которой сайта нет в поиске.

Редиректы на Тильде задаются списком пар адресов и отдают честный 301. Ограничение в том, что это ровно список: масок, регулярных выражений и правил вида «все адреса из старой папки в новую» здесь нет. Когда сайт переезжает на конструктор со старой CMS, где было полторы сотни адресов, каждый придётся вбивать руками. На двадцати адресах это вечер работы, на трёхстах уже повод подумать, туда ли вы переезжаете. Про сам переезд и про то, что в нём чаще всего теряется, есть отдельный текст: перенос сайта с Тильды на WordPress, логика в обратную сторону та же.

Вложенность адресов плоская. Структура вида /uslugi/remont-holodilnikov/ на конструкторе штатно не собирается, максимум получится /uslugi-remont-holodilnikov. На небольшом сайте услуг это не критично: поиск давно ранжирует не по глубине вложенности. На сайте с пятью категориями и сотней позиций отсутствие иерархии начинает мешать и людям, и перелинковке.

Когда ограничения начинают стоить позиций

Отвечу прямо, без балансирования. Для сайта-визитки, лендинга или сайта услуг на десять-двадцать страниц ограничения Тильды в поиске не решают почти ничего. Гораздо больше решают тексты, региональность, отзывы и внешние упоминания. Я видел сайты на конструкторе в топе по коммерческим запросам средней конкуренции, и там всё было ровно.

Проблемы начинаются на трёх сценариях.

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

Второй: масштаб контента. Сотня страниц на конструкторе управляется руками. Массово поменять шаблон title по всем страницам, собрать перелинковку по правилу, вывести список статей по тегу с постраничной навигацией под контролем: всё это либо не делается, либо делается вручную по странице за раз.

Третий: интеграции и данные. Свои поля, фильтры по параметрам, выгрузки, микроразметка сложнее базовой. Что-то докручивается кодом в head, но каждый такой костыль надо помнить и проверять после обновлений платформы.

Признак	Тильда справляется	Пора смотреть в сторону CMS
До 30 страниц, редкие правки	да	нет
Блог с выпуском 2-4 статьи в месяц	со скрипом	скорее да
Каталог с фильтрами и параметрами	нет	да
Требуется вложенная структура адресов	нет	да
Нужен серверный контроль скорости	нет	да
Бюджет на поддержку минимальный	да	нет

Отдельно про деньги. Подписка на конструктор обходится в районе 800 рублей в месяц на тарифе для одного сайта и порядка 1 300 на бизнес-тарифе при годовой оплате. Это дешевле, чем связка «хостинг плюс обслуживание CMS», и в этом сила Тильды. Переезд на WordPress ради двух пунктов из таблицы выше экономически не окупится: сайт с нуля стоит порядка 150 000 рублей, а перенос существующего с сохранением позиций тоже не бесплатный. Считайте не по ощущениям, а по тому, сколько трафика вы теряете сейчас.

Чек-лист SEO-настроек перед запуском

Прохожу по нему на каждом сайте на конструкторе, который беру на обслуживание. Занимает минут сорок вместе с правками.

• Галочка запрета индексации сайта снята, curl не находит noindex на боевых страницах.
• robots.txt открывается, содержит ссылку на sitemap, не закрывает ничего лишнего.
• В robots дописан Clean-param для рекламных меток, если на сайт льют платный трафик.
• sitemap.xml открывается, число адресов совпадает с числом рабочих страниц.
• Права подтверждены в Яндекс Вебмастере, карта сайта добавлена, регион указан.
• Права подтверждены в Google Search Console, карта добавлена туда же.
• У каждой страницы заполнены title и description, ни одного дефолтного «Главная» в выдаче.
• На каждой странице ровно один H1, в Zero Block теги проставлены руками.
• У картинок заполнен alt, хотя бы у смысловых.
• Технический адрес на tilda.ws не показывается в поиске по названию компании.
• Несуществующий адрес отдаёт код 404, а не 200.
• Счётчик Метрики стоит, цели на отправку формы настроены и проверены тестовой заявкой.
• Все страницы переопубликованы после последних правок в общих настройках.
• Старые адреса со старого сайта заведены в список редиректов, если сайт переезжал.

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

Что делать дальше

Если сайт уже работает, а в поиске его нет, начните с двух команд из чек-листа: проверка noindex и проверка robots. В моей практике эти две причины закрывают больше половины случаев «сайт не индексируется», и обе чинятся быстрее, чем вы дочитаете эту статью до конца.

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

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

Частые вопросы

Где на Tilda лежит robots.txt

Он формируется платформой и доступен по обычному адресу в корне, но правится не файлом, а настройками проекта. Полного контроля над ним нет, и это одно из ограничений конструктора.

Как подтвердить права в Вебмастере

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

Всегда ли карта сайта полная

Не всегда. Страницы, скрытые из навигации или созданные вне основного проекта, в неё могут не попасть. Карту стоит открыть и сверить со списком страниц вручную.

Что ломается чаще всего

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