疯狂的技术搜索引擎优化：实际问题和修复
有关技术搜索引擎优化的许多文章都是纯理论; 网站应如何与搜索引擎搜寻器和索引系统进行交互的理想世界方案。
在现实世界中，事情变得一团糟。 网站不是原始的内容交付系统，搜索引擎也不是绝对的人工智能霸主，并且编写网站代码的人会犯很多无意的错误。
多年来，我已经分析了无数网站上的技术性SEO问题，并且遇到了许多用纯SEO理论无法轻松解释的问题。 相反，这些问题需要一些实用的方法来解决，有时问题的根本原因仍然无法解释。
在这里，我将概述其中的一些问题，并希望给您一些想法，以便您自行解决和解决类似的问题。
结构化数据和丰富的摘要
我的一位客户最近将他们的网站迁移到了一个新技术栈，从所有人的角度来看，该技术栈比以前版本的网站更快，更好地进行了优化。 在迁移之前，该客户在Google的搜索结果中享受了很多丰富的摘要。 具体来说，他们在大多数关键页面上都有星级评分。
但是，在迁移之后，他们很快失去了所有这些星级。 而且我们不知道为什么。
Google的结构化数据测试工具（SDTT）没有提供帮助。 该工具可以正确识别站点上的结构化数据，并且似乎是完全有效的标记。 那么，为什么Google会忽略该标记并从该客户的页面中删除星级评分代码段？
我们决定尝试一些我们认为不会有太大变化的事情，但最终解决了整个问题：我们将结构化数据片段移至了页面源代码的<head>部分。
对于SDTT来说，这没有什么区别，因为它丝毫不影响标记的有效性。 看看HTML源代码中事物出现的顺序是否影响Google处理它的方式，是最后的努力。
进行此更改后不久，该站点的丰富摘要迅速开始恢复。 几天之内，所有丢失的星级摘要都回来了。
结构化数据标记的位置对Google的处理方式产生了巨大的影响。
从理论上讲，只要原始HTML源代码中存在标记，标记的位置就不会有任何区别-实际上，该代码段应位于网站的<head>部分中，以实现搜索中的丰富代码段引擎结果页面。
从Google的文档中并不能立即看出这一点。 没有明确提及必须将标记放在页面的<head>部分中，而不是在<body>中。
但是，出于这个问题的考虑，我建议我始终将结构化数据标记放在页面HTML源代码的<head>部分中。 这似乎使Google可以更轻松地处理结构化数据，并帮助我的更多客户获得了丰富的摘要。
Hreflang元标记和iframe
我最近刚遇到类似的问题。 客户的网站已在其首页上实现了hreflang元标记，以指示针对不同国家/地区的替代版本。 这些hreflang标记完全有效，并显示在首页的所有版本中，但Google未能识别它们。
客户的开发人员绞尽脑汁，试图找出是什么原因阻止了Google处理这些hreflang元标记。 标签应该出现在<head>部分的页面HTML源代码中，并且与所有其他首页完全互惠。 这些标签应该没有任何问题。
但是，Google并未在Search Console中报告这些报告，而是倾向于在其国际搜索结果中显示错误的国家/地区版本。
当我接这个客户端时，我要做的第一件事就是将页面的HTML源代码与完整的DOM进行比较。 前者是在页面上执行“查看源代码”时看到的内容，后者是在执行所有客户端代码（例如JavaScript）时浏览器用来向最终用户显示页面的内容。
在这里，我发现了一些非常有趣的东西：在原始HTML代码中，位于hreflang元标记上方的是一段JavaScript。 页面完全呈现并执行了所有客户端代码后，JavaScript在页面中插入了<iframe> 。
然后，此iframe位于hreflang元标记上方。 事实证明，这是一个问题。
您会发现，iframe不属于网页的<head>部分。 根据官方HTML5标准，仅在页面的<body>部分中存在iframe。 将iframe放置在网页代码的<head>部分违反官方W3C标准。
Google将网页编入索引时，它会尝试解决许多此类违反标准的问题。 很少有网页具有完全符合W3C的代码。 幸运的是，HTML是一种非常宽容的标记语言。 Web浏览器和搜索引擎可以很好地处理大多数网页，即使这些网页具有无效的标记。
但是，这种情况被证明是有问题的，并且与Google的两阶段索引编制过程有关。 索引的第一阶段基于网页的HTML源代码，在此索引过程中不会执行任何客户端脚本。 然后，Google还对同一页面进行第二阶段索引编制，在该索引中加载了客户端脚本，并且该页面完全像Web浏览器一样呈现。
在索引的第二阶段，将执行位于hreflang标记上方的页面HTML源代码中的JavaScript，并将iframe插入页面的代码中。
在分析此问题时，我想起了杰米·阿尔贝里科（Jamie Alberico）和Google的约翰·穆勒（John Mueller）最近关于以下内容的Twitter对话：网页呈现代码的<head>部分中的iframe：
简而言之，iframe不属于页面代码的<head> ; 它们应该位于页面的<body>部分中。 当Google在<head>中看到一个iframe时，它假定<head>已经结束并且页面的<body>已经开始。
相反，hreflang标记仅在页面的<head>部分中存在时才有效。 页面的<body>中的任何hreflang标记都被视为无效，并且被Google适当地忽略了。
看来Google处理hreflang元标记是索引第二阶段的一部分。 这为我的客户创造了一个完美的风暴，在该客户中Google呈现页面并将iframe插入代码中。 然后，这导致Google过早地将其余代码作为<body>的一部分进行处理，从而忽略了hreflang标签的存在。
同样，一旦发现根本问题，解决方案就很简单。 我们将有问题的JavaScript移到了<head>部分的末尾，在其中插入iframe不会造成任何损坏。
几天之内，Google识别了该页面的hreflang元标记，并开始报告它们在Search Console中的存在。
Googlebot和自动IP重定向
几年前，我遇到了一个让我感到困惑的问题。 客户刚刚启动了网站的新版本，并且作为其扩展策略的一部分，他们拥有网站的不同国家/地区版本; 一种针对美国，一种针对英国，另一种针对世界其他地区。
该网站的美国版很快开始排名，并且表现良好。 但是，英国和世界其他地区的公司几乎没有从Google获得任何流量。 从历史上看，英国一直是客户的最大听众，而新网站在英国市场上的表现不佳。
在网站管理员工具中查看数据也无济于事。 这是Google将其重命名为Search Console并为我们提供更多有用数据之前的方法。 那时，我所要做的就是索引状态报告，该报告显示的索引页数量很少。 Sitemaps报告也无济于事-我们提交了一个包含该站点所有页面的XML Sitemap，在这里我们也只看到了很少的索引编制，而没有真正的提示导致问题的原因。
网站启动一两个星期后，我在半夜醒来，时光倒流。 我突然知道根本问题是什么。
您会看到，这个新站点使用了基于用户IP地址的自动重定向。 该站点将确定访问者的IP地址与哪个国家/地区相关联，然后自动将访问者重定向到站点内容的正确版本。
Googlebot抓取网站时，主要是通过位于美国的IP地址进行的。 如果有的话，很少会从国际IP地址抓取网站。
由于网站的所有页面上都存在该站点的自动IP重定向，因此每次尝试查看与您所在国家/地区不符的页面都意味着您将被重定向到正确的国家/地区。
对于Googlebot而言，这意味着除美国部分外，看不到该网站的其他任何部分。
每当Googlebot尝试抓取英国及世界其他地区的页面时，该网站都会将其重定向到美国部分。 因此，尽管Googlebot在美国页面上具有完全的可见性，但它看不到该站点的其他部分，因此也无法建立索引。
一旦了解了问题，解决方案就很简单：我们更改了自动IP重定向功能，将Googlebot访问设置为例外。 这样，Googlebot永远不会重定向到任何特定国家/地区，并且可以自由地爬网整个网站。
进行此更改后，该网站上的索引编制水平大幅度提高，英国部分在短时间内获得了Google的大量访问量，从而使其恢复了迁移前的水平。
现实世界中的技术SEO
我希望这些示例表明，在现实世界中，很难识别技术性SEO问题。 一个网站有很多相互影响的活动部分，有时微小的变化会在某个地方引起巨大的问题。
分析网站时，并非总是拥有所需的所有数据。 例如，IP重定向问题本来可以更容易地确定每个国家版本的XML站点地图是否不同，但事实并非如此，因此我们必须从所掌握的少量信息中进行推断。
总体上，它对SEO（特别是技术SEO）有很好的理解，才能识别，分析和解决此类问题。 必须全面了解搜索引擎如何对网页进行爬网和编制索引-这是所有技术SEO的根本。
本文中表达的观点是来宾作者的观点，不一定是Search Engine Land。 工作人员作者在此处列出。
本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。如若转载，请注明出处:http://www.botadmin.cn/sylc/10125.html