RevealTheme检测器的工作原理
当你在我们的某个检测器中输入一个URL时，在你看到结果之前的那两秒钟里会发生很多事情。这里为好奇的读者提供技术解读，包括那些我们无法通过工程手段解决的局限。
第1步：获取公开的HTML
当你提交一个URL时，我们的服务器会使用标准的浏览器User-Agent获取该URL的公开网页。这与你直接访问该网站时浏览器收到的HTML完全相同。我们不绕过付费墙，不抓取受登录保护的内容，也不使用任何身份验证。
获取使用20秒的超时时间。我们最多跟随10次重定向（这涵盖了HTTP → HTTPS、www → 无www以及按国家/地区的重定向）。如果网站返回4xx或5xx响应，或在超时窗口内没有响应，我们会返回清晰的「无法访问」错误，而不是猜测。
第2步：检测平台
在尝试识别具体主题之前，我们会先检查网站运行的是哪种CMS。我们查找7个受支持平台——WordPress、Shopify、Magento、Joomla、Drupal、Moodle和PrestaShop——的指纹特征，并选择最强的匹配项。
如果你把一个Shopify的URL提交到我们的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和Cloudflare的Rocket Loader等插件有时会重写资源URL以隐藏来源。我们基于特征的检测能识别出其中大多数，但并非全部。
- 静态导出的网站。一个被导出为静态HTML的WordPress网站会丢失使检测成为可能的大多数运行时特征。
我们不做的事
有人问过我们这些。答案都是否定的：
- 我们不存储你提交的URL
- 我们不出于营销目的记录IP地址
- 我们不与服务商分享检测数据
- 我们不绕过身份验证、robots.txt或其他访问控制
- 出于安全原因，我们不对内部/私有IP（127.0.0.1、10.x.x.x等）运行检测器
完整的隐私细节请见我们的隐私政策。
API访问
我们目前不提供公开API，但可应要求为代理机构和研究人员提供有限的程序化访问。请将你的使用场景和预期请求量发送至hello@revealtheme.com。
为什么不开源？
检测规则是产品的核心，我们会随着主题和插件的演变而频繁更新它们。将其开源会拖慢我们的更新节奏。话虽如此，我们会在博客上发布关于检测技术的详细文章：搜索「detection」即可找到。
准备好试一试了吗？
使用与你想检查的网站相匹配的检测器：