schema.org - How far to go with Structured Data Markup? -

the more going depths of structured data makeup, more complex , detailed seems become. 1 markup areas of page footer, header, sidebar, single menu elements etc., guess page consist of 80% schema markup , 20% content when taken seriously. :)

is doing add more rough markup skeleton (webpage or article) potentially hundreds of actual content pages of website, , shouldn't 1 include full author information along business opening times, contact details etc. on dedicated contact/business information page? i'm concerned bloat. kind of markup recommended types of pages , of can left out because search engine compile information other parts of website anyway?

if care user-visible search result features in big seach engine services (e.g., bing, google search, yahoo! search , yandex, happen sponsor schema.org), answer easy: provide search engines document recognize.

are these user-visible search result features things search engines "do" schema.org structured data? not. they’ll use structured data better understand page content, , analyze other features offer in future. see example dan brickley’s (he google’s schema.org representative) posting this. typically not documented search engines, of course. if care this, too, answer be: provide conceivable useful search engines.

are search engines consumers interested in schema.org structured data? no, there countless other consumers (services tools). enter world of semantic web , linked data. if know , care consumer, answer easy again: provide consumer documents support. can’t know them all, of course. if care these (known , unknown, existing , still appear) consumers, answer be: provide conceivable useful consumers. or, because interest of these consumers varies widely, even: provide can.

---

that said, there schema.org types useful provide. example webpageelement types, which, mentioned, can used page areas (header, footer, navigation, sidebar etc.). in opinion, a typical web page shouldn’t provide these types.

if care file sizes, you’ll want to use microdata/rdfa (because these syntaxes allow annotate existing content) instead of json-ld (because syntax requires duplicate content). rdfa you’ll save more compared microdata.
however, structured data typically represents fraction of markup/content anyway, if provide data possible.

instead of repeating "background information" on every page (for example, full data business), can make use of references: define uri business (or every other thing) on page describe it, , use uri property value applicable on other pages. possible @id (json-ld, see example), itemid (microdata), , resource (rdfa). reason not possibly lacking consumer support such references (depending on consumer / use case, might not followed). middle way might provide item (about business or other thing) on every page, once full data, , in other cases limited set of data (ideally visible on page, or needed specific consumer). uri gets used identifier each item, conveying these items same thing.