Техническое SEO для Bitrix, Tilda и WordPress: чек-лист 2026
Bitrix, Tilda и WordPress позволяют создавать сайты, которые нормально индексируются и продвигаются в Google. Но техническая работа на каждой платформе отличается.
На Bitrix чаще приходится разбираться с кешированием, шаблонами, фильтрами и нагрузкой на сервер.
На WordPress — с темами, плагинами, базой данных, кешем и дублирующими URL.
На Tilda значительная часть инфраструктуры уже управляется самой платформой, поэтому основные проблемы чаще возникают из-за тяжёлых страниц, сторонних скриптов, структуры сайта и неправильных SEO-настроек.
При этом базовые требования поисковых систем одинаковы:
важная страница должна быть доступна для обхода, индексируема, иметь понятный URL, корректный canonical, нормальную внутреннюю перелинковку и приемлемый пользовательский опыт.
Актуально на сентябрь 2026 года.
Сначала проверьте то, что не зависит от CMS
До оптимизации кеша или установки SEO-плагина проверьте фундамент.
Индексация
Убедитесь, что важные страницы:
возвращают 200 OK;
не имеют случайного noindex;
не закрыты от Googlebot;
доступны без авторизации;
присутствуют во внутренней структуре.
Canonical
Если одна страница доступна по нескольким URL, нужно определить основную версию.
Google рассматривает canonical как сигнал при выборе предпочтительного URL среди одинаковых или очень похожих страниц. (developers.google.com)
Особенно внимательно проверяйте:
параметры;
фильтры;
HTTP/HTTPS;
www/non-www;
страницы сортировки;
дубли CMS.
Sitemap
В XML sitemap должны попадать URL, которые действительно планируется индексировать.
Карта сайта не исправляет плохую структуру, но помогает поисковой системе обнаруживать нужные страницы.
Robots.txt
robots.txt управляет обходом, а не является универсальным инструментом удаления страниц из поиска.
Не нужно без причины закрывать:
CSS;
JavaScript;
изображения;
важные категории.
Если страницу нужно удалить из индекса, обычно рассматривают noindex, удаление URL или другие подходящие способы, а не просто Disallow.
Скорость: что считать нормальным результатом
В 2026 году актуальными Core Web Vitals остаются:
LCP — до 2,5 секунды;
INP — до 200 мс;
CLS — до 0,1.
Google рекомендует оценивать их по реальным пользовательским данным, обычно на уровне 75-го перцентиля. (developers.google.com)
Но не нужно воспринимать PageSpeed как экзамен:
100/100 ≠ гарантированный ТОП.
Google отдельно подчёркивает, что хорошие Core Web Vitals сами по себе не гарантируют высокие позиции. (developers.google.com)
Задача — убрать реальные проблемы для пользователя, а не получить идеальную цифру ради отчёта.
Техническое SEO на Bitrix
Bitrix даёт много контроля, но вместе с этим увеличивает количество мест, где можно создать технические проблемы.
Для больших каталогов и корпоративных проектов особенно важны:
кеширование;
фильтры;
параметры URL;
sitemap;
сервер;
шаблон;
обновления.
Используйте кеширование осмысленно
В современных версиях Bitrix используется технология «Композитный сайт», которая позволяет отдавать статическую часть страницы из кеша, оставляя динамические блоки отдельно. В документации Bitrix предусмотрены автоматический и ручной режимы композита, а кеш может храниться в файлах или Memcached. (dev.1c-bitrix.ru)
Но включить композит — не значит автоматически решить все проблемы скорости.
Нужно проверять:
время ответа сервера;
запросы к базе данных;
тяжёлые компоненты;
сторонние JavaScript;
размер изображений;
количество CSS и JS;
динамические блоки.
Не создавайте отдельный кеш для UTM-меток
URL вроде:
/catalog/?utm_source=google
/catalog/?utm_source=instagram
не должны превращаться в десятки независимых кешированных версий одной страницы.
В настройках композита Bitrix можно указывать параметры вроде utm_source, которые не должны восприниматься системой как отдельные URL для кеша. (dev.1c-bitrix.ru)
Это одновременно полезно для производительности и порядка в URL.
Проверьте sitemap Bitrix
В административной панели Bitrix есть отдельная система генерации sitemap.
Можно выбирать:
разделы;
файлы;
инфоблоки;
элементы;
режим автоматического обновления.
Bitrix также позволяет автоматически добавлять путь к созданной карте сайта в robots.txt. (dev.1c-bitrix.ru)
Проблема обычно не в отсутствии sitemap, а в том, что именно в него попало.
Не стоит отправлять поисковой системе:
технические URL;
результаты поиска;
ненужные фильтры;
дубли;
закрытые страницы.
Отдельно настройте robots.txt
Bitrix имеет встроенный интерфейс управления robots.txt. (dev.1c-bitrix.ru)
Но не копируйте универсальный robots.txt из чужого проекта.
У двух сайтов на Bitrix могут быть совершенно разные:
каталоги;
фильтры;
параметры;
модули;
служебные разделы.
Правила нужно составлять после анализа реальных URL сайта.
CDN — не обязательный «сервер в Казахстане»
Старая рекомендация искать CDN исключительно с казахстанским сервером слишком упрощена.
Смысл CDN — доставлять статические ресурсы через распределённую сеть и сокращать путь до пользователя.
У самого Bitrix есть облачный сервис с поддержкой CDN. В документации указано, что для лицензий России, Беларуси и Казахстана облачная инфраструктура использует Yandex Object Storage. (dev.1c-bitrix.ru)
Но подключение CDN нужно оценивать по фактическому результату, а не по одному названию страны.
Техническое SEO на Tilda
На Tilda пользователю недоступен сервер и большая часть backend-инфраструктуры.
Поэтому здесь важно не пытаться «оптимизировать сервер Tilda», а работать с тем, чем реально можно управлять.
Lazy Load уже включён
В старой версии статьи предлагалось отдельно включать Lazy Load.
Сейчас Tilda указывает, что Lazy Load активирован по умолчанию. Платформа также использует адаптивную загрузку изображений и конвертацию в WebP. (help.tilda.cc)
Поэтому основной вопрос — не «как установить lazy loading», а:
какие изображения загружены;
насколько они тяжёлые;
сколько их в первом экране;
нет ли огромных фоновых фотографий;
нужны ли все декоративные элементы.
Tilda уже использует CDN
Не нужно отдельно подключать CDN только потому, что сайт работает в Казахстане.
Tilda использует собственную CDN-инфраструктуру и адаптивную доставку изображений. (tilda.cc)
На практике чаще тормозят:
сторонние виджеты;
чаты;
карты;
пиксели;
внешние шрифты;
большие видео;
кастомные скрипты;
перегруженные Zero Block.
Именно их стоит проверять в первую очередь.
Не добавляйте аналитику через Zero Block
Zero Block предназначен для дизайна.
Коды аналитики, пиксели и другие глобальные скрипты лучше устанавливать через штатные интеграции Tilda либо через соответствующие настройки вставки кода.
После публикации полезно открыть оба адреса и убедиться, что структура соответствует ожиданиям.
Проверяйте canonical
После подключения собственного домена Tilda автоматически делает его основной версией вместо технического адреса tilda.ws.
При необходимости canonical конкретной страницы можно изменить через SEO-настройки страницы. (help.tilda.cc)
Особенно это важно при:
переносе материалов;
дублях;
миграциях;
нестандартной структуре.
При смене URL ставьте 301
Tilda позволяет настраивать 301 redirects:
Настройки сайта → SEO → 301 redirects.
Если меняется адрес уже опубликованной страницы, старый URL нужно направлять на новый релевантный адрес. (help.tilda.cc)
Просто удалить старую страницу и создать новую — плохая миграционная практика.
Техническое SEO на WordPress
WordPress даёт огромную свободу, но техническое состояние сайта сильно зависит от:
темы;
хостинга;
количества плагинов;
их качества;
кастомного кода;
обновлений.
Два WordPress-сайта могут работать совершенно по-разному.
SEO-плагин полезен, но не является обязательным условием ранжирования
Yoast SEO, Rank Math и другие решения удобны для управления:
Title;
Description;
canonical;
sitemap;
robots;
Schema;
индексированием типов страниц.
Но установка SEO-плагина сама по себе не улучшает позиции.
Это интерфейс управления настройками.
Главное — правильно эти настройки использовать.
WordPress уже имеет XML Sitemap
Начиная с WordPress 5.5, в ядре существует собственная система XML sitemap. Она также добавляет адрес sitemap в виртуальный robots.txt. (developer.wordpress.org)
SEO-плагины могут заменять или расширять этот механизм.
Поэтому после установки Yoast или Rank Math нужно проверить, не работают ли одновременно несколько sitemap-систем с ненужными URL.
Lazy Loading тоже есть в ядре
WordPress использует lazy-loading для изображений на уровне ядра с версии 5.5. (developer.wordpress.org)
Поэтому отдельный плагин только ради loading="lazy" обычно не является необходимостью.
Более того, изображение первого экрана иногда, наоборот, не стоит лениво загружать, если оно является LCP-элементом.
Настройте кеширование
Для WordPress кеширование часто даёт значительный эффект.
Официальная документация WordPress описывает:
page cache;
browser cache;
object cache;
server cache
и приводит специализированные кеш-плагины как один из вариантов реализации. (developer.wordpress.org)
Но не нужно одновременно устанавливать:
WP Rocket + W3 Total Cache + LiteSpeed Cache + ещё один optimizer.
Несколько систем, которые пытаются выполнять одну и ту же работу, могут конфликтовать.
Выберите подходящий стек под конкретный сервер.
Следите за плагинами
Одна из типичных причин тяжёлого WordPress:
десятки ненужных плагинов;
дублирующий функционал;
старые плагины;
тяжёлые page builders;
JavaScript на всех страницах сайта.
Перед добавлением нового расширения стоит спросить:
действительно ли для этой функции нужен ещё один плагин?
Это полезно не только для скорости, но и для стабильности и безопасности.
SSL лучше решать на уровне сервера или хостинга
Не нужно устанавливать отдельный WordPress-плагин только потому, что сайт должен работать по HTTPS.
Большинство современных хостингов позволяют:
выпустить SSL-сертификат;
настроить HTTPS;
организовать redirect HTTP → HTTPS
на уровне инфраструктуры.
После миграции обязательно проверьте:
mixed content;
canonical;
sitemap;
внутренние ссылки;
redirects.
Что одинаково важно для всех трёх платформ
1. Чистая структура URL
Избегайте бессмысленных параметров и дублей.
2. Один основной URL страницы
Проверяйте canonical.
3. Корректные redirects
После изменения адресов используйте 301 на наиболее близкую новую страницу.
4. Нормальная внутренняя перелинковка
Важная страница не должна существовать только в sitemap.
5. Контроль индексации
Регулярно проверяйте Google Search Console.
6. Мобильная версия
Сайт должен оставаться удобным на реальном смартфоне, а не только проходить автоматический тест.
7. Core Web Vitals
Ориентиры:
LCP ≤ 2,5 с
INP ≤ 200 мс
CLS ≤ 0,1
Но оптимизировать нужно реальный пользовательский опыт, а не только лабораторный балл.
8. HTTPS
Все основные страницы должны открываться по защищённому соединению без смешанного контента и конфликтующих версий URL.
Что проверять в PageSpeed Insights
Не ограничивайтесь цифрой Performance.
Посмотрите, что именно создаёт проблему.
Частые причины:
тяжёлое LCP-изображение;
блокирующие ресурсы;
слишком много JavaScript;
сторонние виджеты;
шрифты;
скачки layout;
медленный сервер;
большие изображения.
Решение должно зависеть от причины.
Например, покупать CDN бессмысленно, если основную задержку создаёт сторонний чат, который выполняет десятки JavaScript-запросов.
Что выбрать для SEO: Bitrix, Tilda или WordPress
Сам выбор CMS не определяет позиции.
Tilda
Хорошо подходит, когда нужны:
корпоративные сайты;
лендинги;
промостраницы;
относительно компактные проекты.
Большая часть технической инфраструктуры уже контролируется платформой.
WordPress
Подходит для сайтов, которым нужна гибкость:
блоги;
контентные проекты;
корпоративные сайты;
каталоги;
проекты с кастомной функциональностью.
Но требует контроля темы, плагинов и хостинга.
Bitrix
Часто используется в:
крупных интернет-магазинах;
каталогах;
корпоративных системах;
проектах с интеграциями.
Даёт много технических возможностей, но обычно требует более серьёзной серверной и разработческой поддержки.
SEO можно нормально делать на любой из трёх платформ.
Главный вопрос:
соответствует ли CMS масштабу и функциональности проекта.
Чек-лист технического аудита
Перед продвижением проверьте:
Индексация — важные страницы доступны Google.
Robots.txt — не закрывает нужные ресурсы.
Sitemap — содержит правильные URL.
Canonical — нет конфликтующих версий.
301 — старые URL корректно перенаправлены.
404 — удалённые страницы отвечают правильно.
HTTPS — работает без смешанного контента.
Внутренние ссылки — важные страницы доступны через сайт.
Изображения — оптимизированы.
JavaScript — нет лишней нагрузки.
Core Web Vitals — проверены по LCP, INP и CLS.
Search Console — подключён и регулярно проверяется.
Итог
Техническое SEO нельзя свести к одному набору действий для всех CMS.
Для Bitrix обычно наиболее важны кеширование, сервер, фильтры, параметры URL, sitemap и шаблоны.
Для Tilda — структура страниц, изображения, сторонние скрипты, правильные SEO-настройки, canonical и redirects.
Для WordPress — тема, плагины, кеширование, хостинг, дубли и своевременная техническая поддержка.
При этом цель одна:
поисковая система должна без проблем обнаружить, просканировать и понять важные страницы, а пользователь — быстро и удобно ими воспользоваться.
CDN, кеш-плагины и высокий PageSpeed Score являются инструментами, а не самостоятельной SEO-стратегией.
Статья полностью пересобрана вокруг актуального технического SEO, а не списка плагинов.
Исправлена информация о Tilda: Lazy Load уже включён по умолчанию, изображения автоматически оптимизируются и доставляются через CDN; отдельный CDN с «серверами в Казахстане» не является обязательным.
Удалён совет подключать аналитику через Zero Block.
Для WordPress добавлены встроенные XML sitemap и lazy loading. Убрано требование устанавливать отдельный SSL-плагин.
Для Bitrix уточнена работа Композитного сайта, sitemap, robots.txt и параметров кеширования.
Добавлены canonical, redirects, индексация и актуальные Core Web Vitals: LCP, INP и CLS.
Убрана идея, что кеширование, CDN или идеальный PageSpeed Score сами по себе обеспечивают высокие позиции.