这次事件的影响和意义

接受采访前调查了一下大家对这次事件的理解,发现这篇文章写的最好. http://qiuingseo.com/yejiedongtai/152.html 不再赘述了,就是想强调一下所谓"安全"是针对百度自己,并不是让网站或用户更安全(或者说这部分意义不大).

对于站长们的影响:

  1. 对于小站也许没有影响,可以从站长平台上获取足够的数据.但是对于大站无法得知流量的准确来源,缺少了一个重要的线索,也许还要靠广泛抓取排名来补充评估.

  2. 区分品牌词流量(感谢ZERO张闻一提供思路).SEO品牌词基本是不用花精力优化的,而且不应该算作SEO的KPI,而是Marketing的KPI.将来无法根据关键词的字符串来区分品牌词流量,那么我的建议是PC端把首页的SEO流量都算品牌词贡献,移动端首页没有其他渠道标识的流量都算作品牌词贡献.

  3. 根据referrer自动优化页面.根据用户来源词自动改变页面本身内容,使其与检索词更相关.

  4. 有人说还可以从百度统计上看到关键词数据,我觉得是错误的.这类产品的原理是用js从浏览器端额外发请求到百度统计服务器上,如果referrer中的关键词去掉了,百度统计也是无能为力.所以对于站长来说数据接口应该只有站长平台.

如果让我替百度说句话,我觉得即使完全隐藏关键词的数据,也不是没有道理.SEO有些工作确实目的性太强了,眼里只有业绩,没有用户.页面排名上去了,但用户体验并不一定很好.对于SEO从业者来说,大家都是公平的,没做到位的事情还有很多,努力适应一下吧.

referrer事件技术细节

取消referrer从技术角度看影响的是web服务器访问日志中的referrer字段,意思是访问来源.

referrer逻辑展示 一般情况下它是由用户点击链接的行为触发的,由浏览器实际执行.用户搜索"复仇者联盟"并点击一个A网站(如图上2所示)的搜索结果, 那么A网站的访问日志中一定会新增一条记录,并且referrer是(如图上1所示):

http://www.baidu.com/s?wd=复仇者联盟

取消referrer中关键词,目前百度是这样实现的,把所有搜索结果都替换为这样的中间地址,如图上3所示.请注意其中wd这个参数的值是空的.

https://www.baidu.com/link?url=owOnYs_fgWiw5es8PSwApbQFIG9UmJQrDtUrz8kkQKTPv9AyUpl6BV4zxHlSm2xA8Nwow3gbtxSIsmGqX2UXf_&wd=

几个月以前这个地址的response code还是301,并且location是结果页的URL,那么原始referrer还能继承传递下去,但是现在来看这个地址response code是200,也就是无法传递下去了.

返回的内容如下:

<meta content="always" name="referrer"><script>try{if(window.opener&&window.opener.bds&&window.opener.bds.pdc&&window.opener.bds.pdc.sendLinkLog){window.opener.bds.pdc.sendLinkLog();}}catch(e) {};window.location.replace("http://bbs.3dmgame.com/thread-1013289-1-1.html")</script>
<noscript><META http-equiv="refresh" content="0;URL='http://bbs.3dmgame.com/thread-1013289-1-1.html'"></noscript>

日志中都可以分析哪些字段.如果没有referrer,我们还可以做什么.

  • date - 日期, 工作日与非工作日的访问量区别.
  • time - 时间, 一般用于分析一天当中不同时段的访问量区别.
  • ip - ip地址, 一般用于区分用户所在区域.
  • host - 主机名, 一般用于区分产品.
  • path - URL路径, 是否符合SEO的预期(很重要)
  • query - URL参数, 是否有你不希望的参数(很重要)
  • User-Agent - 浏览器标识, 暂不展开.
  • Cookie - 用户Cookie, 暂不展开.
  • response_code - 状态码, 是否符合SEO的预期(很重要)
  • bytes - 页面尺寸, 应该有一个合理的范围,超出则报警.
  • time-taken - 耗时, 应该有一个合理的范围,超出则报警.

关于路径的分析,可以参考我的这篇博文.目前还是草稿,有待完善. http://seoaqua.com/seo-specs/

对电商的影响,将来这部分工作基本无法进展:

1.对于某些电商来说流量是次要的,收益是关键的,所以考核的KPI是和收益挂钩,并不简单的是UV. 利用cookie关联订单数据,可以知道每一个关键词的转化情况,以及收益.缺少了这部分数据,会加大SEO完成KPI的难度.

2.landing page的选择.同一个关键词落到不同的landing page,转化率是不一样的.

3.计算每个关键词的投入产出比.有些操作可能是涉及费用的,并与关键词紧密相关的.

百度应该做的改进

  1. 如果只是想让站长换一个地方拿数据,则应该通过站长平台提供全量数据(下载文件,API均可).

  2. 如果不想削弱百度统计的作用,则应该打通统计和站长平台的数据的,平滑过渡.

  3. 不管怎么改,最终的目的都应该是互惠互利,提高全行业的工作效率,提高用户体验,一起抵抗app大潮的冲击.堵住了一条路,就应该放开另一条路,否则就是围剿了.有相当一部分用户的查询需求没有被很好满足(也许这部分检索结果前几的评分都很低,但又没有发现更好的内容),百度应该想办法主动告知站长.everybody's happy!

  4. 如果最终的结果导致大量网站更倾向于自己抓排名分析,整个行业的运行成本又会继续增高.希望能针对这个需求为站长提供API服务,即使是收费的都可以,当然我不太相信百度会这么做.

SEO最严重的问题,往往不是SEO问题,而是产品问题,或技术问题.我接手的项目中,几乎每次大改版都会更换一套URL pattern,而且每个版本之间也许并没有映射关系,也许有映射关系也忘了做301.稍微懂一点搜索引擎常识的人应该明白,每经历一次这种改版就是一次灭顶之灾.我问过一个产品经理,这个产品的URL换过多少套pattern? 答曰:不是3就是4.我从web.archive.org上看,最少8个.并且最新版同时存在了3种不同的pattern.在产品,技术和测试的思维中,往往是没有URL的清晰定义的,只要页面能访问,内容是对的就合格了,更不要提SEO的其他基本规范了.也就是说,事实上除了SEO没有人关心这些东西,每个开发环节都可能遗漏或者搞错一些东西.我希望能有个系统自动的帮我梳理这些问题,让我不再每天担忧SEO的需求又不知道被谁弄掉了,让提bug擦屁股的事情不再占用我太多时间.鉴于此,我的解决方案是:内容思维导图,元信息,页面单元测试,蜘蛛日志监控.这些方案5年前就构思好了,并且小规模试用,但是由于复杂度较高,到过很多坑.绝对不适用于小公司,请广大SEO从业者慎重.

内容思维导图

从产品的角度看是这样由各类功能组成的,有合理流程关系的(流程不展开讨论),符合用户体验的,但可能不符合搜索引擎体验: 产品思维导图

从SEO的角度看,某网站的结构是这样由各类用户搜索需求组成的,也是有合理层级关系的: SEO内容思维导图 不同的网站会有截然不同的思维导图,因为他可能基本取决于技术架构.因此建议SEO从业者深入了解网站的技术架构之后再来绘制导图.具体的细节暂不展开.但是最起码自己要清楚网站有哪些内容节点,哪些命中了用户的需求,哪些是毫无检索意义的,缺少哪些节点,应该如何部署层级关系.

元信息

我这里说的不是, 而是一切SEO相关的,有规律的(最好是可以用正则表达的),可量化的信息.包括:标题,关键词,描述,H1,等等.

从SEO的角度看,某网站的URL是这样的,符合"思维导图"层次的:

  • 首页: www.example.com/
  • 首页-频道1: www.example.com/channel/
  • 首页-频道1-维度1: www.example.com/channel/abc/
  • 首页-频道1-维度1-维度2: www.example.com/channel/abc/xyz/
  • 首页-频道1-详细页: www.example.com/channel/item12345/

从产品,开发,测试的角度看URL可能是这样无序的:

  • www.example.com/channel/?category=abc&brand=xyz&tracking=other_website
  • www.example.com/channel/?item=12345

如果下一版改成这样也没问题的:

www.example.com/?channel=123&category=abc&brand=def&tracking=other_website

如果没有清晰的规则定义,几乎是无法知道现在的网站还是不是你优化过的那个样子的. 根据SEO内容思维导图,我们得到如下的元信息表格(仅列出几个字段给大家参考): 元信息

页面单元测试

这个"单元测试"是借用了一个研发的术语,原本是测试某一个函数或类的.我是用来测试SEO的一个具体的细节定义.工具也是借用了"Rspec"来二次开发的.这个模块可以分为两个环境来运行,production和testing.

其中production的测试,我们叫"回归测试",目的是保证之前已经上线的SEO需求,依然好好的呆在那里,如果报警需要及时修复.

testing环境中,是为了给研发人员做类似TDD(测试驱动开发)用的.它包含了production的回归测试也包含了testing中新的需求,可以被当做是需求文档.只要研发人员把这个测试都跑通,就说明你的需求完成了.当这些需求上线后,把测试合并到production一起做回归测试,这样就圆满了.

测试的内容可以涵盖:元信息中的所有细节,已知链接的锚文本, 站内URL, 站外URL, 面包屑, alt, 响应时间, 页面尺寸,等等.

蜘蛛日志监控

有了"元信息"的定义.做蜘蛛日志监控易如反掌.在百度举办的活动上,有不少的站长会向百度工作人员提出一些根本无法回答的问题: 收录掉了, 抓取掉了, 收录不及时,等等.而从来不会说,"我的某某类型页面每天抓取量多少,其中response200的有多少,平均响应时间是多少,response301的......response4xx的......response5xx的......但是最近收录/抓取掉了"

亲身经历的一些现象:

  1. 全站85%的访问,response code都是301.
  2. 蜘蛛抓取量的50%都是抓异步请求(ajax,iframe)的URL.
  3. 某些类别的页面平均响应时间超过10秒/次.

附图仅展示一些字段给大家做参考 蜘蛛日志监控报告

以下是引用官方客服的答案:

10.10.x.x 和 10.20.x.x 这两个是 VPN 网段,所以不可以添加进智能加速,否则 VPN 会无法正常工作。

下面是以 192.168.x.x 为例的添加方法: 在下载下来的智能加速文件夹中,找到 data 文件夹:

ip-up 末尾加一行: route add 192.168.0.0/16 "${OLDGW}"

ip-down 末尾加一行: route delete 192.168.0.0/16 ${OLDGW}

添加完毕后,断开 VPN,再安装一遍 speed_up,最后重启系统,就可以了。

when compiling ruby 2.2.0 in centos 6.4, you may meet this problem:

make[2]: Entering directory `/home/work/ruby-2.2.0/ext/fiddle'
linking shared-object fiddle.so
/usr/bin/ld: ./libffi-3.2.1/.libs/libffi.a(raw_api.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
./libffi-3.2.1/.libs/libffi.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [../../.ext/x86_64-linux/fiddle.so] Error 1
make[2]: Leaving directory `/home/work/ruby-2.2.0/ext/fiddle'
make[1]: *** [ext/fiddle/all] Error 2
make[1]: Leaving directory `/home/work/ruby-2.2.0'
make: *** [build-ext] Error 2

it says there's some problems with fiddle, so you may wanna reinstall fiddle-devel, which would be told by forums after googling a bit while.

actually the way that worked for me is to enter the directory of 'ruby-2.2.0/ext/fiddle' and do :

ruby extconf.rb
make
sudo make install

now have fun compiling ruby 2.2.0 ^_^

部门功能概述:

我们是在线营销部门. 主要职责是从搜索引擎(百度, 360, 搜狗, 神马), 给公司引入流量, 从而产生订单, 最终获得收益. 大体上是三种渠道: SEO,SEM,垂直搜索. SEO是免费的形式, SEM是付费的形式, 也叫百度推广(其实应该叫PPC,按点击付费). 另外还有垂直搜索渠道(去哪, 到到, Tripadvisor等)

岗位描述:

负责开发SEM渠道账号管理自动化项目,数据对接,业绩计算. SEM是所有电商网站的主要客户渠道之一, 特点是金额巨大, 数据量巨大, 涉及的数据链条比较长, 影响转化率的因素比较复杂. 经过合理的数据分析和挖掘, 可以明显提升转化率, 挖掘出很大的价值. 我们是在线营销专家, 靠技术创造价值. 与技术部的区别是, 我们每个项目为公司带来的收益都可以通过数字体现出来;我们要主动思考如何提高业绩,而不是完成产品经理思考的需求.这对每个人未来发展的附加价值更大.

岗位职责:

目前系统分为六大模块:

  1. 基础数据的收集和管理
  2. SEM账户自动化投放和管理
  3. SEM/SEO数据统计及分析
  4. SEM关键词定价策略以及自动竞价
  5. SEO监控和分析系统
  6. 垂直渠道的数据收集,分析,定价策略,及自动竞价

本岗位会主要负责其中一个模块, 并根据实际需要协助其他同事开发.

岗位要求:

  1. 工作积极主动, 喜欢思考.良好的理解力和表达能力.喜欢从事互联网后端类研发.
  2. 计算机类本科最佳.
  3. 语言要求ruby, 或php/python等脚本语言(但需要在1周内学会使用ruby开发)
  4. 日常开发环境使用 linux/mysql
  5. 具有正常的英语读写能力

目前使用的技术包括:

  • ruby(唯一版本,我们不会同时维护多个版本)
  • linux(centos)
  • mysql(mariadb)
  • git(gitlab)
  • map-reduce(hdfs)
  • redis
  • soap
  • capybara
  • capistrano

未来需要探索的技术:

  • NLP
  • ML
  • R

附加条件(非必须):

  • 最好熟悉http, socket, html, xml, map-reduce, 多线程, git, github
  • 最好使用Mac, 公司提供Mac本

我的联系方式:

  • QQ/微信: 628552 (建议加QQ, 微信不谈工作)
  • 我的博客 http://seoaqua.com
  • github账户 http://github.com/seoaqua
  • 队员作品 http://github.com/warriors-of-the-night/ (待补充)
  • 微博 http://weibo.com/seoaqua
  • 公司邮箱 charles.liu@corp.elong.com