Как узнать, на какой CMS сделан сайт, и зачем это владельцу

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

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

Лупа над исходным кодом страницы с логотипами движков

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

Зачем это вообще знать владельцу

Мне регулярно пишут в духе «у нас сайт на движке, надо поправить каталог, сколько будет стоить». На вопрос, какой движок, отвечают «обычный». Разговор буксует, потому что от ответа зависит буквально всё.

Приём сайта от прежнего исполнителя. Пока вы не знаете движок, вы не знаете, что вам передавать: доступ к админке, к БД, к репозиторию, лицензионный ключ. У Битрикса ключ платный и привязан к домену, у WordPress ключей нет вообще, у Tilda весь сайт живёт в чужом аккаунте, и передавать надо не файлы, а логин от проекта. Подробнее про сам процесс приёмки писал в статье про передачу сайта от старого подрядчика.

Оценка стоимости работ. Одна и та же задача «добавить фильтр в каталог» на WooCommerce занимает 3-4 часа готовым плагином, на Битриксе 6-10 часов настройкой компонента, на самописе от 20 часов и с полным погружением в чужой код. Это разница между 10 000 и 60 000 рублей на пустом месте.

Поиск исполнителя. Специалист по Битриксу и специалист по WordPress это два разных человека с разной ставкой. Найти вордпрессника в Питере можно за день, битриксоида под нестандартную конфигурацию за неделю, разработчика по вашему конкретному самопису шестилетней давности не найти вовсе.

Оценка рисков. Устаревшая Joomla 3, брошенная разработчиком в 2023 году, это дыра, через которую сайт ломают ботами по расписанию. Пока не знаешь движок и версию, не понимаешь, насколько горит.

Быстрые способы определить движок

Начинаю всегда с самого дешёвого по времени и иду вниз по списку, пока не появится однозначный ответ.

Исходный код страницы

Открываете сайт, жмёте Ctrl+U, получаете HTML. Дальше ищете по тексту (Ctrl+F) характерные маркеры.

WordPress выдаёт себя мгновенно: пути /wp-content/themes/, /wp-includes/js/, тег <meta name="generator" content="WordPress 6.x">, ссылки вида ?p=123 и REST-эндпоинт /wp-json/. Даже если генератор вычищен плагином, пути к статике почти всегда остаются: их прячут единицы.

Битрикс оставляет /bitrix/js/main/core/core.js, /bitrix/templates/, куки BITRIX_SM_GUEST_ID и BX.ready(...) в скриптах. Ещё встречается класс bx- у обёрток вёрстки.

Tilda видна по tilda-blocks-page*.css, атрибутам data-tilda-..., домену static.tildacdn.com в путях к картинкам и скриптам.

MODX Revolution скромнее, но выдаёт assets/components/, connectors.php и тег генератора при дефолтных настройках. Ещё характерны чистые URL без расширений при полном отсутствии знакомых системных папок.

OpenCart: catalog/view/theme/, index.php?route=common/home, куки OCSESSID. Joomla: /media/system/js/, /templates/, Joomla! - Open Source Content Management в генераторе. Drupal: /sites/default/files/, заголовок X-Generator.

Типовые пути в адресной строке

Второй способ грубее, но работает, когда HTML почищен. Просто дописываете к домену известный путь и смотрите ответ.

Что открываем	Что означает ответ
`/wp-login.php`	форма входа WordPress
`/wp-json/wp/v2/posts`	JSON со статьями, точно WordPress
`/bitrix/admin/`	редирект на авторизацию Битрикса
`/administrator/`	админка Joomla
`/admin/`	OpenCart, Drupal, самопис (зависит от настроек)
`/manager/`	панель MODX
`/user/login`	Drupal
`/sitemap.xml`	по структуре видно генератор карты

Отсутствие ответа ничего не доказывает: адрес админки переименовывают, /wp-login.php закрывают по IP, это нормальная гигиена. А вот 200 или редирект на форму входа доказывает многое.

Заголовки ответа сервера

Самый быстрый вариант из терминала. Одна команда, и часть вопросов закрыта.

# заголовки ответа: сервер, куки, X-Powered-By, X-Generator
curl -sI https://example.ru/ | tr -d 'r'

# ищем маркеры движков прямо в HTML
curl -s https://example.ru/ | grep -Eio 'wp-content|wp-includes|/bitrix/|tildacdn|modx|joomla|opencart|shopify' | sort -u

# тег генератора отдельно
curl -s https://example.ru/ | grep -io '<meta name="generator"[^>]*>'

На что смотреть в заголовках. Куки PHPSESSID намекают на PHP-движок, BITRIX_SM_* на Битрикс, OCSESSID на OpenCart. Заголовок X-Powered-By: PHP/7.4 рассказывает про версию языка, и это уже разговор про безопасность: поддержка 7.4 закончилась в 2022 году, патчей на новые уязвимости нет. Заголовок Link: <https://example.ru/wp-json/>; rel="https://api.w.org/" это WordPress без вариантов.

robots.txt

Файл /robots.txt часто пишут не руками, а генератором CMS или плагином, и он проговаривается служебными путями. Disallow: /wp-admin/ это WordPress, Disallow: /bitrix/ Битрикс, Disallow: /administrator/ Joomla. Заодно сразу видно, не закрыт ли сайт от индексации целиком, что тоже полезная находка.

Онлайн-определители: где помогают, где врут

Сервисы вроде Wappalyzer (расширение для браузера), BuiltWith, W3Techs и десяток российских клонов работают на тех же признаках, что перечислены выше, только автоматически. Для типового сайта на коробочном движке это одна кнопка и правильный ответ.

Ошибаются они предсказуемо, и вот на чём.

Кастомные сборки и headless. Если фронт отдаёт Next.js, а контент лежит в WordPress через REST API, определитель честно скажет «Next.js» и промолчит про движок. Владелец делает вывод, что CMS нет, а она есть, просто спрятана за отдельным фронтендом. Проверяется запросом к /wp-json/ или к другому API на том же домене.

Агрессивный кэш и CDN. Когда страницу отдаёт статикой Nginx или CDN, половина заголовков подменяется, куки не ставятся, и детектор видит только «Nginx, Cloudflare».

Плагины сокрытия. У WordPress есть класс плагинов, которые переименовывают wp-content, убирают генератор и меняют адрес админки. Wappalyzer после этого пожимает плечами. Ирония в том, что REST-эндпоинт и структура классов в разметке всё равно остаются.

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

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

Как узнать версию и почему её не стоит светить

Версия важнее самого факта движка. WordPress 6.7 с автообновлениями и WordPress 4.9 из 2018 года это два разных уровня риска при одинаковом ответе «у нас вордпресс».

Снаружи версия ловится так:

тег генератора (<meta name="generator" content="WordPress 6.7.1">) если его не вычистили;
параметр ?ver= у подключённых стилей и скриптов, часто совпадает с версией ядра;
файл /readme.html у WordPress и /CHANGELOG.txt у Joomla, если их не удалили;
/bitrix/js/main/core/core.js у Битрикса, по хэшу файла можно оценить поколение;
RSS-лента: в /feed/ генератор указан отдельным тегом.

Изнутри проще. Если есть SSH и WP-CLI:

# версия ядра, список плагинов и что просит обновления
wp core version
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update

# без WP-CLI: версия лежит в файле ядра
grep "wp_version =" wp-includes/version.php

Теперь про «не светить». Публичная версия ядра плюс список плагинов из разметки это готовое ТЗ для сканера уязвимостей. Ботнет ходит по спискам CVE и стучится в конкретные версии конкретных плагинов, ему не нужен человек за клавиатурой. Убрать генератор и ?ver= дело пятнадцати минут, а вот заменить сокрытием реальные обновления не выйдет: сокрытие снижает вероятность попасть под массовый перебор, но не закрывает дыру. Про режим обновлений и почему это не косметика, у меня есть отдельный разбор.

Что делать с находкой:

Убрать meta generator и версии в ?ver= (в WordPress это пара строк в functions.php или галочка в плагине безопасности).
Удалить readme.html, license.txt, CHANGELOG.txt из корня.
Закрыть /wp-json/wp/v2/users от анонимов, чтобы не отдавать список логинов.
Накатить обновления ядра и плагинов, желательно сначала на копии.

Признаки самописного движка

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

На что я смотрю:

URL вида /index.php?page=catalog&id=17 или /catalog.php?cat=3 без единого следа известного движка;
нестандартные имена статики: /css/style.css, /js/main.js, /img/, без хэшей и версий;
заголовок Set-Cookie: PHPSESSID при полном отсутствии CMS-маркеров;
HTML с инлайновыми стилями и таблицами вёрстки, датируемый примерно 2014 годом;
админка по адресу вроде /adminka/, /panel/, /cp/, которая ни на что не похожа.

Проверяется одним запросом к базе, если доступ есть. Коробочные движки узнаются по именам таблиц.

SHOW TABLES;
-- wp_posts, wp_options            -> WordPress
-- b_iblock, b_user                -> Битрикс
-- modx_site_content               -> MODX
-- oc_product, oc_category         -> OpenCart
-- #__content, #__users            -> Joomla (префикс задаётся при установке)
-- news, catalog, users без префикса -> скорее всего самопис

Что самопис значит для денег. Коробочный движок это чужой протестированный код, документация и рынок исполнителей. Самопис это код одного человека, который его давно не поддерживает. Оценка работ по нему всегда включает часы на чтение исходников, и на первую задачу закладывается двойной запас времени. По моей практике абонентка на самописе обходится в полтора-два раза дороже, чем на WordPress той же сложности, а любая доработка стартует от 15-20 тысяч, потому что дешевле просто не получается разобраться.

Отдельная беда, когда самопис написан на PHP 5.х и не заводится на PHP 8. Хостинг рано или поздно выключит старую версию языка, и сайт встанет. Это тот случай, когда переезд на коробочный движок дешевле поддержки текущего.

Конструктор или CMS: как отличить

Разница принципиальная, потому что от неё зависит, есть ли у вас вообще сайт как имущество.

CMS живёт на вашем хостинге. Есть файлы, есть база, есть SSH и FTP, сайт можно скачать целиком и перевезти к другому провайдеру за вечер.

Конструктор живёт в чужом аккаунте. Tilda, Wix, Craftum, uKit: вы арендуете и платформу, и хостинг. Экспорт есть не везде, а где есть, вывозит статику без админки и без форм.

Отличается за десять секунд: смотрим, откуда грузится статика. static.tildacdn.com у Тильды, parastorage.com у Wix, cdn.shopify.com у Shopify. Плюс проверяем DNS: конструкторы обычно просят прописать CNAME на свою инфраструктуру.

Признак	CMS на своём хостинге	Конструктор
Где файлы	ваш сервер, доступ по SSH/FTP	чужой аккаунт, доступа к файлам нет
Перенос к другому подрядчику	архив плюс дамп базы	экспорт статики или ручная пересборка
Правки шаблона	любые, вплоть до кода	в пределах редактора платформы
Ежемесячная плата	хостинг от 250 руб.	подписка от 750 руб.
Что будет при неоплате	сайт работает, пока оплачен хостинг	сайт выключается целиком

Про то, чем в 2026 году отличаются основные варианты и кому что подходит, есть развёрнутое сравнение: WordPress, Tilda, Битрикс и MODX.

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

Определили CMS и версию. Это одна строка будущего паспорта сайта, а нужны ещё семь. Список, который я прошу заполнить каждого нового клиента до начала работ:

Хостинг: провайдер, тариф, на кого оформлен аккаунт, до какого числа оплачен.
Домен: регистратор, на кого зарегистрирован, дата продления, куда приходят уведомления.
Доступы: админка CMS, панель хостинга, FTP или SSH, база, аккаунт регистратора, почта на домене.
Лицензии: ключ Битрикса и срок его действия, платные плагины и темы, подписки на сервисы.
Бэкапы: делаются ли, где лежат, кто проверял восстановление и когда.
Аналитика: счётчик Метрики, доступ к Вебмастеру, права владельца.
Интеграции: CRM, эквайринг, телефония, почтовые рассылки, боты.
Кто ещё имеет доступ: бывший подрядчик, агентство, маркетолог, племянник.

Каждый пункт закрывается за 10-20 минут, а вместе они превращаются в документ, из-за отсутствия которого сайты чаще всего и теряются. Как это оформить и вести дальше, писал в статье про паспорт сайта.

Отдельно про пункт 8. Самая частая мина при смене исполнителя не в коде, а в правах: старый подрядчик остаётся администратором в WordPress, владельцем счётчика Метрики или, что хуже, администратором домена у регистратора. Пока это не исправлено, движок и версия вторичны.

Короткий алгоритм на один вечер

Если хочется закрыть вопрос по своему сайту прямо сегодня, порядок такой:

Открыть исходный код главной, поискать wp-content, bitrix, tildacdn, modx, catalog/view.
Прогнать curl -sI по домену, посмотреть куки и заголовки.
Проверить /robots.txt на служебные пути.
Установить Wappalyzer и сверить его вердикт со своими находками.
Найти версию через генератор, ?ver= или /readme.html, а если есть SSH, через wp core version.
Записать результат в файл вместе с хостингом, доменом и списком доступов.

На всё уходит примерно час, и после него разговор с любым подрядчиком идёт совсем иначе: вы называете движок, версию и хостинг, а не «у нас там что-то на php».

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

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