我喜欢把 SEO 说成是“别人的义务”(Somebody Else’s Obligation)的意思，因为如果出了问题，可以把责任推给别人。工程师都知道这种痛苦，因为如果出了问题，会有很多人(有时候是“SEO”团队的人)指责他们。但现实却是：除非你的技术已经解决了所有问题，否则根本不存在所谓的搜索引擎优化。

　　工程师有责任去了解他们在 SEO 中所起的作用，同样，与工程师一起工作的人也有责任与他们合作——在出问题时不要责怪他们。要促成这种关系，需要公开和坦诚地分享一些信息。

　　我希望这篇文章能强调一些重要但很少被讨论的话题，这些话题不仅值得工程界讨论，也值得依赖工程团队的人讨论。

　　服务器稳定性和停机时间

　　在进行计划或意外的停机时，可以使用 HTTP 响应码“503 Service Unavailable”。与其他 5XX 响应码相比，它对搜索排名的影响最小。

　　HTTP 响应码 500、502 和 504 会导致 G​​oogle 禁止某个网页或完全取消网页索引。当有人或搜索爬虫收到其中一个响应码时，预计会丢失 5 到 10 次的有机访问次数。

　　在出现问题时，进行快速的沟通，并通知利益相关者。否则，你会被很多提出疑问的人所困扰(这样会妨碍你的团队寻找解决方案)。

　　为每个错误响应码(例如 4XX 和 5XX 错误)创建自定义皮肤和跟踪事件。如果外行人可以提供一些细节，问题就会变得更容易诊断。

　　在计算错误率时要十分小心。复杂的网页在完成加载时可能会调用服务器 150 次。这意味着日志文件将会低估预先发生的错误响应码的频率。例如，想象一下网页被加载了两次，第一次返回“200-OK”响应码，并加载所有的内容。第二次返回“502-Bad Gateway”响应码，并且无法加载页面的其余部分。服务器总共被调用了 151 次，其中只有一个是 502，但是，用户的错误率是 50%，而不是 0.6%!

　　不要忽视“诡异”的现象，一些被认为“无法重现”的错误可能是更大问题的征兆。

　　内容交付网络和缓存

　　缓存不能替代基本的网站优化。缓存的页面就像放在约会网站上的照片，刚开始人们只能看到照片，但在开始建立关系时，“那个人”就会知道“真实的你”。用户和搜索引擎的关系也是如此。

　　类似的，启用了 AMP 的页面也无法替代速度慢的移动网站。

　　请注意页面大小的限制。例如，Akamai 的文件大小限制为 1MB，超出时会生成 500 响应码。

　　将内部日志与 CDN 日志合并，否则，超过 90%的问题可能无法检测到。

　　考虑在大型网站(包含大量不经常修改的页面)上使用“304-Not Modified”响应码。

　　找出不必要的动态查询(例如，填充很少更改的列表页面的逻辑)。你可以通过缓存查询和刷新缓存来避免给服务器造成不必要的压力。

　　重写规则和重定向管理

　　在改变 URL 时，要确保在启动时对重定向进行验证。这将在最大程度上结转旧页面的信任和权益。先让 URL 遭到破坏，然后再去修复它们，这无异于自杀：谷歌会随着时间的推移逐步让旧页面的价值衰减。

　　仔细检查看看重写标志或规则是否会导致重定向链。当一个网站从 HTTP 迁移到 HTTPS 时很容易发生这种情况。有些 URL 在安全和非安全版本之间跳来跳去，直到到达最终目的地。这些额外的跳转会破坏原始 URL 的权益。

　　如果撤消或撤消重定向，请清除 CDN 的缓存，以避免重定向循环。

　　反机器人

　　在被证明有罪之前，宁可做无罪的事。 由于“不自然”的浏览速度或安装了浏览器插件，网站的超级用户最有可能像机器人一样。这听起来像是一个边缘案例，但在社区网站(例如 Quora)上，一个超级用户每月可以吸引 1 万到 1.2 万的访问量。

　　俄罗斯的机器人不一定就是不好的，美国的机器人也不一定就是好的。有很多不良分子在亚马逊的美国 AWS 服务器上部署机器人。

　　延迟和页面加载速度

　　快速选择一个度量工具(如 Rigor、Lighthouse 或 PageSpeed Insights)并坚持下去。趋势比确切的数字更加重要。

　　移动版页面的加载速度非常重要，即使你正在运行 AMP 版本的网站。谷歌通过原生移动体验(包括加载速度、用户体验和其他因素)来评判一个网站。

　　将添加到页面中的每个跟踪像素和标签的所有权交给某人，然后让利益相关者每六个月验证这些标签。如果不这样做，人们会要求你在页面中添加越来越多的垃圾，直到你的团队因为网站变慢而遭到指责。

　　对于拥有数百万个页面的网站来说，服务器响应时间变得尤为重要。如果你的服务器响应速度慢，谷歌是不会耐心等待的。

　　如果在一个大型网站中使用 NGINX，请确保即时 Gzip 压缩不会带来弊大于利的效果(减慢服务器响应速度)。

　　清除任何影响页面渲染的东西，这样可以一下子改善一系列的指标(即使是纯文本网站，在加载 JS、CSS 和字体时也会遇到瓶颈)。

　　关注页面加载的前 200ms 和 2s 期间发生的事情。因此有动态元素(如广告)，有些页面不会立即“完整”加载。

　　关键的渲染路径

　　加载第一批字节的时间是一个重要的指标，但第一批字节中包含的是哪些内容也同样重要。在打开与服务器的新连接之前，浏览器应该能够构建首屏内容。

　　定义页面元素的大小，避免页面出乱子。如果页面四处移动，用户会感到沮丧，即使加载速度很快，用户也会感觉整个页面很慢。

　　“新”技术和谷歌机器人的可访问性

　　客户端渲染可能意味着 SEO 已死。谷歌建议用户为其搜索爬虫提供服务器端渲染的页面，即使呈现给用户的是客户端渲染的页面。

　　为谷歌机器人提供简单的分页，以免让用户看到“无限滚动”的情况。

　　避免使用“块级”链接，尽管这样可以简化代码。包含在 < a > 标签中的所有额外内容都会导致谷歌机器人难以将上下文的值传递到目标页面。

　　staging 和 QA

　　使用 robots.txt 文件禁止搜索引擎抓取 staging 和 QA 网站。

　　在 Google Search Console 中注册 staging 和 QA 网站。这样做似乎有点违反直觉(因为你不希望搜索引擎找到这些资源)，但如果测试网站被意外索引了，你可以在 Search Console 中取消索引。

　　产品需求

　　找一个人(最好是在 SEO 团队，如果没有，产品经理也可以)来定义必须构建到页面中的所有内容，例如 < title > 标签和其他元数据。这件事情很枯燥无味，他们会因此讨厌你，但如果你构建了一个不能包含这些关键标签的页面，他们会更加讨厌你。

　　内部链接

　　链接是网站和整个网络的命脉。任何重要的东西都应该在离主页五次点击之内，因此要向那些想要消除登陆页面、导航链接的“极简主义者”提出很多问题。

　　登记和 IP 管理

　　永远不要让营销人员从托管网站的 IP 发送简讯和促销电子邮件。违反 CAN-SPAM 法案的流氓员工可能导致整个网站被列入黑名单。

　　确保有人花时间填写登记处要求的年度联系信息更新问卷调查。如果不这样做，会让一些不良分子更容易从技术上窃取你的域名。

　　JAVASCRIPT

　　开始渲染一个页面，然后又变成纯白色，通常是因为只给了 write() 的起始标签，而没有给出结束标签。

　　谷歌会尝试遍历 JavaScript 内的相对路径，即使它们不存在。这样会污染爬虫错误报告。

　　当发生错误时

　　行动要快，因为谷歌是个善变的情人。建造一所房子需要几个月时间，而烧毁它只需要几分钟。所以，要迅速地熄灭火柴，并花时间向每个人传授消防安全知识!

文章来源：蔡江博客
文章标题：Web工程师需要掌握的38种SEO技巧
本文地址：http://www.chengduseo.cn/seo/11131.html