誤用されたSchema.orgはSEOを傷つけますか？
気づいたサイトを継承しました
- すべてのナビゲーション要素でSchema.orgが過度に使用されている
- 製品を説明するページは
itemtype="http://schema.org/CreativeWork"としてマークされます
したがって、これらのタグが間違ったメッセージを送信しており、本当に最適化されていないのではないかと思っています。 nav（1）はいくつかのテーマで行われますが、（2）の方が心配です。製品の代わりにページに誤ったラベルを付けることは、SEOの面でヒットになる可能性がありますか？
Googleには 構造化データの使用に関する品質ガイドライン ：
Googleでの最優先事項は、ユーザーが検索クエリに関連性のある魅力的な回答を見つけられるようにすることです。高品質の構造化データは、検索ユーザーにとって誤解を招く、または欺cept的なエクスペリエンスを生み出してはなりません。テキスト、画像、ビデオなど、ページですでに見つかっているトピックとコンテンツの最新かつ正確な反映である必要があります。例えば：
- ディナーレシピに関するページでは、レシピ構造化データを使用して材料をリストし、調理手順を説明できます。
- ローカルビジネスをリストするページでは、構造化されたデータを使用してビジネス、その場所、連絡先情報、営業時間を説明できます。
構造化データが関連性基準を満たしていることを確認するために、アルゴリズムおよび手動の品質チェックを実行します。これらの標準に準拠していない構造化データが見つかった場合、ユーザーに高品質の検索エクスペリエンスを維持するために、手動でのアクション（サイトのリッチスニペットを無効にするなど）を行う権利を留保します。
構造化データスパムは、Googleにとって問題となっています。検索結果には、不適切なマークアップを持つサイトの例が多数あります： one 、 two 。ユーザーは、スキーマを誤って使用し、不適切なリッチスニペットを取得したため、 Googleは手動によるペナルティの廃止を開始しました を確認しました。以下は、この手動ペナルティを取得したときにウェブマスターが受け取ったテキストです。
スパム構造化マークアップ
このサイトの一部のページのマークアップは、ユーザーには見えないコンテンツのマークアップ、無関係または誤解を招くコンテンツのマークアップ、および/またはGoogleのリッチスニペット品質ガイドラインに違反するその他の操作的動作などのテクニックを使用しているようです。
この質問で与えられた誤用されたスキーマの例がサイトを罰せられるほどスパムであるかどうかはわかりませんが、行き過ぎたサイトは確かに罰則を受ける可能性があります。
SEOを傷つけますか？いや.
役に立たない？はい。
（2）に注目しましょう。
https://schema.org/CreativeWorkの仕様を見ると、製品のように振る舞うことができるOfferの重要な要素と、期待されるタイプのmainEntityを持つThingプロパティが含まれていることがわかります。 Productの親（およびその他すべて）。
つまり、次のような単純な構造を使用して、製品ページを提供できることを意味します。
<body class="page-wrap" itemtype="https://schema.org/CreativeWork">
...
<div class="main" itemprop="mainEntity" itemscope itemtype="Product">
<!-- The main entity property is actually another item called Product, which is the primary focus of the page -->
...
</div>
</body>
したがって、これはページに製品を含める簡単な方法です。
実際、Schema.org ItemTypeのHTMLまたはBody全体をラップするには、デフォルトでschema.org/WebPageまたはそのさまざまな子である必要があります。これらはすべてchildrenCreativeWorkアイテムタイプ。
WebPageをCreativeWorkとしてラベル付けすることに本質的に問題はありません。なぜなら、isであるためです。
Schema.orgを製品ページ用に最適化する方法は次のとおりです。
ItemPageとしてマークされた本文またはHTMLタグ-これは意味的に製品またはアイテムの正しいページです。これはWebPageを拡張し、CreativeWorkを拡張します。- 製品がリストされている関連領域（つまり、メインコンテンツ）で、それを
mainEntityのItemPageプロパティとしてマークし、そのitemTypeをProduct。として設定します。Offerが適切に最適化されていることを確認してください。 SERPの外観から、この全領域は製品ページの最も重要で関連する部分です。実際、Offerなどの親タイプでCreativeWorkが正しく構成されている限り、priceやavailabilityなどのプロパティのリッチスニペットを使用できます。期待されるタイプがoffersであるプロパティOfferとその子AggregateOfferは、そこにある重要な要素です。
だから、それについてはさりげないでください-製品ページはより高いレベルの忠実度であるので好まれますが、CreativeWorkはまだ意味的に正確で、ちょうど低いレベルの忠実度です。
また、注意してください：全体ページをProductとしてラベル付けすることは悪い習慣です。 Webページを製品にすることはできません。about製品にすることができます。これが、Microdataに子、プロパティの継承などがある理由です-ページを分割するのに役立ちます。
上記の例では、ItemPageが適切だったので使用しました。これにより、製品ではなく、ページに適したBreadCrumbs *などの柔軟性が得られます。
（1）について：
ナビゲーション要素の適切なマークアップが悪影響を与えるという証拠はゼロでしたが、これによる純利益はまだ不明です。
Schema.orgに関連するMicrodataのonlyの悪影響はバグ（つまり、間違ったデータを間違ったプロパティに配置する）とクローキングです。<meta>タグを過剰に使用すると、Webサイトが危険にさらされますゲームの関連性を試してみてください。
*そのプロパティのMicrodataの処理方法にはバグがありますが、JSON-LD表記で処理するのが最適です。
2018 Update：明確にするために、スパムまたは不正な構造化データはSEOを傷つける可能性があります
どうして？ Googleが検索コンソールで警告する手動アクションです。対処および修正が行われない場合、ランキングは低下します。すべてのページのフッターに3件のレビューをマークアップするために構造化データを使用するクライアントがいました。その結果、時間の経過とともに、ランキングで顕著なヒットを引き起こした、迅速な手動アクション。
また、スキーマをサイトを分類する方法と考えてください。あなたはレストランだと言っても、自分をアイスクリームショップとしてマークアップします。突然、より多くの人々に手を差し伸べることができるとき、あなたは小さなニッチな聴衆に自分自身を制限しています。
構造化データを使用するときは、潜在的なオーディエンスを排除することなく、常に可能な限り正確になるようにしてください。
一般的なケースでこれに答える正確な方法があるかどうかはわかりませんが、サイト上の誤った情報はSEOにとって自動的に悪いものであると考えます。検索エンジンは、不正な情報に対して次のいずれかのみを実行できます。
- 無視してください。その場合、ロード時間を増やすだけでメリットはありません。
- それを使用します。その場合、実際に必要としないカテゴリのヒットを取得しますが、これはコンバージョンに悪影響を及ぼします。
- 最悪のシナリオであるペナルティを科してください。
だから、私ははい、不正確なマークアップを持つことは悪いと思います。マークアップが多すぎる場合、ユーザビリティに影響を与えたり、サイトの無関係な部分を強調したりしない限り、そのようなものがあるかどうかはわかりません。レンズとして使用して、製品情報、連絡先情報、場所など、関心のあることにWebクローラーの注意を集中させます。より詳細にすると、エンジンはより多くの、より良い顧客をサイトに送ります。
実際、schema.orgの誤用はSEOを傷つけました。
評価の星や記事や製品に関する詳細情報を含む検索結果を覚えていますか？彼らはいなくなった！
あまりにも多くのウェブサイトがそれらを悪用し、今度は検証済みの評価サードパーティを取得する必要があるためです。