除了把每个站URL逐个贴进检测工具跑一遍，还有没有能一次扫描20个站HTML规范性、死链、结构化数据的办法？
有个做站群的朋友，手上18个站，每次改完公共CSS模板之后要做两件事：一是逐个站打开浏览器看看样式有没有崩，二是用W3C验证器把每个站首页贴进去跑一遍HTML校验。18个站，两件事，每轮下来大半天没了。直到有一次改模板漏改了一个站，那个站排版崩了一个月没人发现——因为实在太累了，中间有几个站就被跳过了。
代码检测这件事，单站好办，工具遍地都是。但站一多，问题就变成了"怎么批量跑、怎么自动跑、怎么跑完知道哪里有问题"。这篇文章按检测维度分类，把前端代码、HTML规范、死链、结构化数据、性能这几个方向的批量检测工具和方法理一遍。
代码批量检测，五个核心维度
| 1 | 前端代码质量 — ESLint、Prettier、SonarQube 批量扫描JS/TS/CSS |
| 2 | HTML规范校验 — W3C Validator、HTMLHint 批量跑多站HTML |
| 3 | 死链批量扫描 — Xenu、Screaming Frog、自写Python爬虫 |
| 4 | 结构化数据检测 — Schema Markup Validator 批量检查富媒体标记 |
| 5 | 性能与SEO审计 — Lighthouse Batch Reporter 批量跑Lighthouse |
一、前端代码质量，ESLint一条命令扫全部项目
如果你的站群是用Node.js/React/Vue这类前端框架开发的，或者共用一套JS/CSS模板，ESLint是最直接的批量检测工具。它本身支持在一个命令里扫描多个目录：
npx eslint "projects/site-*/src/**/*.js" --format json > report.json这条命令会把所有 site-1 到 site-N 的JS文件扫一遍，输出JSON格式报告。再配合一个简单的Python脚本解析report.json，就能生成每个站的错误数量和严重等级汇总。如果你还需要统一代码风格，Prettier也能做批量检查：
npx prettier --check "projects/site-*/**/*.{js,css,html}"Prettier的 --check 模式不会直接改你的代码，只会报告哪些文件格式不符合规范。对于维护多站点模板的场景，这个检查能防止某个站的代码因为手动修改而偏离了统一的格式标准。
SonarQube适合什么场景？
如果你不只是检查JS/CSS语法，还要做安全漏洞扫描、重复代码检测、代码复杂度分析，SonarQube更全面。但它需要搭一个服务端，配置门槛比ESLint高。适合20个站以上、有专人维护代码库的团队。对于中小站群，ESLint + Prettier的组合基本够用。
二、HTML规范校验，把W3C验证器自动化
站群最常见的代码问题不在JS里，在HTML里：标签没闭合、属性值缺引号、嵌套结构错误、废弃标签还在用。这些问题在浏览器里可能"看起来正常"，但爬虫解析的时候就可能出问题。W3C Validator提供了API接口，可以用脚本批量提交URL检测：
import requestssites = ["https://www.site-a.com","https://www.site-b.com","https://www.site-c.com",]for url in sites:api = f"https://validator.w3.org/nu/?out=json&doc={url}"resp = requests.get(api)result = resp.json()errors = [m for m in result.get("messages", []) if m["type"] == "error"]print(f"{url}: {len(errors)} errors")W3C API有频率限制，连续请求太快会被限流。建议在每次请求之间加1-2秒的sleep，站点多的话可以配合定时任务每天凌晨跑一次。另外，HTMLHint也提供了命令行版本，适合检测本地HTML文件：
npx htmlhint "sites/*/index.html" --format json注意一个坑：有些站的HTML是通过JS动态渲染的（SPA单页应用），W3C API拿到的只是初始HTML骨架，检测结果不代表用户实际看到的页面。如果你的站点是React/Vue渲染的，建议用Puppeteer抓取渲染后的HTML再送检。
三、死链检测，从Xenu到Screaming Frog再到自写爬虫
死链对SEO的影响比很多人想的严重。百度蜘蛛爬到一个404页面，浪费了一次抓取配额；用户点到一个死链接，直接跳出。站群规模越大，死链越容易积压——因为没有人会每天去点每一个站的每一个链接。
| 工具 | 类型 | 适合规模 | 优势 | 短板 |
|---|---|---|---|---|
| Xenu Link Sleuth | 桌面软件 | 1-5站 | 免费、操作简单、报告直观 | 只能单站跑、不支持批量、Windows only |
| Screaming Frog | 桌面软件 | 1-10站 | 功能强大、能检查状态码/重定向/canonical | 免费版限500URL、不能批量多站同时跑 |
| 自写Python爬虫 | 脚本 | 任意规模 | 完全可定制、批量多站同时跑 | 需要自己写、需要维护 |
| 在线死链工具 | 网页 | 单站快速查 | 不用安装、即开即用 | 不支持批量、URL数量有限 |
如果手上有5个站以上，建议直接用Python写一个死链批量扫描脚本。核心逻辑不复杂：从sitemap里提取所有URL → 逐个发HEAD请求 → 记录非200的URL → 汇总输出。一个基础版本大概50行代码就能跑起来：
import requestsimport xml.etree.ElementTree as ETfrom concurrent.futures import ThreadPoolExecutordef check_url(url):try:r = requests.head(url, timeout=10, allow_redirects=True)return url, r.status_codeexcept:return url, "FAILED"def scan_site(sitemap_url, site_name):resp = requests.get(sitemap_url)root = ET.fromstring(resp.content)ns = {"sm": "http://www.sitemaps.org/schemas/sitemap/0.9"}urls = [loc.text for loc in root.findall(".//sm:loc", ns)]broken = []with ThreadPoolExecutor(max_workers=10) as pool:for url, status in pool.map(check_url, urls):if status != 200:broken.append((url, status))print(f"{site_name}: {len(broken)}/{len(urls)} broken links")return broken关键点：用HEAD请求代替GET请求，减少带宽消耗；用线程池并发检测，20个站几千个URL几分钟就能跑完。定时跑（比如每周一次），跑完把结果发到钉钉或企业微信群里，比人工抽查可靠得多。
四、结构化数据和性能检测，两个常被忽略的维度
结构化数据（Schema.org标记）直接影响搜索结果里的富媒体展示——评分星星、面包屑导航、FAQ折叠、产品价格。标记写错了或者漏写了，搜索结果就显示成普通文字链接，点击率直接受影响。Google的Rich Results Test和Schema Markup Validator都提供了API，可以批量检测：
# Schema Markup Validator APIfor url in urls:api = f"https://validator.schema.org/validate?url={url}"resp = requests.get(api)print(f"{url}: {resp.json()['totalErrors']} schema errors")性能检测方面，Google Lighthouse是事实标准。它的命令行版本可以批量跑，社区还有一个Lighthouse Batch Reporter工具，把多个URL放进一个配置文件，一次性跑完生成汇总报告：
npm install -g lighthouse-batchlighthouse-batch --sites sites.txt --out results/sites.txt里每行一个URL。跑完后results目录下会生成每个站的HTML报告。虽然做不到实时监控，但作为月度体检足够用了——每月跑一次，对比上月的性能分数变化，哪个站变慢了、哪个站的SEO评分下降了，一目了然。
结构化数据检测要点
检查Article/Product/FAQ/BreadcrumbList等类型标记是否完整；检查JSON-LD格式是否有语法错误；确认关键字段（如price、reviewCount、datePublished）不为空。
Lighthouse关键指标
Performance（性能）、Accessibility（无障碍）、Best Practices（最佳实践）、SEO四个维度，每项0-100分。站群至少保证SEO和Performance两项在80分以上。
容易被遗漏的检查项
meta description是否为空、图片是否有alt属性、h1标签是否存在且唯一、canonical标签是否正确指向、robots meta是否误设了noindex。
五、多站点检测怎么做成自动化流水线
工具和方法都有了，但真正的难点是"持续做"而不是"做一次"。多站点检测的自动化流水线可以这样搭：
第一步：配置站点列表
一个JSON或YAML文件，记录所有需要检测的站点域名和对应检测项目（HTML校验/死链/结构化数据/性能）。
第二步：写一个调度脚本
Python或Node.js脚本，读取站点配置，依次调用各检测工具的API/命令行，汇总结果。
第三步：定时触发
GitHub Actions的schedule触发器或服务器crontab，比如每天凌晨2点跑一次HTML校验，每周一跑一次死链和性能检测。
第四步：异常告警
检测结果超过阈值（如死链超过5条、HTML错误超过10个、性能低于60分）自动推送告警到钉钉/飞书/邮件。
这四个步骤串起来，就是一个简易的多站点代码质量监控系统。投入成本大概是一个下午的脚本编写时间，但收益是持续性的——每多一个站，自动化检测的时间成本基本为零，而人工检测的成本是线性增长的。
| 站点规模 | 推荐检测方案 | 自动化程度 | 月耗时（vs手工） |
|---|---|---|---|
| 1-3站 | Xenu死链 + W3C在线验证 + Lighthouse网页版 | 半自动 | 约2小时（手工约6小时） |
| 4-10站 | Screaming Frog + ESLint/HTMLHint CLI + Lighthouse Batch | 半自动 | 约3小时（手工约15小时） |
| 11-20站 | 自写Python检测脚本 + GitHub Actions定时跑 | 全自动 | 约0.5小时看报告（手工约30小时） |
| 20站以上 | SonarQube + 自建检测流水线 + 建站系统内建检测 | 全自动 | 0小时，异常自动告警 |
20站以上的规模，手工检测已经不可能了——30个小时一个月，将近一周的工作量全用来点鼠标。到这一步要么自己搭检测流水线，要么用建站系统把检测能力内建进去。比如用UC建站系统管理多站点时，模板修改后系统会自动触发HTML规范校验和死链扫描，检测结果汇总在多站看板里，哪个站HTML有错误、哪个站出了死链、哪个站结构化数据不完整，一个页面就能看到，不用逐个站跑工具。新内容发布前自动跑一次代码检测，通过的正常发，有问题的标红退回修改，把"人工抽查"变成"系统兜底"。
六、几个检测出来之后容易纠结的问题
W3C报了几十个错，要不要全修？
不一定。W3C的错误分两类：一类是结构性错误（标签没闭合、属性值缺引号），这类会影响爬虫解析，必须修；另一类是警告（如"section缺少h2-h6标题"），这类影响不大，优先级可以放低。建议先把error修完，warning按优先级排期。
Lighthouse性能评分不到60，怎么定位问题？
打开Lighthouse报告看"Opportunities"部分，它会按节省时间的多少排列优化建议。最常见的问题是图片没压缩、没启用缓存、阻塞渲染的JS/CSS太多。通常修前三个问题就能把分数提到80以上。
死链扫描出了几十个404，怎么处理？
分三类处理：外部链接失效（外链网站挂了）→ 删除或替换链接；内部链接写错URL → 直接修正；已删除的页面被其他页面引用 → 要么恢复页面，要么把引用方链接去掉或做301跳转。
最后说一句
代码批量检测这件事，核心不是"找到工具"，而是"把人工抽检变成自动巡检"。工具到处都是——ESLint、W3C Validator API、Screaming Frog、Lighthouse——单拿出来哪个都好用。但当站点数量超过5个之后，关键问题就从"用什么工具"变成了"怎么不用人盯着"。流水线搭好之后，检测这件事就从"一件需要记得去做的事"变成了"一件自动发生的事"，这才是真正省力气的做法。
如果你现在还在手工逐个站跑检测，建议从最痛的一个维度开始自动化——死链扫描或HTML校验，选一个写个脚本跑起来。感受一下"打开报告发现异常已经标好了"和"花一下午挨个贴URL"的体验差距，后面的事情自然就推得动了。
