假网站排全网第二,真官网翻五页都找不到!NanoClaw创始人破防:SEO之战,我快要输了

假网站排全网第二,真官网翻五页都找不到!NanoClaw创始人破防:SEO之战,我快要输了

整理 | 苏宓

出品 | ZEEKLOG(ID:ZEEKLOGnews)

自从 OpenClaw 爆火之后,各种“Claw”项目接连出现,其中以安全优化版 NanoClaw 最为知名。它的核心代码仅有 4000 行,却获得了 AI 大牛 Andrej Karpathy 的点赞。

可谁也没想到,这款口碑极佳的开源项目,近来竟被一个仿冒网站抢了风头。

投诉无门之下,NanoClaw 创始人 Gavriel Cohen 在 X 社交平台上无奈发文怒斥:谷歌搜索错误地将假网站排在真官网前面,不仅破坏了项目声誉,还埋下了严重的安全隐患,而他费尽心力,却只能哀叹一句——“我正在为自己的开源项目打 SEO 战,但我快要输了。”

那么,NanoClaw 究竟发生了什么?又是怎么走红的?事情还要从 OpenClaw 说起。

OpenClaw 爆火引发安全争议,NanoClaw 凭“极简安全”出圈

被开发者亲切称为“小龙虾”的 OpenClaw,是 2026 年初 AI 领域最具话题性的开源项目之一。它可以让大语言模型连接各种软件工具,自动完成邮件处理、日程安排、数据整理等任务,一上线便迅速走红,其在 GitHub 上的 Star 超越了 Linux、React 等老牌开源项目。

但与此同时,它也因为架构和权限设计问题,被不少安全研究者视为潜在风险源。OpenClaw 的代码规模高达 40 万行,几乎没有人能够完整审计整套系统,而其裸机运行的模式又让权限控制变得非常薄弱。此前,曾在 Meta 超级智能实验室从事 AI 安全研究的专家 Summer Yue 就公开提到,自己在测试 OpenClaw 时遭遇失控情况,导致工作邮箱被清空。与此同时,也有开发者报告过信息泄露、设备被植入恶意程序等问题,一些科技公司因此对该工具持谨慎态度。

正是在这样的背景下,以色列软件工程师 Gavriel Cohen 推出了 NanoClaw(https://github.com/qwibitai/nanoclaw)。这个项目被不少人视为 OpenClaw 的“安全版本”。与前者庞大的代码体系不同,NanoClaw 走的是极简路线,核心代码只有约 4000 行。

更重要的是,它从架构上强化了安全边界。NanoClaw 默认让每个 AI 智能体运行在独立容器中,通过严格的环境隔离限制权限范围。同时,NanoClaw 刻意避免堆叠复杂功能,而是依托 Anthropic 的 Agent SDK 构建核心能力,使整个系统更加轻量和可控。

这种“少即是多”的设计思路,让 NanoClaw 在发布之初就吸引了大量关注。 2 月 2 日上线后,很快在 GitHub 上收获 19,400 颗 star。

专注开发,却被仿冒网站“抢先认领”

随着 NanoClaw 的关注度不断攀升,创始人 Gavriel Cohen 把几乎全部精力都投入到了项目的 GitHub 代码库开发中。

在开源世界里,这其实很常见。许多开发者在项目初期都会把 GitHub 仓库当作唯一的官方入口,并不会急着搭建独立官网。NanoClaw 走红后,Gavriel Cohen 也一直把时间花在功能开发、合并社区 PR、维护用户讨论上,完全没意识到,一场“身份冒用”已经悄悄发生。

事情发生在 NanoClaw 发布仅 6 天后的 2 月 8 日,有人抢先注册了域名 nanoclaw.net。对方直接从 NanoClaw 的 GitHub README 抓取内容,自动生成了一个简易网站,更令人无语的是,此网站也链接到了 Gavriel Cohen 所构建的 NanoClaw GitHub 仓库页面。

起初,Gavriel Cohen 本人并不知情。随着 NanoClaw 的知名度不断扩大,开始有人跟他提起这个网站的存在。但当时的 Gavriel Cohen 太忙了,只顾埋头写代码,没太在意。

后来,越来越多用户给 Gavriel Cohen 发消息:有人问“官网的信息怎么有错误?”;有人吐槽“网站全是广告,手机端几乎没法看”;还有人疑惑,“官方页面为什么做得这么粗糙?”

直到这时,Cohen 才意识到问题的严重性——成千上万的用户已经把这个仿冒网站当成了 NanoClaw 的官方页面。每天都有大量人通过它了解项目,而他们对 NanoClaw 的第一印象,却是一堆广告、错误信息和粗糙页面。

“可那根本不是我的网站。我当时根本没有官网。”Gavriel Cohen 说道。

努力:做尽 SEO 优化仍无济于事,假网站稳居搜索前列

眼看项目口碑不断被仿冒网站消耗,Gavriel Cohen 很快行动起来。

他花时间搭建了 NanoClaw 的真正官方网站 nanoclaw.dev,随后开始一系列“正名行动”,几乎把所有常见的 SEO 手段都试了一遍。

  • 他在 GitHub 仓库里加上官网链接;
  • 做了规范的 SEO;
  • 添加结构化数据;
  • 向 Google Search Console 提交了大概 15 次;
  • NanoClaw 又被 The Register、VentureBeat、The New Stack 报道,而且都链接到了真实网站;
  • 其本人又发了一篇博客,在 Hacker News 上冲到 #1;
  • 把网站翻译成 15 种语言;
  • 所有社交媒体账号都指向 nanoclaw.dev;
  • 最后,他还向 Google、Cloudflare 和域名注册商 spaceship.com 提交了“假的 nanoclaw 网站”的下架通知。

简单来说,互联网上几乎所有能够证明“官方身份”的信号,都已经清晰地指向 nanoclaw.dev。

然而,让 Cohen 崩溃的是,搜索结果始终没有变化:当用户在 Google 搜索“NanoClaw”时,排名第一的依然是项目的 GitHub 仓库,第二名仍然是仿冒网站 nanoclaw.net,而真正的官方网站甚至在搜索结果前五页都找不到。

更离谱的是,在 GitHub 仓库页面的 “Website” 字段中,官方地址已经明确写着 nanoclaw.dev。换句话说,项目本身已经清清楚楚地告诉搜索引擎哪个才是官网,但搜索结果却依旧把仿冒网站放在更显眼的位置。

而这个假网站不仅页面粗糙、广告密布,还展示着关于 NanoClaw 的错误信息,甚至篡改了项目发布时间,持续误导着每一个搜索该项目的用户。

创始人:不愿为 SEO 耗费精力,更忧假网站藏安全大患

Cohen 直言道,“这不是 SEO 问题。这是 Google 的问题。”

有 SEO 专家给 Gavriel Cohen 支招,让他投放 Google Ads、持续优化网页 meta 标签、做外链,通过“硬刚”打败仿冒网站,但这个建议被他直接拒绝。

在 Gavriel Cohen 看来,他做 NanoClaw 的初衷是开发开源软件,本该沉浸在终端和 Discord 社区里,和开发者一起写代码、推功能、修 bug,而不是把宝贵的时间和精力,耗费在毫无意义的 SEO 博弈中。

“我不是来打 SEO 战的,我想做的是开源软件。”他的话,道出了无数开源开发者的心声。

比被迫卷入 SEO 战更让他忧心的,是仿冒网站背后的巨大安全风险。

要知道,NanoClaw 的核心设计理念就是“安全第一”,容器化隔离、沙箱机制的所有设计,都是为了让 AI 智能体的运行更安全,避免出现像 OpenClaw 那样的安全事故。

但如今,谷歌搜索的错误排序,却让 NanoClaw 陷入了全新的、更致命的安全危机。

Gavriel Cohen 表示:

「运营仿冒网站的人,随时可以在页面上放置加密货币骗局、钓鱼链接、恶意下载地址,甚至可以 fork NanoClaw 的 GitHub 仓库,注入恶意代码后,再通过这个被谷歌“认证”的仿冒网站传播。

Google 会照样把它展示给所有搜索我项目的人。

这是一个正在发生、真实存在的安全风险,而 Google 正在放大它。」

更让他无奈的是,即便未来他拼尽全力赢下这场 SEO 战,把仿冒网站挤下搜索高位,造成的损害也无法挽回。“到那时,已经有几十万用户访问过那个网站。已经看过错误信息。已经形成错误印象。已经把我的项目和一个垃圾、破碎的体验绑定在一起。这无法撤回。而且它每存在一天,损害就在扩大。”

质疑:谷歌连官网都认不出,其信息权威性何在?

这场假网站截胡的闹剧,不仅让 Gavriel Cohen 感到愤怒和无奈,更让他对谷歌搜索的权威性提出了强烈质疑。

他在长文中写道:

如果 Google 连一个开源项目的官网都判断不出来——在项目本身已经“高声喊出答案”的情况下——那我们还能信任它回答其他问题吗?

我们依赖 Google 去呈现关于选举、疫苗、医疗状况、金融决策的可靠信息。而这样一个答案毫无歧义、所有信号一致、权威来源明确声明真相的问题,它却判断错误?

我不想玩这个游戏。我想写代码、做社区、推功能、修 bug。

我们也许该停止责怪自己。别再纠结 meta 标签是否完美,favicon 格式是否正确。当 Google 拥有大量清晰、明确的信号却依然判断错误,那不是我们的问题。

那是 Google 的问题。

如果 Google 想继续保持自己作为互联网信息入口的地位,它至少应该把这种事情做对。

目前,Gavriel Cohen 仍在为 NanoClaw 的官方身份正名,他也再次向所有用户发出提醒:nanoclaw.net 并非 NanoClaw 的官方网站,真正的官方入口是nanoclaw.dev,项目的核心 GitHub 仓库地址为:github.com/qwibitai/nanoclaw 。

而这场开源开发者与假网站、与谷歌搜索的博弈,还在继续。

来源:

https://x.com/Gavriel_Cohen/status/2028821432759717930

https://github.com/qwibitai/nanoclaw

推荐阅读:

48小时“烧光”56万!三人创业团队濒临破产,仅因Gemini API密钥被盗:“AI账单远超我们的银行余额”

万人大厂一夜裁员4000+人!她拼命用AI提效,却在凌晨12:30等来解雇通知

岗位一朝被Meta砍掉,工程师转头训练小狗敲键盘,竟靠Claude把乱码做成了游戏,还开源了!

未来没有前后端,只有 AI Agent 工程师。

这场十倍速的变革已至,你的下一步在哪?

4 月 17-18 日,由 ZEEKLOG 与奇点智能研究院联合主办「2026 奇点智能技术大会」将在上海隆重召开,大会聚焦 Agent 系统、世界模型、AI 原生研发等 12 大前沿专题,为你绘制通往未来的认知地图。

成为时代的见证者,更要成为时代的先行者。

奇点智能技术大会上海站,我们不见不散!

Read more

Spring MVC请求处理流程源码分析与DispatcherServlet核心逻辑

Spring MVC请求处理流程源码分析与DispatcherServlet核心逻辑

目录 🎯 先说说我遇到过的真实问题 ✨ 摘要 1. 从Tomcat到DispatcherServlet:请求的"奇幻漂流" 1.1 请求是怎么到你Controller的? 1.2 DispatcherServlet的初始化:不是你想的那样简单 2. 请求处理九大步:DispatcherServlet的"工作流程" 2.1 doDispatch方法:Spring MVC的心脏 2.2 九步流程详解:每个步骤都有坑 🚨 步骤1:Multipart检查 🚨 步骤2:获取Handler 3. HandlerMapping:请求的"导航系统" 3.1 四种HandlerMapping的区别 3.2 RequestMappingHandlerMapping的匹配算法 3.3 路径匹配的性能优化

By Ne0inhk
数字身份的通行证:深入解析单点登录(SSO)的架构与艺术

数字身份的通行证:深入解析单点登录(SSO)的架构与艺术

文章目录 * 概述 * 一、什么是单点登录(SSO)? * 二、SSO 的核心价值:为何它如此重要? * 三、SSO 的基本工作原理:一次认证,处处通行 * 场景一:首次登录应用 A * 场景二:访问应用 B(无感登录) * 四、SSO 的通用语言:常见协议与标准 * 五、SSO 架构的两种主流形态 * 1. **中心化 SSO** * 2. **联邦身份** * 六、安全:SSO 的生命线 * 七、典型应用场景:SSO 在哪里发光? * 八、快速上手:从理论到实践 * 九、常见误区澄清 * 总结 概述 在数字世界日益碎片化的今天,我们每个人都在无数应用和服务之间穿梭,

By Ne0inhk
Rust异步编程实战:构建高性能网络应用

Rust异步编程实战:构建高性能网络应用

Rust异步编程实战:构建高性能网络应用 一、异步编程概述 1.1 同步vs异步的区别 💡在传统的同步编程中,代码按照顺序执行,每个操作必须等待前一个完成才能继续。例如,发送网络请求时,主线程会阻塞直到响应返回,这种方式简单直观,但在高并发场景下效率低下,因为大量线程会因阻塞而闲置。 异步编程则允许代码在等待操作完成时继续执行其他任务。当一个异步操作开始后,程序会立即返回并继续处理下一个任务,直到该操作完成后通过回调或事件通知继续执行后续代码。这种方式显著提高了CPU利用率和系统的并发处理能力。 1.2 Rust异步编程的演进 Rust的异步编程经历了几个重要阶段: * 早期阶段:依赖futures库提供基础的Future和Executor支持,但语法冗长且难以使用。 * 2018 Edition:引入了async/await语法糖的实验版本,简化了异步代码的编写。 * 2021 Edition:async/await正式稳定,成为Rust异步编程的标准范式。 * 生态成熟:Tokio、async-std等异步运行时库的发展,以及大量异步IO库的出现,使Rus

By Ne0inhk

Flutter 三方库 inject_annotation 的鸿蒙化适配指南 - 在鸿蒙系统上构建极致、严谨的编译期依赖注入架构实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 inject_annotation 的鸿蒙化适配指南 - 在鸿蒙系统上构建极致、严谨的编译期依赖注入架构实战 在鸿蒙(OpenHarmony)系统开发大型、复杂的企业级应用时,如何优雅地解耦各个业务模块?传统的构造函数注入往往会导致代码冗长且难以维护。inject_annotation 为鸿蒙开发者提供了一套基于编译期生成的、零反射的依赖注入(Dependency Injection)方案。本文将带您深入实战其在鸿蒙生态中的应用。 前言 什么是依赖注入?它是一种控制反转(IoC)的实现方式,旨在将对象的创建与使用分离。与运行时反射注入不同,inject_annotation 借鉴了 Java 端 Dagger 的设计思想,在编译阶段就生成了所有的注入代码。在注重性能和确定性的鸿蒙系统开发中,这种“预编译”的 DI 方案能大幅降低运行期开销,并显著提升代码的健壮性。 一、

By Ne0inhk