simonmb.xyz

What I learned about Structured Data this week

—

by

admin
in

I honestly don’t know that much about SEO. So when a client asked me to help optimize their website, I had to educate myself first. One concept that I didn’t know about was the idea of ‘Structured Data’ on websites.

When search machines like Google display search results, you’ll encounter certain results that are displayed more fancily than others. For example; searching for a movie will automatically show aggregated review scores from IMDB or RottenTomatoes, searching for a musician will show their discography, or searching for a local store might show their opening hours.

In the case of a local store, I used to think that the information such as opening hours, was manually provided by the business themselves, using a Google Business account or similar. And although that’s partly true, there is another way for search machines to get this data: Structured Data.

What is Structured Data?

Structured Data is in essence nothing more than a JSON object, according to a specific schema, that you place somewhere on the page. This object contains contextual information about the page, which the indexers pick up, and can be used to populate the ‘rich’ search results.

Structured Data is usually placed in the header, and looks something like this:

<head>
	... header stuff ...
	<script type="application/ld+json">
	{
		"@context": "https://schema.org",
		"@type": "WebSite",
		"@id": "https://mywebsite.com/#website",
		"url": "https://mywebsite.com",
		"name": "My Website - By Me"
	}
	</script>
</head>
... rest of page ...

As you can see it’s just a JSON object in a scrip tag with the type application/ld+json . The content of the object should follow a predefined schema that you declare using @context. You can see all available types and required values on Schema.org

What should I put there?

Structured data is meant to provide contextual information about the current webpage. As a result it should only contain data about the specific webpage (not website), that’s actually visible to the end-user.

By using the provided @id value crawlers and indexers are able to link back all the separated pieces of information back to each-other. As far as I’m aware, the ID can be anything you’d like, as long as it’s unique, and you reuse it’s exact value. The standard seems to be {url}/#{schema type}.

Example

My website is meant as a personal page. On my homepage (at the base URL) I could put this:

{
	"@context": "https://schema.org",
	"@type": "WebSite",
	"@id": "https://simonmb.xyz/#website",
	"url": "https://simonmb.xyz",
	"name": "Personal page of Simon Meulenbeek",
	"description": "My personal page with my writings, projects and music"
	"owner": {
		"@type": "Person",
		"@id": "https://simonmb.xyz/#owner",
		"givenName": "Simon",
		"familyName": "Meulenbeek"
	}
}

If I had a contact page with my address and phone number, I’d write the JSON on that page like this:

{
	"@context": "https://schema.org",
	"@type": "ContactPage",
	"name": "Contact met Simon",
	"mainEntity": {
		"@id": "https://simonmb.xyz/#owner",
		"@type": "Person",
		"adress": {
			"@type": "PostalAddress",
			"addressCountry": "NL",
			"addressLocality": "Enschede"
		},
		"email": "myemail@email.com",
		"telephone": "+31612345678"
	}
}

The main take away of these examples should be:

  • Provide context to the data that is on the page
  • Use @id values to connect everything

Note: this is not a full example. In the case of a real website you should provide as much information as the schema allows, while not duplicating information across individual pages.