我用 Vibe Code 做出了漂亮的 Web 应用,但 AI 依然无法为 Google Search 自动生成一个简单的 Sitemap


我用 Vibe Code 做出了漂亮的 Web 应用,但 AI 依然无法为 Google Search 自动生成一个简单的 Sitemap

在最近一段时间里,我看到很多开发者和创业者开始用 AI 工具做网站、Web 应用这些东西,比如所谓的 vibe coding 平台:快速生成页面、美观的前端、自动部署等等。乍一看体验很棒,但当你开始关注 SEO 和搜索引擎索引时,这一切就变得很不那么简单了。

我自己做过很多网站的 SEO,这本应该是个“十分钟搞定”的事儿 —— “生成 sitemap.xml,提交到 Google Search Console,搞定。” 但是在实际操作中,问题远比想象复杂。


项目背景

我做的第一个项目是一个在线餐厅目录:收集了所有提供食物过敏菜单的餐厅信息,供过敏患者快速查询。这个目录在本地运行良好,页面内容齐全,理应被搜索引擎收录。

可当我想让 Google 开始索引这些页面时,我遇见了 Sitemap 和 AI 的真实一面。


问题一:本地有效、部署后失效

在本地测试时,生成的 sitemap 路由是正常的。但当部署到线上环境后,这个路由却失效了。即便我多次用各种提示词让 AI 去修复它,还是不断出现问题,直到我花掉了大量的 Lovable 服务积分才修复过来。


问题二:错误的域名

你可能以为 sitemap 只要能访问就行,但 Google 有非常明确的规则:Sitemap 必须与主站点域名一致,才能被 Search Console 接受。 最开始我的 sitemap 出现在了一个随机的 AI 生成域名下,这导致它被直接拒绝。


问题三:动态页面无法更新 sitemap

即便问题解决了,新的餐厅被添加时,sitemap 并不会更新。这意味着即使有新页面存在,它们也不会出现在 sitemap 里,搜索引擎也就无法正确索引它们。


问题四:React 路由与 Headers 混战

这才是真正“让人发疯”的地方:

大多数基于 React 的单页应用默认返回的其实是 HTML 内容,而不是标准的 XML。由于这种种原因 —— 比如路由、响应头错误等 —— sitemap 的响应其实被包装成了 HTML,而不是 Sitemap 规范里要求的纯 XML。即使浏览器看起来没问题,Google 还是会拒绝。

这一切让我白白浪费了大约 25–30% 的 AI 信用额度,只为实现一个原则上非常基础的网页索引功能。


最后奏效的解决方案

直到我放弃了现代 SPA 栈的思路,靠纯技术老方法反而解决了问题:

✅ 方案一:放弃 XML,改用 TXT

Google 官方文档说明:除了 XML,谷歌也支持 TXT 格式的 sitemap,只要里面列出你想让它抓取的 URL 即可。TXT 方案不需要 XML 解析,也不会因为响应头或路由被拒绝。

✅ 方案二:把它做成静态文件

不要任何动态路由,也不要 React 去拦截它,把 sitemap.txt 当成普通的静态资源放在网站根目录下:

https://www.example.com/sitemap.txt 

然后在 Search Console 提交它。Google 立刻就接受了。


静态 vs 动态:如何保持 sitemap 更新

静态文件固然简单,但每次有新页面加入的时候,它必须被重新生成。最终我写了一个钩子,在每次新增内容时自动更新 sitemap.txt,这才真正实现了:

静态交付 + 动态更新 = 可被搜索引擎索引的 sitemap

总结:AI 能做很多事情,但 SEO 仍需人工

即便现在有很多所谓的 AI 构建平台能快速帮你做 Web 应用和前端交互,但在 SEO、搜索引擎索引 机制 这样的细节上,它们依然表现得非常粗糙。AI 生成代码固然方便,但它并不能完全替代开发者对底层原理的理解。

如果你想让自己的网站被 Google 真正收录、被用户检索到,还是需要对 Sitemap、域名策略、响应头、内容更新策略等有深入控制。 AI 只是帮你提高速度,不是替代专业。


Read more

Ubuntu/Debian VPS 上 Apache Web 服务器的完整配置教程

Apache 是互联网上最流行的 Web 服务器之一,用于托管超过半数活跃网站。尽管市面上存在许多可用的 Web 服务器,但由于 Apache 的普遍性,了解其工作原理仍然具有重要意义。 本文将分享 Apache 的通用配置文件及其可配置选项。文中将以 Ubuntu/Debian 系统的 Apache 文件布局为例进行说明,这种布局方式与其他 Linux 发行版的配置层级结构有所不同。 版本兼容性 说明 :本教程已在 Ubuntu 22.04 LTS、Ubuntu 24.04 LTS、Ubuntu 25.04 以及 Debian 11、Debian 12 系统上通过验证测试。所有展示的命令和配置均兼容上述版本,且 Apache 配置结构与命令(如 a2ensite、

前端存储三剑客:localStorage、sessionStorage、cookie 超详细对比

前端存储三剑客:localStorage、sessionStorage、cookie 超详细对比

在前端开发中,数据本地存储是提升用户体验、优化性能、实现持久化状态的核心技术。我们最常用的就是 localStorage、sessionStorage 和 cookie 这三种方案,但很多开发者容易混淆它们的用法、存储特性和适用场景。 这篇博客就用最清晰、最实用的方式,一次性讲透三者的区别、用法和最佳实践。 一、先搞懂核心概念 * cookie:最早的客户端存储方案,会随 HTTP 请求自动发送到服务器,主要用于身份验证、会话保持。 * localStorage:HTML5 新增的本地存储,持久化存储,手动清除才会消失,不参与网络请求。 * sessionStorage:HTML5 新增的会话存储,页面会话期间有效,关闭标签页 / 浏览器就清空。 二、核心区别一张表看懂 表格 特性localStoragesessionStoragecookie生命周期永久有效,手动清除仅当前会话(关闭标签 / 浏览器失效)可设置过期时间,默认会话级存储容量约 5MB约 5MB很小,仅 4KB与服务端通信不参与不参与自动携带在

Qwen3-1.7B支持流式响应?实战验证与前端集成教程

Qwen3-1.7B支持流式响应?实战验证与前端集成教程 最近在折腾大模型应用开发,特别是想给前端加个实时聊天的效果,就一直在找支持流式输出的轻量级模型。Qwen3系列开源后,我第一时间注意到了1.7B这个版本——参数小,部署快,但官方文档里关于流式响应的说明不太详细。 所以,我决定自己动手验证一下:Qwen3-1.7B到底支不支持流式响应?如果支持,怎么在前端项目里用起来?这篇文章就是我的实战记录,从环境搭建、接口测试到前端集成,一步步带你走通整个流程。 1. 环境准备与快速启动 要在本地或者云端快速体验Qwen3-1.7B,最省事的方法就是直接用现成的Docker镜像。这里我以ZEEKLOG星图平台的镜像为例,带你快速启动一个可用的环境。 1.1 启动Jupyter Notebook环境 1. 找到Qwen3-1.7B的镜像并启动。平台通常会提供一个预装好所有依赖的容器。 2. 容器启动后,直接打开提供的Jupyter Notebook链接。你会看到一个熟悉的网页界面,里面已经配置好了Python环境和必要的库。 这样,我们就不用操心安装PyTorch、Tran

0基础转行网络安全,选择pwn还是web?零基础入门到精通,收藏这一篇就够了

0基础转行网络安全,选择pwn还是web?零基础入门到精通,收藏这一篇就够了

随着5G、工业互联网、人工智能等新兴领域技术的兴起,从而快速推动了各国从人人互联迈向万物互联的时代。 奇安信董事长齐向东曾说过:“如果说5G带来了物联网和人工智能的风口,那么网络安全行业就是风口的平方——风口的风口。" 因此,有不少年轻人纷纷想加入网络安全行业,抢占先机。 但由于网络安全行业的岗位很多,例如:信息安全工程师、渗透测试工程师、应急响应、逆向安全、溯源取证、安全架构师、恶意软件分析师等等,导致很多人不知道从哪个方向学起。 下面盾叔凭借自己入行十几年的经验给大家详细说说: 其实,对于学习网络安全的学者们,建议从web安全学起。为什么这么说呢? 首先,web安全相对于整个网络安全行业来说难度是相对比较低的,学起来更加容易入手。虽然渗透测试工程师、溯源取证、红蓝攻防等等这些岗位看起来很不错,但是技术门槛特别高,对于0基础的人来说学起来会相当吃力。所以,web安全方向对于初学者来说是最好入门选择。 现阶段,爆发安全问题最多的就是web安全,大部分攻击都是从web安全入手的。例如:内网渗透、工控安全都要依托于web安全。因此,web安全在整个网络攻击中起着特别关键的作用