Robots.txt на Тильде многие вообще не трогают: платформа генерирует файл сама, сайт открывается, страницы попадают в выдачу, и кажется, что настраивать нечего. На практике за этим файлом прячутся дубли технических адресов вида /page1234567, служебные страницы, которые не нужны в поиске, и лишние обращения роботов к разделам сайта, которые вообще не предназначены для индексации. Я правлю robots.txt на Тильде почти в каждом проекте, где стоит задача по SEO, и в этой статье покажу, где искать нужное поле в настройках, что закрывать и как убедиться, что файл реально работает так, как задумано.
По теме статьи
Готовое решение
Ограничение доставки по зонам на карте в корзине Tilda
Виджет доставки в шапке сайта + ограничение оформления в корзине по зонам на Яндекс.Карте.
от9 000 ₽
Сайт / Tilda
От лендинга до интернет-магазина
Разработка сайтов на Tilda с нестандартным функционалом. Кастомные формы, калькуляторы, интеграции с CRM — всё, что нужно для запуска бизнеса.
от30 000 ₽
Где в Тильде редактировать robots.txt
Файл создаётся автоматически для любого проекта, в том числе для технического адреса вида projectXXXXX.tilda.ws. Кстати, пока сайт крутится на этом техническом поддомене и не подключён к своему домену, Тильда сама закрывает его от индексации, так что переживать за дубли на tilda.ws не нужно, это штатное поведение платформы.
Как только домен подключён, файл становится доступен по адресу вида mysite.ru/robots.txt. Редактировать его в Тильде нельзя: «Оба файла генерируются Тильдой автоматически, ничего дополнительно делать не нужно», и поля для собственного текста robots.txt в настройках сайта нет. Единственная штатная настройка, которая на содержимое файла влияет, это галочка из раздела SEO: «Также в Настройки сайта → SEO → Дополнительно установите галочку «Использовать схему HTTPS в robots.txt, sitemap.xml и метатеге canonical URL»». Всё, что на других платформах правят прямо в robots.txt, на Тильде закрывается другими средствами: запретом индексации страницы (Настройки страницы → SEO → Отображение в поисковой выдаче → Настроить отображение в поисковой выдаче, галочка «Запретить поисковикам индексировать страницу»), запретом индексации всего сайта в Настройках сайта → SEO и редиректами.
Отдельно от robots.txt в Тильде есть настройка на уровне конкретной страницы: в SEO-блоке настроек страницы есть флажок «закрыть страницу от индексации поисковыми системами». Это не строка в robots.txt, а метатег noindex, который добавляется в код именно этой страницы. Разница важная, и путаница между этими двумя механизмами это самая частая ошибка, которую я вижу на чужих проектах.
Какие страницы закрывать от индексации на сайте на Тильде
Список того, что реально стоит убирать из индекса, у большинства проектов на Тильде похож:
- Технические адреса страниц вида /page1234567, если у страницы есть человекочитаемый URL, а числовой остаётся доступен по прямой ссылке.
- Скрытые страницы, которые не привязаны к меню и сделаны для лендингов конкретных рекламных кампаний, но случайно проиндексировались раньше, чем на них перестали вести трафик.
- Черновые и тестовые версии страниц, которые держите в проекте для правок, но не публикуете в основной навигации.
- Адреса с параметрами рекламных меток вроде
?utm_source=и?utm_medium=, чтобы поисковик не считал их отдельными страницами и не размывал показатели между дублями. - Результаты внутреннего поиска по сайту, если на нём подключён поисковый виджет и такие страницы формируют собственный URL с параметром запроса.
Что закрывать не нужно почти никогда: страницы карточек товаров, разделы каталога, статьи блога, страницу с формой заявки. Расчёт доставки СДЭК в корзине, форма подписки, приём оплаты через подключённую платёжную систему, всё это часть контента страницы, а не служебный технический мусор, и закрывать такие блоки от робота смысла нет.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Готовый robots.txt для Тильды: рабочий пример
Ниже базовый вариант, который я адаптирую под конкретный проект. Он подходит и для сайта на Tilda с каталогом, и для лендинга без магазина.
User-agent: *
Disallow: /*?utm_
Disallow: /*?openstat
Allow: /
Sitemap: https://mysite.ru/sitemap.xmlСтроку с адресом Sitemap меняю на реальный домен проекта, файл sitemap.xml Тильда собирает сама и обновляет при добавлении новых страниц, отдельно генерировать его не нужно. Если у проекта есть каталог с фильтрами, которые формируют URL через параметры запроса и вы не хотите, чтобы каждая комбинация фильтра индексировалась как отдельная страница, в это же место добавляю точечные правила под конкретные параметры, а не блокирую все адреса с вопросительным знаком подряд, иначе есть риск случайно закрыть от робота нужные страницы пагинации.
Для интернет-магазина на Тильде
Для магазина обычно добавляю отдельное правило под адреса корзины и оформления заказа, если они формируются как отдельные технические URL, а не открываются попапом поверх страницы каталога. У большинства проектов на Тильде оформление заказа и корзина работают через всплывающее окно без собственного адреса, так что блокировать в robots.txt там часто нечего, но перед публикацией я всегда проверяю через отладку в браузере, не появился ли у процесса оформления заказа собственный URL, это зависит от того, какой блок оплаты и корзины используется в конкретном проекте.
Для лендинга или блога
Здесь набор правил обычно короче: закрываю только utm-параметры и черновые страницы, если они есть. Для блога на Тильде отдельно проверяю, не плодит ли RSS-виджет или система тегов страницы-дубли по каждому тегу, если тегов много и на них почти нет уникального контента, такие адреса тоже стоит вынести в Disallow.
Дубли страниц /page и настройка canonical на Тильде
У каждой страницы в Тильде есть красивый адрес, который вы задаёте вручную, и технический вида /page1234567. Тильда сама проставляет canonical на страницах в сторону основного адреса, но на практике я всё равно периодически вижу в панели вебмастера проиндексированный технический URL, обычно это происходит, если на него когда-то вела внешняя ссылка, виджет или старая рекламная кампания, а страницу успели переименовать.
В таких случаях полностью закрывать шаблон /page через Disallow рискованно: под этот шаблон подпадают все страницы сайта, а не только дубли, поэтому робот вообще перестанет их посещать. Правильнее убрать конкретный проиндексированный технический адрес через инструмент удаления URL в панели вебмастера и проверить, что на него больше никто не ссылается. Если дублей много и они появляются регулярно из-за специфики каталога, это уже задача под кастомную доработку Тильды, где логика canonical и redirect настраивается программно под конкретную структуру сайта.
Как проверить robots.txt после публикации
Файл сохранили, но прежде чем считать задачу закрытой, я всегда проверяю его тремя способами.
| Способ | Что показывает | Когда использую |
|---|---|---|
| curl из терминала | Реальное содержимое файла, которое отдаёт сервер прямо сейчас | Сразу после публикации, чтобы убедиться, что правки сохранились |
| Яндекс.Вебмастер | Как файл понимает робот Яндекса и какие правила из него применяются | Перед тем как ждать переиндексацию в Яндексе |
| Google Search Console | Отчёт по robots.txt в разделе настроек: когда Googlebot последний раз скачивал файл и без ошибок ли он прочитан | Через несколько дней после изменений, если сайт также продвигается в Google |
Проще всего начать с curl:
curl https://mysite.ru/robots.txtКоманда сразу покажет, отдаётся ли файл с обновлённым содержимым, кэш браузера тут ни при чём. Дальше в Яндекс.Вебмастере есть инструмент анализа robots.txt: вставляете список адресов страниц, а сервис показывает, какие из них попадают под Disallow, а какие открыты. Это единственный способ быстро проверить, что новое правило не закрыло случайно что-то нужное.
Частые ошибки при настройке
Самая частая ошибка, которую я поправляю на чужих проектах, это Disallow на странице, у которой одновременно стоит noindex. Робот, которому запрещено заходить на страницу, физически не видит метатег noindex внутри неё, а значит не может учесть команду убрать страницу из индекса. Если страница уже попала в выдачу и её нужно оттуда убрать, сначала снимаю Disallow, дожидаюсь, пока робот увидит noindex и уберёт страницу сам, и только потом при необходимости закрываю адрес от сканирования.
Вторая по частоте история: правило, которое блокирует вообще все адреса с параметрами, включая те, что нужны для пагинации каталога или для работы виджетов оплаты. Перед тем как ставить широкое правило, выписываю все реальные параметры, которые встречаются в адресах сайта, и закрываю только те, что действительно создают дубли.
Условия и возможности Тильды меняются, поэтому перед запуском я уточняю их у самого сервиса.
Частые вопросы
Тильда сама создаёт правильный robots.txt, или его точно нужно редактировать вручную?
Базовый файл платформа генерирует сама и для большинства простых лендингов без каталога его достаточно. Ручная правка нужна, когда в проекте появляются технические дубли адресов, utm-метки в ссылках из рекламы или каталог с фильтрами, которые платформа не может предугадать заранее под конкретный сайт.
Нужно ли закрывать страницу оплаты и корзину от индексации на Тильде?
В большинстве проектов на Тильде корзина и оформление заказа открываются всплывающим окном без собственного адреса, поэтому блокировать в robots.txt нечего. Если конкретный блок оплаты формирует отдельный URL для шага оформления, такой адрес стоит закрыть через Disallow, чтобы он не индексировался как отдельная страница сайта.
Почему технический адрес вида /page1234567 всё равно попадает в индекс, хотя canonical настроен?
Обычно это случается, когда на технический адрес когда-то вела внешняя ссылка, старая рекламная кампания или виджет, а поисковик успел его обойти раньше, чем страницу переименовали. Canonical подсказывает роботу, какой адрес основной, но не гарантирует мгновенное удаление старого технического URL из уже сформированного индекса, для этого быстрее использовать инструмент удаления URL в панели вебмастера.
Как часто нужно проверять robots.txt после того, как он один раз настроен?
Я возвращаюсь к файлу каждый раз, когда в проекте появляется новый раздел каталога, новый виджет с собственными URL-параметрами или когда меняется структура меню. Регулярного расписания для проверки не держу, привязываю её к изменениям на сайте, а не к календарю.