Why Use Schema.Org Microdata to Mark Up Web Page Elements

Why use Schema.org microdata to mark up web page elements?

This answer is primarily about the WebPageElement types (like SiteNavigationElement).

For WebPage, see my answer to the question Implicity of web page structure in Schema.org (tl;dr: it can be useful to provide WebPage, even for the current page).

For WebSite, similar reasons from the answer above apply. HTML doesn’t allow you to state something about the whole site (and, by the way, a Google rich result makes use of this type).

---

Schema.org is not restricted to HTML5.

Schema.org is a vocabulary which can be used with various syntaxes (like JSON-LD, Microdata, RDFa, Turtle, …), stand-alone or in various host languages (like HTML 4.01, XHTML 1.0/1.1, (X)HTML5, XML, SVG, …). So having other ways to specify that something is (or: is about; or: represents) a site-wide navigation, a table etc. is the exception rather than the rule.

But there can be reasons to use these types even in HTML5 documents, for example:

• The HTML5 markup and the annotations from Microdata/RDFa are two "different worlds": a Microdata/RDFa parser is only interested in the annotations, and after successfully parsing a document, the underlying markup is of no relevance anymore (e.g., the information that something was specified in a table element is lost in the Microdata/RDFa layer).

• By using types like WebPageElement, you can specify metadata that is not possible to specify in plain HTML5. For example, the author/license/etc. of a table.

• You can use these types to specify data about something which does not exist on the current document, e.g., you could say on your personal website that you are the author of a table in Wikipedia.

That said, these are not typical use cases relevant for a broad range of authors. Unless you have a specific reason for using them, you might want to omit them. They are not useful for typical websites. Using them can even be problematic in some cases.

See also my Schema.org issue The purpose of WebPageElement and mainContentOfPage, where I suggested to deprecate WebPageElement and the mainContentOfPage property.

What is the proper schema.org markup for a webpage about another website?

The description of what you're listing here is:

An SEO analysis of the code on example.com.

To me, I think it would make more sense to use Article in this case as it can be considered an investigative report. Maybe even Report (but I'm not sure how that's handled by search engines, if that is your intent)

The only downside of using article is you'll have to fill out more information such as publisher and datePublished. If you want to reference the website you are reviewing, I think using About would make the most sense. For example:

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Article",
  "author": "John Doe",
  "headline": "SEO overview for example.com",
  "datePublished":"05/07/2020",
  "image":"articleimage.jpg",
  "publisher": { 
    "@type": "Organization",
    "name": "My Company Name",
    "logo": {
      "@type": "ImageObject",
      "url": "mycompanylogo.jpg"
    }
  },
  "about": {
    "@type": "Webpage",
    "name": "Example.com",
    "url": "http://example.com"
  }
}
</script>

How far to go with Structured Data Markup?

If you only care about user-visible search result features in big seach engine services (e.g., Bing, Google Search, Yahoo! Search and Yandex, which all happen to sponsor Schema.org), the answer is easy: Provide what search engines document to recognize.

Are these user-visible search result features the only things search engines "do" with Schema.org structured data? Probably not. They’ll likely use structured data to better understand page content, and most likely to analyze what other features they could offer in the future. See for example Dan Brickley’s (he is Google’s Schema.org representative) posting about this. But all this is typically not documented by the search engines, of course. So if you care about this, too, the answer would be: Provide what is conceivable to be useful for search engines.

Are search engines the only consumers interested in Schema.org structured data? No, there are countless other consumers (services as well as tools). Enter the world of the Semantic Web and Linked Data. If you know and care about a consumer, the answer is easy again: Provide what this consumer documents to support. But you can’t know them all, of course. So if you care about all these (known and unknown, currently existing and still to appear) consumers, the answer would be: Provide what is conceivable to be useful for all consumers. Or, because the interest of these consumers varies widely, even: Provide what you can.

---

That said, there are certainly Schema.org types which are rarely useful to provide. A good example are the WebPageElement types, which, as you mentioned, can get used for page areas (header, footer, navigation, sidebar etc.). In my opinion, a typical web page shouldn’t provide these types.

If you care about file sizes, you’ll want to use Microdata/RDFa (because these syntaxes allow you to annotate existing content) instead of JSON-LD (because this syntax requires you to duplicate the content). With RDFa you’ll probably even save slightly more compared to Microdata.

However, structured data typically only represents a fraction of the markup/content anyway, even if you provide as much data as possible.

Instead of repeating "background information" on every page (for example, the full data about the business), you can make use of references: you define a URI for your business (or every other thing) on the page where you fully describe it, and use this URI as property value where applicable on other pages. This is possible with @id (JSON-LD, see an example), itemid (Microdata), and resource (RDFa). The only reason not do this is possibly lacking consumer support for such references (depending on the consumer / the use case, they might not get followed). A middle way might be to provide the item (about the business or any other thing) on every page, once with the full data, and in all other cases with a limited set of data (ideally what is visible on the page, or what is needed for a specific consumer). The URI gets used as identifier for each item, conveying that all these items are about the same thing.

Schema markup: WebPage vs Article

In the typical case, you would use both. You could provide a WebPage item on every page, and if the web page contains an article, you could provide an Article item in addition (or multiple, of course).

For a page dedicated to an article, you could use the mainEntity property to denote that the Article is the primary thing on that page:

<body itemscope itemtype="http://schema.org/WebPage">
  <article itemprop="mainEntity" itemscope itemtype="http://schema.org/Article">
  </article>
</body>

Neither a web page nor an article can have a telephone number (at least not in typical cases, which is why Schema.org doesn’t define the telephone property for WebPage/Article). A telephone number typically belongs to a person or an organization, which are among the types that can have the telephone property.

So you need an item that represents your business: in your case probably LocalBusiness. Then you can provide this item as author of the WebPage and/or the Article etc.

PS: Whenevery you use a type, check if a more specific child type applies in your case. So in your case maybe something like MedicalWebPage, NewsArticle, HealthAndBeautyBusiness, etc.

Schema.org WebPage markup on 'body' element with 'id' attribute

This is most likely a bug in Google’s tool. You don’t have to worry about it. But if you do, there are two workarounds:

• Specify itemid on body in addition. This is the correct attribute responsible for providing an ID in Microdata, not id. You should provide the canonical URL of the web page as value.

• Specify itemscope itemtype="http://schema.org/WebPage" on a different element (one that doesn’t have an id attribute). While it’s often useful to specify WebPage on the body, this is not required.

The first solution is preferable, as it’s generally a good practice to provide IDs for your structured data items.

Understanding Schema.org in Stack Overflow

It's used for SEO.

Most webmasters are familiar with HTML tags on their pages. Usually,
HTML tags tell the browser how to display the information included in
the tag. For example,

Avatar

tells the browser to display the
text string "Avatar" in a heading 1 format. However, the HTML tag
doesn't give any information about what that text string
means—"Avatar" could refer to the hugely successful 3D movie, or it
could refer to a type of profile picture—and this can make it more
difficult for search engines to intelligently display relevant content
to a user.

> Schema.org provides a collection of shared vocabularies webmasters can
use to mark up their pages in ways that can be understood by the major
search engines: Google, Microsoft, Yandex and Yahoo!

You use the schema.org vocabulary along with the Microdata, RDFa, or
JSON-LD formats to add information to your Web content. This guide
will help get you up to speed with Microdata and schema.org so that
you can start adding markup to your web pages.

Source: https://schema.org/docs/gs.html

Also, the itemprop attribute is a global one and used to add properties to an item.
See: https://developer.mozilla.org/de/docs/Web/HTML/Global_attributes/itemprop

---

Related Topics