如何进行 SEO 日志文件分析 [包含模板]

在过去的五年中,日志文件越来越受到技术 SEO 的认可,这是有充分理由的。

它们是了解搜索引擎已抓取的 URL 的最值得信赖的信息来源,这可能是帮助诊断技术 SEO 问题的关键信息。

Google 本身也认识到它们的重要性,在 Google Search Console 中发布了新功能,并让查看以前只能通过分析日志才能获得的数据样本变得容易。

抓取统计报告; 上方的关键数据和下方显示抓取请求趋势的折线图

此外,Google Search Advocate John Mueller 曾公开表示日志文件保存了多少好的信息。

 

围绕日志文件中的数据大肆宣传,您可能希望更好地了解日志、如何分析它们以及您正在处理的站点是否会从中受益。

本文将回答所有这些以及更多内容。以下是我们将要讨论的内容:

服务器日志文件是由服务器创建和更新的文件,用于记录其已执行的活动。流行的服务器日志文件是访问日志文件,它保存了对服务器的 HTTP 请求历史记录(用户和机器人)。

当非开发人员提到一个日志文件时,他们通常会提到访问日志。

然而,开发人员发现自己花费更多时间查看错误日志,这些日志报告服务器遇到的问题。

以上内容很重要:如果您向开发人员索取日志,他们首先会问:“哪些?”

因此,请始终指定日志文件请求。如果要日志分析爬取,请索取访问日志

访问日志文件包含有关向服务器发出的每个请求的大量信息,例如:

  • IP 地址
  • 用户代理
  • 网址路径
  • 时间戳(当机器人/浏览器发出请求时)
  • 请求类型(GET 或 POST)
  • HTTP 状态码

访问日志中包含的服务器因服务器类型而异,有时开发人员已将服务器配置为存储在日志文件中。日志文件的常见格式包括:

  • Apache 格式——这由 Nginx 和 Apache 服务器使用。
  • W3C 格式– 这是由 Microsoft IIS 服务器使用的。
  • ELB 格式– 这由 Amazon Elastic Load Balancing 使用。
  • 自定义格式——许多服务器支持输出自定义日志格式。

存在其他形式,但这些是您将遇到的主要形式。

现在我们已经对日志文件有了基本的了解,让我们看看它们如何使 SEO 受益。

以下是一些关键方法:

  • 抓取监控– 您可以查看搜索引擎抓取的 URL,并使用它来发现抓取工具陷阱,注意抓取预算浪费,或者更好地了解获取内容更改的速度。
  • 状态代码报告——这对于优先修复错误特别有用。您可以准确地看到用户/搜索引擎访问 404 URL 的次数,而不是知道您有 404。
  • 趋势分析——通过监控对 URL、页面类型/站点部分或整个站点的爬取,您可以发现变化并调查潜在原因。
  • 孤立页面发现——您可以交叉分析来自日志文件的数据,并通过您自己运行的站点爬网来发现孤立页面。

所有站点都将在一定程度上受益于日志文件分析,但收益量 站点大小而异。

这是因为日志文件主要通过帮助您 更好地管理 爬网而使站点受益。谷歌本身 表示 管理抓取预算是更大规模或经常变化的网站将从中受益。

谷歌文章节选

日志文件分析也是如此。

例如,较小的网站可能会使用 Google Search Console 中提供的“抓取统计”数据并获得上述所有好处,而无需访问日志文件。

爬行统计报告的 Gif 逐渐向下滚动

是的,Google 不会向您提供所有抓取的网址 (例如日志文件),并且趋势分析仅限于三个月的数据。

但是,不经常更改的较小站点也需要较少的持续技术 SEO。让现场审核员发现和诊断问题可能就足够了。

例如,来自站点爬虫、XML 站点地图、Google Analytics 和 Google Search Console 的交叉分析可能会发现所有孤立页面。

您还可以使用站点审核员从内部链接中发现错误状态代码。

我指出这一点有几个关键原因:

  • 获取访问日志文件并不容易 (接下来会详细介绍)。
  • 对于不经常更改的小型站点,日志文件的好处并不多,这意味着 SEO 的重点可能会转移到其他地方。

在大多数情况下,要分析日志文件,您首先必须向开发人员请求访问日志文件。

然后,开发人员可能会遇到一些问题,他们会引起您的注意。这些包括:

  • 部分数据——日志文件可以包含分散在多个服务器上的部分数据。这通常发生在开发人员使用各种服务器时,例如源服务器、负载均衡器和 CDN。获得所有日志的准确图片可能意味着编译来自所有服务器的访问日志。
  • 文件大小– 高流量站点的访问日志文件最终可能达到 TB,如果不是 PB 的话,这使得它们难以传输。
  • 隐私/合规– 日志文件包括属于个人身份信息 (PII) 的用户 IP 地址。用户信息可能需要先删除,然后才能与您共享。
  • 存储历史– 由于文件大小,开发人员可能已将访问日志配置为仅存储几天,这使得它们对于发现趋势和问题没有用处。

这些问题会让人质疑存储、合并、过滤和传输日志文件是否值得开发人员的努力,特别是如果开发人员已经有很长的优先级列表(通常是这种情况)。

开发人员可能会将责任放在 SEO 上来解释/建立一个案例,说明为什么开发人员应该在这方面投入时间,您需要在其他 SEO 重点中优先考虑这一点。

这些问题 正是日志文件分析不经常发生的原因。

您从开发人员那里收到的日志文件也经常被流行的日志文件分析工具以不支持的方式格式化,使得分析更加困难。

值得庆幸的是,有一些软件解决方案可以简化这个过程。我最喜欢的是Logflare,这是一个Cloudflare 应用程序 ,可以将日志文件存储在您拥有的BigQuery 数据库 中。

现在是时候开始分析您的日志了。

我将具体向您展示如何在 Logflare 的上下文中执行此操作;但是,有关如何使用日志数据的提示适用于任何日志。

我将很快分享的模板也适用于任何日志。您只需要确保数据表中的列匹配。

1. 首先设置 Logflare(可选)

Logflare 易于设置。通过 BigQuery 集成,它可以长期存储数据。您将拥有数据,让每个人都可以轻松访问它。

有一个困难。您需要更换您的域名服务器以使用 Cloudflare 并在那里管理您的 DNS。

对于大多数人来说,这很好。但是,如果您使用的是企业级站点,则不太可能说服服务器基础架构团队更改名称服务器以简化日志分析。

我不会详细介绍如何让 Logflare 正常工作的每一步。但要开始使用,您需要做的就是前往仪表板的 Cloudflare 应用程序部分。

侧边栏中的“应用程序”

然后搜索 Logflare。

“Logflare”出现在右上角的搜索字段中,应用程序出现在结果下方

此后的设置是不言自明的(创建一个帐户,为您的项目命名,选择要发送的数据等)。我推荐的唯一额外部分是Logflare 的 BigQuery 设置指南。

但是请记住,BigQuery 的成本 取决于您执行的查询和存储的数据量。

边注。

值得注意的是,BigQuery 后端的一个显着优势是您拥有数据。这意味着您可以通过将 Logflare 配置为不发送类似 IP 地址的 PII 并使用 SQL 查询从 BigQuery 中删除 PII 来规避 PII 问题。

2. 验证 Googlebot

我们现在已经存储了日志文件(通过 Logflare 或其他方法)。接下来,我们需要从我们想要分析的用户代理中精确地提取日志。对于大多数人来说,这将是Googlebot。

在我们这样做之前,我们还有另一个障碍要跨越。

许多机器人伪装成 Googlebot 以通过防火墙(如果有的话)。此外,一些审核工具也会这样做,以准确反映您的网站为用户代理返回的内容,如果您的服务器为 Googlebot 返回不同的 HTML(例如,如果您设置了动态呈现),这一点至关重要。

我没有使用 Logflare

如果您没有使用 Logflare,识别 Googlebot 将需要反向 DNS 查找来验证请求是否来自 Google。

Google 有一个手动验证 Googlebot的便捷指南。

谷歌文章节选

您可以一次性执行此操作,使用反向 IP 查找工具 并检查返回的域名。

但是,我们需要对日志文件中的所有行批量执行此操作。这还要求您匹配 Google 提供的列表中的 IP 地址。

最简单的方法是使用由第三方维护的服务器防火墙规则集来阻止假机器人(导致您的日志文件中更少/没有假 Googlebot)。Nginx 的一个流行是“ Nginx Ultimate Bad Bot Blocker ”。

或者,您会在 Googlebot IP 列表中注意到 IPV4 地址均以“66”开头。

IPV4 地址列表

虽然它不会 100% 准确,但在分析日志中的数据时,您还可以通过过滤以“6”开头的 IP 地址来检查 Googlebot。

我正在使用 Cloudflare/Logflare

Cloudflare 的专业计划(目前每月 20 美元)具有内置防火墙功能,可以阻止虚假 Googlebot 请求访问您的网站。

Cloudflare 定价

Cloudflare 默认禁用这些功能,但您可以通过前往防火墙 > 托管规则 >启用“ Cloudflare Specials ” >选择高级”来找到它们:

显示“托管规则”的网页

接下来,将搜索类型从“描述”更改为“ID”并搜索“100035”。

描述 ID 列表

Cloudflare 现在将为您提供阻止虚假搜索机器人的选项列表。将相关请求设置为“阻止”,Cloudflare 将检查来自搜索机器人用户代理的所有请求是否合法,从而保持您的日志文件干净。

3.从日志文件中提取数据

最后,我们现在可以访问日志文件,并且我们知道日志文件准确地反映了真正的 Googlebot 请求。

我建议您首先在 Google 表格/Excel 中分析您的日志文件,因为您可能习惯于使用电子表格,并且可以很简单地与其他来源(如网站抓取)交叉分析日志文件。

没有一种正确的方法可以做到这一点。您可以使用以下内容:

  • grep
  • 斯普伦克
  • logz.io
  • ELK 堆栈

您也可以在 Data Studio 报表中执行此操作。我发现 Data Studio 有助于随着时间的推移监控数据,而 Google Sheets/Excel 在技术审计时更适合一次性分析。

打开 BigQuery 并前往您的项目/数据集。

显示项目数据集的侧边栏

选择“查询”下拉菜单并在新选项卡中打开它。

“查询”下拉菜单显示 2 个选项:新选项卡或拆分选项卡

接下来,您需要编写一些 SQL 来提取您将要分析的数据。为了使这更容易,首先复制查询的 FROM 部分的内容。

FROM 部分查询

然后您可以在下面我为您编写的查询中添加它:

SELECT DATE(timestamp) AS Date, req.url AS URL, req_headers.cf_connecting_ip AS IP, req_headers.user_agent AS User_Agent, resp.status_code AS Status_Code, resp.origin_time AS Origin_Time, resp_headers.cf_cache_status AS Cache_Status, resp_headers.content_type AS Content_Type

FROM `[Add Your from address here]`,

UNNEST(metadata) m,

UNNEST(m.request) req,

UNNEST(req.headers) req_headers,

UNNEST(m.response) resp,

UNNEST(resp.headers) resp_headers

WHERE DATE(timestamp) >= "2022-01-03" AND (req_headers.user_agent LIKE '%Googlebot%' OR req_headers.user_agent LIKE '%bingbot%')

ORDER BY timestamp DESC

此查询选择对 SEO 目的的日志文件分析有用的所有数据列。它也只为 Googlebot 和 Bingbot 提取数据。

边注。

如果您要分析其他机器人,只需在 WHERE 语句中添加另一个 OR req_headers.user_agent LIKE ‘%bot_name%’。您还可以通过更新 WHERE DATE(timestamp) >= “2022–03-03” 行轻松更改开始日期。

选择顶部的“运行”。然后选择保存结果。

“保存结果”按钮

接下来,将数据保存到 Google Drive 中的 CSV(由于文件较大,这是最好的选择)。

然后,在 BigQuery 运行作业并保存文件后,使用 Google 表格打开文件。

4. 添加到 Google 表格

我们现在开始进行一些分析。我建议使用我的 Google 表格模板。但我会解释我在做什么,如果你愿意,你可以自己构建报告。

这是我的模板。

该模板包含两个数据选项卡,用于复制和粘贴您的数据,然后我使用 Google 表格查询功能将其用于所有其他选项卡。

边注。

如果您想查看我是如何完成设置后将运行的报告的,请选择每个表格中的第一个单元格。

首先,将 BigQuery 的导出输出复制并粘贴到“数据 – 日志文件”选项卡中。

BigQuery 的输出

请注意,表格末尾添加了多个列(深灰色)以使分析更容易一些(如机器人名称和第一个 URL 目录)。

5.添加Ahrefs数据

如果您有现场审核员,我建议您在 Google 表格中添加更多数据。主要是,你应该添加这些:

  • 自然流量
  • 状态码
  • 爬行深度
  • 可转位性
  • 内部链接数

要从 Ahrefs 的 站点审核中获取此数据,请前往页面资源管理器 并选择“管理列”。

然后我建议添加如下所示的列:

要添加的列

然后导出所有这些数据。

导出为 CSV 的选项

并复制并粘贴到“Data – Ahrefs”表中。

6.检查状态码

我们首先要分析的是状态码。该数据将回答搜索机器人是否在非 200 个 URL 上浪费了抓取预算。

请注意,他并不总是指向问题。

有时,Google 可以抓取多年的旧 301。但是,如果您在内部链接到许多非 200 状态代码,它可能会突出显示问题。

“状态代码 – 概述”选项卡有一个QUERY 功能 ,可以汇总日志文件数据并在图表中显示结果。

饼图显示状态代码的日志文件数据摘要

还有一个下拉菜单可以按机器人类型进行过滤,看看哪些机器人最常达到非 200 状态代码。

显示状态代码和相应命中的表格; 上面,下拉菜单按机器人类型过滤结果

当然,仅此报告并不能帮助我们解决问题,因此我添加了另一个选项卡“URL – 概述”。

具有相应数据(如状态代码、自然流量等)的 URL 列表

您可以使用它来过滤返回非 200 状态代码的 URL。由于我还包含了来自 Ahrefs 的 Site Audit的数据,您可以在“Inlinks”列中查看您是否在内部链接到任何非 200 个 URL。

如果您看到很多指向该 URL 的内部链接,则可以使用内部链接机会报告来发现这些不正确的内部链接,只需将 URL 复制并粘贴到搜索栏中并选择“目标页面”即可。

内部链接机会报告结果摘录

7.检测抓取预算浪费

突出显示 不是由于抓取非 200 状态代码而导致的日志文件抓取预算浪费的最佳方法是查找经常抓取的不可索引 URL(例如,它们是规范化的或未编入索引的)。

由于我们从日志文件和 Ahrefs 的 站点审核中添加了数据,因此发现这些 URL 很简单。

前往“抓取预算浪费”选项卡,您会发现高度抓取的 HTML 文件返回 200 但不可索引。

具有相应数据(如命中等)的 URL 列表

既然您有了这些数据,您就需要调查机器人抓取 URL 的原因。以下是一些常见的原因:

  • 它在内部链接到。
  • 它错误地包含在 XML 站点地图中。
  • 它有来自外部网站的链接。

对于较大的网站,尤其是那些带有分面导航的网站,在内部链接到许多不可索引的 URL 是很常见的。

如果此报告中的命中数非常高,并且您认为自己在浪费抓取预算,则可能需要删除指向网址的内部链接或使用 robots.txt 阻止抓取。

8. 监控重要的 URL

如果您的网站上有对您非常重要的特定 URL,您可能需要查看搜索引擎抓取它们的频率。

“URL 监视器”选项卡就是这样做的,它绘制了最多可以添加五个 URL 的每日点击趋势。

显示 4 个 URL 的每日点击趋势的折线图

您还可以按机器人类型进行过滤,从而轻松监控 Bing 或 Google 抓取 URL 的频率。

带有下拉选项的 URL 监控以按机器人类型进行过滤
边注。

您还可以使用此报告检查您最近重定向的 URL。只需在下拉列表中添加旧网址和新网址,即可查看 Googlebot 注意到更改的速度。

通常,这里的建议是,如果 Google 不经常抓取 URL,那将是一件坏事。事实并非如此。

虽然 Google 倾向于更频繁地抓取热门网址,但如果网址不经常更改,它抓取的网址可能会减少。

谷歌文章节选

尽管如此,如果您需要快速获取内容更改,例如在新闻网站的主页上,监控这样的 URL 还是很有帮助的。

事实上,如果您注意到 Google 过于频繁地重新抓取 URL,我会提倡尝试通过将 <lastmod> 添加到 XML 站点地图等操作来帮助它更好地管理抓取速度。这是它的样子:

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

<url>

<loc>https://www.logexample.com/example</loc>

<lastmod>2022-10-04</lastmod>

</url>

</urlset>

然后,您可以在页面内容发生更改时更新 <lastmod> 属性,向 Google 发出重新抓取的信号。

提示

请注意,Google 对此属性提供了不同的反馈。2015 年,Gary Ilysses表示它大多被忽视了。2017 年,John 表示它已被使用。最近,在 2022 年,加里表示,“我们只是不打算使用它。” Google 的 XML 站点地图文档 建议使用该属性。但如果不准确,就会被忽略。

谷歌文章节选

9. 查找孤儿 URL

使用日志文件的另一种方法是发现孤立 URL,即您希望搜索引擎抓取和索引但内部没有链接到的 URL。

我们可以通过检查 Ahrefs 的Site Audit发现的 200 个没有内部链接的状态代码 HTML URL 来做到这一点。

您可以看到我为此创建的名为“孤立 URL”的报告。

具有相应数据(如命中等)的 URL 列表

这里有一个警告。由于 Ahrefs 没有发现这些 URL,但 Googlebot 发现了这些 URL,因此这些 URL 可能不是我们想要链接到的 URL,因为它们是不可索引的。

在为您的 Ahrefs 项目设置爬网源时,我建议使用“自定义 URL 列表”功能复制和粘贴这些 URL。

设置抓取来源的页面; 用于输入自定义 URL 的文本字段

这样,Ahrefs 现在将考虑在您的日志文件中找到的这些孤立 URL,并在您下次抓取时向您报告任何问题:

问题清单

10、监控按目录爬取

假设您已经实现了结构化 URL,这些 URL 指示了您如何组织您的网站(例如,/features/feature-page/)。

在这种情况下,您还可以根据目录分析日志文件,以查看 Googlebot 是否比其他人更多地抓取网站的某些部分。

我已经在 Google 表格的“目录 – 概览”选项卡中实现了这种分析。

表格显示目录列表以及相应数据,如自然流量、内链等

您可以看到我还包含了有关目录内部链接数量以及总有机流量的数据。

您可以使用它来查看 Googlebot 是否花费更多时间来抓取低流量目录而不是高价值目录。

但同样,请记住这可能会发生,因为特定目录中的某些 URL 比其他 URL 更频繁地更改。不过,如果你发现了一个奇怪的趋势,还是值得进一步调查的。

除了此报告之外,如果您想查看您网站的每个目录的抓取趋势,还有一个“目录 – 抓取趋势”报告。

显示每个目录的爬取趋势的折线图

11. 查看 Cloudflare 缓存比率

前往“CF 缓存状态”选项卡,您将看到 Cloudflare 在边缘服务器上缓存文件的频率摘要。

条形图显示 Cloudflare 在边缘服务器上缓存文件的频率

当 Cloudflare 缓存内容(上图中的 HIT)时,请求不再发送到您的源服务器,而是直接从其全球 CDN 提供服务。这会产生更好的Core Web Vital,尤其是对于全球站点。

边注。

在源服务器上设置缓存(例如 Varnish、Nginx FastCGI 或 Redis 全页缓存)也是值得的。这样即使 Cloudflare 没有缓存 URL,您仍然可以从一些缓存中受益。

如果您看到大量“未命中”或“动态”响应,我建议您进一步调查以了解 Cloudflare 不缓存内容的原因。常见原因可能是:

  • 您正在链接到其中包含参数的 URL  – Cloudflare 默认将这些请求传递到您的源服务器,因为它们可能是动态的。
  • 您的缓存过期时间太短 ——如果您设置较短的缓存寿命,很可能会有更多用户收到未缓存的内容。
  • 您没有预加载缓存 – 如果您需要缓存经常过期(因为内容经常更改),而不是让用户点击未缓存的 URL,请使用预加载器机器人来填充缓存,例如 Optimus Cache Preloader。
边注。

我强烈建议通过 Cloudflare 设置 HTML 边缘缓存,这会显着降低 TTFB。您可以使用 WordPress 和 Cloudflare 的自动平台优化轻松做到这一点。

12.检查哪些机器人最常抓取您的网站

最终报告(可在“机器人 – 概览”选项卡中找到)向您显示哪些机器人对您网站的抓取次数最多:

与 Bingbot 相比,显示 Googlebot 抓取网站最多的饼图

在“机器人 – 抓取趋势”报告中,您可以看到该趋势如何随时间变化。

显示抓取趋势如何随时间变化的堆积条形图

此报告可以帮助检查您网站上的机器人活动是否有所增加。当您最近进行了重大更改(例如 URL 迁移)并希望查看机器人是否增加了抓取以收集新数据时,它也很有帮助。

给TA打赏
共{{data.count}}人
人已打赏
SEO交流

作者内容对 EAT 信号的影响

2022-4-11 23:43:33

SEO交流

SEO 办公时间,2022 年 4 月 1 日

2022-4-12 23:31:55

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索