Compass 技术博客上的原文

几个月前，我为公司的软件开发者做了一场题为“面向工程师的 SEO”的技术分享。我们（SEO 团队）发现，许多工程师对搜索引擎优化了解不多，有时会把面向用户的页面设计成不利于 SEO 的样子。

所以我们觉得有必要向更大的团队普及做好 SEO 的基本方法……现在也把这些内容分享给你。关于 SEO 的资料有很多，但大多出自 SEO 代理机构——本文则是由工程师写给工程师的。

过去与现在

值得对比一下如今的 Google 搜索结果页和几年前的样子：

即便 2012 年的屏幕更小，不用滚动也能看到 3 条非广告结果。而到了 2019 年，映入眼帘的是 4 条广告、一堆 Google 知识图谱卡片和“其他人还问了”问答，之后才有一条真正的搜索结果！

想在首屏就出现在结果页上变得越来越难，可以说，做好 SEO 也因此变得更加重要。

什么是 SEO？

SEO 是“搜索引擎优化（search engine optimization）”的缩写。说得花哨一点，就是通过各种手段让你的页面在搜索中排名更靠前，从而从搜索引擎获得更多、更优质的流量。

由于 Google 是最主要的搜索服务商，这实际上就意味着要在 Google 搜索中获得更高排名——不过，为 Google 做的绝大多数优化，对其他搜索引擎同样有效。

需要注意，SEO 不同于 SEM（search engine marketing，搜索引擎营销），后者是指为基于关键词的广告付费。你可以把 SEO 里的 O 理解为 organic（自然的、非付费的）搜索，把 SEM 里的 M 理解为 money（付费）搜索。本文不涉及 SEM，只聚焦 SEO，尤其是如何被收录并获得良好排名。

SEO 的有些方面对工程师来说相当直接（主要是技术层面的部分），而另一些方面则要困难得多（真正去生产和发布优质内容）。本文主要聚焦于前者——那些你应该去做的、相对直接的技术性优化。

被抓取与被收录

你的页面至少要能被 Googlebot 抓取并收录，而这一点出乎意料地容易出错。每一个希望获得排名的页面或页面类型，都应该满足以下条件：

• 被 robots.txt 允许抓取
• 拥有稳定、规范的 URL
• 返回 HTTP 200，而非 404 或 500
• 使用服务端渲染的 HTML
• 能通过站内链接到达
• 包含在 XML 网站地图中

下面逐一详细说明。

Robots.txt

大多数中大型网站都会在 /robots.txt 放置一个文本文件，告诉“善意的爬虫”（例如 Google 网络爬虫）应该或不应该抓取哪些页面。文件格式非常简单，在 robotstxt.org 以及 Google 文档中都有详细介绍。一个简单的 robots.txt 文件可能长这样：

Sitemap: https://www.example.com/sitemap.xml
User-Agent: *  
Disallow: /api/  
Disallow: /staff/

这告诉 Googlebot（以及其他爬虫）两件事：

1. 该网站的 XML 网站地图在哪里。
2. 对于所有 user agent（即所有爬虫），不要抓取以 /api/ 或 /staff/ 开头的 URL。

但你得小心一点——比如，要是一位好心但不了解 SEO（也没读过本文）的工程师决定“把那些烦人的爬虫都屏蔽掉”，在文件里加上一句“Disallow: /”会怎样？

又或者，你的 CEO 让开发人员“给我做个个人页面”，而开发人员在不了解 robots.txt 规则的情况下，把页面放到了 /staff/billg？他不会意识到这个页面根本没有机会被收录。

这类事情比你想象的更常见。有些公司会使用 robots.txt 解析库来做自动化检查，确保重要页面始终可被抓取。至少，你应该把 robots.txt 纳入版本控制，并对所有变更进行严格审查。

显然，你希望被抓取的页面应该在 robots.txt 中被放行。但对于不需要抓取的 URL，你应该主动禁止抓取。例如，JSON 接口的返回就不应该被抓取——Google 只会为你的网站分配一定的抓取配额，你肯定不希望它把配额浪费在不需要的内容上。

需要注意，在 robots.txt 中禁止抓取并不是一种安全措施。任何恶意爬虫或黑客仍然可以抓取这些页面。因此，例如，即便 /api/ 请求在 robots.txt 中被禁止，如果背后的信息并非公开，仍然需要做好安全的身份验证。

稳定、规范的 URL

如果你是在现有的 Web 应用上工作，URL 结构可能已经定型。但如果你在设计新的 URL，有几点需要留意：

一个页面，一个 URL：始终通过唯一的、规范的 URL 提供同一个页面。这里的 canonical 指的不是 rel=canonical 标签，而是单一、标准化的 URL。例如，如果你在 /staff/billg 提供某个页面，就不要在 /staff/gates/bill 也提供相同内容。如果确实需要支持多个 URL，请将其他 URL 通过 301 重定向到规范地址。

处理尾斜杠：与上一条相关，不要让 /staff/billg 和 /staff/billg/ 都返回 HTTP 200。相反，应选择其中一个作为规范 URL，并将另一个版本 301 重定向到它。

半可读的 URL：有不少资料主张在 URL 中加入描述性关键词，这已成为“现代 Web”的一项最佳实践。例如，用 /articles/1234/seo-for-engineers 要好于 /articles/1234。

包含资源 ID：如上例所示，在 URL 中包含像 1234 这样的资源 ID 会让技术实现更简单。用 ID 来实际查找资源，如果“seo-for-engineers”这段 slug 与文章当前的 slug 不一致，就 301 重定向到规范 URL。很多网站都在使用这种做法，包括 StackOverflow、TripAdvisor 等——它避免了维护历史 URL 变更或重定向数据库的麻烦。

如果一个 Web 应用的 URL 结构糟糕到需要重新设计，也是可以安全完成的——你需要使用 HTTP 301 Moved Permanently 将旧 URL 重定向到新 URL。不过，别太频繁地这么做！

有一个地方你肯定应该使用 301，那就是将 http:// 站点重定向到 https:// 站点，以及将不带 www 的域名重定向到带 www 的域名（反之亦然）。

干净的 HTTP 响应

你希望页面在 Googlebot 看来尽可能干净：直接返回 HTTP 200，不带重定向。这样可以避免 Google 把抓取配额浪费在重试上，更严重的情况下，还能避免因死链或间歇性 500 错误导致 Google 降低你的页面排名。需要避免的情况包括：

• HTTP 404：如果某个 URL 错误地返回 404 Page Not Found，要么是链接本身坏了，要么是页面处理逻辑坏了——这两种情况都应避免。当然，如果该位置本来就不该有页面，返回 404 才是正确的。
• HTTP 301：301 Moved Permanently 很有用，也很重要（见上一节），但如果你的站内页面大量链接到会被重定向的 URL，就应该更新这些链接。
• HTTP 500：Internal Server Error 意味着 Google 看到的是一个完全无法访问的页面。无论如何，希望你的工程师本来就在密切监控 500 错误，如果还没有，现在就该开始了！

更多信息请参阅 Moz 的HTTP 状态码指南。

服务端渲染

对于你在乎能否被搜索到的页面，应该始终提供服务端渲染的 HTML。这不仅对用户有益（加载更快、运行 JavaScript 的耗电更少），对 Googlebot 也有好处。

“可是，”有人会说，“Google 现在会执行 JavaScript 了。”这至少从2014 年起就是事实——Google 确实会尝试通过运行你的 JavaScript 来更好地理解页面。然而，执行 JavaScript 的难度可能比单纯解析 HTML 要高一个数量级：想想看，启动 V8 并运行一段 JavaScript 所需的 CPU 算力，比起从服务端渲染的 HTML 中解析文本要多多少。

依赖 Google 来执行你的 JavaScript 存在很多注意事项（见上文链接的 2014 年文章）。此外，Google 似乎能瞬间解析 HTML，而 JavaScript 的执行则是分两个阶段的过程，可能会被显著延迟。因此，为了获得最佳效果，请始终通过服务端生成的 HTML 来提供内容。

你仍然可以使用 React 等客户端技术来让页面具备交互性，只是需要多做一些工作来启用服务端渲染。几年前，Compass 从客户端 React 切换到服务端渲染后，排名就有了显著提升。

ReactDOMServer.renderToString(element)

将 React 元素渲染为初始 HTML。React 会返回一个 HTML 字符串。你可以使用此方法在服务端生成 HTML，并在初始请求时下发标记，以实现更快的页面加载，并让搜索引擎能够为 SEO 目的抓取你的页面。

内部链接

“内部链接”是 SEO 中的一个流行词，意思很简单，就是同一网站内从一个页面指向另一个页面的链接。这类链接不仅能帮助用户在站内导航，还能让 Google 抓取你的网站，并在站内传递“排名权重”。更多内容可参阅 Moz 关于内部链接的文章。

内部链接通常很容易实现，你应该尽可能（在合理范围内）多地让重要页面之间相互链接。内部链接的例子包括：

• 面包屑导航
• 页眉或页脚中的导航链接
• 帮助用户导航、同时帮助 Googlebot 发现更多页面的链接块，例如 Compass 房源页面中指向相似房源的链接：

大多数大型网站还会提供一个 HTML 网站地图，其中包含指向站内所有重要页面的链接。这类地图过去对用户更有用，如今随着搜索无处不在，它们更像是一种 SEO 工具。不过，拥有一个 HTML 网站地图仍被认为是良好的实践。

Compass 以及其他房产网站的 HTML 网站地图具有州、县、邮编的层级结构——其中“叶子”页面链接到所有当前有效的 Compass 独家房源。这也是我们向 Google 曝光房源页面的另一种方式。

XML 网站地图

对于像 Compass 这样的大型网站来说，更重要的可能是 XML 网站地图。这些是简单的 XML 文件，上传到 Google Search Console 或在 robots.txt 中引用，里面只是列出了你网站上的所有 URL。这让 Googlebot 能够系统地找到你的所有产品页面，而不必去追踪成千上万个链接。

Compass 拥有多个 XML 网站地图（你可以有多个）：

Sitemap: https://www.compass.com/sitemaps/exclusives/sales-sf/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-la/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-nyc/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-dc/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-other/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/rentals/index.xml
...

每个 sitemap index.xml 文件都会链接到实际的 sitemap.xml 文件，后者长这样：

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
  <loc>
   https://www.compass.com/listing/101-old-mamaroneck-road-unit-1b4-white-plains-ny-10605/409187998570262817/
  </loc>
  <lastmod>2020-02-22T01:25:55.877000+00:00</lastmod>
 </url>
 <url>
  <loc>
   https://www.compass.com/listing/4641-south-lincoln-street-englewood-co-80113/414572085652655249/
  </loc>
  <lastmod>2020-02-22T01:25:16.710000+00:00</lastmod>
 </url>
 ...

“lastmod”字段是可选的，它让 Google 知道该页面的信息上次修改是何时，从而判断是否需要再次抓取。

你可以在 Google 文档中阅读更多关于 XML 网站地图的内容。

更好地表现与排名

页面基础优化

要让单个页面更易被发现，有几项基本工作需要做好：

• 页面应做到移动端友好。Google 采用移动优先索引，因此你应该优化页面，使其在移动设备上表现优异。同时，不要在移动端和桌面端提供不同的内容。这些不仅有助于 Googlebot，也有助于用户。
• 每个页面都应有一个简洁、具体的 <title> 标签。这有助于 Google 理解页面的主旨，并且该标签通常会在搜索结果页中显著展示。
• 每个页面都应在 meta description 中提供简短而准确的摘要。请参阅 Moz 关于 meta description 的文档。
• 每个页面都应具有良好的结构：有意义的 <h1> 和 <h2> 标题、有意义的链接文本、带有合适 alt 文本的图片等。
• 对于产品页面等，使用结构化数据（如 JSON-LD）来为 Google 提供更多细节。这有助于 Google 更深入地理解内容，同时还能驱动搜索结果页上的信息卡片，例如：

页面速度

2018 年，Google 表示已将页面速度作为决定移动端页面排名的因素之一，因此让页面更快是值得的。

显然，第一步是让后端及时返回 HTML。这很容易衡量，但只是第一步——客户端性能同样会被纳入考量。Google 提供了大量关于如何衡量和提升页面速度的资料，建议你去阅读。

Chrome 内置的工具也能让你在本地以 Google 的视角衡量页面速度。在页面上点击右键，选择“检查”，进入“Audits”标签，对移动端做一次“Performance”审计。你会得到一份美观的报告，其中包含一些（有时很有用的）建议：

Google 关于速度的文章在它们自己的速度测试工具上得了 90/100 分——还不错（还是说这分数有猫腻？:-）。

影响页面速度的因素有很多：

• 首字节时间：服务器返回第一个字节所需的网络时间。在此之后还有 HTML 下载时间，这取决于用户的带宽和 HTML 的大小。尽量控制体积！
• 首次内容绘制：到 DOM 中真实内容首次渲染完成的时间。这能让用户感知到页面正在加载，Google 也将其作为页面速度信号之一。
• 可交互时间：到用户真正能与页面交互所需的时间。通常需要执行一些 JavaScript 后页面才可交互，因此要注意 JavaScript 包的体积、启动时间等。
• 静态资源：你的 CSS 和 JavaScript 应该设置较长的缓存过期时间，最好放在 CDN 之后。它们也应该尽可能小——要当心像 Moment.js 这样的大型 JavaScript 包！
• 图片加载时间：应提供尺寸合理的图片，并设置正确的缓存头，最好通过带缓存的 CDN 提供。如果页面引用了大量大图，考虑对其中一些做懒加载。

要当心！如果你和大多数公司一样，在不断迭代和开发页面，那页面很可能会越来越慢。你需要持续关注页面速度：在添加新功能、增加对后端服务的调用时都要进行衡量。

链接与域名权重

Google 正是诞生于PageRank 算法（奇怪的是，它是以 Larry Page 的名字命名的，而不是 Web Page）。

PageRank 通过统计指向某个页面的链接数量和质量，来大致估算该网站的重要性。

换句话说，如果有很多其他页面链接到你的页面，你的排名就会更好。如果这些链接来自高 PageRank 的页面，那就更好了。因此，你应该尽可能让权威网站链接到你的页面。

一个例外是 rel=nofollow 链接：“nofollow”是网站在其 <a> 链接标签上添加的一个属性，用来告诉 Google 不要跟踪或在排名计算中计入该链接。这通常用于用户生成内容，例如博客或 YouTube 评论，这类内容可能质量较低且充满垃圾信息。

如果这类网站不使用 rel=nofollow，垃圾信息发布者就会提交数百个指向其页面的链接来人为推高排名。而这正是“nofollow”引入之前所发生的情况。

还有一个 SEO 概念叫域名权重（domain authority），这是 Moz 的一项指标，用于表示某个域名整体权威度的高低（例如：nytimes.com 为 95/100，stackoverflow.com 为 93，而我的个人小网站只有 37）。这不是 Google 的指标，但似乎可以作为 Google 如何看待某个域名重要性的合理参考。

延伸阅读

本文主要讨论的是技术层面的 SEO 改进——这些往往是工程师能够直接掌控的部分。但这只是故事的一半。

如果你把这些技术性 SEO 都做到了，却没有优质内容，Google 不会给你好排名，也没人会使用你的网站。SEO 做得再好，内容糟糕也是糟糕的 SEO。反过来说，如果你拥有优质内容，遵循这些技巧将大大提升其获得良好排名的机会。

Google 的《SEO 入门指南》是关于这些主题的官方权威读物，Moz 的《SEO 初学者指南》同样值得一读。

如果你想联系我们，请查看我们 robots.txt 顶部的横幅！