译者定义: 1. 应用页面 的原文叫“app screen”,相当于一个网页,比如你在看知乎APP中的一篇帖子,那么这个帖子就是一个“应用页面”。 2. TDK的意思是“标题 描述 关键词”

=============================================================== 苹果和谷歌会在每年的6月份公布最新的技术进展。两家公司都会重申更远大的目标和更高的价值空间。苹果公司更倾向于产品的设计和销售;谷歌则会鼓吹他的终极使命,收集和结构化全世界的数据,而实际意图则是通过广告将搜索结果变现。

从两家公司很多商业决策上来看,不同的价值观体现的淋漓尽致,尤其是近期提出的完全不同的APP索引框架。在很长时间里,APP中的内容都禁锢在程序代码里,对于搜索引擎爬虫来说几乎是不可能访问或索引的。爬虫唯一可以获取到的仅仅是各种应用商店里的标题和描述。

随着苹果和谷歌公布了APP内容的索引方案,这种局势戏剧性的来了个180度大转弯。对于致力于数字营销的从业人员来说,SEO的概念必须要重新定义了。

苹果的产品体系使得他很容易从应用中获取最重要的数据。在苹果理想的架构中,web只是一个透明的中间层,负责把APP连接起来,让APP成为私有或公共内容的展示层,而APP入口是由苹果统一控制的。

相反的,谷歌更倾向于从基于web的世界中获取数据(因为web数据易于收集、组织和传播),从而占据互联网的入口。正因为应用只是数据收集策略的一部分,谷歌投入了巨大的资源,启动了各种项目,鼓励开发人员创建HTML5的web内容和APP抗衡,希望借此把用户拉回基于web的生态系统中。

这篇文章是三部曲中的第一部,整个系列都是关于苹果,谷歌或其他生态系统对APP索引的新策略以及相应的新机遇。

第一篇文章集中论述苹果在iOS9中采用的新搜索API对APP生态系统的鼓励政策,以及营销人员应该如何向Apple用户展示深层的应用内容。这篇完整的教程主要讲述了以下几点: 1. 苹果首次尝试的搜索工程,SEO从业者需要知道什么。 2. 对公司的APP策略有哪些影响 3. 对公司的SEO策略有哪些影响 4. 如何利用这些新机遇来提高APP和网站在苹果搜索中的曝光度

本系列的后续文章会着重阐述两大块。谷歌app索引中的机遇,和应对的策略。可穿戴设备和其他非标准设备的快速增长下,我们即将面临的挑战。

什么是苹果搜索 & 为什么对SEO如此重要? 如果你想对iOS用户展示应用内容,苹果搜索就是SEO策略中的关键一环。和谷歌类似,苹果搜索也是用索引(或者更确切的说是多重索引)来管理应用页面集合与排序的。这些索引和调用索引的软件统称为“苹果搜索”。

索引中的应用页面可以在一次Spotlight搜索或Siri搜索中被触发,也可以在Safari地址栏中通过Spotlight建议触发(用户在输入的同时,而且在按下“回车”之前)。那么这意味着用户在Safari中搜索时可完全绕过谷歌搜索结果,直接启动相应APP并进入对应的内容页,即使谷歌是“默认”搜索引擎。

为了达到这个效果,苹果引入了公共索引和私有索引的概念,以及三种索引方法,分别是:NSUserActivity, CoreSpotlight, 和 Web Markup。

虽然局限于iOS应用索引(不好意思,安卓阵营的朋友们,没法带你们一起玩),苹果的新搜索和索引框架必将成为一个重量级流量入口,尤其对于苹果用户而言,因为这和谷歌算法完全无关。与谷歌不同,苹果提出了两种不需要对应网页的APP索引方案:

  1. NSUserActivity 索引

在这个方案中,苹果可以把用户行为编入索引,你可以理解为一种“书签 + JsessionID + cookie”的应用页面快照,同时又补充了用户行为信息(用户是如何进入这个应用页面的,之前是如何于这个应用页面交互的)。这些快照,即苹果所定义的“NSUserActivities”,可以根据开发者的程序逻辑打上搜索标记(完全脱离了网站),用户就有机会搜到了。

每一个NSUserActivity都可以关联到一个contentAttributeSet,其中包括相关的TDK元信息,比如标题,关键词,描述。这些信息会被用于最终给用户展示的搜索结果中,也是排序的影响因素。每一个NSUserActivity都应该包含一个uniqueIdentifier,最好还包含一个相应网页内容的URL链接。

  1. CoreSpotlight Indexing CoreSpotlight API之前只允许系统自带的iOS组件,比如日历,邮件,在Spotlight搜索中建立索引。现在已经对所有App Store中的应用开放了。这种索引方案有点像SEO工作中的“提交XML sitemap”,只不过这次提交的是一个清单(manifest),而且格式是专为iOS定制的。这个索引文件就是“CSSearchableIndex”。

在这个索引方案中,每一个应用页面就是一个CSSearchableItem,并且需要于“uniqueIdentifier”标签关联。每一个CSSearchableItem可以关联一个CSSerchableItemAttributeSet属性集合,比如TDK。这个CSSerchableItemAttributeSet不仅仅是给用户展示搜索结果用,也会影响搜索排序。

每一个CSSearchableItem + uniqueIdentifier 组合都可以关联到“domainIdentifier”,用于在数据库中对特定类型的应用页面分组,利用分组可以很方便的加入或者退出CSSearchableIndex。比如一个uniqueIdentifier可以和一个特张的图片绑定,domainIdentifier可以看作是同一个相册中的所有图片。

需要注重的一点是,NSUserActivity 和 CoreSpotlight是从应用内部的代码中获取元信息的,不是网站。这意味着SEOer需要尽早参与到应用开发的过程中,才能确保苹果搜索结果的TDK和索引标记在应用激活的时候加载出来。(就像1999年的网页一样)

除了NSUserActivity和CoreSpotlight,苹果还提供了一种通过爬去网页内容获得应用页面的方案,有点类似谷歌的做法。Deep linking 是把网页URL映射到应用页面(或者叫URI)的一个过程,这样爬虫就能理解URL和URI的关联。这个方案就需要应用内容有对应的、可抓取的网页内容了:

  1. Web Markup Indexing 在这个索引方案中,苹果的网页爬虫,Applebot,会顺着应用提交时自带的公司信息(市场合作,技术支持)URL抓取网页。苹果爬虫会根据以下markup协议抓取和索引应用页面:

  2. Twitter Card Markup: 可以包含一个向应用页面提供deep link的协议。
  3. App Links Protocol: 这是一个额外的链接标准,Facebook和必应都在使用,iOS和安卓系统也都支持。
  4. Apple’s Smart App Banners: 苹果建立的协议,用于在iOS设备访问网站时,在网页上展示一个特殊的苹果广告条。用户如果已经安装了app会看到“打开”按钮,点击直接打开应用;否则会看到“安装”按钮,点击后就会跳转到App Store进行下载。

补充一句,即便这个功能没有帮你提高应用页面的索引量,Applebot也可以通过下面两个协议补充可展示在搜索结果的元信息:

  1. Open Graph:Facebooke的协议,为了让网页内容更容易分享。苹果完整的支持了这一协议,如果已经开发过了,就等Applebot抓取吧。
  2. Schema.org:一种在web行业广泛使用的额外的markup标准。苹果搜索只支持一部分功能,包括这么几种格式: AggregateRating(评价数), Offers(大礼包), PriceRange(价格区间), Interaction Count(互动次数,比如阅读量,评论数), Organization (公司信息,比如电话), Recipes(配方), SearchAction (搜索,即搜索的着陆页), ImageObject(图片信息) Actions(各种操作),仅限:拨号,导航,播放音频或视频。

Web Markup对SEOer是很方便的,跟以往的操作没有什么区别,只需要在网页上添加特定的markup就可以很方便的控制索引了。iOS的开发人员只需要把URI格式告诉SEO团队。如果应用已经支持URI了,下面的工作会很快,而且不需要太多的开发资源了,也不用更新应用。

请注意:当iOS用户在网页上点击deep link的时候,系统会初始化一个“openURL”的命令通知操作系统从浏览器切换到对应的应用。这个openURL功能必须在应用代码里设置开启。

必须确保你的应用可以支持deep link之后才能在网页上添加markup。即使你只采用 Web Markup的索引方案,也需要支持deep link。这个细节非常重要。

苹果搜索的排序原则是什么? 随着全球对个人隐私问题的越发关注(比如欧盟的Right to Be Forgotten法案),苹果已经开始用保护个人隐私的特性来达到差异化营销的效果,并把这作为产品及服务的一个卖点。苹果最新的应用索引框架明显地展示了对用户个人信息保护所付出的努力。请看一下这两个应用索引方案:

  1. 自有设备索引,是一个只有特定用户才能访问的非公开索引,有点像给每个独立苹果用户单独定制的小型数据库。
  2. 公有云索引,数据可以被任何一个苹果设备访问,可用于Spotlight, Siri, 或者Safari中的 Spotlight Suggest服务。 在这种架构下,开发者可以(而且应该)把用户的个人应用页面只提交给非公开的Device Index。理论上任何一个应用页面都可以被检索了,比如私信。

注意:谷歌也曾经提供过类似的个人搜索历史的功能,但是从未公开的描述为“索引”,或开放给开发者们使用。谷歌很多年前就试验过“桌面检索”工具,并且最近开始测试Gmail个人电子邮件的检索。我们希望谷歌和苹果的这种趋势能够继续发扬光大。

跟谷歌一样,苹果并没有透露搜索算法的准确细节,但是给出了几点需要关注的,影响排序的关键因素。许多苹果搜索排序的考虑因素都是集中在如何决定自有设备索引和公有云索引的排序孰先孰后。SEOer们需要倍加小心,严格监控,保证优化对搜索结果是积极有益的影响,因为苹果声明恶意或不负责任的优化策略会被惩罚或彻底下架。所以不要精力放在研究如何作弊上了。

更完整的苹果搜索排序影响因素请看下面:

可能提高排名的因素: 1. 应用安装状态。用户是否已经安装过?安装过的应用似乎表现更佳。 2. 个体用户的参与度。用户频繁使用的应用页面会被优先展示给这个用户自己。这个算法可以基于苹果对用户session的分析实现。 3. 搜索结果的点击率。用户是否会点击你的搜索结果?还是选择了下一个结果?或者没有点击就重新搜索了? 4. 关键词和标题。关键词和标题与用户查询词的相关性。 5. 所有用户的参与度。所有用户对这个应用页面的使用次数。 6. 网页中的结构化数据。结构化数据是否按照标准正确实现了? 7. 统一的App ID。在任何不同的索引方案中(NSUserActivity, CoreSpotlight, and Web Markup),同一个应用页面应该使用唯一的ID,或者URL。 8. 网页的流行度。类似谷歌PageRank的概念,每一个关联到APP deep link的网页都可以计算出流行度。苹果蜘蛛可以根据抓取情况判断流行度,从而计算APP的排名顺序。

可能降低排名的因素: 1. 低参与度。某个应用页面是不是很少被人使用? 2. 过度索引。你的APP有没有索引了一大堆没人用的应用页面? 3. 返回率。用户通过搜索进入你的app以后,马上又回到了搜索结果? 4. 滥用关键词字段。加入很多无关的关键词。 5. 插播内容。应用页面的上面又覆盖了一层广告或者任何什么东西,让用户无法正常访问。 6. Javascript(仅适用于网页)。Javascript有没有阻止Applebot抓取网站发现新的app deep link? 7. App Store内的评级。苹果没有正式声明星级低的,评论数少的,评论差的应用会不会受影响,但既然适用于App Store的排序,应该也适用于Spotlight排序。

题外话,感兴趣的同学可以安装“艺龙”或“携程”的ios app,点开后回到桌面,手指下拉触发spotlight,然后搜“酒店预订”等关键词,也可以使用“知乎”的ios app,浏览一些文章后,搜索浏览过的内容关键词看看效果。

苹果期望通过多种索引方法优化APP的展现,但是这几种方法必然造成重复索引。比如私有内容可以同时使用NSUserActivity 和 CSSearchableItem索引,而公共内容可以同时使用 NSUserActivity 和 Web Markup。

重复索引肯定会增加Applebot的工作难度,从而降低排名。因此苹果强烈建议在三种索引方式中使用相同的ID或者URL。其实这个东西就相当于谷歌定义的canonical,对于苹果来说是影响排名的最重要因素之一,因为算法中可用的因素就那么几个。

译者:刘明 本文未经许可,禁止转载! 原文来自: http://searchengineland.com/app-indexing-new-frontier-seo-apple-search-ios-app-indexing-223880

一般的大网站会划分产品,运营,销售,营销,研发等部门。其中几乎所有职能部门都会给研发部提需求,排期,上线,改BUG。营销中的SEO往往是被排在优先级靠后的位置,SEO的需求实现很慢,而出了BUG也比较靠后才会修复。为了解决这个问题,我提出一个“SEO PUSH API”的概念。 相信很多公司已经这么做了,比如的友情链接管理(全站每个页面都不同,不是说首页的),TDK的单独定制。我所描述的这个API,无非是将所有SEO需求都综合到一起了,没什么难理解的。

SEO PUSH API

好处有三点:

一,可以任意定制每个页面的SEO元素:

举个例子(临时找的,如果不准确请原谅),先说好几个前提:

  1. 我们先假设例子中的模板是没有问题的,命中了大部分的用户的需求。
  2. 百度指数真实反应了实际用户查询需求。
  3. 假设这个网站上没有更好的页面来匹配“花冠和卡罗拉的区别”。
  4. 更换完title之后,内容仍然是100%符合用户需求的。
url  :  http://price.pcauto.com.cn/pk/sid-487-2734.html
title: 【花冠和卡罗拉哪个好?】发动机、油耗、空间等对比_太平洋汽车网

他的模板是:

【{车型1}和{车型2}哪个好?】发动机、油耗、空间等对比_太平洋汽车网

他想匹配的用户需求是:xx和xx哪个好

但是从百度指数上看“花冠和卡罗拉的区别”指数不错,而“花冠和卡罗拉哪个好”,却没有记录。

“花冠和卡罗拉的区别”的百度指数 “花冠和卡罗拉哪个好”的百度指数

那么这个页面的title应该被定制为:

【花冠和卡罗拉的区别】发动机、油耗、空间等对比_太平洋汽车网

下面说理论。如图所示,当用户访问产品的Web服务器时,看到的页面是经过SEO人员定制的,模板化的页面。比如:

title       = {车型名称}_{车型名称}价格_{车型名称}评估_{车型名称}怎么样
keywords    = {车型名称},油耗,评估,怎么样
description = {车型简介}。市场价:{市场最低价}~{市场最高价},油耗:{油耗},好评度:{好评度}。
h1          = {车新名称}
h2          = ...
介绍部分      = ...
友情链接      = ...
(其他需求暂不赘述)

模板基本可以满足大部分需求,也便于技术实现。但对于有些商品,用户的搜索习惯却和模板不一致。当发现这种需求量大的时候,需要SEO运营人员在后台针对某个URL定制有针对性的SEO元素,还可能需要人工手写差异化的内容,或者由SEO的技术团队从其他的数据源对接。

二,便于SEO需求和产品需求的隔离:

SEO的很多需求是关于内容相关性,而产品的很多需求往往是关于用户体验的。两类需求都由同一个技术团队来实现,必然顾此失彼。在大型网站中,SEO团队是可以专门配置技术人员的。这样就可以将两类需求分割给不同团队来实现,再通过API对接,展示到前端。这样可以使得产品和SEO的需求并行实现,极大提升了生产效率。并行的意思就是,SEO的很多需求完全可以通过后台运营实现,而不需要麻烦web技术团队了。而web技术团队可以集中精力改善用户体验和网站稳定性。

三,SEO的需求可以随时上线,而不必等迭代周期:

友情链接的时效性就不用说了。其他方面的改动,如果运气好的话,第二天就可以看到效果。改动周期越短,越能提高工作效率。

完整的格式定义

总原则:      若任何一个key的value没有内容(null或""),则跳过,不做任何处理,避免生成一个奇怪的html标签。
title:        替换<title>标签内容
keywords:     替换或生成<meta name="keywords">标签中的content属性内容
description:    替换或生成<meta name="description">标签中的content属性内容
canonical:    替换或生成<link rel='canonical' >标签中的href属性内容
location:     替换或生成<meta name="location" >标签中的content属性内容
robots:       替换或生成<meta name="robots">标签中的content属性内容
device:     替换或生成<meta name="applicable-device" >中的content属性内容
cache:      替换或生成<meta http-equiv="cache-control" >中的content属性内容
inlinks:      生成“相关链接”栏目的链接内容,用于网站内部链接
outlinks:       生成“友情链接”栏目的链接内容,用于给其他网站的链接
agent:        生成或替换<meta name="mobile-agent" content="format=html5; url="/> 中的url
introduction:     生成N个栏目,栏目名称根据name字段定义。比如“北京酒店的相关评论”,“西直门附近比较好的快捷酒店”。栏目内容是对应的text字段
require 'json'

SEO = Hash.new

SEO['title']        = '【艺龙旅行网】酒店预订_机票查询_酒店团购_电话4009-333-333'
SEO['keywords']     = '酒店预订,机票查询,酒店团购,艺龙旅行网'
SEO['description']  = '艺龙网-中国领先的在线旅行服务提供商,纳斯达克上市公司.提供全球20万家酒店预订服务:高星酒店返现101元起,经济酒店返现30元,酒店团购1折起!海外酒店全场9折!低价有房保障-无房赔付首晚房费,差额3倍赔付.订酒店,用艺龙!'
SEO['canonical']    = 'http://www.elong.com'
SEO['location']     = 'province=广西;city=百色;coord=106.658,23.0294'
SEO['robots']       = 'all'
SEO['device']       = 'pc,mobile'
SEO['cache']        = 'no-transform'
SEO['inlinks']      = [
                       0 =>  {
                               'text'   => '北京酒店预订',
                               'url'   => 'http://hotel.elong.com/beijing/'
                             },
                       1 =>  {
                               'text'   => '上海酒店预订',
                               'url'   => 'http://hotel.elong.com/shanghai/'
                             }
                     ]

SEO['outlinks']    =[
                     0 =>  {
                             'text'  => '携程旅行网',
                             'url'   => 'http://www.ctrip.com'
                           },
                     1 =>  {
                             'text'  => '同程旅游网',
                             'url'   => 'http://www.ly.com'
                           },
                     2 =>  {
                           'text'  => '途牛旅游网',
                           'url'   => 'http://www.tuniu.com'
                         }
                   ]

SEO['introduction'] = [
                       0 =>  {
                               'name' =>   '艺龙旅行网简介',
                               'text' =>   '酒店预订。艺龙旅行网提供全球50万家酒店的预订服务和酒店团购服务。通过真实的酒店照片、酒店评价,无论您是和家人一起旅游度假还是商务出行,我们都能为您提供称心如意的酒店。
                                           艺龙酒店地标大全。为了方便用户快速定位酒店而存在,我们涵盖了北京、西安、上海、成都、广州、武汉、南京、东莞、长沙、深圳、重庆等城市的常见地标类型。'
                             },
                       1 =>  {
                               'name' =>   '国内酒店预订方法',
                               'text' =>   '国内酒店简介国内酒店简介国内酒店简介国内酒店简介国内酒店简介国内酒店简介国内酒店简介国内酒店简介国内酒店简介国内酒店简介国内酒店简介国内酒店简介'
                             },
                       2 =>  {
                               'name' =>   '国际酒店预订流程',
                               'text' =>   '国际酒店预订流程国际酒店预订流程国际酒店预订流程国际酒店预订流程国际酒店预订流程国际酒店预订流程国际酒店预订流程国际酒店预订流程'
                             }
                     ]


puts SEO.to_json

技术方面再啰嗦几句 ========== 1. 这个API所推送的内容,在Web端必须有缓存(以URL为key)。如果使用主动缓存(有新内容则及时覆盖旧内容),那么SEO需求的改动可以随时生效。 2. SEO部门只运维离线数据库,单机即可,不保证可用性。生产库必须由Web技术部门运维,必须有负载均衡或其他手段保证可用性。即使离线数据库挂掉1年,也不能影响线上的内容。 3. API其实是由Web部门提供的,采取push的方式(可以用http post),由SEO部门从离线库push到生产库。千万不要从离线库pull数据,毕竟这是单点服务。 4. 请一定做好语法风险控制,即api中的内容不应该包含html语法符号。否则很可能导致页面排版错乱。

什么是百度蜘蛛的referer

百度蜘蛛的referer,是指当百度蜘蛛抓取某一个URL的时候,在HTTP头中带的Referer字段。请注意,这个定义和百度最近声明去除Referer中关键词数据没有任何关系。这次讲的是spider发起的HTTP请求,百度而去除的是用户发起的。如果百度蜘蛛抓取百度首页的logo,会发起这样的请求:

GET /img/bd_logo1.png HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html
Referer: https://www.baidu.com/

上面Referer字段很明确的表示了他是从www.baidu.com这个页面上发现并抓取了www.baidu.com/img/bd_logo1.png。而大家在服务器访问日志中也应该能看到相应的记录。目前发现只有当百度抓取一个网页的同时,又抓取了网页中的:img、js和css才会带上referer字段。这部分额外的抓取量,应该不会占用百度分配的抓取配额,属于“买1送1”。

对于站长的意义

如果你发现有一批URL(仅限于img,js,css)报错(4xx或者5xx),但是一直找不到入口在哪,也就是说你不明白百度蜘蛛是从哪里发现这些错误URL的。这个字段可以帮助你迅速定位。

举个例子

比如我们的SEO日志分析系统中可以看到,符合下面这种URL Pattern的路径每天有6万到10万的抓取而且全部报404。

/\d{6}/\d{2}/.+

日志统计中的404

从发现问题至今过了1个月,查遍整个网站我也没找到入口。今天偶然仔细查了一下日志,想起了百度蜘蛛的referer,马上就能定位问题了。这些404的URL来自于一套没人维护也没人关注的页面(往往是这样)。收录流量都不错。由于最近公司图片系统更新,图片的URL全部更改了,但这套页面并没有跟着更新。

如果站点没有记录referer怎么办

iis请在这里勾选“cs(Referer)”:

iis-log-1 iis-log-2

apache请参考:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/access_log combined

Nginx请参考:

log_format combined '$remote_addr - $remote_user [$time_local]  '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

结束语

  • 很多SEO问题并不是立即致命的,所以没有及时解决。流量就像蚂蚁啃大象一样一点一点啃掉了。
  • 系统性的知识积累还是会在关键时刻发挥作用的。
  • 感谢飞鹰对本文的修正。

首先声明,我们只谈论有检索意义的URL,也就是用户会从搜索引擎查找的页面.其他页面按照常用的方法做屏蔽就好了.

鉴于很多站长都爱讨论整体的收录量,我必须泼一下冷水,也许你的有效收录是1/10.

URL参数

也叫URL query,是一个最复杂,最容易被忽视,最容易被妥协的问题.他是网站运营中必不可少的元素,如果简单的去除,其他部门就无法工作了. 静态化是的话题,URL参数经常被用于以下几方面:

同一个实体的不同状态展示,比如同一个酒店,在不同时间点会有不同的房间库存.

http://www.travel.com/hotel/123/?checkindate=2015-06-09&checkoutdate=2015-06-10

为了统计不同渠道的流量

http://www.a.com/?tracking=website_a

为了统计不同渠道,具体模块的点击量

http://www.a.com/?tracking=website_a&click_spot=zone_abc

调试

http://www.a.com/product/item123/?debug=true

全世界最奇葩的是亚马逊,居然把统计参数放到了路径中

http://www.amazon.cn/abc/dp/B005TZHJEQ/ref=lp_2130608051_1_1

出现这种问题的坏处有几点:

  1. 浪费搜索引擎对你网站的各项配额,从而影响其他正常的页面.
  2. 丢失很多本应拿到的链接加分,站外渠道的链接往往是最优质的.同一个URL的分值可能分散成几十份.
  3. SEO的流量被统计到别的渠道(因为tracking字段写的是别的渠道,而且被收录被点击)
  4. 往往形成一种局面,产品用一套URL,SEO用另一套URL, 甚至不同渠道用不同的URL,后期开发和维护的成本极高.

为了解决这个问题,首先要弄清网页的URL的定义.以我的理解,每一个URL是一个静态的,独立不重复的,有意义的实体,一般也有检索意义(就是有人会搜).比如一个人,一辆车,一条道路,一个零件.而不能混入各种”状态”,比如这个人生病的时候,难道就不是他自己了么? 一件商品在促销的状态难道是另一件商品了么?

理论上canonical标签就可以解决这个问题了, 但是从实际测试结果看,百度对这个标签的支持优先级非常低, 几乎可以忽略不计.那么我的解决方案是这样的:

  1. 建立好网站的思维导图和元信息. (可参考:SEO健康度 )
  2. 所有和SEO元信息相关的参数都放到路径中去
  3. 所有和SEO元信息不相干的参数都放到#后边,因为#后边不影响web服务器返回的内容.简单的说就是用”#”替代”?”.
  4. 每个页面中都利用js获取#后边的参数对,通过二次请求发回给统计服务器
  5. 如果#后边的参数影响页面内容,比如酒店的入住日期.那么这部分内容用ajax加载就行,他是不稳定的,不属于页面内容的一部分.(当然还有变通的办法,暂不赘述.)
  6. 原始的#锚点定义肯定会冲突,定义一个#后边的变量,并用js控制屏幕滚动,来保证原始锚点的作用.

有人可能会想到,根据ua判断,如果是搜索引擎爬虫,就用跳转的方式去掉URL参数.但效率最高的方法必然是从一开始就不展示错误URL.那么前面的例子优化后就变成了:

http://www.travel.com/hotel/123/#checkindate=2015-06-09&checkoutdate=2015-06-10
http://www.a.com/#tracking=website_a
http://www.a.com/#tracking=website_a&click_spot=zone_abc

http://www.a.com/product/item123/#debug=true

其实我们的竞争对手早就使用这种方式了,但是由于我们的开发效率无法及时实现,还没有赶上行业的进度.所以对于一般的小网站,一定要考虑开发成本,不要轻易冒进.只要能避免问题的发生,变通的方法是很多的.

路径中使用非必要元素

很多网站仿照亚马逊的做法,把商品名体现在URL中,然后再通过id来决定页面展示的内容:

http://www.amazon.cn/博集典藏馆043•基督山伯爵-亚历山大·仲马/dp/B005TZHJEQ/

这样虽然可以提高一些相关性,但是很危险.在长期甚至短期的时间内,大量商品的名称是非常可能有变化的,那么URL也就跟着变化.成本也是非常高的,因为加大了技术实现难度,不管从站内还是站外,每次增加链接都是一个很麻烦的事情.

在我接手艺龙SEO之前,URL被全部改成了这样,对我早期的工作造成了非常巨大的负担:

http://www.a.com/Shangrila_International_Hotel-12345678-hotel/

通过日志分析发现基本所有的百度蜘蛛发起的请求都被301跳转了一次(日志分析方法可参考SEO健康度 )

细致调查后发现,从SEO拼接规则到后台的汉字和翻译数据被一直修改.也就是说,这个URL相关的元素有:

  1. 中文 (非必要元素)
  2. 由中文翻译的英文 (非必要元素)
  3. id (必要元素)

而当时负责SEO的同事把英文和id拼接在了URL中

那么这样一个URL先后变成过:

http://www.a.com/Shangrila_International_Hotel-12345678-hotel/
http://www.a.com/Xianggelila_International_Hotel-12345678-hotel/
http://www.a.com/XiangGeLiLa_International_Hotel-12345678-hotel/
http://www.a.com/Shangrila_guoji_Hotel-12345678-hotel/

跟”相关性”比,URL的唯一性和稳定性更重要.所以针对这个问题,URL的最佳策略应该是

http://www.a.com/hotel/12345678/

如果这个id是隶属于一个分类下的,比如城市,那么就可以

http://www.a.com/hotel/beijing/123/

从技术角度说, id一般是数据库的primary key,可以是数字也可以是字符串,那么这个时候URL是一维的; id也可以是联合的唯一索引,那么URL就是二维的,就像上面的(bejing,123)缺一不可.电商类网站列表页经常用到三维以上.

大小写

如果网站的技术架构用的是开源系统,一般是不会有这个问题的.如果使用了微软的技术架构,这个问题非常常见.

http://www.a.com/newyork/
http://www.a.com/Newyork/
http://www.a.com/NewYork/

我的建议是统一使用小写,大写自动跳转为小写(小心301死循环!).

目录的规范

很多网站同时存在这样的URL,无形中把收录量扩大了一倍.

http://www.a.com/product/123
http://www.a.com/product/123/

上边第一个路径的意思是在product目录下有一个123文件.第二个路径的意思是在product目录下有一个123目录,这个目录下可能有很多文件,但是他代表众多文件中的index.html或index.php或default.aspx等优先级最高的那个文件.为了避免歧义,我定义文件都是用”.html”结尾的.

为了减少重复收录,那么按我的习惯是:

http://www.a.com/product/123  => http://www.a.com/product/123/
或者
http://www.a.com/product/123  => http://www.a.com/product/123.html

总结

  1. 所有部门统一使用SEO定义的URL,屏蔽非SEO URL的入口.
  2. 用”#”替代”?”
  3. 统一使用小写
  4. 保证目录的规范
  5. 把不规范的URL跳转到规范的URL

这次事件的影响和意义

接受采访前调查了一下大家对这次事件的理解,发现这篇文章写的最好. 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服务,即使是收费的都可以,当然我不太相信百度会这么做.