Return to site

野外技术搜索引擎优化:现实问题和修复

· seo优化

关于技术搜索引擎优化的很多内容都是纯粹的理论; 网站应如何与搜索引擎抓取工具和索引系统进行交互的理想世界场景。

在现实世界中,事情变得混乱。网站不是原始的内容传送系统,搜索引擎不是绝对可靠的人工智能领域,而且编码网站的人会犯很多无意的错误。

多年来,我已经分析了无数网站的技术搜索引擎优化问题,我遇到了许多问题,纯粹的SEO理论不容易解释。相反,这些问题需要一些实用的方法来解决,有时问题的根本原因仍然无法解释。

在这里,我将概述其中的一些问题,并希望能给你一些想法,如果碰巧碰到它们,就自己排除故障并解决类似的问题。

结构化数据和丰富的代码段
我的一位客户最近将他们的网站迁移到了一个新的技术堆栈,无论如何,这个技术堆栈比他们网站的先前版本更快,更优化。在迁移之前,此客户在Google的搜索结果中享有大量丰富的摘要。具体来说,他们在大多数关键页面上都有星级评分片段。

然而,在他们迁移后,他们很快失去了所有这些星级评级。我们无法弄清楚原因。

谷歌的结构化数据测试工具(SDTT)没有提供任何帮助。该工具正确识别了网站上的结构化数据,似乎是完全有效的标记。那么为什么谷歌会忽略该标记并从该客户的页面中删除星级评分片段?

我们决定尝试一些我们认为不会产生太大影响的东西,但最终解决了整个问题:我们将结构化数据片段移动到页面源代码的<head>部分。

这对SDTT没有任何影响,因为它不会以任何方式影响标记的有效性。看看HTML源代码中出现的内容的顺序是否会影响Google处理它的方式,这是最后的努力。

在我们进行此更改后不久,该网站的丰富网页摘要迅速开始回归。几天之内,所有丢失的星级评分片段都已归还。

结构化数据标记的位置对Google处理它的方式产生了巨大的影响。

虽然从理论上讲,它应该在标记所在的位置没有任何区别 - 只要它存在于原始HTML源代码中 - 实际上,该片段应位于<head>部分,以便网站在搜索中实现丰富的片段引擎结果页面。

Google的文档并未立即显示这一点。没有明确提到必须将标记放在页面的<head>部分而不是<body>中。

然而,在这个问题的背后,我建议我始终将结构化数据标记放在页面的HTML源代码的<head>部分。这似乎可以让Google更轻松地处理结构化数据,并有助于为更多客户实现丰富的代码段。

Hreflang元标签和iframe
我最近遇到了类似的问题。客户的网站在其主页上实施了hreflang元标记,以指示针对不同国家/地区的替代版本。这些hreflang标签完全有效并且存在于所有版本的主页中,但Google无法识别它们。

客户的开发人员绞尽脑汁试图弄清楚什么可能阻止谷歌处理这些hreflang元标记。标签存在于<head>部分的页面的HTML源代码中,因为它们应该是,并且它们与所有其他主页完全互惠。这些标签应该没有任何问题。

然而,Google并没有在Search Console中报告这些内容,而是倾向于在其国际搜索结果中显示错误的国家/地区版本。

当我接手这个客户端时,我做的第一件事就是将页面的HTML源代码与完成的DOM进行比较。前者是您在页面上执行“查看源”时看到的内容,后者是浏览器在执行所有客户端代码(如JavaScript)时向最终用户显示页面的内容。

在这里我发现了一些非常有趣的东西:在原始HTML代码中,有一段JavaScript位于hreflang元标记之上。当页面完全呈现并且所有客户端代码都已执行时,JavaScript 在页面中插入了<iframe>。

这个iframe然后坐在hreflang元标记之上。事实证明,这是一个问题。

你看,iframe不属于网页的<head>部分。根据官方HTML5标准,iframe只应存在于页面的<body>部分中。将iframe放在网页代码的<head>部分是违反官方W3C标准的。

当Google为网页编制索引时,它会尝试解决许多此类标准问题。找到一个完全符合W3C标准的网页是非常罕见的。幸运的是,HTML是一种非常宽容的标记语言。即使这些页面具有无效标记,Web浏览器和搜索引擎也能很好地处理大多数网页。

然而,这个例子被证明是有问题的,它与谷歌的两阶段索引过程有关。索引的第一阶段基于网页的HTML源代码,并且在此索引过程中不会执行任何客户端脚本。然后Google还对同一页面进行第二阶段索引,其中加载了客户端脚本,并且页面完全呈现为Web浏览器。

在索引的第二阶段,执行位于hreflang标记上方的页面HTML源代码中的JavaScript,并将iframe插入到页面代码中。

在我分析这个问题时,我记得Jamie Alberico和Google的John Mueller之间最近发生的关于这一点的谈话:iframe在页面的渲染代码的<head>部分:

简而言之,iframe不属于页面代码的<head> ; 它们应该在页面的<body>部分中。当Google在<head>中看到iframe时,它会假定<head>已经结束并且页面的<body>已经开始。

相反,hreflang标签仅在页面的<head>部分中存在时才有效。页面的<body>中的任何hreflang标记都被视为无效,并且被Google正式忽略。

似乎Google将hreflang元标记作为索引第二阶段的一部分进行处理。这为我的客户创造了一个完美的风暴,谷歌渲染页面并将iframe插入到代码中。这导致Google过早地处理其余代码作为<body>的一部分,因此忽略了hreflang标签的存在。

同样,一旦我们找到了潜在的问题,解决方案就很简单了。我们将有问题的JavaScript移动到<head>部分的末尾,其中iframe的任何插入都不会造成任何损害。

几天之内,Google就识别了该页面的hreflang元标记,并开始在Search Console中报告它们的存在。

Googlebot和自动IP重定向
几年前,我遇到了一个问题,当时,我真的很困惑。客户刚刚推出了他们网站的新版本,作为其扩展战略的一部分,他们拥有不同国家版本的网站; 一个针对美国,一个针对英国,一个针对世界其他地区。

该网站的美国版本很快开始排名并且似乎表现良好。然而,英国和世界其他地区的部分几乎没有从谷歌获得任何流量。从历史上看,英国一直是客户的最大受众,新网站在英国市场上表现不佳。

查看网站站长工具中的数据也没有帮助。这是谷歌将其重命名为Search Console并为我们提供更多有用数据的方法。那时,我所要做的只是索引状态报告,它显示了索引页面的数量相当少。Sitemaps报告也没有多大帮助 - 我们提交了一个包含所有网站页面的XML站点地图,在这里我们也只看到了一个低级别的索引,没有真正暗示导致问题的原因。

在网站发布一两周后,我在半夜醒来时带着“尤里卡”时刻醒来。我突然知道根本问题是什么。

您看,这个新站点使用基于用户IP地址的自动重定向。该网站将确定访问者的IP地址与哪个国家/地区相关联,然后自动将访问者重定向到网站内容的正确版本。

当Googlebot抓取网站时,它主要来自美国的IP地址。如果有的话,很少从国际IP地址抓取网站。

由于网站的所有页面都存在自动IP重定向,因此每次查看与当前国家/地区不一致的页面的尝试都意味着您将被重定向到正确的国家/地区。

对于Googlebot,这意味着除了美国部分之外,它无法看到该网站的任何其他部分。

每当Googlebot尝试抓取英国和世界其他地区的网页时,网站都会将其重定向到美国部分。因此,虽然Googlebot在美国网页上具有完全可见性,但它无法看到 - 因此无法索引 - 该网站的其他部分。

一旦我们理解了问题,解决方案很简单:我们更改了自动IP重定向,以便为Googlebot访问设置例外。这样,Googlebot从未被重定向到任何特定国家/地区,并且可以自由地抓取整个网站。

在我们进行此更改后,网站上的索引级别大幅提升,英国部门在很短的时间内从Google获得了大量流量,以使其恢复到迁移前的水平。

现实世界中的技术SEO
我希望这些例子表明,在现实世界中,技术搜索引擎优化问题可能非常难以识别。一个网站有很多相互影响的活动部分,有时一点点变化都可能导致一个巨大的问题。

分析网站时,并不总是拥有您想要的所有数据。例如,如果我们为每个国家/地区版本提供不同的XML站点地图,那么IP重定向问题会更容易识别,但事实并非如此,因此我们不得不根据我们所拥有的少量信息进行推断。

一般来说,它需要很好地理解SEO,特别是技术SEO,能够识别,分析和修复这些问题。充分了解搜索引擎如何抓取和索引网页是必须的 - 这是所有技术搜索引擎优化的根源。

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