Движок сайта: как узнать, на чём сделан сайт, и что с этим делать

Движок сайта узнают по открытым признакам: исходному коду страницы, заголовкам ответа сервера, публичным файлам и записям DNS. Проверяют, на чём сделан сайт, по двум поводам: перед доработкой или переездом своего проекта и при разборе конкурента, у которого каталог открывается быстрее. Запрос звучит по-разному («на чём написан сайт», «узнать CMS сайта», «определить платформу сайта», «стек сайта»), а нужен в итоге план работ, спор о фреймворках выигрывать незачем.

Что входит в движок сайта и зачем это знать

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

Смотрите дальше главной. Каталог, карточка товара, блог и форма часто живут на разных технологиях: лендинг собран в конструкторе, блог работает на CMS, личный кабинет вынесен в отдельное приложение. У такого гибрида движок сайта не один, и это стоит записать сразу.

Как узнать CMS сайта по исходному коду и заголовкам

Движок сайта честнее всего видно в том, что сервер отдаёт браузеру. Откройте исходный код страницы (view-source) и поищите маркеры.

Затем вкладка Network в панели разработчика или команда curl -I. Заголовки ответа рассказывают про сервер больше разметки:

• Server называет веб-сервер или прокси, иногда с версией;
• X-Powered-By выдаёт язык или платформу, если администратор его не убрал;
• имена cookie в Set-Cookie почти всегда указывают на платформу;
• X-Cache, Age, Via говорят, что перед сайтом стоит CDN;
• Content-Security-Policy перечисляет домены сторонних скриптов.

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

Детекторы стека и DNS: где они ошибаются

Расширения класса Wappalyzer сверяют страницу с базой отпечатков: пути к файлам, cookie, глобальные переменные JS, заголовки. Гипотеза появляется за один клик, но движок сайта детектор угадывает не всегда:

• CDN подменяет заголовки, и вместо приложения определяется инфраструктура;
• движок сайта сменили, а файлы старой темы остались на сервере, и отпечаток живёт дальше;
• своя сборка на популярной библиотеке записывается в «библиотеку», хотя логика своя;
• SPA подгружает часть скриптов позже, статический анализ их пропускает;
• версии платформ в таких отчётах часто устаревшие или угаданные.

Поэтому детектор даёт первый шаг. Подтверждают его кодом и заголовками, а для своего проекта ещё доступом в админку и к хостингу.

NS-записи домена показывают, где управляется DNS, A или CNAME указывают, где физически стоит сайт, MX называют почтовый сервис. Для переезда это часто важнее, чем движок сайта: бывает, что домен оформлен на бывшего подрядчика и доступа к панели DNS нет ни у кого.

Чужой сайт: что смотреть и где граница

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

Что выписать по конкуренту:

1. Движок сайта и характер фронтенда: серверный рендер или клиентский.
2. Наличие CDN и скорость первого экрана на телефоне.
3. Сторонние скрипты: аналитика, чат, квиз, обратный звонок.
4. Как устроена форма заявки и сколько в ней полей.
5. Есть ли блог и FAQ на коммерческих страницах.

Про скорость: движок сайта сам по себе быстрым или медленным его не делает, это делают решения внутри. Опубликованные Google пороги «хорошо»: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Мерить стоит на мобильном профиле на главной, карточке и статье.

Фраза «тормозит, потому что такой движок сайта» почти всегда мимо. Сначала замер и разбор по элементам, потом выводы.

Оставить движок сайта или переезжать

Сверьте свой проект с таблицей.

Конструктор сам по себе не приговор: часто выигрыш дают структура, скорость и тексты, а платформа остаётся прежней. Сравнение вариантов есть в обзоре конструкторов сайтов и в разборе сайта на Tilda. Если движок сайта WordPress, проверьте плагины и тему по статье о WordPress для блога и магазина.

Смена движка сайта всегда начинается с карты URL и списка редиректов, иначе накопленный трафик остаётся на старых адресах. Частые ошибки здесь: обещать переезд «за день» без инвентаризации страниц и удалять плагины пачкой на живом сайте без бэкапа.

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

Как точно узнать CMS сайта, если он чужой?

Абсолютной точности снаружи нет. Совпадение трёх независимых признаков (путей в HTML, имён cookie, структуры карты сайта) даёт надёжную гипотезу, а точный движок сайта знает только владелец доступов.

Детекторы называют разный движок сайта. Кому верить?

Тому, что подтверждают исходный код и заголовки. Базы отпечатков обновляются по-разному, а CDN перед сайтом легко сбивает любой инструмент.

Как определить, на чём написан сайт, если он целиком на JavaScript?

Частично. Помогают имена файлов сборки, объект с начальным состоянием в разметке и запросы к API на вкладке Network. Серверную часть видно только по косвенным признакам.

Что делать, если движок сайта известен, а доступов нет?

Начать с организационной части: вернуть контроль над доменом и хостингом. Без этого анализ остаётся внешним, а перенос превращается в ручное восстановление контента.

Что сделать на этой неделе

1. Пройти шаги из статьи по своему проекту и записать результат в таблицу.
2. Отметить, что подтверждено фактами, а что осталось гипотезой.
3. Замерить Core Web Vitals на трёх типах страниц.
4. Отправить тестовую заявку и проверить, куда она пришла.
5. Решить, дорабатывать или переезжать, и назначить срок.

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