一个HTTP请求误判200网站：浏览器+LLM管道如何逆袭

用一条HTTP请求去判断200个本地商家网站是否真的属于某地服务商，听起来是个轻量级方案。但Nearbia团队的实际测试证明，这个简单方法会漏掉三成以上的死站和大量营销站点。他们最终转向了浏览器渲染加本地LLM分类的管道，把准确率拉回可用水平。以下是完整的踩坑记录与数据。

rss source: Why One HTTP Request Misjudged 200 Business Websites, and the Browser + LLM Pipeline That Replaced I

输入：8个来源，200个域名

候选域名来自5个免费源和3个付费源。免费源包括Overture Maps、Foursquare、OpenStreetMap、AllThePlaces以及佛罗里达州执照记录；付费源则是Google商业列表、Google Maps和Google自然搜索结果。

筛选规则以地理边界为准：只要至少一个来源把域名标记在圣彼得堡市界内（采用美国人口普查局TIGERweb的Places图层），或距离边界3公里以内，就保留。最终有92个域名在城内，90个在Gulfport、Kenneth City等紧邻区域，17个仅来自自然搜索且无坐标，1个只有邮政城市信息。

来源覆盖各有缺失：30个域名仅来自Foursquare，21个仅来自Overture，17个仅来自Google自然结果。该切片所有Google查询总花费约0.18美元。

第一版：一条HTTP请求打天下

初版方案很省资源：向每个首页发送一次请求，截取前400KB原始HTML，搜索城市名和水管相关词汇。结果双向翻车。

它拒绝了真正的商家：用JavaScript渲染内容的站点、只在联系页放地址的站点、以及写“Tampa Bay”而非具体城市名的站点。

它又放过了错误目标：引流站和目录站会在页面里反复堆砌城市名；停放域名和服务器占位页被误判为活站。

与真实浏览器对比，快速检查把死域名少算了9个（27对36），并放行了6个引流域名。2026年10月1日之后，这个检查器被降级为只报告域名是否响应，不再参与判定。

检查器跑在哪里同样关键

从荷兰的计算机发起检查，200个站中有47个无响应。但从美国IP重试，这47个里有15个立即加载成功。此后所有检查都从美国节点执行。

为什么“一条 HTTP 请求”会天然失效？

用 requests 或 curl 抓取的只是服务器返回的原始 HTML，它不执行页面里的 JavaScript。现代商家站点大量依赖前端框架（React、Vue、Wix、Squarespace 等）或第三方组件，地址、电话、营业时间常常是脚本运行后才注入 DOM 的。爬虫拿到的那 400KB 里，城市名根本还没出现，于是被误判为“无关站点”。

另一面则是“假阳性”：SEO 引流站、目录聚合页会把“St. Petersburg plumber”这类关键词堆满标题和正文，静态文本匹配很容易上当；停放域名（parking page）和主机商的默认占位页虽然返回 HTTP 200，却没有任何真实业务内容。

浏览器渲染（headless Chrome）之所以关键，是因为它模拟了真实用户看到的最终 DOM，同时暴露网络请求、重定向链和页面存活状态，这才能把“响应”和“有真实内容”区分开。

地理 IP 为何会改变可用性判断？

同一域名从荷兰请求失败、从美国请求成功，通常不是网络抖动，而是三种情况的叠加：

CDN 与边缘节点策略——Cloudflare、Akamai 等会根据来源 IP 的地区分配不同节点，部分地区可能被限速或触发质询。
地域性 bot 防护——许多美国主机商对非本土流量默认更严格，返回 403、429 或 JS challenge 页面，看起来就像站点“挂了”。
本地化内容与 DNS 解析——部分站点按访问者地理位置返回不同页面，甚至解析到不同的源站 IP。

这意味着任何以“站点是否存活”为输入的管道，都必须把探测节点固定在目标市场所在地，否则会把可正常访问的本地商家误判为死站，直接污染后续的语料库。

第二版：渲染、标注、验证、定位

新管道分四步：

渲染。 每个活站首页在普通Chrome中加载并启用JavaScript，5个浏览器并行。171个有响应的首页耗时约40分钟。
标注。 部署在Nearbia自有服务器上的语言模型读取每个捕获页面，分配一种站点类型：本地公司自有站、连锁分店页、全国连锁、目录站、引流站、无关站点或死站。
验证。 模型必须引用页面原文来支撑其标注，代码会确认每个引用确实出现在页面中。置信度低于0.6的标注转交人工。
定位。 商家是否本地化不作为模型职责。代码根据站点上找到的证据决定。

“先标注、再定位”的架构为什么要拆成两步？

让语言模型同时回答“这是什么类型的站点”和“它在哪个城市”，看似省事，实则不可靠：LLM 对“地理位置”的判断极易被页面里提到的其他城市、连锁品牌总部、甚至广告内容带偏，而这恰恰是最不能出错的一环。

拆开之后，模型只负责它擅长的语义分类——这是本地自有站、连锁分店页、目录站还是引流站；位置判定交给确定性代码，按电话、邮编、城市名与州名组合逐级校验。这种“模型做感知、代码做判定”的分工，使每一处位置证据都可被复核和解释，避免了把幻觉直接写进目录。

验证环节也服务于同一目标：模型必须引用原文句子，代码检查该句子确实存在于页面中。引用不匹配或置信度低于 0.6 就转人工，相当于给自动化流程加了一道可审计的闸门。

位置证据的优先级排序

代码先读首页，找不到时再打开最多两个页面：联系页、服务区域页或连锁店的本地页。

证据强度从高到低：

优先级	信号	细节
1	站点电话与来源为该域名记录的电话匹配	来源记录本身已在城内；忽略8xx免费电话，因为连锁店各地共用
2	地址或结构化数据中的区域邮编	33701至33716、33730至33747、33781、33782
3	与“FL”或“Florida”相邻区域的城市名	州名强制校验：Gulfport在密西西比也有，田纳西有个Petersburg
弱	仅区域名（Pinellas、Tampa Bay）或仅727区号	不足以进入语料库

合并三个重复项前，91个站点有位置证据。最强信号是58个电话匹配，19个城市加州匹配，14个邮编匹配。这91个中有10个是连锁品牌的本地页面。

为什么电话号码被视为最强信号？

电话（尤其是本地固话或与来源数据库完全一致的号码）几乎无法被引流站和目录站伪造——它们通常只列全国客服或 8xx 号码，而 8xx 因连锁店各地共用被明确排除。相比之下，城市名和邮编写在页面上成本极低，SEO 站点会主动堆砌，可信度自然更低。

“城市名 + 州名”的组合则是为了解决地名歧义：Gulfport 在密西西比州也存在，Petersburg 在田纳西州同样有，只匹配城市名会直接引入错误。强制要求城市名与“FL”或“Florida”相邻出现，本质上是要求页面自身给出足以消歧的地理上下文。

优先级表的意义在于：它把模糊的“看起来像本地商家”转化为可排序、可审计的规则，只有通过最高等级证据的域名才进入语料库，从而把 200 个候选收敛到 88 个高置信度目标。

200个域名的最终分类（2026年10月1日快照）

分组	域名数
有位置证据的本地水管工	88
仅区域信息的本地水管工	10
无位置证据的本地水管工	7
其他行业本地商家（暖通、家电维修）	13
全国连锁与品牌	3
目录站与引流站	17
非家庭服务	16
重定向到列表内其他域名的重复项	4
即使真实浏览器也被机器人防护拦截	6
死站、停放或DNS无解析	36
总计	200

88个域名构成语料库，只有它们进入全量爬取和事实提取。其中45个位于市界内，38个在边界3公里以内。

数据本身的三类错误

本地记录上的错误网站。 五个与圣彼得堡关联的域名实际属于科罗拉多、爱达荷、密西西比、布劳沃德县和佛罗里达州奥兰治市的水管工。没有站点自身的证据，它们会进入目录。

起始数据库的盲区。 语料库中45个城内水管工有21个未被初始数据库收录。仅Google就发现了这45个中的11个。

编造行业。 模型有一次把一家下水道管道衬砌公司标为窗户清洁。这就是“其他行业”分组必须人工复核的原因。

已知限制

这仅是2026年10月1日的单次快照。网站会变化，死域名可能复活。

检查只读首页加最多两个内页。如果水管工只在更深层页面标注服务区域，就会落入“仅区域”或“无位置证据”组，这17个域名仍需人工审核。

只覆盖已知网站的商家。佛罗里达记录列出93个圣彼得堡地址的活跃水管执照；其中69个没有已知域名，有些根本没有网站。

如何确认一个网站确实属于某地的某商家？欢迎分享你依赖的信号。

本文基于Nearbia原始现场笔记，在AI辅助下撰写；所有数字均来自这些笔记。