Как узнать CMS сайта: определяем движок и используемые технологии

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

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

Как быстро узнать, на какой CMS сделан сайт

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

1. Откройте нужный адрес и проверьте, что загрузилось. Заглушка хостинга, проверка защиты и страница ошибки могут скрыть признаки основного приложения. Зафиксируйте конечный URL после перенаправлений.
2. Проверьте страницу одним сервисом определения технологий. Найдите категорию CMS или платформы электронной торговли. Сохраните название, адрес и дату проверки.
3. Посмотрите ещё один типовой раздел. Например, статью блога или карточку товара. Главная и магазин иногда обслуживаются разными системами.
4. Найдите подтверждение в самой странице. Это может быть метатег генератора, характерный путь к ресурсам или несколько согласованных технических признаков.
5. Для своего сайта сверьтесь с административной панелью. Если есть доступ к действующему проекту, сведения из него полезнее предположений внешнего детектора.

Если сервис показал только Nginx, JavaScript и Google Analytics, CMS пока не определена. Если два инструмента назвали WordPress, а страница загружает характерные ресурсы WordPress, оснований для такой гипотезы больше. Но одинаковый вывод двух детекторов может опираться на один общий признак: количество совпадений само по себе не гарантирует точность.

CMS, конструктор, фреймворк и хостинг: что вы ищете

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

• CMS или торговая платформа: управляет содержимым и частью логики проекта. Примеры — WordPress и «1С-Битрикс: Управление сайтом».
• Конструктор: предоставляет среду сборки и публикации страниц. Некоторые конструкторы также включают управление товарами, блогом и другими данными.
• Фреймворк или библиотека: помогает разработчикам строить приложение или интерфейс. Обнаружение React не отвечает на вопрос, где редактор меняет тексты.
• Веб-сервер и CDN: участвуют в доставке ответа и файлов посетителю. Название Cloudflare или Nginx не определяет систему управления контентом.
• Тема, плагин и внешний виджет: добавляют оформление или отдельную функцию. Чат, аналитика и платёжный модуль могут работать на разных платформах.

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

Одинаковый внешний вид также мало говорит о внутреннем устройстве. Дизайн можно воспроизвести на нескольких платформах, а одну тему значительно переработать. Узнавать CMS по цветам, расположению меню или знакомому шаблону стоит только как предварительную догадку.

Как определить CMS сайта онлайн и через расширение

Детекторы анализируют доступные снаружи признаки: HTML, подключённые ресурсы, заголовки ответа и другие данные страницы. Они удобны для первого прохода, особенно когда вы пока не знаете характерных признаков конкретной платформы.

Какие инструменты использовать

Wappalyzer показывает категории обнаруженных технологий и предлагает проверку через сайт и браузерное расширение. Начните с категории CMS, затем посмотрите платформу магазина, библиотеки и инфраструктуру. Так проще не принять один компонент интерфейса за основной движок.

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

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

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

Как пользоваться расширением

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

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

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

В браузере откройте страницу, нажмите правой кнопкой мыши и выберите просмотр исходного кода. Название пункта зависит от браузера. Используйте поиск по тексту, обычно Ctrl+F в Windows и Linux или Command+F в macOS. Исследуйте полученный HTML, не меняя страницу.

Метатег generator

Начните с поиска слова generator. Некоторые системы добавляют метатег с названием программы, которая сформировала документ. Условный пример записи выглядит так:

<meta name="generator" content="WordPress">

Это прямое упоминание платформы в документе, но его следует подтвердить другими данными. Метатег можно убрать, заменить или сохранить при копировании страницы. Если его нет, делать вывод об отсутствии CMS нельзя. Если он есть только в старой статье, проверьте ещё несколько актуальных разделов.

Пути к стилям, скриптам и изображениям

Посмотрите адреса файлов в атрибутах href и src. У WordPress характерны пути, содержащие /wp-content/ и /wp-includes/. Ресурсы темы и плагинов обычно помогают понять происхождение страницы, особенно когда найдено несколько согласованных путей.

У «1С-Битрикс» встречаются ресурсы из /bitrix/ и /local/templates/. Расположение системных и пользовательских шаблонов описано в официальной документации платформы. Однако любое совпадение названия папки требует контекста: один импортированный файл ещё не характеризует весь проект.

Для каждого обнаруженного ресурса посмотрите полный адрес. Файл может принадлежать вашему сайту, внешнему виджету или другому проекту. Если WordPress упоминается только в URL чужой картинки, это слабое основание считать текущую страницу работающей на WordPress.

Комментарии и подписи

В HTML иногда остаются комментарии генератора, названия шаблонов и подписи разработчиков. Они помогают сформировать гипотезу, но быстро устаревают. Подпись студии сообщает об авторстве, а не обязательно о CMS. Название плагина описывает отдельную функцию и не всегда раскрывает способ управления всем сайтом.

По одному файлу index.php также нельзя определить движок: PHP используют разные приложения. Красивые адреса страниц без расширения не доказывают, что сайт статический. Внешняя структура URL зависит от настроек публикации и маршрутизации, поэтому используйте её только вместе с более конкретными признаками.

Что можно проверить через инструменты разработчика

Исходный HTML показывает документ, полученный от сервера. Часть данных и компонентов может появляться позже, после выполнения JavaScript. Чтобы увидеть загрузку ресурсов, откройте инструменты разработчика через меню браузера и выберите вкладку Network / Сеть.

1. Перезагрузите страницу с открытой вкладкой Network.
2. Выберите запрос основного документа, ориентируясь на адрес и тип Document.
3. Откройте Headers / Заголовки и посмотрите заголовки ответа.
4. Отдельно изучите несколько CSS- и JavaScript-файлов: их домены, пути и инициатор загрузки.
5. Если страница получает содержимое отдельными запросами, посмотрите их адреса, не передавая параметры сессии сторонним сервисам.

Заголовок Server может указывать на веб-сервер или промежуточный сервис. X-Powered-By иногда содержит название технологии, но может отсутствовать или быть изменён. Заголовки помогают дополнить картину; они не открывают доступ к внутреннему коду приложения.

Не нужно вставлять команды из случайных инструкций в консоль, чтобы просто определить платформу. В большинстве случаев достаточно чтения уже загруженных данных. Если делитесь скриншотом или выгрузкой сетевых запросов с подрядчиком, удалите cookies, токены и персональные сведения.

Какие признаки полезны и как их трактовать

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

Наблюдение	Разумная гипотеза	Что уточнить
Название CMS в generator и характерные ресурсы на нескольких страницах	Есть согласованные признаки этой платформы	Актуальность страниц и отсутствие статической копии
Ресурсы из /wp-content/ и /wp-includes/	Вероятно используется или использовался WordPress	Принадлежность файлов основному проекту
Ресурсы из /bitrix/ и /local/templates/	Есть признаки инфраструктуры «1С-Битрикс»	Другие страницы и сведения владельца
Название конструктора в файлах и подписи	Страница могла быть создана в этом конструкторе	Где она размещена и как сейчас обновляется
React, Vue или другая библиотека интерфейса	Обнаружена часть клиентской технологии	Какая система хранит и редактирует содержимое
Cloudflare, Nginx или Apache в отчёте	Обнаружен элемент доставки ответа	CMS и исходное размещение могут оставаться неизвестными
Ни одного узнаваемого маркера	Данных для определения недостаточно	Другие разделы и информация владельца

Не превращайте эту таблицу в автоматическую оценку точности в процентах. Без проверенной методики число вроде «достоверность 95%» будет выдуманным. Полезнее записать конкретные основания и то, что ещё требуется подтвердить.

Почему CMS не определяется или сервисы показывают разное

Разногласие не обязательно означает, что один инструмент плохой. Детекторы могли получить разные страницы, использовать разное время наблюдения или распознать разные уровни одной архитектуры.

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

Несколько систем. Блог может работать на одной CMS, магазин — на другой, а личный кабинет быть отдельным приложением. Фиксируйте платформу для конкретного адреса или раздела. Общая запись «весь домен на WordPress» в таком случае потеряет важное различие.

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

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

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

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

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

1. Проверьте адрес рабочей панели. Используйте ссылку из передачи проекта или менеджера паролей. Уточните, к какому домену и окружению относится эта панель: рабочему сайту, копии или тестовому стенду.
2. Откройте сведения о системе. Найдите название платформы, установленную версию, тему и список расширений. Нужные разделы отличаются у разных CMS.
3. Сопоставьте данные с размещением. В панели хостинга убедитесь, какая папка или приложение обслуживает нужный домен. Старый каталог рядом не обязательно относится к работающей версии сайта.
4. Уточните состав проекта у разработчика. Попросите описать CMS, интерфейс, интеграции и способ публикации. Если используется несколько систем, пусть их границы будут указаны явно.

В WordPress раздел «Инструменты → Здоровье сайта → Информация» содержит сведения о версии, теме, плагинах и технической конфигурации. Названия пунктов могут зависеть от языка интерфейса и доступных прав. Скопировать полный отчёт для собственного специалиста удобно, но перед внешней пересылкой стоит проверить его содержимое.

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

Как узнать версию CMS и насколько ей можно доверять

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

Параметр вроде ?ver=1.2.3 у файла может относиться к теме, плагину или способу обновления кэша. По нему нельзя автоматически определять версию ядра CMS. Старая строка в сохранённой странице тоже может пережить обновление приложения.

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

Даже подтверждённая версия не описывает всё состояние проекта. Отдельно имеют значение расширения, настройки и выполненные изменения. Задача определения CMS заканчивается установлением платформы и обоснованности сведений о ней; оценка безопасности требует самостоятельной работы.

Пример: как оформить результат без лишних предположений

Представим условный сайт услуг. Детектор показывает WordPress, а в HTML главной и статьи обнаружены стили из /wp-content/themes/. При этом внешних сведений о версии нет. Полезная запись для передачи проекта будет выглядеть так:

Раздел: главная и блог
Предполагаемая CMS: WordPress
Основания: результат детектора и пути ресурсов на двух страницах
Версия: по публичным данным не подтверждена
Что проверить владельцу: сведения действующей установки в панели
Дата и адреса наблюдений: указать при реальной проверке

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

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

Используйте результат для конкретной задачи: подобрать специалиста по нужной платформе, запросить доступы, уточнить совместимость модуля или составить план переноса. Не оценивайте качество сайта только по названию CMS: важны реализация, содержание и работа пользовательских действий.

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

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

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

Ниже — ответы на ситуации, которые чаще всего мешают получить понятный итог проверки.

Можно ли узнать CMS чужого сайта без доступа к панели?

Часто можно определить вероятную платформу по публичным признакам. Начните с детектора, затем проверьте HTML и несколько разделов. Если система не оставляет узнаваемых маркеров, точного ответа извне может не быть.

Сервис ничего не нашёл. Значит, сайт самописный?

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

Почему один сайт показывает сразу две CMS?

Проверьте, относятся ли результаты к разным разделам, старым наблюдениям или встроенному содержимому. В сложном проекте несколько систем действительно могут работать одновременно. Указывайте конкретные адреса для каждого вывода.

Можно ли одновременно узнать тему и плагины?

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

Какой способ самый надёжный для собственного сайта?

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