seo界面晃悠_网站工程师的SEO 38个来之不易的教训和提示

文章目录 [+]

John DeFeo

我喜好开玩笑说SEO代表“其他人的责任”，由于当涌现问题时很随意马虎被责怪。
工程师们懂得这种痛。
很多人责怪他们，有时是“SEO职员”。
但是，事实是这样的:如果你的技能问题已经全部办理，就不会有搜索引擎优化这样的事情。

seo界面晃悠_网站工程师的SEO 38个来之不易的教训和提示 seo界面晃悠_网站工程师的SEO 38个来之不易的教训和提示网站建设公司

工程师有任务理解他们在SEO中的角色，同样，那些与工程师一起事情的人也有任务与他们互助，而不是在涌现问题时责怪他们。
这种关系须要公开和老实地分享信息。

（图片来自网络侵删）

我希望这篇文章突出了一些主要但很少谈论的话题，这些话题不仅值得工程界谈论，也值得依赖工程团队的人谈论。

做事器稳定性和停机韶光

503做事不可用”HTTP相应代码是处理操持停机或意外停机的最佳办法。
与其他5XX相应比较，它对搜索排名的影响很小。

500、502和504 HTTP相应代码会导致谷歌关闭一个网页或完备取消索引。
每次一个人或搜索爬虫收到这些相应代码中的一个，随着韶光的推移，估量会失落去5-10次有机访问。

快速沟通，并在涌现问题时向管理者发送更新。
否则，你会被许多探求答案的人所困扰(这会妨碍你的团队探求办理方案)。

为每个有害相应代码(例如4XX和5XX缺点)创建自定义皮肤和跟踪事宜。
当外行人能够供应一些细节时，问题就更随意马虎诊断。

打算缺点率时要非常小心。
一个繁芜的web页面在加载完成时可能会调用做事器150次。
这意味着日志文件将低估预先发生的有害相应代码的频率。
假设一个web页面被加载了两次。
第一次，它相应一个“200-OK”状态码，并加载页面上的其他所有内容。
第二次考试测验时，它会相应一个“502-Bad Gateway”状态码，页面的别的部分无法加载。
做事器统共被调用了151次，个中只有一次是502状态，但是，该用户的缺点率是50%，而不是0.6%!

抵抗搁置轶事证据的诱惑。
许多被认为是“不能重现”而搁置的bug是更大问题的预兆。

内容交付网络和缓存

缓存不能替代基本的站点优化。
可以把缓存页面想象成约会网站上一张很棒的照片。
这是人们看到的第一件事，但是当你开始一段关系，一个人开始理解“真正的你”。
用户和搜索引擎也是如此。

类似地，支持AMP的页面也不能替代速率慢的移动站点。

把稳页面大小限定。
例如，Akamai有一个严格的的1MB文件大小限定，当超过该限定时将导致一个500相应代码。

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

考虑在大型网站上利用“304-Not Modified”相应代码，这些网站有很多页面不常常变动。

探求没有必要的动态查询(例如添补很少变动的列表页面的逻辑)。
你可以通过缓存查询和调度刷新来避免做事器上不必要的包袱。

重写规则和重定向管理

当你变动URL时，确保在启动时验证了重定向。
这将带来最大程度的旧页面的信赖和公正。
让URL断开，然后再修复它们这无异于自尽:谷歌会随着韶光的推移而降落此故障页面的值。

检讨重写标志或规则是否正在导致重定向链。
当站点以HTTP形式启动并迁移到HTTPs时，这很随意马虎发生。
一些URL在安全版本和非安全版本之间来回切换，直达到到终极目的地。
这些额外的跳转会毁坏原始URL具有的公正性（equity）。

如果撤销或反向重定向，请打消你的CDN缓存，以避免重定向循环。

机器人壅塞

在被证明有罪之前，宁肯做无罪的事。
网站的超级用户最有可能是那些像机器人一样的人，由于他们的浏览速率很“不正常”，或者浏览器安装的插件也可能会让人掉入陷阱。
这听起来像是一个边缘案例，但在Quora这样的社区网站上，一个超级用户每月可以吸引1万到1.2万的访问量。

俄罗斯的机器人不会自动变坏，美国的机器人也不会自动变好。
许多坏蛋在亚马逊公司的美国境内支配基于AWS做事器的机器人。

延迟和PageSpeed

PageSpeed（一款网页速率丈量工具，也可以理解为页面加载速率）

快速选择一种丈量工具(比如Rigor, Lighthouse 或 PageSpeed Insights)并坚持利用。
趋势比精确的数字更主要，在工具上吹毛求疵很随意马虎摧残浪费蹂躏韶光。

手机移动页面速率很主要，纵然你运行的是一个AMP版本的网站。
谷歌根据网站确当地移动体验(包括速率、用户体验和其他成分)来判断网站。

哀求某个人拥有添加到页面中的每个跟踪像素和标记的所有权，然后让这些任务人每六个月对他们的标记整理一次。
如果你不这样做，人们会哀求你在页面中添加垃圾，直到你的团队由于站点缓慢而受到责怪。

做事器相应韶光对付拥有数百万页面的站点尤其主要。
如果你的做事器相应缓慢，谷歌不会勾留太久。

如果你在大型网站上运行NGINX，请确保实时Gzip压缩不会弊大于利(比如，造成瓶颈，从而降落做事器相应韶光)。

打消任何阻碍页面呈现的东西。
这将同时改进许多指标。
(纵然是纯文本网站[1]，在加载JS、CSS和字体时也会碰着瓶颈。
)

关注页面加载的前200ms和2s期间发生的事情。
由于动态元素(如广告)的影响，有些页面从不会加载“完备”。

关键渲染路径

Time-to-first-byte(TTFB全称Time To First Byte，是指网络要求被发起到从做事器吸收到第一个字节的这段韶光，它包含了 TCP连接韶光，发送HTTP要求韶光和得到相应第一个字节的韶光。
)是一个主要的指标，但同样主要的是第一个字节中包含的内容。
在打开与做事器的新连接之前，浏览器该当能够构建第一屏的内容。

定义页面元素的大小，以避免跳跃和扭捏页面。
当页面来回移动时，用户会感到沮丧，这会让全体页面看上去很慢，纵然它加载得很快。

阅读Ilya Grigorik在这个主题上揭橥的文章[2]。
纵然是履历丰富的开拓职员也可以从中学到一些东西。

GOOGLEBOT（谷歌网页抓取机器人）的“新”技能和可访问性

客户端呈现可能意味着SEO的去世亡。
(看看Hulu发生了什么[3]。
)谷歌建议你为他们的搜索爬虫程序供应一个做事器端呈现的页面，即利用户也将会看到客户端呈现的页面。
(注:谷歌并不认为这是一种掩饰笼罩，只管它看起来是。
)

在用户看到“无限滚动”的情形下，为Googlebot供应大略的分页。

避免利用“块级别”链接，纵然它简化了代码。
所有这些额外的东西都被打包到一个<a>标记中，这使得Googlebot很难将高下文值通报到目标页面。

STAGING(仿照)和QA

利用robots.txt文件阻挡搜索引擎从仿照和QA（Question Asked）站点爬取数据。

在谷歌搜索掌握台注册staging和QA站点。
这听起来不可思议(由于你不肯望搜索引擎找到这些域名)，但是如果测试域名意外地被索引时，你可以在搜索掌握台中删除全体域名的索引。

产品需求

找个人(最好是SEO团队里的，但如果没有的话，那便是产品经理)来定义必须构建到页面中的所有东西，包括一些显而易见的东西，比如<title>标签和其他元数据。
这很乏味，他们会讨厌你问这问那，但如果你创建的页面没有考虑到这些关键标签，他们会更讨厌你。

内部链接