Return to site

使用Big Query进行日志分析的完整指南

· seo优化

对日志分析感到好奇吗?本指南将涵盖从您为什么要这样做,到获取日志,上传和分析它们的所有内容。

你需要任何编程技巧来遵循这个吗?不,但我们会为那些做的人提供一些选择。

你需要知道SEO吗?是。如果你不这样做,那么希望你为什么感兴趣,但是日志分析本身并不好。要利用它给你的所有信息,你需要知道你的SEO基础知识,并能够抓取并理解它将突出显示的可能问题。

什么是TL;本文的DR?您应该使用分析日志获取有关Google如何抓取和查看您的网站,发现和监控错误以及确定决策优先级的宝贵见解,通过使用BigQuery,您的分析将变得简单且可重复,并且您可以使用我们已编写的所有令人惊讶的查询。

内容
什么是日志?
你为什么要做日志分析?
诊断爬网和索引
优先级
发现错误并检查网站运行状况
了解Google对您网站的部分内容的重要性
衡量内容的新鲜度
如何获取日志
有没有PII
所有日志文件都在同一个地方吗?
移动网站
网站部分
网站缓存
可用于分析日志的不同工具
BigQuery的
高强
麋鹿
商业日志工具
你自己的SQL服务器
如何处理日志
使用Screaming Frog Log Analyzer处理日志
将日志上载到BigQuery
如何分析日志
验证您的数据
一个快速的SQL教程
将您的数据与Google Search Console进行比较
分析日志的过程是什么
问正确的问题
什么是日志?
每次访问网站时,服务器都会向您发送页面并写下有关要求的人的一些基本信息。对于访问您网站的任何人,人或机器人的每一个请求,这都是一行。

日志文件条目如下所示:

123.65.150.10 - - [23 / Aug / 2010:03:50:59 +0000]“GET / my_homepage HTTP / 1.1”200 2262“ - ”“Mozilla / 5.0(兼容; Googlebot / 2.1; + http:// www .google.com / bot.html)“

IP地址:这是访问该网站的人或机器人的IP。这是他们的网址。
时间戳:这是请求的时间(和时区)
请求类型:GET请求(您在大多数时间看到的)是要求页面的人或机器人,PUT请求是发送信息的人(例如发送表单)。
页面:正在请求的页面,在本例中为my_homepage。
协议:这将始终显示HTTP,如果您有一个混合的HTTP / HTTPS网站,您需要让开发人员为此设置跟踪。
状态代码:指示服务器响应类型的数字,例如200 - 返回请求,301 - 重定向请求等。
页面大小(以字节为单位):用户下载的文件的字节数。
用户代理:机器人的名称,或用户用于访问网站的浏览器版本的名称。
想在收件箱中获得更多这样的建议吗?加入月刊。

Email address...
你为什么要做日志分析?
在查询部分,您将能够看到您可以通过日志分析查询的所有详细问题,但大多数情况下最适合5个主要问题:

诊断爬网和索引问题
优先级
发现错误并检查网站运行状况
了解Google对您网站的部分内容的重要性
衡量内容的新鲜度
诊断爬网和索引问题
这是日志文件分析的基础。如果Google在抓取您的网站时遇到问题,那么可能会产生很多负面影响:

如果您的内容未编入索引,那么您就错过了潜在的流量。
您所做的任何更改都可能需要很长时间才能生效延迟结果。
如果您尝试衡量网站上的更改效果,并且所有网页在不同时间更新,则很难衡量您所做的更改。
爬行问题是一个常见的指示,表明您可能意外地生成了大量精简或重复的内容。
值得庆幸的是,日志文件很棒。通过检查Google抓取的位置以及花费的时间,您可以缩短确切花费太多时间的时间,缩短花费的时间,网站的哪些部分不会经常被抓取以及应该在哪里“完全爬行。

优先级
搜索引擎优化最困难的部分之一是优先考虑您遇到的不同问题。例如:

这在我的网站,重定向链或精简内容上更是一个问题?
我有两套不同的内部链接301重定向,这导致谷歌出现更多问题?
通过查看Google在您的网站上花费时间的位置,您可以优先考虑最有影响力的区域。

发现错误并检查网站运行状况
特别是在大型网站上,会立即发生很多变化,很难跟踪它们。即使在小型网站上,这也是一个问题,因为尽管网站规模较小,但团队规模较小,而且没有时间跟踪事情。

所有这些更改通常都会破坏事情,并且可能需要数周才能发现404或部分网站302重定向的一组链接。

你可能每天都要刮掉你的网站,但这是很多工作,你也可能正在开展一个太大而无法抓取的网站。

Google Search Console提供了一个用于检查这类错误的界面,但它存在很多问题:

每种错误类型限制为1000个结果
如果你没有掌握它,那么旧的错误可以在界面中留下来
没有优先顺序
创建的错误与它们出现在搜索控制台中之间存在延迟。
您只能看到错误,而不是重定向。
日志文件分析解决了Google Search Console的所有问题。

Google对您网站的部分内容有多重要?
我们现在开始变得更加复杂。查看您的日志文件还可以让您了解Google查看您网站上不同网页或网页模板的重要性。

从广义上讲,影响网站抓取网页频率的一个较大因素是Google认为它的价值。

这是否意味着如果您按照从大多数抓取到最少的顺序排列所有页面,您会看到哪些页面很重要?不一定,因为还有其他事情会影响它,例如更新的频率。例如,RSS Feed被大量抓取,因为它们不断更新内容,而不是因为它们是Google想要排名很好的重要页面。

例如,如果您拥有电子商务,并且平均所有产品都会像您的类别页面一样被抓取,那么Google似乎无法理解您的层次结构。另一方面,如果一个产品网址被抓得更远,或许它特别引起争议,并且已经收到很多社会关注或新闻提及,那么这些其他情况最有可能导致这种情况。

衡量内容的新鲜度
Cyrus Shepard发表了一篇精彩文章,通过研究Google专利中提到的一些技术,探讨了为什么新鲜度对您的内容很重要。

但是,通常您会更新您的内容,但只有在Google发现这些更新时才会更新。如果您每天更新您的网页3次,而Google每周只会抓取一次,那么您就会浪费大量时间。您需要Google更频繁地抓取您的网页,或者您可以节省一些时间并更少地更新您的内容。

日志文件可以测量新鲜度。

您可以计算Google在发布或更新页面时抓取页面所需的时间,或计算每天抓取页面的平均次数,并衡量您为提高新鲜度所做的任何更改所产生的影响。

如何获取日志
如果你到达这里,你已经确信或者你已经说服了。那么怎么样。

首先,我们需要获取日志并执行此操作,我们需要向开发人员询问有关日志设置的一些信息,以确保我们获得正确的日志。此信息收集还有双重目的,即我们更有可能获取日志,特别是如果您在代理机构工作,在这种情况下,某些公司将更不愿意交出数据。

那么我们需要找出什么呢?

有没有PII?
日志文件可以包含个人身份信息,如电子邮件,电话号码等。

公司对这些信息的理解是可以理解的,所以我们要首先明确的是我们不想要任何这些信息。

如果日志文件包含任何内容,请在移交日志之前请求删除它。

所有日志都在同一个地方吗?
我们需要确保获取所有我们感兴趣的日志。这些是一些常见的地方,日志可能是不同的地方,我们需要确保我们明确检查它:

移动网站
如果一个网站有www。还有一个。网站例如

www.example.com
m.example.com
看起来与众不同的网站部分
从前面看起来像是一个网站可能实际上是后端的两个不同的网站。

如果是这种情况,每个部分可能会记录到不同的地方,我们需要获取日志的两个部分。

网站缓存
另一个常见的例子是网站是否正在运行某种缓存,这可以分离日志。究竟是什么意思?

以下面的例子为例:

当用户1请求页面时,服务器生成页面并发送给他们。它通过一个缓存来制作页面的副本。

当用户2请求相同的页面时,缓存会发现这一点并向他们发送它所做的副本,而服务器不必做任何事情。

此缓存可以记录与服务器不同的位置,因此我们必须确保获取两组日志。

我们可以获取日志多长时间?
我们希望有足够的日志数据来建立一个有用的基线,通常需要三个月,但是在特别大的集合中,可能很少爬网页面,您可能需要更多。

有些网站一次只能存储一个月的日志,因此我们需要将这些日志存储在某个地方,以便我们一次访问一个月以上。

他们记录主机名吗?
让我们举个例子,他们有两个子域名的电子商务网站:

www.example.com / tvs
example.com/tvs
blog.example.com/tvs
第一页是电视的类别,第二页是未正确重定向的重复版本,第二页是电视上内容的博客类别。

这3个URL之间的关键区别是主机名,www,博客或*空白*。

不幸的是,在某些情况下,当日志聚合在一起时,网站将不会存储主机名,这意味着所有这三个页面看起来都相同。

我们需要询问他们是否记录了主机名,如果没有,则将其打开。

是否有太多的日志数据?
还记得我们之前说过的吗?日志文件包含对服务器发出的每个请求。这是很多要求。对于非常大的网站或收到大量垃圾邮件流量的网站,这可能意味着我们获得的文件太大,我们无法处理。

我们需要找出日志文件的大小。如果它们超过我们可以轻松使用(对于非技术头脑,这个限制大约4-6GB),或者你的开发人员抱怨它们的大小,我们可以采取一个简单的措施来减少在尺寸上。

由于我们主要对Googlebot感兴趣(对不起Bing),我们可以让开发人员删除所有不是Googlebot的内容。

以下命令(您无需了解)将捕获99.9%的Googlebot请求并使您的文件更易于使用。

grep -i -E“googlebot | mediapartners-google | adsbot-google”

(当然,如果您对不同的搜索引擎感兴趣,则需要更改撇号之间的字符串。)

给开发者的电子邮件
这是我在项目开始时发送给开发人员的电子邮件副本,以了解这些方面并缩小问题范围。

嗨x

我是来自{y}的{x},我们被要求做一些日志分析,以更好地了解Google在网站上的表现,我希望你能帮助解决有关日志设置的一些问题(以及和获取日志一样!)。

我们理想的是网站的3-6个月的历史日志。我们的目标是查看搜索引擎在我们的网站上抓取的所有不同页面,发现他们花费时间的地方,他们找到的状态代码错误等。

在获取日志时,还有一些对我们真正有帮助的事情。

日志中是否有任何个人信息?

我们只关注Google和Bing等各种搜索爬虫机器人,我们不需要用户提供任何日志,因此可以删除任何带有电子邮件或电话号码的日志。

您是否有任何类型的缓存可以创建单独的日志集?

如果有什么像Varnish在服务器上运行,或者CDN可能会在与服务器其余部分不同的位置创建日志?如果是这样,那么我们将需要那些日志以及来自服务器的日志。(虽然我们只关心CDN,如果它是缓存页面,或者使用相同的主机名提供服务;如果您只是使用Cloudflare来缓存外部图像,那么我们就不需要它了)。

您网站的任何子部分是否都可以登录到其他地方?

你有没有像嵌入式Wordpress博客那样登录到不同的位置?如果是这样,那么我们也需要那些日志。

你记录主机名吗?

能够在日志中查看主机名对我们非常有用。默认情况下,许多常见的服务器日志记录设置不会记录主机名,因此如果没有打开主机名,那么现在打开它以进行任何将来的分析将非常有用。

还有其他什么我们需要知道的么?

最好,

{X}

可用于分析日志的不同工具
一旦我们得到了我们的日志,我们需要选择如何分析它们。

从广义上讲,我认为在判断日志分析工具时应该使用6个标准:

我们能问一些强大而复杂的问题吗?
分析是否可重复?
我们可以结合抓取数据吗?
该工具易于设置吗?
该工具易于学习吗?
它可扩展吗?
它便宜吗?
最值得注意的可能不适用于小型企业的是6号。

代理商将需要一个可扩展,大型或快速增长的企业也需要的工具,但对于小型的一些中小型企业来说,6将不那么令人担忧。

BigQuery的
BigQuery是我推荐的工具。这是Google用于数据分析的云可扩展数据库。

就我们的目的而言,它有两个重要的事情:

它是一个已在云端设置的数据库,因此无需设置,扩展性好,使用起来便宜。
它允许我们使用SQL来分析我们的日志。如果这听起来很可怕,请不要担心。它实际上很简单。
为什么SQL是适合这项工作的工具?

值得一提的是为什么SQL是适合这项工作的正确工具。标准1,2和5由SQL解决。

首先,它很容易学习。编写SQL就像是向一个非常合乎逻辑的人写一个请求。例如

SELECT
car_model
FROM
list_of_ford_cars
WHERE
price_range =“cheap”
没有多想,我相信很多人都可以猜到可能会有什么回报:

指数

汽车模型

1

嘉年华

2

斑马

3

焦点

它也非常强大。虽然最后一个查询非常基础,但SQL的设计也能够支持非常复杂的查询。我们可以编写一个查询来平均告诉我们Google抓取我们的网页所需的时间。

Lastl它是可重复的。如果我们有不同的汽车列表,我们可以复制并粘贴我们的查询,只更改FROM并获取新表的相同信息集:

SELECT
car_model
FROM
list_of_bmw_cars
WHERE
price_range =“affordable”
但是还有其他各种工具可用于日志分析,值得一提:

高强
对不起Excel,你不适合进行日志分析。你只能进入这个列表,因为否则每个人都会想知道你在哪里。你很难处理我们将要通过的所有数据而不会减速和崩溃。

提出复杂的问题,例如计算Google抓取页面所需的平均时长,需要花费很长时间才能执行多个步骤,并且只有在Excel中编码才能重复。如果你可以编码VBA,你宁愿用别的代码编写吗?

ELK Stack
ELK代表Elasticsearch,Logstash和Kibana。这是一系列程序,可以设置为监视服务器上的所有日志。

通常情况下,开发人员会设置它来监控服务器的运行状况,但是,它可以被一个有进取心的SEO劫持,以便实时关注Googlebot。

ELK堆栈的主要3个问题是

它没有设置为允许您轻松组合爬网数据
它使用的查询语言不像SQL那样直观,语法更复杂。(这有点像尝试学习一门语言,其中一个语法规则很少而另一个语言很多。第二个会更难。)
你必须自己设置这可能很困难。
但是,如果你的开发人员已经设置好了,那么花一点时间来学习查询语言是值得的,因为它可以让你做一些我们将在分析中描述的任务(通常围绕状态查看)代码)很快。

商业日志工具
在SEO特定方面,这包括诸如Botify,OnCrawl和Screaming Frog Log Analyzer之类的东西,在非SEO方面,它包括像Splunk这样的工具。

从广义上讲,这些工具属于以下两个方面之一:

他们太贵了
他们不能以可重复的简单方式提出有力的问题。
你自己的SQL服务器
我们已经在第一部分中支持SQL,那么为什么不使用自己的SQL服务器,而不是使用Google的SQL服务器呢?

大多是方便。设置自己的SQL服务器可能很麻烦,而像MySQL Workbench这样的许多常见免费接口都很混乱,很难用于初学者。

考虑到BigQuery是免费的,除了最大的日志分析之外,为什么不使用它而不是让自己付出额外的努力呢?

处理日志
我们需要处理我们的日志以将它们上传到BigQuery(从这里开始的BQ),我们将在那里进行日志分析。

我们正在尝试做两件事:

将我们的日志格式化为CSV,以便我们将它们加载到BQ中
删除任何非Googlebot的内容
(我们将假设我们只分析Googlebot。)

有两种方法可以做到这一点。如果你不能编码那么我们将使用Screaming Frog分析仪。如果您可以编写代码然后继续阅读(或者对详细信息感兴趣),那么请跳转到我们的GitHub页面,在那里我们将完成处理日志的来龙去脉。

构建自己的流程日志解决方案
我已将文章的这一部分分离到它自己的Github页面。

https://github.com/dom-devel/log-analysis-notes

使用Screaming Frog Log Analyzer处理日志
这最好用视频显示。所以准备好你的日志,我们走了。

您可以在此处找到时间戳转换程序 。

将日志上载到BigQuery
再次,最好用视频显示。

以下是视频中引用的架构和查询:

用于上传过程的模式

logs:full_url:STRING,timestamp:TIMESTAMP,ip_address:STRING,method:STRING,status_code:INTEGER,size:FLOAT,time_taken:FLOAT,user_agent:STRING,referer:STRING
查询初始处理:

SELECT
*,
CASE
WHEN full_url CONTAINS“?” THEN 1
ELSE 0
END AS has_params,
CASE
WHEN USER_AGENT CONTAINS “Googlebot的”,然后“Googlebot的”
WHEN USER_AGENT CONTAINS “了MediaPartners,谷歌”,然后“Googlebot的-广告”
WHEN USER_AGENT CONTAINS “了AdsBot-谷歌”,然后“Googlebot的-广告”
ELSE“不googlebot“
END AS google_agent,
FIRST(SPLIT(full_url,':'))AS协议,
FIRST(SPLIT(REGEXP_REPLACE(full_url,r'(http | https):\ / \ /(www。)?example \ .com' ,''),'?'))AS路径,
NTH(2,SPLIT(REGEXP_REPLACE(full_url,r'(http | https):\ / \ /(www。)?example \ .com',''), '?'))AS查询,

NTH(5,SPLIT(full_url,'/'))AS page_path_3,
NTH(6,SPLIT(full_url,'/'))AS page_path_4,
NTH(6,SPLIT(full_url,'/'))AS page_path_5
FROM
[insert你自己的桌子]
如何分析日志
验证数据
一旦我们在BigQuery中记录了日志,我们就需要确保拥有所有日志。

为此,我们将我们获取的日志总抓取次数与我们在Google Search Console上看到的抓取次数进行比较。

我们第一次SQL查询的时间:

问题:Googlebot每天在我们的日志中抓取多少次网站?

查询:

SELECT
date(timestamp)as date,
count(*)as num_requests
FROM
[my_dataset.log_analysis]
GROUP BY
date
ORDER BY
date desc
快速浏览一下SQL
因为这是我们的第一个查询,我们将花一点时间来讨论它。

我们从数据库中选择时间戳,然后将其转换为日期。我们从log_analysis表中获取它并对其进行排序,以便日期按降序排列。

这涵盖了除第3,6和7行之外的所有内容。我们实际上并不想要每个日志请求中的日期,我们想要每天的总数。第3,6和7行需要一起阅读。我们计算第3行和第6行和第7行中的所有行,我们说的是日期相同的计数。

如果您不能完全遵循这一点,请不要担心,我们最终会得到一个完整的示例查询列表,最简单的方法就是使用它来解决问题。尝试查询,看看你得到了什么。(最后我们在常见的调试错误中有一些注意事项。)

将日志结果与GSC进行比较
然后,我们想将其与Google Search Console进行比较。根据我的经验,日志数据从未与搜索控制台数据产生巨大差异。虽然两个图形不完全匹配,但它们应该看起来大致相同的形状(可能根据服务器时区偏移一天)并且大致相同。

例如,如果您的日志中每天有10,000次点击,但GSC中有20k次点击,则会丢失一些日志。

如果他们没有时间回到您的开发人员并找出您丢失的日志。

但假设他们这样做。恭喜我们终于达到了令人兴奋的部分,即实际分析。

分析日志的过程是什么?
无论您正在做什么,日志分析过程都将大致通过相同的三个方面。

你去做一些疑问
你找到值得研究的东西
您可以从尖叫青蛙或深度爬行等程序中获取爬行数据,也可以前往实际网站了解正在发生的情况。
虽然日志很好,但您仍然需要能够查看某人的网站并了解您正在查找的问题。

问正确的问题
考虑到这个过程,我们需要提出正确的问题。对于我们在开头提到的这五个领域中的每一个:

诊断爬网和索引
优先级
发现错误并查看网站运行状况
了解Google查看网站各个部分的重要性
衡量内容的新鲜度
我们有问题(以及查询)可以帮助您深入了解它们。

如果您已经按照这些步骤进行操作,那么只要您记得更改FROM部分中的表格,您就可以直接复制并粘贴这些查询。

如果您已经从SF Log Analyzer上传了日志,那么您不仅拥有Googlebot,还拥有所有机器人(Bing,Yandex等)。如果你想查看Googlebot以外的机器人,你需要删除:

在哪里
google_agent =“googlebot”或
google_agent =“googlebot-ad”
从它在查询中出现的位置。

实用程序查询
此部分的大部分内容都是允许您检查数据的查询:

获取日期范围:
原因:不确定您的日志结束的时间段?不要担心它会发生。此查询将告诉您日志中的第一个和最后一个日期。

查询:

SELECT
min(timestamp),max(timestamp)
FROM
[insert_your_table_here]
获取Googlebot每天发出的请求总数:
原因:这是我们上面提到的查询,我们用来仔细检查我们的数据是好的。

查询:

SELECT
DATE(timestamp)as date,count(*)as num_requests
FROM
[insert_your_table_here]
WHERE
google_agent =“googlebot”或
google_agent =“googlebot-ad”
GROUP BY
date
ORDER BY
date asc
每天查看每个用户代理的抓取次数
原因: 有时查看Googlebot抓取的百分比与Googlebot移动抓取的百分比有用。特别是即将推出的仅限移动设备的索引,了解Google使用移动抓取工具和桌面抓取您网站的频率非常有用。

查询:

SELECT
user_agent,date(timestamp)as date,count(user_agent)as num_requests
FROM
[insert_your_table_here]
GROUP BY
user_agent,date
诊断爬行和索引问题及重要性
获取前100个抓取最多的网址:
为什么?一个开始寻找地方的好地方谷歌不应该爬行它。

查询:

SELECT
路径,计数(路径)为num_requests
FROM
[insert_your_table_here]
WHERE
(google_agent =“googlebot”或
google_agent =“googlebot-ad”)
GROUP BY路径
ORDER BY num_requests desc
LIMIT 100
获取前100个抓取最多的page_path_1文件夹:
原因:很高兴看到谷歌如何在整个网站上分割它的时间。你可以从中看到它不应该花费时间的地方,等等。

查询:

SELECT
page_path_1,count(page_path_1)为num_requests
FROM
[insert_your_table_here]
WHERE
(google_agent =“googlebot”或
google_agent =“googlebot-ad”)
GROUP BY page_path_1
ORDER BY num_requests desc
LIMIT 100
获取page_path_1和page_path_2组合的前100个最多爬网目录
原因: 网站架构通常意味着有趣的目录有两个层次。假设您的大部分抓取预算都在/ shop /文件夹中,它实际上是那些有趣的第二级文件夹,/ shop / shirts /,/ shop / trousers /等。此查询将显示您的第一个和第一个和二级目录。

查询:

SELECT
page_path_1,page_path_2,count(page_path_1)as num_requests
FROM
[insert_your_table_here]
WHERE
(google_agent =“googlebot”或
google_agent =“googlebot-ad”)
GROUP BY page_path_1,page_path_2
ORDER BY num_requests desc
LIMIT 1000
获取路径的每日查询号码 - 从整个期间的前20个已爬网路径中获取
原因: 正如我们上面提到的,在我们提出任何建议之前,我们需要每日查询号码。此查询为我们提供了前20个最常爬网路径的抓取数字。

查询:

SELECT
路径,
COUNT(路径)AS num_requests,
DATE(timestamp)AS日期
FROM
[insert_your_table_here]
WHERE
路径IN(
SELECT
路径
FROM(
SELECT
路径,
COUNT(路径)AS num_requests
FROM
[insert_your_table_here]
WHERE
(google_agent =“googlebot”
或google_agent =“googlebot-ad”)
GROUP BY
路径
ORDER BY
num_requests DESC,
LIMIT 20))
GROUP BY
路径,
日期
ORDER BY
路径ASC,
日期ASC
获取每天抓取参数的网址总数
原因: 网址参数通常是重复内容的常见来源(尽管显然这可能会因网站而异),但此查询可让您高度了解Google花费多少时间。

查询:

SELECT
has_params,
date(timestamp)as date,
count(*)as num_requests
FROM
[insert_your_table_here]
WHERE
google_agent =“googlebot”或
google_agent =“googlebot-ads”
GROUP BY
has_params,date
获取所有指定参数的日常请求总数
原因: 继上述内容之后,您可能需要调查特定参数的爬网,以了解哪些参数最有问题,并衡量更改参数访问方式的效果。我通常会将此与搜索控制台中找到的参数列表一起使用,因为您需要为此查询提供您要调查的参数。在下面的示例中,我将它们称为param_1和param_2,因此当您复制并粘贴此查询时,您需要使用自己的参数替换param_1和param_2的所有实例。如果您想要调查两个以上,您还可以添加更多参数。

查询:

SELECT
SUM(param_1)AS param_1_count,
SUM(param_2)AS param_2_count,
DATE(timestamp)AS date
FROM(
SELECT
IF(查询CONTAINS'param_1 =',INTEGER(num_requests),0)AS param_1,
IF(查询CONTAINS'param_2 = ',INTEGER(num_requests),0)AS param_2,
timestamp
FROM(
SELECT
查询,
COUNT(查询)AS num_requests,
时间戳
FROM
[insert_your_table_here]
WHERE
(google_agent =“googlebot”或
google_agent =“googlebot-ad”)
GROUP BY
查询,
时间戳))
GROUP BY
日期
ORDER BY
日期ASC
发现错误
获取每个状态代码的总数
原因:此查询为您提供了您所看到的每个状态代码的最高级别概述。


SELECT
status_code,count(status_code)as num_requests
FROM
[insert_your_table_here]
WHERE
google_agent =“googlebot”或
google_agent =“googlebot-ad”
GROUP BY status_code
ORDER BY status_code asc
LIMIT 1000
每天获取每个状态代码的总数
原因: 一旦您看到了顶级概述,那么您希望每天都能看到状态代码,看看它们是如何变化的,并允许您发现重大变化发生的时间。

SELECT
status_code,
date(timestamp)as date,
count(status_code)as num_requests
FROM
[insert_your_table_here]
WHERE
google_agent =“googlebot”或
google_agent =“googlebot-ad”
GROUP BY status_code
ORDER BY status_code asc
LIMIT 1000
获取返回最多状态代码“xxx”的前100个网址
原因:一旦发现特定状态代码存在问题,您就需要调查导致该问题的网址。对于此查询,请将xxx替换为您正在调查的状态代码。(不需要报价!)

SELECT
路径,status_code,has_params,count(路径)为num_requests
FROM
[insert_your_table_here]
WHERE
(google_agent =“googlebot”或
google_agent =“googlebot-ad”)
AND status_code = xxx
GROUP BY
路径,status_code,has_params
ORDER BY
num_requests desc
LIMIT
100
测量新鲜度
一个部分中每个页面平均被抓取多少次?
原因:查看抓取某个部分中每个网页的平均次数可以告诉我们Google何时接受我们的更改并帮助我们衡量它对我们的内容的新鲜程度。

SELECT
page_path_1,
page_path_2,
AVG(crawled_per_day)as average_of_crawl_per_individual_page
FROM(
SELECT
DATE(timestamp)as date,
path,
count(*)crawled_per_day,
page_path_1,
page_path_2
FROM
[insert_your_table_here]
WHERE
(google_agent =“googlebot”
或google_agent =“googlebot-ad “)
GROUP BY
date,
path,
page_path_1,
page_path_2

GROUP BY
page_path_1,
page_path_2
ORDER BY
average_of_crawl_per_individual_page DESC
LIMIT
1000
常见的改动:
按特定日期搜索

您可以通过在WHERE子句中添加日期部分来过滤大多数查询。例如,从上面获取第一个查询:

SELECT
路径,计数(路径)为num_requests
FROM
[insert_your_table_here.log_analysis]
WHERE
timestamp> = TIMESTAMP('2015-11-08')和
timestamp = <TIMESTAMP('2015-12-08')
GROUP BY路径
ORDER BY num_requests desc
 

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly