用产品的思维去做SEO优化,会有不一样的效果

最近和朋友聊天,我们都感到SEO行业有个很致命的问题,就是没有一个固定的规范和标准。不像python,PHP等程序语言,有个很完善的官方手册,实在不行就直接做个小程序跑下,马上就有准确的答案。而SEO,毛标准都没有,所以就经常出现这样的情况:两个人为关键词密度争得面红耳赤,一个说3~7%好,一个说4~9%好,两个人差点打起来,但结果还是谁也说服不了谁(而且通常都是扯淡问题)。

让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名与空间、雅安服务器托管、营销软件、网站建设、成武网站维护、网站推广。

在规模较大的公司里,这样的SEO是很危险的。因为在大公司里,任何一点资源都需要去争取,都有一定的成本,比如要说服领导,得到产品和研发的配合,BI和搜索的支持。好不容易各种流程走完了,大家翘首以待等待流量提升,结果运气好的会有点效果,大多数是毛都没有,甚至倒退都很有可能。就比如往厨房送了一只鸡,大伙等着做成鸡汤或大盘鸡,结果出来一盘鸡屁股,或者直接出来一盘炒青菜。问厨师是怎么回事,厨师也挠了挠脑袋,也不知道哪里出了问题。

这样不可控的SEO是危险的,在大公司会逐渐失去地位。(这也是为什么都说SEO的ROI高,但大多数老板还是偏爱SEM的原因,很多SEO都做不到可控,无法保证投入一定有产出)因此,一定要让SEO可控。投入一分钱,就要见到一分钱的效果,不能听天由命,看天吃饭。

那怎样才能让SEO做到可控呢,不那么坑爹呢?

首先,要以科学的思路为指导。什么叫科学的思路,有3个方面:1、一切结论都有据可循,有数据支持,或出自搜索引擎基础理论或官方文档(这里的基础理论可不是什么关键词密度等);2、一切方案都要考虑清楚预期效果及风险(不要求完全精确,但至少对效果的预判方向一致);3、监控最终效果,与之前结论和方案进行实际对照(失败不要紧,要紧的是不管成功或失败)。

其次,SEO项目可以参考卫哲3+1的产品思考法。卫哲的3+1产品思考法是我之前看到的一个很完整,符合逻辑的产品思路,后来发现SEO也同样适用(产品经理是从用户角度改善网站,而SEO是从搜索引擎角度改善网站,两者有很多相同点的。)。下面是3+1思考法的SEO:

第一问:需求从哪里来,目标客户是谁

需求从哪里来,目标客户是谁,我认为这是最重要的一个问题。SEO通常这样,没有数据和理论支持,完全是出于自己感性的考虑,就对网站进行调整,比如看这个URL不爽,就重新做一套。这类需求通常没有明确的目标,或者目标不清晰,只是为了做而做。这些需求是需要直接砍掉的。

还有一类需求,看起来很有逻辑但最底层的理论却有问题。比如认为自己排名不高,原因是关键词密度过低,于是就提出需求增加关键词密度。但问题是排名低是否确实是由于关键词密度低引起,增加关键词密度是否真的会提高排名?从nlp角度来说,不仅要考虑关键词词频TF,还要考虑逆文档频率IDF,并没有那么简单;其次,从搜索引擎博弈角度出发,关键词密度如此容易操作,而且一直被SEO拿来控制排名的因素,恐怕早就被搜索引擎打入冷宫了。

其次,SEO需求应该是来自搜索引擎或用户,即针对搜索引擎或用户的某些问题进行优化。比如生成并提交sitemap,提高搜索引擎爬虫的抓取效率,或将主要内容放在首屏,提高用户体验。如果某个需求,对搜索引擎没有益处,对用户也没有益处,只从SEO角度考虑,那通常是没有作用的,再比如之前提到的关键词密度。

第二问:如果不做会有什么后果?这个需求紧迫吗?

上一问是考察需求是否必要,这一问是考察需求的重要和迫切程度。这个需求是紧急处理,还是排在队列中慢慢来,都需要通过这一问来确定。

第三问:他们的痛是什么?场景是什么(优化之前/之后)

这一问是考察需求能否解决之前问题。原来的问题是什么,那需求实施后能否解决问题。

+1:解决之后在网站数据上会有什么表现

这一问是考察需求的效果。不管最终结果成功与否,都要考察其结果,符合预期效果那太好了,如果跟预期差距较大,或没有任何效果,则需要自我分析,找出其中症结,就是“死也要死个明白”,作为以后的教训。

之前做过一个性能优化的需求,虽说效果不明显,而且严格意义上跟SEO没直接关系,不过仍然可以用产品思维去思考下。大致情况是这样的:

背景

有同事刚听了什么搜索大会,某砖家在会上提到了网站速度对SEO的影响,回来后就用某工具跑了下,果然比竞争对手网站速度要慢,于是交给我去分析。我主要是用PageSpeed,Yslow和WebPagetest对网页几个重点页面进行测试(这几个工具在谷歌网站站长指南中有推荐),并出了个初步方案,列了12项优化items。不过由于这些items涉及网站架构,并且我本身专业度不够,就只算是给研发同事的优化建议。

第一问:需求从哪里来,目标客户是谁

需求表面上是同事让我分析,但总归是网站自身存在的问题。

对于速度优化的受益方,一般是搜索引擎和用户。因为随着网站速度的提升,搜索引擎爬虫的抓取效率会提高,用户方面就不必说了,必然会提高用户体验。不过跟前端和开发同事讨论后,考虑到实现难度,第一期就先对静态文件缓存,CSS与JS的合并进行优化,所以就跟搜索引擎爬虫没有关系了(搜索引擎爬虫只是向搜索引擎发送请求,并保存返回的结果。对于返回网页代码中的静态文件,包括JS和CSS,并加载和保存。这一点可以参考谷歌管理员工具中的谷歌抓取方式来试验。)。

第二问:如果不做会有什么后果?这个需求紧迫吗?

速度优化如果不做就会影响网页打开速度,这个需求算比较重要,但不算紧迫。这个需求算是优化类,而不算是纠错类。(我将SEO需求按照目的简单分为两类:纠错类和优化类。纠错类是网站本身的SEO基础优化,比如多个栏目未单独设置title,而优化类则是加分项,比如这个速度优化。)

第三问:他们的痛是什么?场景是什么(优化之前/之后)

由于是优化类需求,所以也不算很痛。就是优化前,用户每次打开网页都要重新下载静态文件,并且JS和CSS都要一个个下载,JS还是单线下载。而优化之后,老用户打开网页时部分静态文件就直接从缓存中取,而不用重新下载,再加上合并后JS和CSS文件数量的减少,都大大降低了HTTP请求的数量,这样用户打开网页时,速度就快了100+毫秒。

另外,前端还在列表页进行了懒加载,这样就不用等到32个图片全部加载后网页才显示,而是先显示首屏,随着鼠标下滚才加载并显示下面图片。

+1:解决之后在网站数据上会有什么表现

以下是某个页面优化后的数据:

某栏目主要做了图片懒加载以及背景图合并,css合并等。

JS文件增加3个(业务需要),体积减少30KB;CSS文件减少3个,减少幅度为50%;CSS背景图减少11个,减少幅度 61.1%;首屏图片减少27张,减少幅度56.25%,首屏图片体积减少200KB左右。

整体请求减少38个,幅度为41.3%;体积减少 277KB, 幅度为30.1%。

用产品的思维去做SEO

注:这个结果是前端同事提供,是优化后的直接数据,可能还有后续的数据,比如GA的网页打开速度,用户停留时间,跳出率等,这些后续数据暂未记录。

很早之前就想写这个文章了,但老觉得太过理论,写出来就像是忽悠的,于是就拖着没写。一直到最近,实在不堪一些拍脑门需求,就写出来,请随意拍砖。

文中那个需求是我刚来公司时候做的,记得那时早上等班车都要看会那本性能优化的动物书,现在就像个老油条一样,不思进取,真不喜欢这样。

图注。漫画台词:“简单的说,这样做就能提高网站排名了”。


名称栏目:用产品的思维去做SEO优化,会有不一样的效果
网页网址:http://ybzwz.com/article/ceesj.html