Как работает детектор RevealTheme

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

Шаг 1: Получение публичного HTML

Когда вы отправляете URL, наш сервер получает публичную веб-страницу по этому URL, используя стандартный браузерный User-Agent. Это тот же HTML, который получил бы ваш браузер, если бы вы зашли на сайт напрямую. Мы не обходим платные стены, не извлекаем контент, защищённый входом, и не используем какую-либо аутентификацию.

Получение использует тайм-аут в 20 секунд. Мы следуем за перенаправлениями до 10 раз (что охватывает перенаправления HTTP → HTTPS, www → без-www и перенаправления по странам). Если сайт возвращает ответ 4xx или 5xx либо не отвечает в пределах окна тайм-аута, мы возвращаем понятную ошибку «не удалось получить доступ» вместо того, чтобы гадать.

Шаг 2: Определение платформы

Прежде чем пытаться определить конкретную тему, мы проверяем, на какой CMS работает сайт. Мы ищем отпечатки 7 поддерживаемых платформ — WordPress, Shopify, Magento, Joomla, Drupal, Moodle и PrestaShop — и выбираем наиболее сильное совпадение.

Если вы отправите URL Shopify в наш детектор WordPress (или наоборот), мы сообщим вам об этом и дадим ссылку на правильный детектор. Без догадок, без ложных срабатываний.

Шаг 3: Определение темы

Для WordPress в частности ссылки на тему обычно появляются в HTML страницы в путях вроде wp-content/themes/ИМЯ_ТЕМЫ/style.css. Мы извлекаем каждую такую ссылку из любой части документа: тегов link, тегов script, встроенного JavaScript, блоков JSON-LD и даже текстового содержимого. Это позволяет обнаружить темы, которые сильно оптимизированные сайты скрыли от стандартных инструментов определения.

Для каждой обнаруженной темы мы пытаемся получить файл style.css темы. Заголовок этого файла содержит официальное название темы, автора, версию, URI и описание — напрямую от разработчика темы. Это и есть источник той богатой информации о теме, которую мы показываем рядом с результатом определения.

Шаг 4: Определение плагинов

Определение плагинов использует два параллельных подхода. Во-первых, мы извлекаем любые пути к файлам, совпадающие с wp-content/plugins/ИМЯ_ПЛАГИНА/. Во-вторых, мы выполняем десятки проверок на основе сигнатур: ищем определённые HTML-структуры, имена CSS-классов, встроенные JavaScript-переменные и HTTP-заголовки ответа, которые однозначно идентифицируют популярные плагины, такие как Elementor, Yoast SEO, WPForms, WooCommerce, Wordfence и другие.

Двойной подход позволяет обнаруживать плагины, которые скрывают свои пути к файлам (с помощью кэширования или объединения ресурсов), но всё равно оставляют характерные сигнатуры. Для каждого обнаруженного плагина мы ищем его в Каталоге плагинов WordPress.org, чтобы обогатить результат официальным названием плагина, описанием, автором и скриншотами.

Шаг 5: Поиск хостинга + DNS

Чтобы определить хостинг-провайдера, мы выполняем DNS-запрос по домену и проверяем IP-адрес, ASN и обратный DNS. Мы сверяем это с базой данных известных диапазонов IP хостинг-провайдеров, чтобы определить провайдера. Точность высока для крупных хостингов (AWS, Cloudflare, Hostinger, SiteGround и т. д.) и ниже для нишевых провайдеров.

Чего мы не можем сделать

Некоторые случаи, в которых определение не сработает, каким бы хорошим ни был наш код:

Проверка ботов Cloudflare. Сайты со строгой защитой от ботов Cloudflare (экран «Выполняется проверка безопасности...») блокируют наш загрузчик так же, как блокировали бы любой автоматизированный запрос. Чистого способа это обойти нет.
Сильно кастомизированные темы. Если тема изменена настолько, что из HTML удалена каждая ссылка на исходное название темы, нам нечего определять.
Агрессивное кэширование с переписанными путями ресурсов. Плагины вроде LiteSpeed Cache, WP Rocket и Rocket Loader от Cloudflare иногда переписывают URL ресурсов, чтобы скрыть источник. Наше определение на основе сигнатур обнаруживает большинство из них, но не все.
Сайты со статическим экспортом. Сайт WordPress, экспортированный в статический HTML, теряет большинство runtime-сигнатур, которые делают определение возможным.

Чего мы не делаем

Нас об этом спрашивали. Ответы — нет:

Мы не храним отправляемые вами URL
Мы не записываем IP-адреса в маркетинговых целях
Мы не передаём данные определения провайдерам
Мы не обходим аутентификацию, robots.txt или другие средства контроля доступа
Мы не запускаем детектор для внутренних/частных IP (127.0.0.1, 10.x.x.x и т. д.) из соображений безопасности

Полные сведения о конфиденциальности — в нашей Политике конфиденциальности.

Доступ к API

В настоящее время мы не предлагаем публичный API, но ограниченный программный доступ доступен по запросу для агентств и исследователей. Напишите на hello@revealtheme.com, указав ваш сценарий использования и предполагаемый объём запросов.

Почему это не с открытым исходным кодом?

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

Готовы попробовать?

Воспользуйтесь детектором, подходящим для сайта, который вы хотите проверить: