Короткий ответ
Вставьте адрес нужной страницы в сервис определения CMS и запустите проверку. Посмотрите название найденной технологии, статус и признаки, на которых основан вывод. Убедитесь, что результат относится к нужному адресу: после перенаправления сервис мог получить другую страницу. Если найдены только отдельные сигналы, подтвердите платформу у разработчика. Одна проверка не описывает автоматически весь сайт: главная, магазин и блог могут работать на разных системах. Отсутствие признаков не позволяет объявить сайт самописным. Для первоначальной оценки достаточно публичной страницы; доступ к панели управления не нужен.
Что именно определяет проверка
CMS — система управления содержимым. Через неё редактор публикует статьи, меняет страницы и работает с данными сайта. Словом «движок» часто называют и CMS, и платформу магазина, поэтому в результате полезно смотреть категорию технологии.
Например, WordPress может управлять материалами, а WooCommerce — добавлять каталог, корзину и заказы. Это совместимые части одного проекта. Интерфейс при этом может быть создан отдельно с помощью React или Next.js. React — библиотека для интерфейсов, Next.js — фреймворк на её основе; сами по себе они не сообщают, где редактор хранит и меняет контент [2, 3].
У конструктора вроде Tilda создание страниц и их публикация объединены в одной платформе. Генератор статических страниц, напротив, может собирать HTML из файлов или получать материалы из отдельной CMS. Поэтому найденный frontend или статический генератор не доказывает отсутствие системы управления. Кроме того, одна CMS может обслуживать только блог, а не весь домен.
Как проверить CMS онлайн
Шаг 1 Выберите нужный URL
Укажите адрес страницы, которую предстоит дорабатывать: главной, каталога или блога. Если проверяете статью, сохраните путь к ней, а не только домен. Для кириллического домена можно использовать исходное написание или punycode — техническую запись доменного имени латинскими символами.
Шаг 2 Запустите проверку и уточните адрес
Откройте определение CMS в SEOскопе, вставьте URL и запустите проверку. Сравните введённый адрес с финальным адресом после перенаправлений. Если вместо каталога открылась главная или страница входа, результат относится к полученной странице. Не переносите его на исходный раздел без уточнения.
Шаг 3 Изучите признаки
Смотрите, что именно найдено: generator, путь CSS или JavaScript, технический заголовок. Несколько согласованных признаков полезнее одного случайного совпадения. Многократное повторение одного пути не становится несколькими независимыми подтверждениями. Оценка признаков помогает читать результат, но не выражает вероятность правильного ответа.
Шаг 4 Сохраните основания вывода
Скачайте результат в JSON или CSV. Сохраните фактически проверенный URL, время проверки, статусы и признаки. Передайте файл разработчику вместе с описанием задачи. Если CMS не подтверждена, это ограничение нужно сохранить и в постановке работ.
Если таблица не помещается, прокрутите её вбок. С клавиатуры: перейдите к таблице клавишей Tab и используйте стрелки.
| Способ | Для какой задачи подходит | Что остаётся уточнить |
|---|---|---|
| Онлайн-сервис | Быстро собрать признаки публичной страницы | Полноту и актуальность вывода |
| Исходный HTML | Проверить generator и подключённые ресурсы | Скрытые и загружаемые позже компоненты |
| Заголовки ответа | Найти дополнительные технические сигналы | Связь сигнала именно с CMS |
| Проверка владельцем | Подтвердить установку и конфигурацию | Роль компонентов в конкретном разделе |
Как определить CMS по коду и ресурсам
Метатег generator
В Chrome откройте инструменты разработчика, затем Network и обновите страницу. Выберите основной запрос типа Document и вкладку Response: здесь можно искать признаки в полученном HTML. В исходном коде страницы найдите name="generator" и прочитайте значение content. Для WordPress условный пример выглядит так:
<meta name="generator" content="WordPress 6.x">Функция WordPress get_the_generator действительно может формировать метатег с названием системы и строкой версии [1]. Здесь 6.x — учебное обозначение, а не обнаруженная версия сайта. Значение generator можно удалить или изменить; оно также может остаться в сохранённой копии страницы. Поэтому найденную строку стоит сопоставить с другими признаками. Отсутствие тега не исключает CMS.
Пути CSS и JavaScript
В том же HTML найдите теги script и link: важны адреса подключённых ресурсов в src и href. Для WordPress характерны пути /wp-content/ и /wp-includes/. Для ручной проверки полезно увидеть, как именно они используются:
<script src="/wp-includes/js/wp-emoji-release.min.js"></script>Это пример подключения файла. Упоминание такого пути в статье, комментарии к коду или обычной ссылке не подтверждает, что страница использует WordPress. Учитывайте и домен ресурса: файл стороннего виджета может описывать технологию виджета, а не всего сайта. Название файла тоже можно изменить или воспроизвести вручную.
Если таблица не помещается, прокрутите её вбок. С клавиатуры: перейдите к таблице клавишей Tab и используйте стрелки.
| Технология | Пример сигнала | Где наблюдается | Ограничение |
|---|---|---|---|
| 1С-Битрикс | /bitrix/js/main/core.js и BX.message(...) | Адрес script и встроенный JavaScript | Фрагменты могли сохраниться после переноса |
| Tilda | data-tilda-project-id и ресурс с static.tildacdn.com | Атрибут HTML и адрес script | Экспорт страницы не подтверждает текущее размещение на Tilda |
| Drupal | /core/misc/drupal.js и data-drupal-selector | Адрес script и атрибут HTML | Наблюдение относится к этой странице |
| OpenCart | /catalog/view/javascript/common.js и /catalog/view/theme/ | Адреса script и link | Пути могут быть изменены или скопированы |
Все строки таблицы — учебные примеры наблюдаемых сигналов. Сочетание признаков даёт основание для предположения; фактическую конфигурацию подтверждает владелец. Для проекта с нестандартной сборкой привычные пути могут отсутствовать.
Заголовки HTTP и имена cookies
В Network выберите основной Document, откройте Headers и раздел Response Headers. Например, X-Powered-By: PHP сообщает о технологии выполнения, но не определяет CMS: PHP используют разные системы. Заголовок Server тоже описывает сервер или промежуточный узел, а не редакторскую платформу.
Cookies запроса можно посмотреть на вкладке Cookies [4]. Для распознавания важны характерные имена, а не их секретные значения. Учебный пример имени wordpress_logged_in_… связан с механизмом авторизации WordPress [7], но при обычном анонимном открытии страницы такого cookie может не быть. Отсутствие имени не опровергает платформу. Для иллюстрации или задачи достаточно названия признака: значения cookies и токены передавать не нужно.
Почему найдены разные технологии
Если сервис показывает несколько названий, сначала сравните их роли. WordPress и WooCommerce могут относиться к одной установке: CMS отвечает за контент, расширение — за магазин. Упоминание Next.js добавляет информацию об интерфейсе, но не подтверждает способ обмена данными с CMS.
Условный набор WordPress + WooCommerce + Next.js показывает, как могут сочетаться категории. Он не является доказательством архитектуры проверяемого сайта. Нужны признаки каждой технологии, относящиеся к конкретному URL. Ресурс из старого шаблона или встроенного блока тоже может попасть в HTML.
Если таблица не помещается, прокрутите её вбок. С клавиатуры: перейдите к таблице клавишей Tab и используйте стрелки.
| Наблюдение | Допустимый вывод | Что уточнить |
|---|---|---|
| WordPress и WooCommerce на одной странице | CMS и магазин могут работать вместе | Есть ли признаки обоих компонентов |
| На главной Tilda, а в блоге WordPress | Разделы могут использовать разные платформы | URL и результат каждого раздела отдельно |
| Найден Next.js без признаков CMS | Есть признаки фреймворка приложения | Где хранятся и редактируются материалы |
Разные ответы двух детекторов тоже не всегда означают ошибку одного из них. Сравните URL, время проверки, перенаправления и полученный ответ: сервисы могут увидеть разные страницы и применять разные правила. Для спорного случая передайте разработчику оба набора признаков. Выбирать ответ только по более высокому числу в оценке не стоит.
Почему CMS не удалось определить
Сначала выясните, получил ли сервис пригодную страницу. Возможны два разных исхода: страница доступна, но признаков мало; либо доступ к её содержимому не состоялся. Из второго исхода нельзя делать вывод о платформе.
Недостаточно сигналов. В полученном HTML нет подходящих совпадений. Generator могли убрать, пути изменить, а публичную страницу — отделить от CMS. Проверьте адрес другого нужного раздела вручную. Если решение влияет на стоимость работ, уточните платформу у владельца.
Есть только отдельные признаки. Например, виден один путь ресурса или только frontend. Сохраните находку как предположение и проверьте её источник. Несколько похожих ссылок из одного шаблона могут повторять один и тот же сигнал.
Ошибка HTTP или соединения. Код 403, 429, ошибка TLS, DNS или тайм-аут описывают проблему доступа. Проверьте написание адреса, откройте страницу в браузере и при необходимости повторите позже. Код ошибки не сообщает, что сайт самописный.
Проверка доступа. Вместо страницы сервис мог получить защитный экран. То, что сайт открывается у вас, не означает, что автоматическая проверка получает такой же ответ. Если результат нужен для вашего проекта, попросите разработчика подтвердить платформу.
Интерфейс загружается через JavaScript. SEOскоп анализирует публичный HTML одной страницы и не выполняет JavaScript. Часть данных, видимых в браузере после загрузки, может отсутствовать в исходном ответе. Это ограничение метода; для подтверждения может потребоваться проверка владельцем.
Превышен размер ответа. Если сервис сообщает об ограничении размера, анализ не считается полным. Можно отдельно проверить более лёгкую страницу того же раздела, но её результат будет относиться только к ней.
Версия CMS и ресурсы тем и плагинов
Название системы и её точная версия требуют разных подтверждений. Если в generator указано WordPress 6.7.2, вы увидели заявленную строку версии в ответе. Она может быть изменена, устареть в кеше или не соответствовать текущей установке. Перед оценкой совместимости разработчик сверяет её с данными самого проекта.
Пути /wp-content/themes/имя-темы/ и /wp-content/plugins/имя-плагина/ помогают заметить ресурсы темы или расширения. Каталог темы и каталог плагина имеют разное назначение [5, 6]. При этом имя папки не всегда совпадает с полным названием продукта, а ресурс в HTML не доказывает, что компонент сейчас активен во всей установке.
Если пути не обнаружены, полный список компонентов всё равно остаётся неизвестным: файлы могут объединяться, загружаться с другого адреса или подключаться лишь на отдельных страницах. Для точного перечня владелец может предоставить выгрузку из панели управления или поручить проверку разработчику. По одному номеру версии нельзя объявлять сайт уязвимым: определение CMS не заменяет проверку безопасности.
Что делать после определения движка
Доработка сайта. Передайте специалисту платформу, нужный раздел и ожидаемое изменение: например, новые поля карточки товара или редактируемый блок страницы. Попросите подтвердить систему и ограничения перед расчётом. Если нужен новый сайт или переработка существующего, начните с требований к разработке.
Смена платформы. Уточните, какие данные, URL и интеграции предстоит сохранить. Название CMS не даёт готового плана миграции. Сопоставьте старые и новые страницы, подготовьте редиректы и контроль индексации по чек-листу переезда сайта.
Поиск ошибок SEO. Используйте CMS как контекст для специалиста. Дубли, закрытые страницы, canonical, метатеги и перелинковку исследуют отдельно. Эти задачи входят в технический SEO-аудит.
Задачу разработчику можно сформулировать так: «Проверена страница [URL], дата и время [значение и часовой пояс]. Найдены [технологии]. Основания: [признаки и источники]. Ограничения: [неподтверждённая версия или недостаток данных]. Подтвердите платформу и версию перед оценкой работ». Это шаблон, который нужно заполнить результатами своей проверки.
Короткие ответы
Можно ли проверить чужой сайт?
Можно изучить признаки открытой страницы без доступа к панели управления. Такой результат показывает только публично доступные сведения и не раскрывает внутреннюю конфигурацию проекта.
Почему главная и блог дают разные результаты?
Разделы могут быть сделаны на разных системах. Проверьте каждый адрес отдельно, учитывая перенаправления, и сохраните признаки для каждого URL.
Обязательно ли знать точную версию до обращения к разработчику?
Для первого обсуждения достаточно предполагаемой платформы и описания задачи. Перед расчётом обновления или совместимости специалист должен подтвердить версию в проекте.
Можно ли угадать CMS по доменной зоне?
Нет. Зоны .ru, .рф или .com не закреплены за определённым движком. Для вывода нужны технические признаки страницы.
Что отправить разработчику вместе с результатом?
URL, дату и время, названия технологий, источники признаков и ограничения. Если проверка завершилась ошибкой доступа, передайте её сообщение и код вместо предположения о CMS.
Источники
- WordPress get_the_generator — формирование generator и возможность изменения значения.
- WooCommerce — платформа магазина для WordPress.
- Next.js Documentation и React — назначение фреймворка и библиотеки интерфейсов.
- Chrome DevTools Network reference — просмотр ответа, заголовков и cookies.
- WordPress Theme Structure — устройство каталогов тем.
- WordPress Plugin and Content Directories — каталоги плагинов и возможность изменения путей.
- WordPress Cookies — назначение имён cookies авторизации.