很多关于技术搜索引擎优化的文章都是纯理论;网站应该如何与搜索引擎爬虫和索引系统交互的理想世界场景。
在现实世界中，事情变得一团糟。网站并不是原始的内容传递系统，搜索引擎也不是万无一失的人工智能霸主，网站编码人员也会犯很多无心的错误。
多年来，我分析了无数网站的技术SEO问题，我遇到了许多问题，这些问题用纯SEO理论很难解释清楚。相反，这些问题需要一些实际的办法来解决，有时问题的根本原因仍然无法解释。
在这里，我将概述其中的一些问题，并希望能给您一些想法，以便您在遇到类似问题时自己解决它们。
结构化数据和富片段
我的一个客户最近将他们的网站迁移到了一个新的技术栈上，所有人都说，这个技术栈比他们以前的网站版本更快、更好。在迁移之前，这个客户端在谷歌的搜索结果中享受了很多丰富的片段。具体来说，他们在大多数关键页面上都有星级评价的片段。
然而，在它们迁徙之后，它们很快就失去了所有的星级。我们不知道为什么。
谷歌的结构化数据测试工具(SDTT)没有提供任何帮助。该工具正确地识别了站点上的结构化数据，并且似乎是完全有效的标记。那么，为什么谷歌会忽略标记并从该客户机的页面中删除星级评级片段呢?
我们决定尝试一些我们认为不会有太大区别的方法，但最终解决了整个问题:我们将结构化数据片段移动到页面源代码的< head >部分。
这对SDTT没有影响，因为它不会以任何方式影响标记的有效性。这更像是最后一刻的努力，看看HTML源代码中内容出现的顺序是否会影响谷歌处理它的方式。
在我们做出这一改变后不久，该网站的富片段迅速开始回归。没过几天，所有丢失的星评片段都回来了。
结构化数据标记的位置对谷歌处理它的方式有很大影响。
虽然从理论上讲,它不应该有什么影响标记所在——只要它存在于原始的HTML源代码——在实践中在< >头部分片段应该为一个网站在搜索引擎结果页面实现丰富的片段。
这在谷歌的文档中并不明显。没有明确提到必须将标记放在页面的< head >部分中，而不是放在< body >中。
然而，抛开这个问题不提，我建议始终将结构化数据标记放在页面HTML源代码的< head >部分中。这似乎使谷歌更容易处理结构化数据，并帮助我的更多客户实现了丰富的片段。
Hreflang元标签和iframe
最近我遇到了类似的问题。一个客户的网站在他们的主页上实施了hreflang元标签，以表明针对不同国家的替代版本。这些hreflang标签是完全有效的，并出现在所有版本的主页，但谷歌未能识别他们。
客户的开发人员绞尽脑汁，试图找出什么可以阻止谷歌处理这些hreflang元标签。标签出现在页面的HTML源代码< head >部分中，正如它们应该的那样，它们与所有其他的主页完全对等。这些标签不应该有任何问题。
然而，谷歌并没有在搜索控制台报告他们，并且倾向于在其国际搜索结果中显示错误的国家版本。
当我使用这个客户机时，我做的第一件事就是将页面的HTML源代码与完成的DOM进行比较。前者是在页面上执行“查看源代码”时看到的内容，后者是在执行所有客户端代码(如JavaScript)时浏览器用于向最终用户显示页面的内容。
这里我发现了一些非常有趣的东西:在原始的HTML代码中，有一段JavaScript位于hreflang元标签的上方。当页面完全呈现并执行所有客户端代码时，JavaScript已经在页面中插入了< iframe >。
这个iframe然后坐在hreflang元标签上面。事实证明，这是一个问题。
你看，iframes不属于一个网页的< head >部分。根据官方HTML5标准，iframe应该只存在于页面的< body >部分。在网页代码的< head >部分放置iframe是违反W3C官方标准的。
当谷歌对网页进行索引时，它试图解决许多此类打破标准的问题。很少有网页是完全W3C的