Prismic 优化检测 免费在线检测工具
首页 › 笔记 › 一个网站到底是用什么建的？三步自查 + 13 种信号

一个网站到底是用什么建的？三步自查 + 13 种信号

接手一个站、或者想改自己的站，第一件事不是打开代码，是搞清楚它是用什么搭的。

因为技术栈决定了后面每一件事的可行性。

  • 改得动改不动：WordPress 站的标题字体可能在一个主题设置里；Webflow 站你可能连 HTML 都拿不到；无头 CMS 则要去改内容模型。
  • 图片能不能救：WordPress 走 /wp-content/uploads/，Shopify 走 cdn.shopify.com，Prismic 走 images.prismic.io——每条管线给的变换参数都不一样，不认管线就不知道该调什么。
  • 缓存与渲染策略：无头方案靠 CDN 缓存 API JSON 和 HTML 壳；经典 PHP 靠整页缓存加对象缓存；托管建站给你的旋钮最少。
  • 能不能改代码：有些平台你只能改面板，有些可以随便改。

一句话：先认平台，再谈优化。顺序反了就是白干。

#三步自查法

第一步：看源码，然后在源码里搜

打开页面 → Ctrl+U（Mac 上是 Cmd+Option+U）→ 在 HTML 里搜你怀疑的厂商名。

关键区别在这里：如果这个名字只出现在正文或注释里，它什么都证明不了。真正算数的是它出现在 src、href 或 data- 属性里——那才是浏览器被要求去加载的资源。

举个具体例子：你在源码里搜到 prismic，但它出现在一段 <p> 文字里，那可能只是这站写过一篇讲 Prismic 的文章。但如果它出现在 src="https://images.prismic.io/..."，那就是实打实的证据。

所以搜的时候，看的不是"有没有这个词"，而是这个词出现在什么位置。

打开开发者工具 → Network → 刷新 → 点第一个文档请求。看这几样：

  • x-powered-by、x-generator、server
  • set-cookie 里的名字——这一条最有价值

为什么 cookie 比 meta 标签更有力？因为 meta 标签是人写的，cookie 是平台自己下发的。一个叫 wp-settings-1 或者 _shopify_s 的 cookie，基本等于平台在自报家门。

⚠️ 注意一个陷阱：CDN 会剥掉响应头。Cloudflare、Vercel 这些在前面一站，很多原始头就没了。所以"没看到"不能当作"不是"——它只是一票，不是判决。

第三步：和一个已知的站点对照

同一个平台，在任何站上都留下同样的形状：同样的资源主机、同样的路径前缀、同样的编辑端点。

这是"检测 CMS"这件事能可靠的根本原因——不是靠猜，是靠形状匹配。

  • 单个词命中 → 可能是误判
  • 命中 + 对应主机 + 对应路径 → 这才叫确认

#13 种常见信号

  • WordPress：/wp-content/、/wp-includes/、/wp-json/、wp-emoji-release 脚本、wp-* cookie
  • Shopify：cdn.shopify.com、cdn.shopifycdn.com、/cdn/shop/、页面脚本里的 Shopify.theme
  • Wix：static.wixstatic.com、static.parastorage.com、内联的 viewer model JSON
  • Squarespace：static1.squarespace.com、Static.SQUARESPACE_CONTEXT
  • Webflow：website-files.com、website-images-assets.com、<html> 上的 data-wf-*
  • Prismic：images.prismic.io、/prismic-assets/、slice 标记、prismic-toolbar
  • Contentful：images.ctfassets.net、assets.ctfassets.net
  • Sanity：cdn.sanity.io、页面脚本里引用的 project id
  • Ghost：/ghost/、/content/ 路径、ghost-* meta、Ghost admin SDK
  • Drupal：/sites/default/files/、drupalSettings、X-Generator 响应头
  • Joomla：/media/jui/、/media/system/、/components/com_
  • Craft CMS：CRAFT_CSRF_TOKEN cookie、/cpresources/
  • Strapi：/uploads/ 路径 + api. 主机或 /api/ JSON 接口

#一个真实例子

拿一个大家都认识的站练手：TechCrunch 首页。

源码里，这两行是决定性的：

<link rel="https://api.w.org/" href="https://techcrunch.com/wp-json/" />
<script src="https://techcrunch.com/wp-includes/js/dist/i18n.min.js?ver=..." id="wp-i18n-js"></script>

/wp-json/ 和 /wp-includes/ 都是 WordPress 的专属路径，而且出现在 href 和 src 里——浏览器真的会去加载它们。

响应头里更直接：

x-powered-by: WordPress VIP <https://wpvip.com>
link: <https://techcrunch.com/wp-json/>; rel="https://api.w.org/"
server: cloudflare

x-powered-by 直接自报家门，link 头还把 REST API 的地址给了出来。

注意最后一行：server 是 cloudflare，不是真正的源站。这就是"CDN 会剥头"的现场——CDN 挡在前面的时候，你能看到的信息少一层。

#两个最常见的误判

误判一：在正文里搜到品牌名就当成了。

文档站、对比文章、招聘 JD 里会同时出现好几家厂商的名字。那不是装机证据。

误判二：只看一个信号就下结论。

比如很多站都用了 Cloudflare，但 Cloudflare 只是个 CDN，不代表它是什么 CMS。

正确的做法是把信号分层看：

  • 厂商专属主机（强）> 路径前缀（强）> cookie（强）
  • 响应头（中——会被 CDN 剥）
  • 页面里的品牌字符串（弱）

#不想自己一步步查

上面三步如果懒得走，把网址粘到 prismicaudit.com/tools/cms-checker 就行——它会跑 100 多个探测器，覆盖 CMS、框架、主机、CDN、第三方脚本，并把命中的证据原文列出来（不是只给一个"是/否"）。

我比较在意"给证据"而不是"给结论"，因为你能自己核对的东西才值得信。

*本文提到的检查方法在任何站点上都适用；文中列出的厂商名只为说明识别特征，与本工具无隶属关系。*