The Power of Schema Markups in SEO


Google is replacing its Structured Data Testing Tool

Google is officially moving the Rich Results Test out of beta now that it fully supports all Google Search rich results features.

Today’s search engines may be powerhouses at sorting information, but it’s still all too easy for your site to get lost in the mix of the rapidly increasing number of sites they must crawl — even when you implement traditional SEO strategies.

Schema markups — are helpful yet often overlooked forms of SEO — can quickly and methodically guide the crawlers, telling them exactly what content your page contains and why it matters.

In this article you’ll get the benefits of my 2 years of research and hands-on learning that helped me harness the power of schema markups.

But there’s no doubt about it — schema markups can get intricate. I’ll provide my guidance along with numerous example code sets and an overview of a software solution that makes it easier for Google bots to crawl your site, potentially helping you rank higher in the SERPs.

How to Use Schema Markups

What are schema markups?

“ is the result of collaboration between Google, Bing, Yandex, and Yahoo! to help you provide the information their search engines need to understand your content and provide the best search results possible at this time.“



Why are they so important?

Schema markups don’t just tell the search engines the structure of the page and what content the user will see but the intent behind that content. Adding Schema markup to your HTML improves the way your page displays in SERPs by enhancing the rich snippets that are displayed beneath the page title.

What happens when pages don’t have the correct schema markups?

When there’s an “Article” schema on a page that isn’t actually an article, or marking your local business and location on a page that does not include these details, the search engine will have trouble with the missed matched information between the schema and the page content and how relevant your content is to the user’s query. This could go against Google’s guidelines and could hurt your page rankings, even causing your page schemas to be ignored.

Another common example is adding a breadcrumbs schema on a front page that often does not include a breadcrumb – this can actually cause your rankings to drop. The list can easily go on and is hindering many websites.

Schema markups are available in 3 formats:
    1. Microdata
    2. RDFa
    3. JSON-LD (Recommended by Google)

The first two schema formats come in the form of a predefined HTML tag, a piece of an HTML code from a list that exists on and that’s then added to a pages’ HTML code.

The third format, JSON-LD, is recommended by Google and implemented in Javascript code added to the HTML code of a page.

The use, structure, and examples of schemas (in all three formats) can be found on its schema page on

But before we break down each type, there’s one factor that WordPress CMS users should be aware of: the theme and plugin developers often add, in their core code, some schema markups with a universal code. These will match information given in the schema markups to any website it is being installed on.

For example, they may add a Breadcrumbs schema that will automatically collect your page titles and second level structure in inner pages and will “auto complete” it into the schema so Google will see the final result.

So wait, isn’t that a good thing that developers add in universal code and schemas?

For the average website builder, these automatic schemas are helpful; they can prevent the need to do it all yourself and avoid having to alter code or hire a developer. But there’s often a significant problem: These schemas are often incorrect, outdated, and unchangeable. And if you ever decide to implement your own schemas, this can create duplicate schemas. Having duplicate schemas will have a negative effect on SEO and ranking, so it’s important to check for duplicates and make sure all of your schemas are correct and without any errors.

These mishaps can have a negative effect on SEO without you even realizing what’s occurring. By optimizing schemas, you’ll take advantage of an aspect that many sites overlook to help the overall SEO strategy.


Now that you know the importance of optimized schemas, let’s look at the three formats and see how each can be applied.





Microdata is a very common and simple way to see structure data. This is done by adding tags to the preexisting HTML code of a website.


HTML Code:

*h1 itemscope itemtype="" itemprop="name"* Sarah */h1*

The tag “itemscope” indicates it is a schema. “itemtype” The item type indicates what schema type is coming, and the “itemprop” gives it a value (in this case) “Sarah”.

A more common example:


A “Local Business” Schema:

HTML Code:

“*div itemscope itemtype=””*”

The tag “itemscope” indicates it is a schema item. “Type” indicates the schema type to come.

We’ll add an itemprop “name” which tells us we are going to be giving the business a name.

“*h1* *span itemprop=”name”* The Company */h1*”

To Break it down:

Microdata is being applied by adding tags such as “itemscope” and “itemprop” to an HTML code to “Mark” to the crawlers that it is a part of a schema.

For us SEOs the basic, like H1 title, such as an article title, looks like this:

*h1* My Article  */h1*

So with the Microdata markup it will look like this:

*h1 itemprop=”name”* My Article */h1*

with itemprop=”name” marking the articles “Name”.

To read more about the guidelines go to:

Microdata vocabulary can be found on and often includes examples of implementations of a specific desired schema.



Just as with Microdata, RDFa is located within an HTML tag. In order to better describe what is visible within the page, RDFa gets more specific, marking up things like People, Places, Events, Recipes and Reviews.


While more specific, RDFa appears to be a less common and a bit more complex way to add schema markups to your HTML code. You’ll need to add pieces of code and sources for the crawlers to read.

RDFa can be used in various host languages, i.e. several (X)HTML variants and XML (thus also in SVG, MathML, Atom etc.). And new host languages can be supported, as RDFa Core “is a specification for attributes to express structured data in any markup language”.

” An HTML5 extension that supports linked data by introducing HTML tag attributes that correspond to the user-visible content that you want to describe for search engines. RDFa is commonly used in both the head and body sections of the HTML page.”


or more specific, described by the website :

” RDFa is an extension to HTML5 that helps you markup things like People, Places, Events, Recipes and Reviews. Search Engines and Web Services use this markup to generate better search listings and give you better visibility on the Web, so that people can find your website more easily. “

More in depth info can be found here:




JSON-LD is Google’s recommended format and offers more customization and flexibility when building a schema. It is a “javascript” code and begins with

For an Article schema example

script type=”application/ld+json”


“@context”: “”,

“@type”: “Article”,

“name”: “Apple announces iPhone SE”,

“description”: “New iPhone announced at 11:30 in California.”,

“about”: {

“@type”: “Event”,

“name”: “Apple’s March 21 Announcements”


“contentReferenceTime”: “2016-03-21T11:30:00-07:00”



from top to bottom here is what we see:
1. opening script type=”application/ld+json”> marking the following code as a JSON-ld code.
2.curly brace that opens the code.
3. “@context”: “” the dictionary of the schemas, it is referring to the crawler that is reading the schema that about to unfold to the source for more information about each field.
4. “@type”: “Article”, in this case, the type is “Article” (also note the capital A), marking that the following code will suggest that the page that this schema is presented on is, in fact, an article and the following fields will match an article type of a schema and will give more information about the article and what is visible to the reader on this article.
5. “name”: the articles’ titles, should match exactly to the title of the article and that is visible to the reader.
6.”description”: just like meta description, a description of the article, a summerize of the article, here, it is worth to mention that it DOES NOT have to match exactly to the meta description that has been written/added to the article.
7. “about”: another way of giving more detail about the article, in this case, this article is about an event.
8. “@type”: “Event”, a sub-property of “about”, in this case, this article is “about” the “event” of.
9. “name”: giving the name of the event that is about to be presented in the article, in this case ” “Apple’s March 21 Announcements”.
10. “contentReferenceTime” another extension of the “Event” type, giving a specific date and time in which the event occurs.
11.closing braces.
12.closing the script with “/script”

For an LocalBusiness schema example, click here

script type=’application/ld+json’


“@context”: “”,

“@type”: “LocalBusiness”,
“priceRange”: “$”,

“telephone”: “+1-910-448-7429”,

“name”: “SchemaMarkApp”,

“url”: “”,

“logo”: “”,

“image”: “”,

“description”: “At Schema MarkApp, We are a data driven, fast moving, motivated and highly experienced team. .”,

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “46 Main St”,
“addressLocality”: “New York City”,
“addressRegion”: “NY”,
“postalCode”: “12345”,
“addressCountry”: “US”

“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “34.7372887”,
“longitude”: “-76.7847”

“hasMap”: “,-76.7847,17z/data=!3m1!4b1!4m5!3m4!1s0x89a89372e15dd195:0x33347a77d7ed1744!8m2!3d34.7372887!4d-76.782506”,

“openingHours”: “Mo, Tu, We, Th, Fr 09:00-17:00”,

“contactPoint”: {
“@type”: “ContactPoint”,

“contactType”: “Consultation”,

“telephone”: “+1-123-456-7890”,

“areaServed” : “US”

} ,

“@type” : “ContactPoint”,
“email” : “”,
“contactType” : “customer service”

what do we see here – in parts

1. opening script type=”application/ld+json” marking the following code as a Json-ld code.

2.curly brace that opens the code.

3. “@context”: “” the dictionary of the schemas, it is referring the crawler that is reading the schema that about to unfold to the source for more information about each field.

4. “@type”: LocalBusiness”, marking that the following code will describe a business andalso will suggest that the page this schema is presented on is a page that contain a visibile informationlocal business details.

5.”priceRange” – gives an idea of the price range of the products/services being offered in the local business, the price range is marked by “$” signs and range from one $ to three “$”.

6. “telephone”: “+1-234-567-8901”, the business phone number, this is the currect format, country code, area code and number with dashs in between.

7. “name”: “Business Name”, the business name.

8.”url”: “”, the business website URL (Website address).

9. “logo”: “”, the business logo image URL. *on a WordPress website, if the logo was uploaded to the media folder it might look something like this ” https:// “.

10. “image”: “”, an image that represent the business, could be anything, a photo of the business or emplyees, an infograph or anyting.

11. “description”: “At local business , We are fast moving, motivated and highly experienced team”, a description of the business and what they do.

12.address has its our curly braces and begins with “@type”: “PostalAddress”, includes the business street address, city, state, postal code, and country. wrapped with curly braces.

13.Geo – the business coordinates on the map by “latitude”: “”, “longitude”: “”.

14.hasMap – A URL to a map of the place. can be obtained by searching the the business address on Google maps,and also if a business has a Google my business account, a simple search for the business name will take you to the location on the map and then you could copy and use the maps browser tab URL.

15.”openingHours”: “Mo, Tu, We, Th, Fr 09:00-17:00”, this is the format used to describe the opening days and hours of the business.

16. “contactPoint”: will indecate that the following fields will provide contacting ways to the local business and service area of the business.

17.”ContactType”: this is Basically desribes who will be contacted with the following contact points, for example, sales, consultant, support, a PR contact point, a specialist and so on.

18. “telephone”: the telephone number for that specific person/department that will be reached when calling the given number.

19.”areaServed” : “US” the area in which the business is serving, in this case, the entire US.

20. “email” : the email address of that department in the local business in which a customer could contact.

Schema markups are built with structure – Nesting is key


Schema markups have structure, which is why they are also referred to as Structure Data. has a predefined hierarchy in which each schema markup is layed, and giving the schema a frame and structure. This hierarchy is laid by parent types (@type/itemtype) for each schema that frames the schema.

For example, a “Webpage” type schema has a parent type “CreativeWork”, an “Article” schema is also under “CreativeWork”, and a “HowTo” is a parent type for “Recipe”.

There are also multiple parent types schemas such as “FAQPAGE” or “AboutPage” which their parent type is “Webpage” and its parent type is “CreativeWork”. So in that example, the structure would be CreativeWork>WebPage>FAQPAGE.

As for the structure within the schema itself, as long as the schema passes with no errors or warnings in the Google schema markup testing tool or the CheckTool (more about that later), the order of the fields does not usually matter. And when testing the schema, you would notice that the order of the fields will be reorganized automatically by the tool.

Within the schema itself, Nesting is key, there is a schema fields “hasPart” which indicates an item or CreativeWork is a part of this item or CreativeWork in some sense. Additionally, “IsPartOf” is an Inverse-property  of “hasPart”. The idea is simple: to indicate that the schema has a part OR is a part of a different schema.

For example, a Webpage is part of a website. Also, a Webpage has a header, marked as “WPHeader”, and that header can have a menu which is the “SiteNavigationElement”.

Implementation of schema markup can be done in many ways:


Leaving the plugins aside for a minute, here are the ways to implement the schema markups for total control and full customization. Plus, this can be done for free:



You can add the Microdata or RDFA tags into the code tags in the html code of a page.

For example:

*h1*My Article*/h1* 

with itemprop=”name” marking the articles “Name”.

Depending on your site configuration, the implementation will happen directly on the page’s HTML code. Itemscope” and  “itemtype” will be added to the DIV that is wrapping the H1 tag. These tags will define that this DIV is a part of a schema, and the itemtype will define the type of a schema to come.

Next comes the “itemprop” to the next tag, E.G title tag(h1/h2)/paragraph tag, or whatever the case may be, which will help determine what content is coming between these tags and how the crawlers should read it.

For example, itemprop=”name” and the value of “name” will be the text in between the tags.  And,

*h1* My Article */h1*

the value of “name” in the schema will be “My Article”.

So, editing the page HTML code and implementing the desiried schema into the right tags within the page and in the right order will create the desired schema that will be then read by Google’s schema tester tool. It’s important to make sure the schemas were done correctly and include the required and allowed fields and that the values that were added are correct. For WordPress CMS Users: this can be done via WordPress page editor TEXT tab or page builder (i.e. Elementor/WPBakery).

*Use Search function (CTRL+F in Windows) to look through the code to find the title/paragraph or any part you would like to tag for the schema.



After writing the script and testing it on Google’s schema markup testing tool, it’s time to implement it.

For CMSs like WordPress, there are a  bunch of ways to do so.

One way is to use a simple PHP code that will add the script to the header of the page.

For an example click here

add_action( ‘wp_head’, function() {

if ( ! is_page( ) ) {

script type=’application/ld+json’>
“@context”: “”,
“@type”: “Person”,
“email”: “”,
“familyName”: “Ohayon”,
“givenName”: “Shay”,
“jobTitle”: “CEO”,
“description”: “”,
“mainEntityOfPage”: “”,
“name”: “Schema MarkApp”

the next part,

if ( ! is_page( 4 ) ) {




determine at what condition and where the code will be deployed on the page.

if the page is a page (is_page) and not a post (is_post),

keep reading the following code (and eventually deploy it on the page).

Next is the actual JSON script.

and last is the closing of the PHP code, which is very important to be able to activate the code.

another PHP command that is nativly exsist in the WordPress system, wp_json_encode(). here is how to use it:

function generate_json_ld_webpage() {

if ( is_page () ) {
return null;
$datawp = [];

$datawp[“@context”] = “”;
$datawp[“@type”] = “WebPage”;
$datawp[“url”] = home_url( add_query_arg(null, null));
$datawp[“name”] = get_the_title();
$datawp[“inLanguage”] = “en-US”;
$datawp[“datePublished”] = get_the_date( ‘c’ );
$datawp[“dateModified”] = get_the_modified_date( ‘c’ );
$datawp[“description”] = get_the_excerpt();

echo ‘script class=”my-json-markup” type=”application/ld+json”>’ . wp_json_encode( $datawp ) . ”;

add_action( ‘wp_head’, ‘generate_json_ld_webpage’ );

To break it down:

1. a function is being generated, in this came it is named “generate_json_ld_webpage” followed by required “()”.

2. the next part
if ( is_page () ) {
return null;
determine at what condition and where the code will be deployed, in this example, if the page is a regular page (is_page) and not a post, deploy the following code.

3.this part requires more understanding of code and how PHP works, a simple way to put it is that each field of the schema is being stored into a greater collection of data.
in this example the collection of data is named “datawp”(random picked name, can basically be named anything desired), and each field of the schema is being stored to it and also includes the value of that field, for example, $datawp[“@type”] = “WebPage”; ” stores the type and also gives the types value that this schema is a WebPage schema, the rest of the fields in the example are WordPress built-in functions, “get_the_date(‘c’)” pulls out the date published from the WordPress system automatically, same for ” get_the_modified_date( ‘c’ ); “, ” get_the_excerpt(); ” pulls the excerpt of the page, if one exists, “get_the_title” pulls the current page title, these functions are useful since they are universal and should be working on any WordPress system and on any page without the need to manually add the title/date/url/name of each page and basically autocomplete the required field.
more options to “autocomplete” fields can be found in WordPress codex here.

4.echo, followed by the <script> tag and in between its opening and closing of the tag the data that has been stored in the script above will be echoed (printed).

5.this part is where the location on the website page where the code will be added to is being decided, in the example it is the head of the page (wp_head) but it is also possible to add it to the body of the page (‘wp_body_open’).
for some themes and configurations adding the code to the head is better, some the body, some will have a custom head and body and will require different code to be able to add it to the wanted part of the page.
lastly, the name of the function that has been decided at the start of the code is needed.

A few important notes to keep in mind:


  1. Google does not support all available schema markups. In fact, Google created a list named “Search gallery” where they list all the schemas that the search engine supports.
  1. Not supporting a certain schema does not mean Google can’t “read” them. The schema markup tester tool will be able to read the schema markup added, even if not supported, and will flag an error if anything is not “supported by Google”.
  1. Adding unsupported schemas to a website will not “hurt” its SEO efforts.  Assuming you followed the rules mentioned before, Google will most likely simply ignore the unsupported schemas, and will not flag an error in the search console. With that being said, the schemas implemented need to be tested first, just as you would for a supported schema, and be valid with no errors or warnings.
  1. Since adding unsupported schemas does not “hurt” the website, and Google’s guidelines state that adding multiple schemas is not a problem, I would recommend adding all relevant schemas to a page. For example, a page is a web page but could also be a service page, it can include both a service schema and a webpage schema — and even more if it is relevant. I.e. a post can be an article, and can also include a recipe or an FAQ, meaning a recipe or FAQ schema should also be added. For best practices, all elements should be marked up!

My Software Solution

Most schemas, as complicated as they are, Luckily utilizing WordPress code, populating the schema fields “automatically” is quite easy to do with the right tool — typically an app or plugin.

Schema MarkApp, a WordPress plugin I created, takes out the time-consuming and complicated process of manually entering schemas and missing an opportunity to help Google read the website elements and potentially help with the ranking of the site. It also helps eliminate those hurtful flags and errors.

As of writing this guide, Schema MarkApp is still under Beta. But the app is available for all who want to try it out.

Share this post

Share on facebook
Share on twitter
Share on linkedin
Share on email