我从使用十大最常用JS框架中学到的SEO知识
6. 第三方渲染 – 设置监控
7. 性能：减少 JS
8. Google 能否加载所有 JS 脚本？
9. 防止在预渲染期间触发分析视图
10. 一些更广泛的SSR风险
JavaScript 将定义并影响大多数 SEO 顾问的未来。大量网站已经、正在或即将迁移到基于 JS 框架的平台。Stack Overflow 发布了一项广泛的研究，该研究收集了超过 10 万名专业程序员最常用的编程语言、脚本语言和标记语言的数据：更多信息请访问Most Popular Technologies。结果非常明确，如今一切都与 JavaScript 有关：
但 JavaScript 和搜索引擎的组合却很棘手。成功与失败之间往往只有一线之隔。下面我将分享 10 个技巧，帮助您避免在自己或客户网站上出现 SEO 灾难。
1. 始终选择服务器端渲染（SSR）
正如谷歌在今年早些时候的 Google I/O 大会上分享的那样，抓取、索引和渲染的流程与最初的流程有所不同。您可以访问https://web.dev/javascript-and-google-search-io-2019了解更多背景信息，但下面的图表足以让您初步了解：有一个独立的流程，也称为第二波，用于渲染 JavaScript 代码。为了确保谷歌能够处理 URL 并将其返回到抓取队列，初始 HTML 响应需要包含所有与 SEO 相关的 HTML 元素。这意味着至少要包含出现在搜索结果页面 (SERP) 中的基本页面元素和链接。毕竟，一切都离不开链接，对吧？🙂
谷歌在其关于网页渲染的文章中展示了许多设置，但却忽略了SEO方面。这促使我发布了一个替代表格：更多信息请访问https://www.notprovided.eu/rendering-on-the-web-the-seo-version/
服务器端渲染 (SSR) 是最稳妥的选择。虽然也有缺点，但对于 SEO 来说，你绝对不想冒任何风险。谷歌在首次抓取时看到的页面都经过了完整的 SEO 优化。别忘了，即使是最先进的搜索引擎谷歌也无法很好地处理这种情况。更何况是百度、Naver、Bing 等其他搜索引擎呢？
鉴于谷歌公开承认未来仍面临一些挑战，他们一直在分享动态渲染的配置方案。针对特定用户群体（例如低CPU性能的手机用户）或搜索引擎机器人，选择最合适的方案。例如，可以对大多数用户（不适用于旧版浏览器、不支持JavaScript的用户、低端手机等）使用客户端渲染，而将完全静态渲染的HTML版本发送给搜索引擎机器人或社交媒体爬虫。
无论谷歌告诉我们什么，请阅读《渲染预算，或者：我如何不再担心并学会服务器端渲染》，作者是一位前谷歌工程师。
2. 用于检查搜索引擎能看到什么和看不到什么的工具
由于大多数平台都会捕获用户代理以进行动态渲染设置，因此我首先会做的就是直接在 Chrome 中进行更改。这能百分百保证吗？不能，有些设置也会根据 IP 地址进行匹配。但我会尽可能扩大 SSR 的覆盖范围，例如，还要考虑到社交媒体爬虫可能需要捕获 OpenGraph 标签。仅仅结合 IP 地址和用户代理是不够的。与其错过某些特定平台的机会，不如覆盖更多的请求，并投入更多资金购买足够的服务器来推送渲染后的 HTML。
接下来需要检查的是用户、机器人和其他请求是否都能获取到相同的内容元素和指令。我见过这样的例子：Googlebot 获取到的标题、H1 标题和内容块与用户看到的不同。一个不错的 Chrome 插件是View Rendered Source，它可以直接比较获取到的内容和渲染后的内容之间的差异。
如果您有权访问 Google Search Console 中的域名，当然应该使用检查工具。它现在也使用 Googlebot 的永久版本（与其他所有 Google 搜索工具一样），因此能够真实反映 Google 在抓取过程中实际看到的内容。请检查 HTML 代码和屏幕截图，确保所有重要元素都已涵盖并填写了正确的信息。
想检查非自有网址？请使用富媒体搜索结果测试工具https://search.google.com/test/rich-results，它还会显示渲染后的 HTML 版本，您可以分别检查移动版和桌面版，以仔细检查是否存在差异。
3. 初始 HTML 响应的最低要求
这是一份简单的搜索引擎优化基础知识清单，但对搜索引擎优化结果至关重要：
- 标题和元标签
- 诸如索引指令、爬虫指令、规范引用和 hreflangs 注释之类的指令。
- 所有文本内容，包括语义结构化的 Hx 标题集
- 结构化数据标记
延迟加载：这无疑是现代性能优化中的最佳实践，但事实证明，对于移动端搜索结果缩略图和 Google Discover Feed 等内容，Googlebot 更倾向于使用无 JavaScript 版本。请确保 Google 能够找到无需任何 JavaScript 的纯净链接。
4. 数据持久性风险
Googlebot 使用无头浏览器进行抓取，不会将任何信息传递给下一个 URL 请求。因此，请勿使用 cookie、本地存储或会话数据来填充任何重要的 SEO 元素。我见过一些例子，其中产品在类别页面内进行了个性化设置，产品链接仅根据特定的 cookie 加载。切勿这样做，否则排名将会下降。
5. 单元测试 SSR
无论开发人员怎么说，系统总有崩溃的时候。网络故障会导致网站离线。这可能是由于新版本发布，也可能是开发人员在开发其他功能时意外引入的未知漏洞。以下是一个网站的例子，该网站的服务器端渲染 (SSR) 功能在去年的 #BrightonSEO 活动之后出现故障，导致内部运营中断了两周。
请确保为服务器端渲染设置单元测试。以下是常用 JavaScript 框架的测试设置：
- Angular 和 React 测试：https://jestjs.io/
- Vue 测试https://github.com/vuejs/vue-test-utils
6. 第三方渲染 – 设置监控
此外，像 prerender.io 这样的第三方渲染工具也并非完美无缺，它们也可能出现故障。如果亚马逊的基础设施崩溃，你使用的绝大多数第三方服务都会离线。不妨试试 ContentKing、Little Warden 或 PageModified 这类第三方工具（哈哈！）。不过，一定要考虑一下它们的托管位置哦 🙂
为了确保谷歌不会索引空页面，你可以采取另一种策略：先设置 503 错误响应，加载页面，然后在内容加载完毕后向服务器发送信号并更新响应状态。这种方法比较复杂，需要仔细调整，否则可能会严重影响排名。它更像是一种权宜之计，可以弥补网站配置的不足。
7. 性能：减少 JS
即使初始 HTML 响应中包含了所有与 SEO 相关的元素，我仍然遇到过客户因为用户体验和搜索引擎爬虫的性能下降而导致流量流失的情况。首先，要考虑真实用户的体验。谷歌 Chrome 用户体验报告是监控实际性能的绝佳工具。而且谷歌完全可以利用这些数据来优化他们那庞大的算法，哈哈！
最有效的技巧是使用 tree-shaking 来减少需要加载的 JavaScript 字节数。优化脚本也能加快处理速度，这对老旧、速度较慢的 CPU 尤其有帮助。对于老款手机来说，这可以显著提升用户体验。
8. Google 能否加载所有 JS 脚本？
务必监控并分析日志文件，查看是否有任何静态 JS 文件产生错误。Botify非常适合这项工作，它有一个专门的模块可以监控静态文件响应。棕色的 404 错误趋势清楚地表明，在 Google 需要访问这些文件时，它们无法访问。
9. 防止在预渲染期间触发分析视图
请确保在预渲染期间不要将页面浏览量发送到分析工具。最简单的方法是屏蔽所有发送到跟踪像素域的请求。就这么简单。注意到流量提升了吗？在报告流量大幅增长之前，请先检查您的服务器端渲染 (SSR)。
10. 一些更广泛的SSR风险
搜索引擎仍然不喜欢这种做法，并会确保你不会意外地使用这种“伪装”功能。对于服务器端渲染而言，这可能意味着向用户展示的内容与搜索引擎看到的内容有所不同。
缓存已渲染的页面可以降低成本，但要考虑发送给 Google 的数据点的影响：你肯定不希望过时的结构化数据（例如产品标记）也过时。
检查移动端和桌面端 Googlebot 之间的差异，像 SEO Radar 这样的工具可以帮助您快速识别这两个用户代理之间的差异。