Mueller最近公开分享了自己亲身使用Vibe Coding（AI辅助编程）建站的经历，并给出了一个精准的比喻：用模糊的AI指令要求SEO，就像对一个不懂SEO的开发者说”加点SEO进去”一样——他不知道你在说什么。
模糊指令带来模糊结果
Mueller的核心发现很直接：AI工具能够快速生成功能性网站，但”生成功能性网站”和”生成SEO友好的网站”是两件不同的事。
当你对AI说”帮我建一个网站”，它会根据自己的训练数据做出各种架构决策：选择什么技术栈（静态站点生成器、客户端渲染框架还是数据库驱动的CMS）、如何处理路由、如何生成URL结构……
这些决策对SEO有直接影响，但AI默认情况下不会把SEO优化作为优先考量——除非你明确告诉它。
Mueller的实践方法
Mueller分享了自己如何在Vibe Coding中获得更好SEO结果的方法：从一开始就提供明确的技术规格，而不是在网站建好后再说”加点SEO”。
他的具体实践包括：
预先指定技术架构：Mueller选择了Hugo（静态站点生成器）+ GitHub版本控制 + Firebase托管。这个组合在爬取速度、页面加载时间和技术可控性上都有优势。
明确要求SEO基础配置：
- 域名配置
- Canonical标签设置
- Sitemap生成
- robots.txt文件
设置发布前验证流程：确保URL返回正确的内容，确认JavaScript文件没有被错误地屏蔽爬虫访问。
他的工具选择也值得注意：Mueller从VS Code + Copilot迁移到了命令行工具，具体使用Claude Code和Gemini CLI——他认为命令行工具给了他更精确的控制。
Splitt的JavaScript教训
Google的另一位工程师Martin Splitt也分享了类似的测试经历，但侧重在JavaScript框架的问题上。
Splitt在Google AI Studio测试了客户端JavaScript应用的生成。输出结果表面上看起来像标准的Next.js代码，但他花了大量时间试图阻止AI自动引入他不想要的库——AI有自己的”习惯偏好”，而这些偏好不一定对你的SEO友好。
从SEO的角度看，客户端渲染（CSR）框架有一个已知风险：如果爬虫无法正确执行JavaScript，内容就无法被索引。这需要开发者主动配置服务端渲染（SSR）或预渲染——而AI默认生成的代码不会主动考虑这一点。
为什么技术背景仍然不可替代
两位专家的经历指向同一个结论：AI工具是执行者，不是决策者。
在建站过程中，存在大量需要专业判断的架构决策点：
- 选静态站点生成器还是动态框架？（对爬取速度、CDN友好性的影响不同）
- Core Web Vitals如何在当前架构下优化？
- 如何处理多语言、分页、参数URL的canonical设置？
- JavaScript依赖如何影响爬虫可访问性？
这些问题，AI会做出某种选择——但它不知道你的具体业务场景、目标搜索引擎的算法偏好，以及你愿意在技术复杂度和SEO效果之间如何取舍。
没有技术SEO背景的人，可能根本不知道AI的默认选择带来了问题，直到网站上线后发现流量不如预期。
内容生成的根本性问题
Mueller还触及了一个更深的问题：AI可以生成网站内容，但这引出了一个根本性的问题——如果AI已经能告诉用户答案，用户为什么还要访问一个AI生成内容的网站？
这不是技术问题，而是价值主张问题。
在AI大量生产内容的环境下，真正有价值的网站内容需要具备AI无法轻易复制的东西：原创研究、第一手数据、真实案例、独到观点，以及与特定受众建立的信任关系。
Vibe Coding降低了”有一个网站”的门槛，但它同时也提高了”有一个值得访问的网站”的要求。
实践建议
如果你打算用AI工具辅助建站，这几点可以让结果更接近SEO友好：
建站前：写清楚技术规格文档，包括你的SEO要求清单（Canonical、Sitemap、robots.txt、结构化数据、页面速度目标）。
建站中：不要用”加点SEO”这样的模糊指令。用具体问题驱动：”这个页面的canonical标签是如何设置的？””sitemap是否包含所有需要被索引的URL？”
建站后：用Search Console验证索引状态，用PageSpeed Insights检查Core Web Vitals，检查robots.txt和sitemap是否配置正确。
AI加速了建站过程，但SEO审查的责任没有因此消失——它只是从开发环节转移到了验证环节。
原文：Google’s Mueller: Vibe Coding Won’t Handle Your SEO For You @ Search Engine Journal
微信扫一扫 或 点击链接联系我