客户端付费墙的isAccessibleForFree处理

时间:2018-09-03 15:40:13

标签: google-search schema.org json-ld

试图了解Google's guidelines for paywalled content

我的网站是这样的:

  • 文章的内容位于.paid-content元素中。
  • 免费用户我们使用的脚本有时会删除.paid-content元素,并用一个.paywall元素替换为“请购买订阅以阅读本文”。

因此,免费用户访问我网站上的文章有两种可能性:

  1. 您可以免费阅读该文章,在这种情况下,只有.paid-content元素存在,没有付费界面。

  2. 您不会阅读这篇文章。我们删除.paid-content元素,然后将其替换为.paywall元素。

当前我的JSON-LD看起来像这样

"hasPart":[  
      {  
         "@type":"WebPageElement",
         "isAccessibleForFree":false,
         "cssSelector":".paid-content"
      },
      {  
         "@type":"WebPageElement",
         "isAccessibleForFree":false,
         "cssSelector":".paywall"
      }
   ],
   "isAccessibleForFree":false

问题:

  1. .paywall是否还要列在hasParts数组中?该元素仅显示“请购买订阅”。它不包含任何对免费用户隐藏的文本。

  2. 就我而言,在任何给定时间,页面上都将仅存在这两个元素之一。那样行吗?或者,如果Google搜寻器无法找到hasPart数组中指定的所有元素,这会是一个问题吗?

1 个答案:

答案 0 :(得分:0)

简短答案:

对于Google来说,hasPart> cssSelector用于在付费墙后面显示视觉上隐藏的内容。在您的示例中,您要么完全删除内容,要么公开显示所有内容,因此无论哪种情况,架构都是无关紧要的和不必要的。

.paywall并不是必需的,因为cssSelector应该引用包裹付费内容的元素的类,而不仅是付费消息(所有用户都可见)。

.paid-content封装了所有用户可见的内容,这也将使该架构也不必要,因为您只应将目标视觉隐藏在付费专线墙后面的内容作为目标(请参阅下文和their second example)。

我不确定Google对不匹配DOM的架构标记的反应如何,但是我认为在这种情况下它可能会被忽略,因为他们正在寻找非常具体的东西。此处没有索引内容的页面是更大的问题。

长答案:

(从Google的角度来看)拥有这种付费专区架构的意义可以归结为one major reason

  

发布者应将付费墙内容与结构化数据一起封闭,以   帮助Google从实践中区分付费墙内容   伪装,则提供给Googlebot的内容与   内容提供给用户。

Cloaking(即,为了获得SEO收益而将内容隐藏在页面上)多年来一直是“黑帽匠”使用的一项重要策略。 Google会在可能的情况下(例如BMW back in 2006)对这种做法进行惩罚,并且肯定会在算法上做了大量工作来自动捕获这些信息。问题是-现在我们有像您这样的付费专区网站,这些网站“隐藏内容”,但出于不同(且不太可信)的原因。

但是,您并不是在视觉上隐藏内容,而是从页面上剥离内容。这种方法的问题在于,您会冒着Google机器人也碰到付费专栏且无法正确索引页面的风险-因为内容不存在。即使您正在使用JavaScript it's a risk剥离内容。

这就是为什么典型的付费专区网站会覆盖或隐藏CSS覆盖物与正文上的overflow:hidden后面的内容的原因。这种方法可能会触发Google伪装的危险信号,这就是为什么他们现在要求人们使用它(我只是假设最后一句话)。

因此,考虑到这一点,并从您提供的链接中查看Google的示例,cssSelector的意思是:“此内容不是伪装/黑帽骗术,只是付费隔离,所以让我们仍然索引它。”

您的底线是示例中的模式无关紧要...因为您正在向用户显示所有内容而没有任何要向Google证明的内容,或者您​​正在显示的页面没有内容而且Google无需担心任何隐蔽问题。

因此,如果这是您的事,则经验法则是:

  1. 如果需要,请勿从页面中删除内容(甚至通过JS) 索引
  2. 如果您付费墙内容,则将其隐藏并使用其内容来帮助Google 模式说明

其他松散相关的注释:

  1. 如果您从structured data tool中取出cssSelector,它仍然 验证,但我并不总是相信该工具是正确的
  2. Google hasPart和schema.org hasPart似乎不太匹配 上
  3. 让我感到奇怪的是,这不仅为新的黑帽技巧打开了大门