为什么Google缓存对您说谎以及如何处理（如果有的话）
我经常在Google网站站长论坛，Reddit和Twitter上浏览SEO社区，并且看到诸如“ Google Cache is empty !!!”之类的标题。 和“ Google缓存中的404错误页面”一遍又一遍。
有这么多人清楚地担心Google无**确呈现其页面，我想写一篇有关缓存的文章，以帮助读者理解为什么检查Google Cache并不是分析Google如何查看页面的可靠方法。
我还将提供有关何时可能有用Google Cache以及应使用哪些工具检查Google如何呈现页面的信息。
什么是Google缓存？
在大多数情况下，如果您访问页面的Google缓存，则会看到Google上次对其进行抓取时的页面版本。 但是，您究竟看到了什么？ Google缓存包含Googlebot从您的服务器接收到的原始HTML的快照。 然后，您的浏览器将呈现Google捕获的HTML。
Google存储缓存页面的想法很简单：当页面关闭或出现临时超时时，它使用户可以浏览页面。
有几种方法可以让您检查Google缓存。 这是你的选择：
在搜索结果中，单击搜索结果中URL旁边的箭头，然后选择Google缓存。 Google提供了更好的说明：
您也可以直接在浏览器中键入地址。 使用cache：URL，您将被重定向到http://webcache.googleusercontent.com托管的缓存。 此外，您可以使用一种可一次检查多个URL的工具，例如Google Cache Checker。
浏览器插件也是一种选择。 例如，您可以使用Web缓存查看器。
现在，转到您要检查的页面。 单击页面上的任意位置，然后选择Web缓存查看器> Google缓存存档
现在，让我们对Google Cache进行切片和切块。 缓存视图显示了一些元素：
- 要求的网址-当Googlebot重新索引网站时，请求此页面。
- Google对页面建立索引或重新索引的日期–请记住，有时他们可能会使用您页面的较旧版本，因此该日期不会提供重要信息。
- 3种视图类型–完整版，纯文本版和查看源。
完整版显示页面的渲染视图。 请记住，您在渲染视图中看到的是您的浏览器而不是Google渲染的页面。
我如何知道此视图是由计算机上安装的浏览器而不是Google使用的Web渲染服务（WRS）渲染的？ 这是一个小实验。 如果我在Google缓存中看到的内容是由Google的WRS呈现的，则我会看到完整版本中与Google重新索引页面时捕获的内容相同的内容。
检查此页面的Google缓存-Online-Stopwatch，并比较上次重新建立索引的日期与缓存中显示的时间和日期。
如您所见，网站重新编入索引的时间和日期与时钟上显示的时间和日期不同。 我检查缓存时显示时钟，因此它实时显示内容。
如果页面是由WRS呈现的，则时间和日期将被冻结，并显示与灰色框中相同的时间。
文本视图是关闭CSS且未显示图像的版本。 在这里，您只会看到文本和超链接。 文本视图不会显示JavaScript加载的内容，因此，如果您检查Online-Stopwatch的纯文本版本，时钟就不存在了。
源代码不过是服务器发送给Googlebot的原始HTML。 请记住，您在源代码视图中看到的不是DOM（文档对象模型），因此不会执行JavaScript。
误解Google缓存中显示的信息非常容易。 我们应该在看到的内容与如何使用Google缓存中的数据之间保持合理的距离。
为什么不应该依赖Google缓存
现在，是时候解释为什么Google Cache无法显示Google如何“看到”您的网站了。
如上所示，缓存中的视图源显示了提供给Googlebot的原始HTML。 同时，完整版会显示您的浏览器呈现的呈现页面。 这两条信息极大地影响了我们如何解释我们在Google缓存中看到的内容。
让我猜猜。 您可能或多或少使用了最新版本的浏览器。 您可以通过访问此页面进行检查。 我的浏览器是Chrome 69版。
出于渲染目的，Google使用基于Chrome 41的Web渲染服务。Chrome41是使用三年的浏览器，它不支持正确渲染所需的所有现代功能。 这些版本之间的差距非常大，您可以通过简单比较caniuse中支持和不支持的功能来看到。
因此，使用Chrome 41和更新的浏览器进行渲染是无与伦比的。 即使您可以在Google缓存中看到正确呈现的页面版本，也无法确定它也可以在Chrome 41中使用。反之亦然。
审核网站时不应依赖Google缓存的第二个原因是内容的新鲜度。 Google在为页面重新编制索引时并不总是创建新的快照。 尽管此后内容可能已更改两次，但他们可能会使用较旧的版本。 结果，缓存中的内容可能已过时。
Google未提供有关Google Cache如何工作的详细信息，但它们为我们提供了有关如何解释在Google Cache中发现的问题的提示。 您可以在下面找到常见问题及其起因的回顾。
Google缓存中观察到的常见问题
重要说明：在缓存中观察到的某些异常是相当无害的，但这并不意味着您应该忽略它们。 如果某些事情无法按预期的方式进行，则您仍应投入一些精力并进行更深入的调查。
1.页面显示不正确
可能的原因： CSS或.js之类的资源已更改。
当您访问页面的缓存版本时，您可能会看到它已崩溃。 某些元素可能无**确呈现。 一些图像可能会丢失; 字体可能与您在网站上看到的字体有所不同。
发生这种情况的原因是，最近的呈现基于页面的缓存版本，该缓存版本可能引用了不再存在的资源。 因此，例如，如果自上次Googlebot访问以来某些资源（您的样式表或一些JavaScript代码）发生了变化，则当前的渲染可能不会按照您的意愿显示。
Google网站管理员趋势分析师约翰·穆勒（John Mueller）说，这种情况有时会发生，但不必担心。
但是，为确保Google在一次大聚会后不会看到看起来像是一团糟的页面，我宁愿进入Google Search Console并执行“获取并呈现”功能。
2. Google缓存中的404错误页面
原因：网站已切换为移动优先索引。
当Google开始推出移动优先索引时，人们感到非常恐慌，而且似乎许多网站在缓存中显示404错误页面。
很难解释为什么会发生此问题，因为Google未提供详细信息，但是Google Webmasters Twitter帐户明确指出，尽管可能会发生这种情况，但是缺少缓存视图不会影响您的排名。
注意：有些人注意到您可以使用替代方法来查看正确的结果。 单击404页面的地址栏中，然后将站点名称更改为其他名称，例如“ x.xyz”，然后输入。
Twitter上的某人注意到，如果在单击搜索后更改了缓存的页面URL，则可以使其正常工作。 我不知道这是否总是可行，但这是一个很酷的技巧。 https://t.co/NXjxmC8tdP
-> https://t.co/8sFmkyVAJq—？ 约翰 ？ （@JohnMu）2018年10月8日
3.缓存显示另一个子页面
原因：内部重复
最令人困惑的情况之一是，当您打开缓存视图并看到与预期不同的页面。
您进行“ site：”查询以检查缓存的版本，在搜索结果中可以看到的第一个奇怪症状是属于不同子页面的元标题和元描述。
当两个页面太相似而无法在索引中将它们分开时，Google可能会决定将两个页面折叠在一起。 如果他们看不到两个页面之间的重大差异，并且无法理解彼此之间的区别，则他们可能只会保留一个版本。 这似乎是Google处理重复页面的方法之一。
如果要对这两页进行单独索引，则需要查看内容并回答问题：为什么将它们标记为重复项？ 在下一步中，请确保在这些页面中发布的内容是唯一的，并且能够响应用户的意图。
4. Google缓存显示完全不同的域
原因：外部重复，不正确的规范化。
调查Google缓存时，有时可能会看到一个页面属于另一个域。 这可能确实令人困惑。
Google将一个网站与另一个网站融合在一起。
在一个Google环聊中，约翰·穆勒（John Mueller）提到了一种可能发生的具体情况。 有时，Google只会通过查看URL中的模式来尝试评估内容的唯一性（可能还有其他信号，但它们不会访问给定的页面）。 例如，如果两个电子商务站点具有几乎相同的URL结构，并且它们共享相同的产品ID，则Google可以将它们折叠在一起。
Google的John Mueller在网站站长视频群聊上发表了讲话。
rel = canonical标签不正确。
导致相同结果的另一种情况是有人错误地实施了rel = canonical标签。 例如，如果开发人员不小心在页面上添加了指向另一个域的规范标签，则很可能导致在Google缓存视图中显示另一个页面。 在这种情况下，您向Google发送信号说这两个页面是相同的，应该将它们折叠在一起。
当我诊断类似问题时，发生了我的个人噩梦。 显然，在我开始使用该网站之前:站群，有些页面带有外部规范标签-只能使用一段时间，但足够长的时间才能被Google发现。 此后，规范消失了，没有迹象表明它们存在，但是缓存仍然显示曾经被引用为规范的页面。
在GSC中添加了Inspect URL功能后，有可能解决这个神秘的问题（谢谢Google！）。 这使我能够确定Google选择了一个外部URL作为规范版本，并且该URL与用户声明的URL相同。 该用户（该网站的开发人员）遇到了麻烦。
具有相同内容的国际站点。 此问题的最后一个示例可能出现在使用不同域（TLD）上的相同内容的国际站点上。 例如，如果您决定在网站的德语版和奥地利版中发布相同的内容，则Google在理解它们之间的关系时可能会遇到问题。 甚至hreflang标记也可能无济于事，Google会将这些URL合并在一起。
在此示例中，请查看下面的动画GIF中显示的搜索结果。 该URL属于google.fr，但是如果进入缓存视图，您将看到google.ca作为请求的URL
5. Google缓存中出现404错误页面，但网站未切换到移动版
原因：该页面未缓存。
即使该站点尚未切换到移动优先索引，您也可以在Google缓存中看到404错误页面。 之所以可能发生这种情况，是因为Google不会为他们抓取并建立索引的所有页面存储缓存的视图。 Google拥有大量资源可供使用，但是它们并不是无限的，因此它们可能会放弃存储所有内容。
因此，仅因为对页面建立了索引，并不意味着就拍摄了快照。 但是，如果您在Google缓存中有快照，那肯定意味着该页面已被索引。
6.缓存为空
原因：该网站由JavaScript驱动
如果您有一个基于JS的网站，而没有以将渲染的版本提供给Google的方式（例如，使用预渲染或动态渲染）来渲染内容，则可能会看到一个空的缓存。
这是因为JavaScript应用程序的HTML可能包含几行代码，其余代码在JavaScript执行后加载。 因此，如果Google缓存显示原始HTML，则不会显示任何内容。
但是，即使您看到一个空的缓存，也并不意味着该内容没有被索引。 有关两波索引的规则（请参见下文）使之成为可能，因此无论您要使用JS加载的内容都将被索引，但可能会被延迟。
在第一波中，谷歌索引页面而不执行JavaScript。 在第二波中，执行JS，以便Google可以正确索引内容。
从技术角度来看，由JS驱动的网站的HTML在执行JavaScript之前没有太多元素可以显示是非常好的。
但是，考虑到JS索引的所有问题，由于索引的延迟，我不会依赖Google呈现我的JavaScript网站。 内容的索引编制可能会延迟几天甚至几个月！
7.根本没有缓存
原因：正在使用noarchive元标记。
使用noarchive元标记会阻止Google创建可以显示在Google缓存中的快照。 在大多数情况下，这是有意采取的步骤。 它指示工具或应用程序不应存储页面快照。
如果页面显示不应访问的敏感数据，这可能会很有用。 如果您决定使用noarchive元标记，那么它不会影响排名，只会影响是否创建并保留快照。
什么时候值得检查Google缓存
Google缓存显示了太多信息。 但是，它们是否可行？ 不总是。 是的，我在分析网站时会检查Google缓存，但我并不专注于解决Google Cache的问题。 我将在那里发现的任何问题视为其他问题的症状。
以下是一些对我始终有价值的信息：
- 对于使用JavaScript的网站，当我看到缓存为空时，我知道该网站不会通过预渲染或SSR（服务器端渲染）将内容提供给搜索引擎。 同样，当我看到基于JS的网站具有缓存视图时，我知道它们以某种方式将内容提供给Google。
- 当我看到与预期不同的页面时，我知道此页面可能存在重复内容问题。 这是分析内容质量时的宝贵提示。
- 最后，在检查缓存时，您可以验证Google是否遵守您的规范标记。 如果是，那就太好了。 如果没有，那么该是时候仔细看看您发送给Google的与索引编制相关的信号了。
保持健康距离
我不想阻止您在审核网站时检查Google缓存。 我们不能忽略在那里观察到的异常，因为我们不知道Google缓存背后的机制。 但是我们应该保持冷静。
我建议不要使用其中一种可以提供更多可操作数据的工具，而不必恐慌：
- 在Google Search Console中以Google身份获取：您可以在这里以与Google相同的方式呈现页面。 移动和桌面渲染可用。
- 移动设备适合性测试：如果您无权访问Google Search Console，则可以随时使用此工具。
- 在Google Search Console中检查URL：一个出色的工具，可用于检查有关特定URL的详细信息-提取状态，抓取日期，规范化。 通常，它提供有关Google对给定页面的看法的信息。
- 抓取工具：他们将帮助评估重复内容或薄页的规模-这是基于数据的更深入分析
您应该记住，Google缓存是用户的一项功能，其创建和显示快照的能力不会影响排名。 也就是说，您在Google缓存中看到的差异可能是可能影响排名过程的其他问题的征兆，因此值得仔细检查。
本文中表达的观点是来宾作者的观点，不一定是Search Engine Land。 工作人员作者在此处列出。
本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。如若转载，请注明出处:http://www.botadmin.cn/sylc/10110.html