一般的大网站会划分产品,运营,销售,营销,研发等部门。其中几乎所有职能部门都会给研发部提需求,排期,上线,改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的需求可以随时上线,而不必等迭代周期:

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

技术方面再啰嗦几句

  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服务,即使是收费的都可以,当然我不太相信百度会这么做.

本篇文章的意义之一,很多站长对自己网站健康状况没有头绪:

在百度举办的活动上,有不少的站长会向百度工作人员提出一些根本无法回答的问题:

  1. 收录掉了,怎么办?
  2. 抓取掉了,怎么办?
  3. 流量掉了,怎么办?
  4. 排名掉了,怎么办?
  5. 收录不及时,怎么办?

这些问题太笼统了,即使把百度所有后台数据完全开放,也无法解答。提问的人肯定是连网站的基本结构都没有清晰的认识。好的问题是怎样的?耐心看完就有答案了。

本篇文章的意义之二,产品改版对SEO造成毁灭性打击

SEO最严重的问题,往往不是SEO问题,而是产品问题,或技术问题。有些大型网站每次大改版都是这样的:

  1. 会更换一套URL pattern。
  2. 由于数据的不兼容,旧版本pattern无法301到最新版。
  3. 即使数据兼容,也忘了做301。

我问过一个产品经理,这个产品的URL换过多少pattern, 答案是3到4个。但是我从web.archive.org上看,最少8个。平均每年换一个。稍微有一点搜索引擎基本常识的人应该能意识到,这种网站是典型的no zuo no die。

本篇文章的意义之三,长期的迭代开发流程中,SEO的需求可能被逐步改错

在产品,技术和测试的思维中,往往是没有URL的清晰定义的,只要页面能访问,内容是对的就合格了.以下几种URL都是被认为没问题的:

  1. http://www.a.com/product(category)/
  2. http://www.a.com/product.html/
  3. http://www.a.com/product/?channel=123&category=abc&brand=def&tracking=other_website

更不要提SEO的其他基本规范了。也就是说,事实上除了SEO没有人关心这些东西,每个开发环节都可能遗漏或者搞错一些东西。

曾经有一个产品,本来谷歌收录量达到了3000万,百度收录2000万,流量也不错,精力挪到别的产品上去了。 过了1个月发现流量有所下滑,以为是季节因素,没有在意,又过了2个月,流量下降非常多。仔细检查了一下发现一个惊人的变化。

  1. 本来收录的地址是http://www.a.com/product/item100.html。
  2. 在没有被告知的情况下,被技术同事加了一个301跳转,到http://www.a.com/search/?product=a&item=100。
  3. 其中/search/目录在robots.txt中是Disallow的。
  4. 在随后的2周内,收录量最低降到了300万左右。

我希望能有个系统自动的帮我梳理这些问题,让我不再每天担忧SEO的需求又不知道被谁弄掉了,如果有问题,能让开发测试的同事马上就收到警报,让“擦屁股”的事情不再占用我太多时间。

内容思维导图,元信息,页面单元测试,蜘蛛日志监控

鉴于前边几点,我的解决方案是:

  • 内容思维导图
  • 元信息
  • 页面单元测试
  • 蜘蛛日志监控

这些方案5年前就构思好了,并且小规模试用,但是由于复杂度和开发成本较高,到过很多坑。直到最近两年才逐步启用。绝对不适用于小公司,请广大SEO从业者慎重决策。

内容思维导图

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

从SEO的角度看,网站的结构是这样由各类用户搜索需求组成的,也是有合理层级关系的: SEO内容思维导图 不同的网站会有截然不同的思维导图,因为他可能基本取决于技术架构。因此建议SEO从业者深入了解网站的技术架构之后再来绘制导图。具体的细节暂不展开。但是最起码自己要保证这几点:

  1. 网站有哪些内容节点
  2. 哪些命中了用户的需求
  3. 哪些是毫无检索意义的
  4. 缺少哪些节点
  5. 应该如何部署层级关系

思维导图绝对不是一劳永逸的,每当产品有新的pattern上线,或者旧的pattern下线,需要及时更新。每当你发现新的用户搜索习惯,也应该更新,并且推送给产品同事知道。

元信息

我这里说的不是, 而是一切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, 响应时间, 页面尺寸,等等。

蜘蛛日志监控

有了“元信息”的定义。做蜘蛛日志监控易如反掌。

亲身经历的一些现象:

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

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

针对本文开头的问题,比较靠谱的提问方式是, “我的某某pattern页面每天抓取量多少,其中response200的有多少,平均响应时间是多少,主要的内容,SEO元素都正常,没有作弊的行为,但是这个pattern最近抓取掉了,收录掉了”。 其实能问这种问题的人,也基本不用提这类问题了。大多数的问题只要足够细化,就已经迎刃而解了。