假网站排全网第二,真官网翻五页都找不到!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

Flutter for OpenHarmony:Flutter 三方库 gql_link — 掌握鸿蒙端 GraphQL 请求拦截与扩展核心(适配鸿蒙 HarmonyOS Next ohos)

Flutter for OpenHarmony:Flutter 三方库 gql_link — 掌握鸿蒙端 GraphQL 请求拦截与扩展核心(适配鸿蒙 HarmonyOS Next ohos)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net。 Flutter for OpenHarmony:Flutter 三方库 gql_link — 掌握鸿蒙端 GraphQL 请求拦截与扩展核心(适配鸿蒙 HarmonyOS Next ohos) 在现代 App 开发中,GraphQL 的灵活性让我们能精准获取数据。然而,一个健壮的 GraphQL 架构不仅需要发送请求,更需要对请求进行“手术刀”级的拦截、转换和链路编排。例如:统一注入身份 Token、自动日志记录、根据网络状况切换端点等。 在 Flutter for OpenHarmony 开发中,gql_link 库就是这套架构的灵魂所在。它定义了抽象的 Link 通信契约,让我们能像插拔积木一样组合不同的通信能力。今天,

By Ne0inhk
《拆解Linux中的IP协议与数据链路层:地址、路由与分片的底层逻辑》

《拆解Linux中的IP协议与数据链路层:地址、路由与分片的底层逻辑》

前引:在Linux内核的网络子系统中,IP协议承担着“承上启下”的关键职责:向上接收传输层(TCP/UDP)的数据包,为其添加地址与路由信息;向下将数据包交付给链路层(以太网等),完成物理传输的适配。当一个数据包从应用层发出,它会先经过TCP封装,再进入IP层被打上“源IP”“目的IP”的标签,随后通过路由表计算出最优路径,最终通过网卡发送出去。这个过程中,IP地址的分配、路由的选择、数据包的分片与重组,每一个环节都直接影响Linux网络的稳定性与性能。对于运维人员来说,理解IP协议是排查网络丢包、延迟问题的核心;对于开发人员来说,掌握IP协议的细节能让网络程序更适配Linux环境。本文将聚焦Linux场景下IP协议的核心机制,结合实际案例解析其应用与优化思路! 目录 【一】IP协议 【二】报文格式 (1)四位版本号 (2)四位首都长度 (3)8位服务类型 (4)16位总长度 (5)16位标识 (6)3位标识

By Ne0inhk

【零基础】手把手教你在 Mac 上装虚拟机(保姆级教程)

写在前面 想装个虚拟机玩玩,结果一搜教程,满屏的专业术语直接把人劝退。 收藏了一堆"史上最全攻略",结果全在收藏夹里吃灰,从来没打开过。 今天这篇,专门写给完全零基础的朋友。 我们会在 Mac(M系列芯片) 上,从零开始搭建一台运行 Kali Linux 的虚拟机。 不用怕,跟着我一步步来,能复制粘贴就能装好。 先搞懂三个东西: 在动手之前,花1分钟搞清楚这三个概念,后面就不会懵: 名词大白话解释VMware Fusion一个"电脑模拟器"。它能在你的 Mac 里虚拟出一台独立的电脑,互不干扰。Kali Linux一个专门用来学习网络安全的 Linux 系统,里面预装了很多安全工具,黑客电影里常出现的那种界面。ARM 架构苹果 M 系列芯片(M1/M2/M3/M4)

By Ne0inhk

Flutter 三方库 stash_hive 的鸿蒙化适配指南 - 在鸿蒙系统上构建极致、全能、全功能的非关系型数据库缓存与跨平台持久化存储引擎

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 stash_hive 的鸿蒙化适配指南 - 在鸿蒙系统上构建极致、全能、全功能的非关系型数据库缓存与跨平台持久化存储引擎 在鸿蒙(OpenHarmony)系统的端侧高性能存储、动态离线缓存、或者是针对海量 KV 数据的高速存取中,如何结合 Hive 这类卓越的非关系型数据库实现一套统一的、具备过期策略(Expiry)且完全透明的缓存 API?stash_hive 为开发者提供了一套工业级的、基于 Stash 抽象层的 Hive 存储扩展方案。本文将深入实战其在鸿蒙端深度持久化中的应用。 前言 什么是 Stash Hive?它不仅是简单的 Hive 封装,而是一个将“缓存原语(Caching Primitives)”与“Hive

By Ne0inhk