SEO 办公时间,2021 年 11 月 12 日

已发表: 2021-11-16

这是2021 年 11 月 12 日Google SEO Office HoursJohn Mueller的最有趣问题和答案的摘要

内容隐藏
1 Google Search Console 中的 Noindex 页面
2规范和替代标签
3规范化或无索引标签
4移动优先索引和爬取
5网络技术与排名
6 Google PageSpeed Insights 与 Lighthouse
7谷歌发现
8响应时间

Google Search Console 中的无索引页面

8:16 [某些页面] 被错误地设置为 noindex。 这是在几个月前修复的。 [...] 我们尝试通过 Search Console [和] 重新提交站点地图请求索引,但仍然没有将这些页面编入索引。 您对可能导致 Googlebot 不听索引请求的原因有什么想法,或者 Search Console 中是否存在与索引相关的任何已知问题?”

约翰:“我认为在这方面没有任何已知问题,但有时我们在提交索引请求方面有点保守,这可能是你在那里看到的部分内容。 [...] 一方面,如果我们看到一个页面在较长时间内没有索引,那么我们通常会在抓取该页面时放慢速度。 [...] 这也意味着当页面变得可索引时,我们将再次开始抓取,所以本质上这是您需要做的一种推送。

另一件事是,由于 Search Console 报告的基本上是我们所知道的网站 URL,因此图片看起来可能比实际情况更糟。 这可能是您可以查看的内容,例如,查看性能报告并针对网站的该部分或这些 URL 模式进行过滤,以查看 Search Console 中的高 noindex 页面数量是否报告了以下页面不是很重要,这些部分的重要页面实际上已编入索引。”

John 还表示“[...] 站点地图本质上是一个好的开始,但您可以做的另一件事是通过内部链接明确这些页面对网站非常重要,以便我们更快地抓取它们。 这可以是您所说的临时内部链接:在几周内,我们会从主页链接到各个产品。 […]本质上,当我们发现内部链接发生了显着变化时,通常我们也会去仔细检查这些页面。 所以这可能是一种将事物再次推入索引的临时方法。 使用内部链接,并不是说这些是网络上的重要页面,而是说与您的网站相关的重要页面。 因此,如果您显着更改内部链接,可能会发生网站的其他部分(可能只是勉强编入索引)在某个时候退出。 所以这就是为什么我会在临时级别上这样做并说,我想将它们推回系统,以便它们以正常速度重新抓取,然后我将更改内部链接,以便一切恢复正常。”

关于向页脚添加链接,John 补充说:“我认为这也可以。 如果我们可以在网站上非常重要的页面上找到它通常会更好,通常就像在您的主页上,[...] 您说这对您很重要,因此,我们将仔细检查该页面。 ”

规范标签和备用标签

14:25 “我正在使用一个 WordPress 网站,并且我正在使用两个插件。 [其中一个] 会自动将 rel="canonical" 链接添加到每个页面。 […] [另一个是翻译器插件],它向 [to] 每个页面添加一个 rel=“alternate” 链接。 它说的是否合乎逻辑:对于那个 URL,它是规范的,但它也是替代的? 它在爬虫的某个地方发生冲突吗?”

约翰说:“不。 我的意思是我不知道这两个插件到底是做什么的。 从整体的角度来看,如果您的页面上有一个 rel=canonical ,那么您基本上就是在使用一个规范的说法:那里提到的链接是我想要的首选 URL。 如果是同一个页面,那就完美了,因为它让我们确认该页面是您想要编入索引的页面。

rel="alternate" 基本上意味着该页面也有其他版本。 因此,对于不同的语言,例如,如果您有一页是英文的,一页是法文的,那么您将在这两种语言版本之间拥有 rel=”alternate” 链接。 这并不是说该链接所在的页面是备用页面,而是就像这是两个不同的版本,一个是英文的,一个是法文的。 它们都可以是规范的,因此具有这种组合通常很好。

需要注意的一个地方是规范不应该跨语言。 因此,在您的法语页面上,您不应该将规范设置为英文版本,因为它们本质上是不同的页面。 但是法语页面可以是规范的,英文页面可以是规范的,并且您在两者之间有备用链接,这本质上是一个很好的集合。”

规范化或无索引标签

16:49 “我们有一个网站,其中包含一个电子商务商店,其中包含许多产品变体,内容稀少或重复。 我列出了我们想要编入索引的所有 URL […],但我们不想编入索引。 [...] 我不确定哪个更好:规范化还是无索引?”

John 说,“我认为对于另一个页面我应该使用 noindex 还是 rel=”canonical”这个一般性问题可能没有绝对的答案。 [...] 如果你为此苦苦挣扎,你不是唯一一个喜欢的人,哦,我应该使用哪一个? 这通常也意味着这两个选项都可以。 所以通常情况下,我会看到你真正强烈的偏好是什么。 如果强烈的偏好是您真的不希望在搜索中显示此内容,那么我会使用 noindex。 如果您的偏好更多,我真的希望将所有内容组合在一个页面中 [...],那么我会使用 rel=”canonical”。 最终效果是相似的,您正在查看的页面很可能不会在搜索中显示,但使用 noindex - 它肯定不会显示,而使用 rel=“canonical” - 它更有可能不会显示。 ”

约翰总结道:“你也可以两者都做。 例如,如果外部链接指向此页面,那么将它们都放在此处有助于我们弄清楚,您不希望该页面被编入索引,但您还指定了另一个,所以也许一些信号我们可以就往前走。”

移动优先索引和抓取

28:26 “[...] 我们相应地优化了我们的网站 [用于移动优先索引]。 至于配置,谷歌推荐两种方式。 第一个是响应式网页设计,第二个是动态服务。 因为第一种方式对我们来说通过我们的技术环境实现起来有点困难,所以我们使用第二种方式。 但我们仍然看到,如今,每天有超过 20 万次爬入我们的移动域。 这是正常现象吗? [...] 我们有 m-dot 域,然后我们将其重定向到主域。”

约翰回答说:“有一些像那样的爬行是正常的。 即使在重定向之后,我们的系统也需要很长时间才能完全停止对域的抓取,所以我不认为这是一个问题。 我们的系统有时对此类事情有很长的记忆,如果您将站点从一个域移动到另一个域,或者如果您使用子域进行这种移动更改,有时需要数年才能完全停止爬行。”

网络技术与排名

36:00 使用普通 HTML、CSS、JS 和另一种——PWA 制作的网站的排名是否有任何关系或影响? [...] 我们的一个主要竞争对手最近采用了它,我们注意到他们的 SERP 排名有了巨大的飞跃。”

John 说:“这些是制作网站的本质不同的方法,您可以制作具有许多不同框架和格式的网站。 在大多数情况下,我们将这些视为普通的 HTML 页面。 因此,如果它是基于 JavaScript 的网站,我们将对其进行渲染,然后像处理普通 HTML 页面一样对其进行处理。 如果一开始就已经是 HTML,我们可以这样做。 [有] 不同的框架和 CMS 背后。 通常,我们基本上忽略了这一点,只是说,好吧,这是一个 HTML 页面,我们可以处理它。

因此,您的一个竞争对手已经从一个框架转移到另一个框架,并且在搜索方面有所改进,从我的角度来看,框架的变化不会对此负责。 但更确切地说,也许他们现在有了一个更新的网站,以及框架的变化。 也许较新的网站有不同的内部链接,不同的内部内容,[它] 明显更快或更慢,用户真的很喜欢它,或者他们在网站启动时进行了营销活动。 所有这些东西都在其中发挥作用,而且这些东西并不局限于你正在使用的框架。”

Google PageSpeed Insights 与 Lighthouse

37:39 “Google PageSpeed Insights 中的实验室数据结果与我的 Chrome 浏览器中的 Lighthouse 结果相同吗? 他们使用相同的公式吗?”

约翰说:“我不知道百分百,但他们的做法完全不同。 [...] 如果您使用在某个数据中心上运行的 PageSpeed Insights,该数据中心具有基本上模拟的设备,我们试图在其中像普通计算机一样工作,并且我们有一些限制使其速度变慢。 [...] 在 Lighthouse 中,它基本上可以在您的计算机上通过您的互联网连接运行。 我认为Chrome 中的 Lighthouse 也有一些限制,它适用于使其看起来可能比您的计算机可能能够做的慢一点,以确保它具有可比性。

但本质上,它们在完全不同的环境中运行,这就是为什么你经常会在那里看到不同的数字。 [...] 如果您使用其他在线运行的速度工具进行测试,您可能 [还] 看到不同的数字。 此外,我们在 Search Console 中看到的用于搜索排名的字段数据也可能是完全不同的数字,因为您的用户平均可能拥有不同类型的设备或不同类型的互联网连接。 因此,即使公式相同,这些系统周围的整个环境也大不相同。”

谷歌发现

47:09 “我们注意到我们网站上的 Google Discover 存在一个大问题。 两天之内,流量下降了百分之七十。 [...] 所以我们想知道我们是否做错了什么? [...] 你能澄清一下到底发生了什么,因为它是如此激烈的平局? [...] 会不会是技术错误?”

John 说:“我不具体了解您的网站,但我收到很多人的报告,发现流量处于开启或关闭状态,因为如果我们的算法确定我们'目前不会在 Discover 中显示该网站的太多内容,然后基本上所有的流量都会消失。 另一方面,如果我们确实在“发现”中展示了您网站上的某些内容,那么您会突然再次获得大量流量。

如果这是一个技术问题,那么您也会在网络搜索中看到它,并且您会看到出现抓取问题。 我没有完全了解 Discover 中到底发生了什么,但通常,我看到人们谈论的问题是一方面是质量问题,可能是网站的质量不太好,以及关于我们为 Discover 制定的个人政策。 特别是,对于 Discover,我们有一些不同于网络搜索的政策和建议,我认为这些政策在成人内容、点击诱饵内容方面略有不同。 [...]我们在 Discover 的帮助中心页面上都提到了这些。 我想很多网站都混合了所有这些东西,有时我怀疑我们的算法发现太多了,然后他们说,哦,我们现在必须小心这个网站。 因此,在不了解您的网站并且不知道 Discover 在那里所获取的具体内容的情况下,这就是我要去的方向。 […]

从我们的角度来看,Discover 是我们尝试向人们展示信息流的地方,因此,我们往往没有很多详细信息来说明您需要提供哪些内容才能真正表现出色。 所以有时候看看其他人的想法是有意义的。”

响应时间

50:41 “对于一个新的新闻媒体网站来说,什么是好的响应时间?”

根据 John 的说法,“响应时间影响我们计算服务器可以进行多少爬网的能力。 通常,从实际的角度来看,响应时间会限制或影响爬网需要多少并行连接。 因此,如果我们想从一个网站上抓取一千个 URL,那么在一天中将其分散的响应时间可能会非常长。 然而,如果我们想从一个网站抓取一百万个 URL,并且响应时间很长,那么这意味着我们最终会与服务器建立大量并行连接。 我认为我们有一些限制,我们不想在服务器上引起问题,所以这就是响应时间与抓取速度直接相关的原因。

对于一个新闻网站来说,与其说是不是新闻,不如说是我们每天需要抓取多少个网址。 所以这就是我要看的角度。 可能在一个新闻网站上,我们一天爬一万页,那些重要的新闻文章都被覆盖了。 可能我们每天必须抓取数百万篇文章,因为我们总是需要刷新存档 [...],那么显然响应时间和抓取速度看起来会有所不同。”