我越深入到結構化數據構成的深處，它就越複雜，越詳細。人們甚至可以在頁面的頁眉，頁眉，側邊欄，單個菜單元素等標記區域，我認爲一個頁面可以很容易地包括80％的架構標記和20％的內容時，太重視了。 :)結構化數據標記還有多遠？
它是否真的有益於向網站的潛在數百個實際內容頁面添加粗略標記骨架（WebPage或Article），並且不應僅包含完整的作者信息以及業務開放時間，聯繫方式等在專門的聯繫人/業務信息頁面上？我很擔心這個膨脹。對於某些類型的頁面，建議使用哪種類型的標記，以及哪些標記可以省略，因爲搜索引擎無論如何都會編譯來自網站其他部分的信息？
如果你只關心大SEACH引擎服務用戶可見的搜索結果功能（例如：兵，谷歌搜索，雅虎搜索和Yandex的，這一切發生贊助Schema.org ），答案很簡單：提供什麼搜索引擎文件來識別。
這些用戶可見的搜索結果功能是搜索引擎對Schema.org結構化數據「做」的唯一東西嗎？可能不會。他們可能會使用結構化數據更好地理解頁面內容，並且最有可能分析他們將來可以提供的其他功能。例如參見Dan Brickley’s (he is Google’s Schema.org representative) posting about this。但是，當然，所有這些通常都不會被搜索引擎記錄下來。所以如果你也關心這個問題，答案可能是：提供什麼是可以想象的有用的搜索引擎。
搜索引擎是唯一對Schema.org結構化數據感興趣的消費者嗎？不，有無數的其他消費者（服務和工具）。輸入Semantic Web和Linked Data的世界。如果您瞭解並關心消費者，答案會很簡單：提供此消費者文件支持的內容。但是，當然，你無法全部瞭解它們。因此，如果您關心所有這些消費者（已知和未知，目前存在且仍將出現）的消費者，那麼答案將是：提供對所有消費者有用的可以想象的東西。或者，因爲這些消費者的興趣差別很大，甚至：提供你所能。
這就是說，肯定有Schema.org類型的很少提供有用的。一個很好的例子是WebPageElement類型，正如你所提到的那樣，它可以用於頁面區域（頁眉，頁腳，導航，側邊欄等）。在我看來，a typical web page shouldn’t provide these types。
如果您關心文件大小，you’ll want to使用Microdata/RDFa（因爲這些語法允許您註釋現有內容）而不是JSON-LD（因爲此語法要求您複製內容）。使用RDFa，與Microdata相比，您甚至可以節省更多。
但是，無論如何，結構化數據通常僅代表標記/內容的一小部分，即使您提供儘可能多的數據。
除了在每個頁面上重複「背景信息」（例如，有關業務的完整數據）之外，還可以在頁面上使用引用：you define a URI for your business (or every other thing)，並將此URI用作屬性價值適用於其他頁面。這可以通過@id（JSON-LD，see an example），itemid（Microdata）和resource（RDFa）來實現。不這樣做的唯一原因可能是缺少消費者對這種引用的支持（取決於消費者/用例，他們可能沒有遵循）。中間的方法可能是在每個頁面上提供項目（關於業務或任何其他事物），一次使用完整的數據，而在所有其他情況下使用有限的一組數據（理想情況下頁面上可見的內容或什麼是特定消費者需要的）。 URI被用作每個項目的標識符，表示所有這些項目都是大致相同的東西。
感謝您的寶貴意見！那麼，您是否會建議在每個「文章」頁面上添加完整的業務信息，還是隻應在提供有關實際業務信息的頁面上提供完整的業務信息？搜索引擎是否會通過「發佈者」屬性建立連接？ – richey
@richey：我在回答（最後一篇）中添加了一段關於參考的文章。對於用戶可見的搜索結果功能的情況，我認爲沒有搜索引擎跟蹤對其他頁面的引用。對於這些功能，所需的所有內容都必須位於頁面上，當然這很有意義，因爲此頁面是用戶在結果中獲得的內容。 - 如果搜索引擎遵循這樣的參考文獻，他們的結構化數據的其他用途沒有記錄。 - 一個很好的規則是始終提供頁面上顯示的內容，並使用該項目的標識符，以便感興趣的消費者可以獲得完整的描述。 – unor
偉大的問題。我猜整體評估是「收益遞減」，但當然，你必須排名你的目標...可訪問性...... SEO ....安撫穀神（個人我「就夠了」;） – mayersdesign