AngularJS SEO 百度收录难题的实战解法
为什么 AngularJS 站点常在百度里"隐身"
很多团队用 AngularJS 做完一个界面漂亮、交互流畅的单页应用（SPA），却发现一个尴尬的现象：网站在浏览器里一切正常，可一旦在百度搜索自己的品牌词或核心内容，收录量长期停留在首页一两条，内页更是迟迟进不了索引。问题的根子往往不在内容质量，而在渲染方式。
AngularJS 属于典型的客户端渲染框架。服务器返回的通常只是一个近乎空白的 HTML 骨架，真正的标题、正文、列表都要等浏览器下载并执行 JavaScript 之后，再由框架动态填进 ng-view 或指令容器里。人用浏览器访问没问题，但搜索引擎蜘蛛看到的可能只是一个空壳。
百度蜘蛛的真实抓取边界
和 Google 相比，百度蜘蛛对 JavaScript 的执行能力起步较晚，也更保守。即便近年来百度在渲染上有所进步，可面对复杂的异步加载、路由跳转和延迟渲染，抓取结果依然不稳定。换句话说，你不能默认百度一定会像浏览器那样"跑完"脚本再收录。
我经手过一个内容型 AngularJS 站点：文章数上千，被百度收录的却只有几十个 URL，而且大多是靠外链偶然抓到的入口页。用站长平台的抓取诊断工具去看，返回的源码里正文区域一片空白，只剩一串 script 标签。这基本就是客户端渲染站点收录困难的典型信号。
三条主流解决路径
服务端渲染（SSR）
最彻底的思路是让服务器直接吐出带内容的完整 HTML。AngularJS 时代常见的做法是借助 Node 环境做同构渲染，升级到新版 Angular 后则可使用官方的 Universal 方案。蜘蛛一来就能拿到完整正文，收录友好度最高，代价是改造成本和服务器压力都会上升。
预渲染（Prerender）
如果不想重构整套架构，可以用无头浏览器（如基于 Puppeteer 的方案）在构建期或运行期把每个页面"跑"成静态 HTML 快照，缓存起来专门喂给蜘蛛。它对存量项目改动小，适合内容更新不太频繁的站点；但页面数量庞大或内容实时性强时，快照的生成与更新会变成新的负担。
动态渲染
折中方案是判断来访者的 User-Agent：真实用户走原来的客户端渲染，识别到百度等蜘蛛时，服务器返回预渲染好的静态版本。这种方式落地快、见效直接。需要注意的是，两个版本的核心内容必须保持一致，不能让用户和蜘蛛看到截然不同的东西，否则容易被判定为作弊。
那些容易被忽视的细节
选对渲染方案只是第一步，下面这些配置同样决定成败：
- URL 形式：尽量启用 HTML5 History 模式，用干净路径代替早期的 #! 井号锚点，让每个内容页都有独立、可抓取的地址。
- 标题与描述：不同路由要动态更新各自的 title 和 meta description，避免全站共用一套，导致搜索结果千篇一律。
- 站点地图：整理一份完整的 sitemap，把希望收录的 URL 都列进去，并主动提交给百度。
- 主动推送：善用百度搜索资源平台的链接提交与抓取诊断，让新页面更快被发现，也能反向确认蜘蛛究竟看到了什么。
给团队的落地建议
技术选型没有唯一答案，关键是匹配自身情况。新项目或对 SEO 依赖较重的站点，值得一开始就把服务端渲染纳入架构；存量的老 AngularJS 项目，则可以先用动态渲染或预渲染快速止血，再逐步演进。
更重要的是养成"用蜘蛛的视角验证"的习惯：改完之后别只在浏览器里自测，务必用站长平台抓取真实源码，确认正文、标题、链接都实实在在地出现在返回的 HTML 里。SEO 收录从来不是一次性配置，而是持续观察抓取、收录、排名数据后不断调整的过程。对 AngularJS 这类单页应用而言，先解决"能被看见"，再谈"被看好"，顺序不能颠倒。