As a result, users and search engines are increasingly focused on accessing high-quality, reliable information. This shift has led many organizations to revise their content strategies to maintain accuracy, relevance, and trust in this evolving environment.

To develop a successful content strategy in this new search experience, marketers must address several critical questions on an ongoing basis:

• How can you maintain an up-to-date content inventory?
• What content gaps exist, and where are opportunities for new high-quality content to be added?
• Which existing content pieces require improvement or disambiguation?
• How has your content impacted your website’s performance as search evolves?

While your website content is a rich data source, it’s often unstructured. This makes it difficult to analyze and answer these questions at scale. Many marketers manually review and revise content to inform their strategy, which is time-consuming and inefficient.

So what if you could automatically structure your content to make high-level analysis fast and easy? Good news, a content knowledge graph can be leveraged to do precisely that. This approach is particularly valuable for large websites or organizations managing multiple sites, where understanding the full scope of covered topics can be challenging.

This article will explore how leveraging your content knowledge graph can support and enhance your content strategy.

By harnessing the power of your content knowledge graph, you can make well-informed decisions that drive your content strategy forward in today’s competitive digital landscape.

Understanding Content Knowledge Graphs

At Schema App, we define a content knowledge graph as a graph that represents entities (things), their attributes, and the relationships between them on a publicly-facing website.

Like a general knowledge graph, it uses a standardized vocabulary or ontology (such as Schema.org) to create a structured, reusable data layer. This structure enables machines to discover new insights through inferencing, helping to explore and understand the connections between various entities in your content.

At Schema App, we build content knowledge graphs by mapping the content on your website to specific types and properties in the Schema.org vocabulary. This results in a precise and organized framework that accurately reflects your content’s meaning and relationships.

While Schema.org provides an excellent foundation for knowledge graph creation, its available types and properties can be limiting. That’s why Schema App created the Omni Linked Entity Recognition (Omni LER) feature, which automatically identifies entities in your content that have been described in external authoritative databases such as Wikipedia, Wikidata, and Google’s Knowledge Graph. This process is known as entity linking, and it offers two significant benefits:

1. Improved SEO: Embedding these entities in the Schema Markup on your pages helps to disambiguate them, which enhances search engine optimization for queries related to those entities.
2. Content Inventory: Identified entities also function as an inventory of what’s discussed in your content, offering valuable insights for content strategy planning.

By leveraging both the Schema.org vocabulary and Omni LER, the content knowledge graph provided by Schema App gives you a comprehensive understanding of your content architecture. This enables you to make data-driven decisions to optimize your content strategy for search.

Content Knowledge Graph Use Cases

Now that you’ve been introduced to content knowledge graphs, let’s explore some practical applications and effective ways to leverage this powerful resource to enhance your content strategy.

Improve Content Inventory Organization

When you develop a content knowledge graph with Schema App, you can implement a multi-dimensional categorization method for your content.

Schema App’s Highlighter builds your content knowledge graph by consistently tagging and classifying your website content at scale. This is particularly beneficial for organizations with large websites, a wide variety of assets, and different content stakeholders.

Your content knowledge graph establishes meaningful connections between different content pieces based on entities, types, and properties – not just keywords. For example, a blog post would likely show up in your content knowledge graph as an instance of a BlogPosting with properties like author, datePublished, and dateModified. If Omni LER is also used, additional metadata about the identified entities mentioned within the article body will be added. This enables you to do more detailed content analysis, which we will cover later in the article.

Content Coverage and Gap Identification

By constructing your content knowledge graph with both the Schema.org vocabulary and Omni LER, you can query all of your content with greater precision. Schema.org provides detailed types and properties, and Omni LER adds unique entities for varied levels of granularity in your data layer. When combined, you can leverage your content knowledge graph to help you determine what new content to add or which existing content to improve to better meet your audience’s needs.

This holistic view of the Schema.org types and entities covered by your website allows you to:

• Identify areas of content saturation
• Discover underrepresented topics
• Align your content with current business goals and market trends

Use Case 1: Aligning Content With Business Goals

For instance, one of Schema App’s customers aimed to be recognized for their product’s ease of use. To align their content with this business goal, we employed the following strategy:

1. First, we identified Schema.org types and properties that indicate user support and ease of use. These included:

• HowTo
• BreadcrumbList
• FAQPage
• VideoObject

These content types can represent ease of use by making processes feel manageable and easy to follow, empowering users to self-serve, or simplifying site navigation.

2. We then queried their content knowledge graph to pinpoint where these types and properties already exist on their site and where existing content could be further enhanced to align content with their goals.

3. Finally, we identified opportunities to add net new content in alignment with their goal. For instance, we recommended creating more HowTo content with clear steps and accompanying images and/or videos to support ease of use.

Through this process, our customer identified content gaps that, when addressed, aligned better with their business goals and enhanced the quality of their site’s content.

Just like how content knowledge graphs can identify gaps in your content, they can also reveal how much of your existing content overlaps with desired entities. This information is crucial for ensuring that your content strategy covers all necessary areas and effectively addresses your audience’s interests.

Use Case 2: Assessing and Revising Content Coverage

Consider another example from one of our healthcare customers:

Our customer did entity linking using our OmniLER feature. The feature automatically identified known entities in their content, which revealed an unexpected insight: they had numerous blog posts mentioning COVID-19, a topic they no longer wished to emphasize in their content strategy.

Armed with this information, the customer was able to:

• Quickly identify all content pieces mentioning COVID-19
• Assess the relevance and necessity of each mention
• Selectively remove or update content to align with their updated business goals

This targeted approach allowed the customer to refine their content strategy without needing a time-consuming manual review of their entire content inventory.

Disambiguating Entities to Ensure Brand Name Consistency

Your content knowledge graph can also ensure the disambiguation of your entities and brand voice consistency across your website. This capability is particularly valuable when dealing with ambiguous terms or acronyms that could lead to misinterpretation or unintended associations.

For instance, imagine a scenario where our brand, Schema App, faces a challenge when its name is shortened to just “Schema” in some content. The word “Schema” can refer to various concepts on the web, from psychology to structured data. If machines unintentionally link this shortened form to unrelated information, it could confuse and potentially damage our brand image.

To resolve this issue, we would leverage our content knowledge graph to:

• Locate all instances where our brand name is inconsistently represented
• Implement a standardized approach to always use our full brand name, “Schema App”
• Disambiguate our brand using Schema Markup and entity linking. This ensures our brand is accurately identified and associated with the correct definition in external authoritative knowledge bases
• Ensure that our brand is consistently and correctly represented across all content

This scenario illustrates how a content knowledge graph enables organizations like ours to:

• Gain a holistic view of entity usage across our content
• Identify areas where content should be more explicit based on entity interpretation and their links to external knowledge bases
• Make informed decisions about content revisions to maintain brand integrity
• Ensure consistent brand voice and messaging across all content

By leveraging a content knowledge graph, we can proactively address potential ambiguities, maintain brand consistency, and enhance our content’s overall quality and clarity. This approach not only improves user experience but also protects our brand from unintended associations or misrepresentations, ultimately enhancing our performance in search.

Schema App Helps Develop Your Content Knowledge Graph

As explored throughout this article, a content knowledge graph is a powerful tool for optimizing your content strategy, improving SEO performance, and preparing your organization for the future of AI-driven search.

At Schema App, we implement semantic Schema Markup and automate the entity linking on your website to develop your organization’s content knowledge graph.

If you’re a current Schema App customer interested in leveraging your content knowledge graph, we encourage you to reach out to your Customer Success Manager. They can take you through what’s currently available so that you can leverage your content knowledge graph to support and enhance your content strategy.

If you’re new to Schema App and interested in harnessing the power of a content knowledge graph for your organization, now is the perfect time to get started. Our team is ready to help you navigate the complexities of semantic SEO and knowledge graph development, ensuring your content strategy is primed for success in today’s digital landscape.

Don’t let your content strategy fall behind in the era of semantic search and AI. Contact our team today to begin developing your content knowledge graph and optimizing your content strategy for search.

The post How to Optimize Your Content Strategy Using Your Content Knowledge Graph appeared first on Schema App Solutions.

It’s crucial to express Schema Markup in a format accepted by major search engines to take advantage of the Schema.org vocabulary, become eligible for rich results, and accurately describe your website content.

Popular search platforms like Google and Bing recognize three primary formats for Schema Markup:

1. Microdata
2. RDFa
3. JSON-LD

Implementing the appropriate format ensures that your structured data is accurately understood, enhancing your site’s visibility, aligning your content with more relevant search queries, and supporting rich result eligibility.

Understanding the Different Schema Markup Formats

Microdata, RDFa, and JSON-LD have unique features and implementation methods. Each of the three available formats has unique features and implementation methods. Let’s examine the pros and cons of each format to help you understand which format you should utilize for your website.

What is Microdata?

Microdata is an open-community HTML specification used to nest structured data within HTML content. Similar to RDFa, it utilizes HTML tag attributes to name the properties we want to present as structured data.

Microdata is typically implemented within the <body> element but can also be used in the <head> element.

<div itemscope itemtype="https://schema.org/Organization">
 <span itemprop="name">Schema App</span>
Contact Details:
 <div itemprop="address" itemscope itemtype="https://schema.org/PostalAddress">
  Address:
   <span itemprop="streetAddress">412 Laird Road</span>
   <span itemprop="postalCode">N1G 3X7</span>
   <span itemprop="addressLocality">Guelph</span>
   <span itemprop="addressRegion">Ontario</span>
   <span itemprop="addressCountry">Canada</span>
 </div>
  Tel:<span itemprop="telephone">+1 855-444-8624</span>,
  E-mail: <span itemprop="email">support@schemaapp.com</span>

Pros of Using Microdata Format for Schema Markup

1. Markup is Dynamic

The microdata is added as an attribute for individual HTML elements, so your markup will be updated dynamically if any content changes are made.

For example, consider a <div> element attributed to the “Organization” type. This <div> can contain properties like “name” and “address.” If you change the content within any of these elements, the markup will automatically update to reflect the latest content.

2. Easy to Implement

Microdata can be easily inserted into HTML, making it more straightforward for those without coding skills to implement the Schema Markup. Microdata is generally easier to understand and maintain than other formats like RDFa.

Cons of Using Microdata Format for Schema Markup

1. Less Suitable for Advanced Schema Markup

While microdata works well for basic Schema Markup, it can become more complicated when dealing with advanced Schema Markup involving many nested entities.

Consider the Product schema type, which requires HTML elements for various attributes like price, ratings, reviews, and return policies to be nested. If your product page only had an image and a price, you can easily use microdata to markup your page.

However, the complexity increases with additional elements such as FAQs located lower on the page, branding information in a separate section, and ratings and reviews in a separate tab. These extra layers make the implementation messy and difficult to manage.

2. Messy Implementation

Since microdata has to be applied to each individual element on the webpage, the markup can become cluttered and messy, especially for larger websites, where your code can become “bloated” very quickly.

3. Unsuitable for Larger Websites

Due to the potential for clutter and the limitations of complex schemas, microdata is generally better suited for smaller websites with simpler structured data requirements.

What is RDFa?

RDFa (Resource Description Framework in Attributes) is an HTML5 extension that supports linked data. It does this by introducing HTML tag attributes that correspond to the user-visible content you want to describe for search engines.

RDFa is considered a W3C (World Wide Web Consortium) recommendation, meaning that it is a web standard. It can be used to chain structured data vocabularies together, which is especially useful if you want to add structured data that extends beyond the limits of Schema.org.

You can breathe a sigh of relief, however, as RDFa isn’t much different from Microdata. Similar to microdata, RDFa tags are incorporated with your webpage’s preexisting HTML code and are commonly used in both the <head> and <body> sections of an HTML page.

<div vocab="https://schema.org/" typeof="Organization">
  <span property="name">Schema App</span>
Contact Details:
  <div property="address" typeof="PostalAddress">
    Address:
     <span property="streetAddress">412 Laird Road</span>
     <span property="postalCode">N1G 3X7</span>
     <span property="addressLocality">Guelph</span>
     <span property="addressRegion">Ontario</span>
     <span property="addressCountry">Canada</span>
</div>
  Tel:<span property="telephone">+1 855-444-8624</span>,
  E-mail: <span property="email">support@schemaapp.com</span>

Pros of Using RDFa Format for Schema Markup

1. Flexibility

RDFa allows you to combine multiple vocabularies, making it more flexible than Microdata or JSON-LD for complex structured data requirements.

2. Widely Adopted Standard

Since RDFa is a standardized format recommended by the W3C, it ensures broad compatibility across various platforms, browsers, and search engines. This means that structured data marked up with RDFa will be more consistently interpreted and utilized by different web services.

3. Integrates with Existing HTML

Like Microdata, RDFa seamlessly integrates with your existing HTML code, making implementation easier.

Cons of Using RDFa Format for Schema Markup

1. Steep Learning Curve

RDFa has a steeper learning curve compared to Microdata or JSON-LD, as it requires a deeper understanding of linked data principles and vocabularies.

2. Messy implementation

Also similar to microdata, RDFa markup can become verbose and cluttered, especially for complex structured data implementations.

3. Limited Browser Support

While search engines support RDFa, some older browsers may have limited or no support for rendering RDFa markup.

Overall, RDFa offers a flexible and standards-compliant approach to structured data markup, but it may be more suitable for advanced use cases or when combining multiple vocabularies is necessary.

What is JSON-LD?

JSON-LD stands for JavaScript Object Notation for Linked Data. It is a method of encoding structured data using the JSON format, which is a lightweight data-interchange format that is easy for machines to parse and generate.

The key difference between RDFa, Microdata, and JSON-LD is their implementation method on a page. Both RDFa and Microdata are added as properties within the content itself. Conversely, JSON-LD is added independently, typically in the header or footer of the HTML.

This resolves the issue of messy and cluttered implementation associated with both RDFa and microdata.

<script type="application/ld+json">
{
   "@context": "https://schemaapp.com",
   "@type": "Organization",
   "name": "Schema App",
   "address": {
      "@type": "PostalAddress",
      "addressLocality": "Guelph",
      "addressRegion": "Ontario",
      "addressCountry": "Canada",
      "postalCode": "N1G 3X7",
      "streetAddress": "412 Laird Rd",
      },
   "email": "support@schemaapp.com",
   "telephone": "+1 855-444-8624",
}

JSON-LD is also a W3C recommendation and Google’s recommended format for structured data due to its simplicity and readability for both machines and humans. It offers several advantages.

Pros of Using JSON-LD Format for Schema Markup

1. Easiest Format for Machines to Interpret

JSON-LD is designed to be easily parsed and understood by machines, making it an efficient and accessible format for structured data.

2. Easy to Implement and Update

JSON-LD can be read even when dynamically injected into the page’s contents via JavaScript code or embedded widgets. It can be used to describe all types of media on a website—videos, audio, images, and interactive content—not just what exists in HTML documents.

JSON-LD also exists as a single block of code embedded within HTML, so you are not restricted by the structure of the content you are marking up.

3. Ability to Handle Complex Schema Markup

JSON-LD supports the management of complex, nested structured data, making it ideal for advanced use cases. Unlike Microdata, JSON-LD is not restricted by the content and structure of the HTML, offering greater flexibility. For instance, the ratings and reviews for a product can be positioned anywhere on the product page. With JSON-LD, you can easily nest the properties and values in the structured data regardless of where the content is placed in the HTML.

Cons of Using JSON-LD Format for Schema Markup

1. Learning Curve

JSON-LD can be difficult to learn and write manually, especially for those without prior experience with JSON or linked data concepts.

2. Technical Complexity

Implementing JSON-LD may require a higher level of technical expertise compared to Microdata or RDFa.

3. Update to Schema Markup Required If Done Manually

If you author the JSON-LD manually, you’ll need to update the JSON-LD code whenever you make content updates, as it’s separate from the main content.

This is why our customers love using the Schema App Highlighter, a scalable Schema Markup tool that generates and deploys JSON-LD Schema Markup to thousands of similarly templated pages on your site.

The Schema App Highlighter dynamically updates the Schema Markup on your page when content changes are made. This ensures that all content changes are automatically reflected in your JSON-LD markup in real time. This prevents Schema Drift and reduces the risk of manual coding errors.

What Format Should I Use for Schema Markup?

While Microdata, RDFa, and JSON-LD are all accepted formats for Schema Markup, JSON-LD emerges as our recommended choice. This is due to its flexibility and scalability for complex structured data implementations.

Despite its steeper learning curve and technical expertise requirements, JSON-LD is the format also endorsed by Google and other major search engines for its ease of readability for both machines and humans.

At Schema App, we understand the challenges of implementing JSON-LD at scale. This is why we created tools like the Schema App Highlighter to enable SEO teams to generate and deploy dynamic JSON-LD markup at scale.

With our end-to-end Schema Markup solution, we can help your team deploy robust Schema Markup to your site seamlessly, ensuring optimal search engine understanding and accurate representation of your brand in search results.

Get started with us today and unlock the full potential of JSON-LD Schema Markup for your organization.

The post What is the Recommended Format for Schema Markup? appeared first on Schema App Solutions.

This approach communicates clear relationships, giving machines context about the different entities described on your web pages. By improving search engine understanding of your content, it can lead to better visibility and more accurate presentation in search results.

Here’s a breakdown of nesting in Schema Markup:

Main Entity: This is typically the primary entity or item that your webpage is about. For example, if you’re describing a recipe page, the Recipe itself would be the main entity.

Nested Entities: These are secondary entities on the page that are closely related to the main entity. For instance, if your main entity is a Recipe, nested entities could include AggregateRating and VideoObject.

Image pulled from Google’s General Structured Data Guidelines.

Why is it Important to Nest your Schema Markup?

Nesting your Schema Markup serves several purposes:

1. It clarifies the relationships and hierarchy between different entities defined on your web page.
2. It helps build your content knowledge graph.

Nesting Helps Clarify Hierarchy and Entity Relationships

When implementing Schema Markup, many SEOs often create separate markups for multiple entities on a single page. For example, a page might feature a product along with its color variations and also include reviews and ratings of the product. All this visible content should be marked up with structured data.

However, if you specify each of these entities separately, you miss the opportunity to clearly communicate to search engines the primary focus of your page and the relationships between these entities. Are the reviews and ratings specific to that product, or are they unrelated to the product and pertain to the organization selling it?

This example shows that structuring your entities in a clear hierarchy helps search engines better understand the properties associated with your defined entities and how they all relate to each other.

This leads us to our second purpose for nesting your markup: the development of your knowledge graph.

Building Your Content Knowledge Graph Using Nested Schema Markup

Implementing nested Schema Markup is crucial for building a robust content knowledge graph. A knowledge graph is a collection of relationships between things, aka “entities,” defined using a standardized vocabulary, like Schema.org, from which new knowledge may be gained through inferencing.

Simply put, it is a way to organize your website content into a graph of interconnected entities, enabled through connected Schema Markup.

As search engines advance with AI technologies, establishing a well-defined and interconnected knowledge graph for your organization using Schema Markup is critical to staying ahead. AI search engines can utilize your structured data to uncover new insights about your organization and interpret valuable information from your website’s content and relationships more effectively.

This, in turn, allows your content to show up more accurately and relevantly for user queries.

Additionally, you can use your content knowledge graph to support internal AI initiatives and LLMs like ChatGPT. You can learn more about that in this article.

How do you Nest Schema Markup?

Now that you know what nesting is and why it’s important, it’s time to dive into the “how.” Nesting your Schema Markup can be broken down into several steps.

1. Identify the Main Entity

Determine the primary entity or topic of your web page. The main entity is easier to identify on some pages than others. If you’re unsure which Schema.org type to use, ask yourself what the intent of the page is. Is it selling something? If so, it’s likely a Product or Service. Is it informing an audience about a particular topic? In that case, it’s probably an Article or Blog Posting.

2. Identify Related Entities

Identify the other entities on the page that are associated with the main entity. For example, if your main entity is a Recipe, the webpage containing that recipe may also contain information about the author, reviews and ratings, or even a video showing the steps in the process. Each of these “things” is a related entity that you’ll want to represent in the structured data about that Recipe.

3. Implement a Nested Structure

Use the correct properties to connect your main entity and related entities together. In our Recipe example, we might use the author, review, aggregateRating, and video properties to connect the related entities we identified in the previous step.

Going to the Schema.org page associated with the type of your main entity will help you figure out which properties are available to that type. However, many types have more than 40 properties available to them, so finding the right one can be challenging.

Good news! If you’re unsure which Schema.org properties you should use to connect your entities, you can use our free Schema Paths Tool to identify all possible connections. To use this tool, select the two Schema.org types you want to connect, and it will output all the available properties that connect the two types.

The Schema Paths Tool in the image below shows that you can connect Recipe and VideoObject entities using a number of different properties. In our case, the subjectOf or video properties would both work. But since Recipe is eligible for a rich result, we would also want to consult Google’s Structured Data Documentation to see what they recommend. In this case, VideoObject should be connected to a Recipe using the video property.

Read our article for more information on how to use the Schema Paths Tool.

4. Validate your Schema

The Schema Validator will show all the markup on a single webpage and check for any syntax errors in the code. If the Schema Markup you’ve added aims to achieve a rich result, Google’s Rich Results Test will help you test which rich results your page is eligible for based on the structured data it contains.

5. Maintain Hierarchy

Keep in mind that effective Schema Markup requires ongoing maintenance and management, as on-page content and Google’s structured data requirements are subject to change. This ongoing maintenance will prevent schema drift and ensure you are optimizing your markup for search engine comprehension.

When Shouldn’t You Nest Schema Markup?

If the entities on your page are distinct and unrelated, nesting them within a hierarchical structure may not accurately represent the content. For example, a page featuring both a recipe and a list of unrelated events should use separate Schema Markup for each entity instead of nesting them together.

Additionally, some Schema types and properties are designed to be standalone and should not be nested within other types. For example, BreadcrumbList is used for navigational purposes, while the rest of your Schema Markup is probably intended to represent the meaning (semantics) of the page’s contents. As a result, these markups should not be nested.

Start Nesting Your Schema Markup Today

Implementing proper nested Schema Markup requires expertise and ongoing maintenance. Before worrying about nesting your markup, you must ensure your markup first aligns with your page content and that your entities are properly defined. Although this adds to the challenge, the benefits of this approach can significantly enhance your semantic SEO and provide your organization with agility in response to AI-driven search.

As we rapidly approach a future where AI powers search engines, you can implement nested Schema Markup to help them infer and access new knowledge about your organization. This can improve your visibility to potential customers in search results.

At Schema App, we understand the importance of nested Schema Markup and have designed our solution to help you easily create, connect, and manage your markup.

Don’t let the complexity of Schema Markup hinder your success. Get in touch with us to learn more about our end-to-end Schema Markup solution.

The post What is Nesting in Schema Markup? appeared first on Schema App Solutions.

But even with a long history, knowledge graphs are more relevant than they’ve ever been. According to Gartner’s Emerging Tech Impact Report, a robust knowledge graph is imperative for organizations looking to implement generative AI technologies. Knowledge graphs can help organizations ground their AI initiatives—like LLMs—in factual data about the organization.

If you’re interested in building a knowledge graph but are unsure where to start, you’re in luck. The good news is that if you have a website, you can construct a reusable content knowledge graph that supports both SEO and your internal AI initiatives.

This article will take you through the four steps of building a content knowledge graph using the Schema.org vocabulary.

Why should you use Schema.org to build your content knowledge graph?

You can create a knowledge graph using any number of ontologies, vocabularies, or glossaries. However, Schema.org should be the vocabulary of choice for constructing a content knowledge graph since it allows you to simultaneously maximize the SEO benefits.

Help search engines clearly understand and contextualize the content on your web page

The Schema.org vocabulary was created by major search engines as an industry-standard vocabulary for translating human-readable web content into a language that machines understand. By using this vocabulary to construct a knowledge graph based on your content, you’re also reaping the SEO benefits that come with it, including:

• Equipping search engines with an accurate understanding of your brand content
• Facilitating accurate and pertinent search queries that closely match your content
• Driving more targeted, engaged, and quality traffic to your site

Achieve rich results and stand out in search

By annotating your web content with the required Schema.org types and properties, search engines like Google may award visually enhanced search features for content like Products, Videos, Recipes, and Ratings. These rich results present key information directly in the SERP, and can increase click-through rates and drive more engagement and quality traffic to your pages.

Building Your Content Knowledge Graph

So you know about the SEO benefits of using Schema.org, but how does that get you a content knowledge graph? In the book Knowledge Graphs: Methodology, Tools and Selected Use Cases, Semantic Web and Knowledge Graph Experts, Fensel et al., break down the process of creating a knowledge graph into four steps:

1. Knowledge Creation,
2. Knowledge Hosting,
3. Knowledge Curation, and
4. Knowledge Deployment.

We’ve applied an SEO lens to these steps to explain how you can create a robust content knowledge graph using your organization’s web content. Let’s get started.

Step 1: Knowledge Creation

The first step to building a content knowledge graph is having high-quality, original content on your website and marking up that content using the Schema.org vocabulary.

Have high-quality content on your website

As a general first rule, you need to ensure your website content supports the specific objectives of your organization. Whether you’re selling good and services, educating the public, or wanting to build authority in a particular domain of expertise, the content across your website should exist to support those goals.

Beyond this, Google has shared guidelines on what it deems “helpful, reliable, people-first content.” This is an excellent resource that provides a series of questions you can use to assess the quality of your content. For example, you’ll want to ensure your content provides:

• Original information, reporting, research, or analysis
• A substantial, complete, or comprehensive description of the topic
• Substantial value when compared to other pages in search results

Marking up your content using the Schema.org vocabulary

To start building your content knowledge graph, you must annotate your high-quality content using types and properties from the Schema.org vocabulary. The annotations can be expressed in various formats, but Google recommends using JSON-LD. This translates the human-readable content on your website into machine-readable statements called RDF triples.

Include URIs in your Schema Markup to disambiguate your entities
In order to provide value beyond SEO, the entities in your Schema Markup must be represented by Uniform Resource Identifiers (URIs).

In JSON-LD, these identifiers appear as @ids to give the entities in your markup a unique identity that disambiguates and differentiates them from other entities – similar to how a social security number can uniquely differentiate people who may share the same name.

While Schema Markup still provides SEO value without including @ids, they are a requirement for the markup to become a reusable knowledge graph.

How to Apply JSON-LD to Web Pages
There are a few options for implementing Schema Markup on your web pages. You can manually author the JSON-LD and insert it in your webpages’ HTML, or you can use a plugin to generate and deploy the markup on your site.

Manual authoring requires technical expertise and isn’t scalable if you have a large number of webpages, and while plugins that auto-generate markup are a scalable authoring solution, the markup is generally much less descriptive. If you want to customize your markup and ensure it is dynamic and connected, we recommend using the Schema App Highlighter to generate and deploy your markup at scale without having to do any manual coding.

Whatever method you choose, the Schema Markup you author must appear in the HTML of the webpages being described, making it available for search engines and other web crawlers. In this state, your webpage content transforms into semantically enriched data, but this data doesn’t truly become a knowledge graph until it’s been collected and stored.

Step 2: Knowledge Hosting

In the hosting step, the Schema Markup you’ve authored for your website must be collected and hosted in a way that allows the RDF data to be retrieved.

Collecting the Schema Markup

There are two ways of collecting the Schema Markup once it has been applied to a website:

1. Crawling: Where a crawler crawls a website, extracts the JSON-LD that has been applied, and stores it in a knowledge graph.

2. Mapping: Many tools that map content to Schema.org will also store that markup in a knowledge graph.

But where does this storage occur?

Storing Data

Because knowledge graphs are represented as RDF triples, the best place to store them for easy retrieval is an RDF database or triplestore. There are a variety of RDF stores available. Examples include:

• OpenLink Virtuoso
• Ontotext GraphDB
• Amazon Neptune
• Stardog
• AllegroGraph

For more information and to compare the various options, check out DB-engines.com. They rank the popularity of database management systems and provide helpful analysis.

Retrieving Data

You can retrieve RDF data from a database or triplestore using SPARQL – an RDF query language. In the simplest terms, SPARQL uses known information to find unknown information (variables) using pattern matching.

For example, we could write a SPARQL query that says, “Find all the people in my database who work for Schema App and know about semantic technology.” “Mark van Berkel,” our co-founder, would return as a match, and so would all other entities in our knowledge graph that match the same criteria.

When you add Schema Markup to your website using Schema App’s authoring tools, we host that data for you in our Knowledge Graph Data Platform. You can query your own graph using the SPARQL endpoint interface in your account. You can also use our Export Data API to export your knowledge graph for reuse in other contexts.

Once you have found an appropriate way to host your knowledge graph, you can move on to curation.

Step 3: Knowledge Curation

It is a well-known fact that cleaning data is time consuming, and resource intensive, especially if you’ve got a lot of it. That said, we will address 3 of the most important aspects of curating your data to ensure your high-quality web content has resulted in a high-quality content knowledge graph.

In the knowledge curation step, you should ensure that the data within your content knowledge graph is:

• Accessible
• Correct
• Complete

Let’s break those down further.

Accessible

The data in your knowledge graph needs to be available.

For example, when extracting your content knowledge graph from your website, you’ll want to ensure that none of your web pages run into issues like “404 not found” errors. You will also want to ensure that the RDF store you’ve selected for hosting keeps your data retrievable and secure.

Correct

Your markup is free of syntax errors
The language used to express your knowledge graph can’t have syntax errors like missing commas or brackets in the wrong places. Auto-generated markup from plugins or other authoring tools will prevent this from happening, but if you’ve authored your markup manually, you’ll need to take extra precautions. Syntax errors can be identified on a page-by-page basis by running your pages through the Schema Validator.

The markup must align with the content on the page
If you make content changes to your page without updating your markup, your knowledge graph will become out of date.

Assessing whether the statements in your markup are correct and up-to-date can be difficult depending on the size of your dataset and how you manage your Schema Markup. This is especially true if you implement your markup manually. As previously mentioned, data cleanup is complex and resource-intensive, and becomes ever more so as your content grows and changes over time.

Therefore, we recommend using a dynamic Schema Markup generator tool like the Schema App Highlighter to ensure your page’s markup always aligns with its content and your RDF triples remain correct.

The markup follows the Schema.org vocabulary guidelines
You also need to ensure that your entity types use the most descriptive properties and that the properties used connect to expected types. For example, I can’t say that a Person worksFor another Person, because Schema.org states that the worksFor property can only connect a Person to an Organization.

The types and relationships you apply to your data dictate what you’re able to query for in your graph, and as a result also play an essential role in the completeness of your Knowledge Curation.

Complete

Ensure your knowledge graph contains enough data to answer queries relevant to your use cases. For example, if you want to know the correlation between ratings for products of specific sizes, colors, or prices, those properties must exist in your data.

In cases where your content references well-known entities (like brands, people, places, or concepts), you may also want to implement entity linking. Entity linking is a process that identifies entities in text and links them to corresponding known entities from external knowledge bases like Wikipedia, DBpedia, and Google’s Knowledge Graph.

You can apply entity linking:

1. Manually for absolute precision
2. Automatically using Natural Language Processing APIs

Once embedded in your markup, these entities provide additional SEO value by helping search engines like Google disambiguate and contextualize your content to provide more accurate results for search queries. When it comes to your content knowledge graph, entity linking makes your knowledge graph more descriptive, providing an even richer data layer for you to reuse.

Step 4: Knowledge Deployment

The knowledge deployment stage transforms the knowledge graph’s theoretical structure into practical applications that drive tangible benefits for your organization and its stakeholders. In fact, I prefer to call this the “Reuse” stage, since this is when you can finally reuse the knowledge graph you’ve created for all sorts of different initiatives.

To reap the SEO benefits we’ve previously described, you’ll need to ensure you’ve published your Schema Markup externally for search engines to consume.

Beyond the SEO benefits, your content knowledge graph can be reused for things like enhancing user experience, content optimization, and AI and machine learning. Let’s explore these opportunities further.

Enhancing User Experience

You can utilize your content knowledge graph to improve website navigation and internal search functionality.

For example, if a user visits a product page on an eCommerce site for smartphones, the content knowledge graph can be leveraged for a recommendation engine to dynamically generate suggestions based on the products being viewed. This can appear as a “You May Also Like” section or complementary products, like phone cases or chargers, suggested during checkout. This enhanced user experience can significantly increase engagement and conversion rates.

Content Optimization

You can use your content knowledge graph to optimize existing content or identify gaps in your content.

For instance, your organization likely publishes blog posts on various topics. With a content knowledge graph, you can analyze the connections among entities in your blog posts. This analysis helps you pinpoint clusters of related topics or categories that have more coverage. If you notice gaps in the topics your organization wants to emphasize in their web presence, you can create additional content to fill those gaps.

AI and Machine Learning Applications

Organizations can use knowledge graphs to accelerate their AI initiatives, including Chatbots and other LLM functions.

Knowledge graphs provide a foundation for training AI and machine learning models for tasks such as natural language processing, recommendation systems, and predictive analytics. Knowledge graph data is already structured, making it easier for machines to process than unstructured content (natural language). This makes using AI less costly as use continues to scale.

If you’re concerned about the risks of hallucinations from LLMs, you’ll be happy to know that knowledge graphs can also be leveraged for Retrieval-Augmented Generation (RAG), resulting in more accurate answers to queries.

These are just some of the ways a content knowledge graph can support your organization in this rapidly changing technical landscape. And the best part is, you can easily construct one with the pre-existing data that constitutes your website.

Developing a Content Knowledge Graph for Your Organization

Although creating a content knowledge graph has only four steps, implementing these steps can be resource-intensive. However, with the numerous possibilities for reuse, building a content knowledge graph is a worthwhile investment that will yield a strong return as semantic search, AI, and knowledge management continue to evolve.

At Schema App, we can help you implement your Schema Markup data layer and develop a semantically enriched reusable content knowledge graph to prepare your organization for AI and support your semantic SEO efforts.

Get in touch with our team to learn more.

The post The 4 Steps to Building a Content Knowledge Graph appeared first on Schema App Solutions.

The new structured data for product variants uses the Schema.org ProductGroup type in addition to Product structured data.

Benefits of Implementing Product Variant Structured Data

There are many products in the market with variants. For example, clothes can come in different colours and sizes. Phones can come in different capacities, colours, and models. The implementation of this new structured data for product variants brings advantages to both eCommerce sites and their users by:

• More precisely showcasing product offerings in search results, highlighting diverse variations such as size, color, and patterns.
• Better supporting the complex product variant scenarios for eCommerce sites and potentially increasing visibility for the diverse range of products they offer directly in the SERP.
• Improving user experience and click-through rates through offering more comprehensive product details.

Additionally, as specific, long-tail keywords become more prominent in search, this markup can help your product variants stand out. For example, if someone searches “navy blue long sleeve shirt size small,” a clothing retail site’s product variant that best fits this query could show up as a product rich result.

Prior to these changes, there was no easy way to differentiate product variants within product markup. Historically, the Schema App team tackled this problem by:

• Identifying variable pricing on a product with AggregateOffer,
• Identifying each variant as an individual Offer, with a different sku, or
• Listing each variant as an individual ProductModel to identify different colors, sizes, etc.

However, Google has expanded Product Variant Structured Data, which can help us overcome the previous challenge of dealing with product variants.

You can read this GitHub issue for more information on what sparked these changes.

In this article, we will specifically focus on the changes introduced with Product Variant Structured Data and how you can implement these changes to your eCommerce site.

Product Variant Structured Data Overview

Product variants must be grouped under a single identified “parent” product. To support this, Google introduced three new properties within the Schema.org ProductGroup type:

1. hasVariant – to nest Product variants under their parent ProductGroup
2. variesBy – Indicates the property by which the variants in a ProductGroup vary, e.g. their size or color
3. productGroupID – the ID, aka “parent sku” of the ProductGroup

Google also added a new property, isVariantOf, to the Product structured data. The isVariantOf property indicates the type of product a variant is associated with, and Google has clarified that this property supports product variants with distinct URLs.

Required and Recommended Properties for Product Variant Structured Data

To properly mark up information about your product variant within your page content, use the following required properties within the ProductGroup type. Additionally, we recommend including as many of the recommended properties as applicable to your page content.

Required: name.

Recommended: aggregateRating, brand, description, hasVariant, productGroupID, review, url, variesBy.

Refer to Google’s Structured Data Documentation for a comprehensive guideline for the required and recommended properties for Product Variant structured data.

Additional Eligibility Requirements

To be eligible for this newly enhanced Product rich result, you must also abide by the following guidelines written and established by Google:

• Each variant must have a unique ID in its corresponding structured data markup (like a sku, for example).
• Each product group must have a unique ID in its corresponding structured data markup, specified with the inProductGroupWithID property in variant Product properties or the productGroupID property in the ProductGroup property.
• Be sure to add Product structured data in addition to the product variant properties, following the list of required properties for merchant listings (or product snippets).
• For single-page sites, there must be only one distinct canonical URL for the overall ProductGroup that all variants belong to. Typically this is the base URL that leads to a page without a variant pre-selected, for example: https://www.example.com/winter_coat. Note: This doesn’t apply to multi-page sites as there is no single canonical URL representing the ProductGroup property (since the variants are distributed across equally important pages).
• For multi-page sites, each page must have full and self-contained markup for the entities defined on that page (meaning, off-page entities shouldn’t be necessary to fully understand the markup on the page itself).
• The site must be able to preselect each variant directly with a distinct URL (using URL query parameters), for example, https://www.example.com/winter_coat/size=small&color=green. This allows Google to crawl and identify each variant. Preselecting each variant includes showing the right image, price, and availability, as well as allowing the user to add the variant to the cart.

Marking Up Single-Page vs. Multi-Page Product Variants

Most eCommerce sites have two design types for their pages – Single-page and multi-page.

Single-page is when all variants are present on a single page without jumping to an alternative page for each variant (typically through query parameters).

Multi-page is when variants of the same product are accessible on separate pages.

Your variants can be:

• nested under ProductGroup markup, or
• be separate and unnested from the ProductGroup.

We typically recommend nesting your markup because it is a more accurate representation of the content on your page and its relationship to other products on your site. Nesting your markup can also help you develop a more robust content knowledge graph for your site.

The Product Variant rich result result uses properties like sku, gtin, and productGroupID to differentiate between individual products and their parent Product Group. At Schema App, our Editor and Highlighter will automatically generate identifiers in the form of @id for each entity in your markup, making it easier to query your Product data alongside other entities in your knowledge graph.

Depending on how your specific site is set up, how you mark up your product variants will differ. See Google’s examples and documentation for specific guidelines on how to markup your product variants.

Implement Product Variant Structured Data On Your Site

With constant updates and additions to Google’s Structured Data Documentation, having an agile and dynamic Schema Markup strategy and solution is critical.

The Schema App Highlighter ensures the dynamic and continuous updating of your site’s Schema Markup, aligning it with internal content changes and adjustments to Google’s structured data requirements and recommendations. This agility helps you stay competitive in search, as outdated Schema Markup can compromise your eligibility for targeted rich results.

Want to learn more about Schema App’s solution? Click here to get started.

The post Google Expands Structured Data Support for Product Variants appeared first on Schema App Solutions.

A knowledge graph is a structured representation of knowledge that describes entities and the relationships between them.

Knowledge graphs are a part of “knowledge representation“, a field of Artificial Intelligence (AI) that deals with presenting data in a way that enables machines to engage in reasoning, problem-solving, decision-making, and inferencing.

The versatility of knowledge graphs extends across various domains, with use cases that include:

• Recommendation engines
• Targeted advertising
• Data analysis
• Semantic search
• The training of Large Language Models (LLMs)

Knowledge graphs empower machines to extract meaningful knowledge from data by presenting information in a machine-readable format.

But did you know you can also create a “content” knowledge graph that is particularly useful for SEO initiatives? Although structured like a general knowledge graph, a content knowledge graph functions as a representation of the content on your website.

This graph can be published externally for search engines to consume, be employed for internal AI projects, or be used to identify content gaps.

Moreover, these graphs establish a robust foundation for developing more extensive marketing knowledge graphs if you have additional data sources you’d like to bring into the fold.

But before we get into that, this article will explore the basic components of a knowledge graph to enable you to develop your own content knowledge graph using the content on your website.

Anatomy of a Content Knowledge Graph

At its simplest form, a knowledge graph fundamentally consists of nodes and edges.

Nodes represent entities within a knowledge graph, and edges interconnect these nodes, delineating the relationships between them.

To fully understand how a knowledge graph works, it’s important to know the technologies required to build them.

Our focus in this section is to guide you through the key terminology and functions that are critical to the development of a robust content knowledge graph.

Uniform Resource Identifier (URI)

In the realm of knowledge graphs, the Uniform Resource Identifier (URI) plays a crucial role in uniquely identifying entities. A URI is a distinctive string of characters designed to distinguish and disambiguate a specific resource on the web.

Similar to license plates on cars that enable individual identification despite many people sharing the same make and model, URIs serve a similar function by ensuring the unique identification of various resources amidst the vast expanse of the internet.

At Schema App, we generate HTTPS URIs for entities defined in your Schema Markup, as shown in the image below. These URIs appear in the @id attribute. They allow you to link the entities on your site within your markup and enable search engines to identify the entities in your knowledge graph.

This systematic identification enables efficient communication and access to resources across different platforms and technologies. Within the context of a knowledge graph, URIs represent entities.

Entities

An entity, as defined by Google, denotes a single, unique, well-defined, and distinguishable thing or idea. It possesses defining characteristics or attributes such as size, color, and duration. However, an entity’s true significance emerges when it is described in relation to other entities, giving it contextual meaning.

This is where RDF Triples play a pivotal role, providing the framework to represent these interconnected relationships between entities within a knowledge graph. But first, what is RDF?

RDF

RDF, which stands for Resource Description Framework, is a standardized method for expressing data in the form of a directed graph using subject-predicate-object statements, commonly referred to as “triples.”

RDF Triples

The foundational unit of a knowledge graph is the triple. It comprises two nodes that represent entities connected by a single edge to articulate their relationship. Represented as “subject-predicate-object” statements, a triple illustrates how an entity (subject) links to another entity or a simple value (object) through a specific property (predicate).

As these triples combine, they form interconnected graphs of resources, laying the groundwork for a comprehensive knowledge graph. However, to provide meaning to the machine, you must express these triples in a machine-readable format.

You can express RDF triples in a variety of formats, including:

• Turtle
• RDF/XML
• And JSON-LD

The most widely adopted format is JSON-LD, which we utilize here at Schema App.

JSON-LD

JSON-LD, or JSON for Linked Data, is a serialization format for expressing RDF triples. It is relatively easy for humans to read and write and also for machines to consume. It is also the preferred Schema Markup format for search engines like Google.

JSON-LD code allows machines to understand RDF statements about entities.

For example, Mark van Berkel is an author for the Schema App blog, and his author page states that he works for the organization Schema App. On the left is the Schema Markup expressed in JSON-LD telling machines that Mark van Berkel (Person) works for Schema App (Organization). On the right is this same code visualized as an RDF triple, depicting these same entities and illustrating the relationships between them.

Ontologies

The last component in a knowledge graph is an ontology.

In Information Science, an ontology is a “formal, explicit specification of a shared conceptualization,” essentially serving as a blueprint for defining what exists in a data model (i.e. the method for describing contents within a database).

This model typically encompasses three key elements.

First, we have classes, also known as types, representing categories of entities such as an organization, event, or person.

Secondly, attributes, aka properties, are used to describe an entity. For instance, a Person entity might possess a name as one of its attributes.

Lastly, relationships, which are also represented by properties, delineate how one entity connects to another. These are similar to attributes in that they describe an entity, but more specifically, they describe how one entity connects to another entity.

For example, a Person may have a parent, child, or colleague relationship with another Person who will have their own attributes.

A wide variety of ontologies, vocabularies, and glossaries exist for categorizing and relating data, with Schema.org standing out as one of the most widely used in SEO. While technically a vocabulary and not a strict ontology, Schema.org effectively fulfills the role of describing categories of things and the relationships between them.

Building a Content Knowledge Graph with Schema.org

Founded in 2011 by Google, Bing, Yahoo, and Yandex, Schema.org emerged as a collaborative effort to enhance the web by introducing a standardized vocabulary. This initiative aimed to transform human language into a structured, machine-readable language.

All major search engines would support this language, improving their ability to match search queries with relevant results, making it beneficial for SEO purposes.

While SEO strategies commonly employ Schema.org, its utility extends beyond; it can also serve as a robust tool for constructing a knowledge graph.

Leveraging the Schema.org vocabulary allows you to organize your website content into a graph of interconnected entities. To achieve this, you can utilize the types and properties defined by Schema.org to express RDF triples in a machine-readable format like JSON-LD, all while representing your entities with URIs.

See how all of these terms come together?

This amalgamation of elements effectively creates a content knowledge graph for your organization.

Construct a Content Knowledge Graph for Your Organization

Developing your own content knowledge graph is essential for optimizing your semantic SEO strategy. It readies your content for the future of search and drives higher-quality traffic to your site.

Knowledge graphs empower search engines to infer knowledge through additional contextual information, bridging gaps for more relevant results. As such, this deeper comprehension should drive more qualified traffic to your site and boost the CTR for relevant pages.

At Schema App, we specialize in building and managing content knowledge graphs through the use of Schema Markup. Our dynamic authoring solutions ensure your Schema Markup is always descriptive, interconnected, and up-to-date.

Whether you’re integrating Schema Markup into your SEO strategy or aspiring to transform your content into a reusable data layer, Schema App has you covered.

Interested in building a content knowledge graph for your own organization but aren’t sure where to start? Schema App handles the technical aspects, enabling you to reap the benefits of having a well-constructed content knowledge graph without imposing the technical burden on your internal teams.

Contact our team today to get started.

The post The Anatomy of a Content Knowledge Graph appeared first on Schema App Solutions.

At Schema App, the ambiguity around the use of the Physician type has long been an area of contention for many of our healthcare customers. Therefore, this article will hone in on the issues around Physician Schema Markup and how the new clarifying subtypes will resolve them.

The Issue With Physician Schema Markup

Prior to Schema.org’s version 24 release, the Physician type was intended to represent a doctor’s office. It was a subtype of MedicalBusiness via both Organization and Place, and MedicalOrganization via Organization, as shown in the hierarchy below.

• Thing > Organization > LocalBusiness > MedicalBusiness > Physician
• Thing > Place > LocalBusiness > MedicalBusiness > Physician
• Thing > Organization > MedicalOrganization > Physician

This hierarchy emphasized the categorization of Physician markup as a business with a physical location.

However, naming the type “Physician” caused confusion regarding how to use it properly. As a result, the Physician type was usually applied to describe an individual physician rather than a physician’s office with a physical location.

You can read more about the issue in this GitHub ticket.

Changes to Physician Type in Schema.org v24

Therefore, Schema.org made a few changes to the Physician type in v24 to provide users with greater clarity in their categorization.

1. Redefined the Physician type

The Physician type is now defined as ‘an individual physician or a physician’s office considered as a MedicalOrganization’.

2. Removed Physician as a subtype of LocalBusiness

The Physician type is now exclusively a subtype of MedicalOrganization.

3. Added usNPI property to the Physician type

The Physician type now also includes the usNPI (National Provider Identifier) property, a unique 10-digit identification number issued to healthcare providers in the United States by the Centers for Medicare and Medicaid Services.

4. Introduced two new Physician subtypes: IndividualPhysician and PhysiciansOffice

Schema.org added IndividualPhysician and PhysiciansOffice as subtypes of Physician to disambiguate between these two interpretations of the Physician type.

Note: Schema.org version 26.0 later went on to restore PhysiciansOffice as a subtype of MedicalBusiness, after accidentally omitting it from the v24 update.

You can read more about it in this GitHub ticket.

5. Added occupationalCategory property to the Physician type

The occupationalCategory property is used to describe a job, preferably using a term from a taxonomy such as BLS O*NET-SOC, ISCO-08 or similar. This means you can specify whether a Physician (or its subtypes) has a specific occupational category like obstetrics or pediatrics.

6. Added new practicesAt property to the IndividualPhysician subtype

We will expand on this more in the section below.

But before that, let’s learn more about the two new Physician subtypes and how to use them.

Using the IndividualPhysician Subtype

The IndividualPhysician subtype should be used to describe an entity that is an individual medical practitioner.

The IndividualPhysician subtype still has properties available for things like:

• address
• hospitalAffiliation
• availableService

However, it also has the new ‘practicesAt’ property, which is unavailable to either Physician or PhysiciansOffice.

The practicesAt property should be used to indicate the MedicalOrganization (i.e. hospital, clinic, pharmacies, etc.) where this individual physician practices. If you have the MedicalOrganization entity defined on a different page of your site, you can connect both entities using this property.

Using the PhysiciansOffice Subtype

The PhysiciansOffice subtype should be used to describe an entity that is a doctor’s office or clinic.

It has the exact same properties as the Physician type, so you can still associate the PhysiciansOffice with a location using the address and hospitalAffiliation properties.

Should you Update Your Physician Markup?

In summary, the changes made to the Physician type in v24 will allow users to describe their content with greater specificity and help search engines better understand and contextualize the content on a page.

If you would like to continue using the Physician type to describe the entity on your page, you can do so since the new subtypes have almost the exact same properties. However, being specific with your Schema Markup is essential for search engines to disambiguate the entities on your site, thus allowing them to provide users with more accurate and relevant search results.

Therefore, we recommend updating your markup if you want to:

• Clearly distinguish between an individual physician vs a physician’s office,
• Leverage the practicesAt property, which is only available under the IndividualPhysician type.

The Schema App platform already supports Schema.org V24 if you want to try out the new Physician subtypes and properties. If you are a Schema App Enterprise customer, chat with your Customer Success Manager if you have questions about using these new types and properties.

If your healthcare organization is in need of healthcare schema expertise, we can help!

At Schema App, we provide an end-to-end Schema Markup solution for healthcare organizations and other enterprise SEO teams. Contact us to learn more about our solution.

The post Schema.org V24.0 Release: Changes to Physician Schema Markup appeared first on Schema App Solutions.

On December 4, 2023, Google released Vacation Rental structured data. If your website features vacation rentals, adding this new structured data markup to your site can enhance the visibility of your listings on the search engine results page (SERP).

History of Vacation Rentals in Search

Prior to this, Google’s SERP already featured an enhanced search function for vacation rentals. When you search for ‘vacation rentals in Vancouver’, for instance, you’ll find rental prices along with filtering options to adjust dates and occupancy.

The recent expansion in visual representation within search results marks a significant change. Previously, this feature wasn’t available through structured data, and even if you incorporated structured data on your site, appearing on the enhanced feature wasn’t guaranteed.

Now that Google supports vacation rental structured data, it provides greater control over the appearance of your vacation rental in search results. While Google historically utilized an existing XML feed method, which remains a viable choice for large partners and those managing multiple domains and brands, the use of structured data offers a simpler and more flexible approach.

What You Need To Know About Vacation Rental Structured Data

Vacation rental structured data is structured data you can add to your vacation rental listing pages to achieve a rich result on Google. The vacation rental rich results will provide users with information about the listing, such as the name, description, reviews, location, images, and more in the search results.

What are the Required and Recommended Properties?

To be eligible for the rich result, you must include all the required properties.

However, we recommend including as many of the recommended properties as possible. These details are not just about what appears on the rich result visually; detailed listings contribute to effective filtering for users’ specific needs.

By including properties like addressLocality and numberOfBeds, your listing becomes more relevant to targeted queries. For instance, someone searching for “vacation rentals in downtown toronto” can be shown listings that have specified the locality of downtown Toronto in their structured data.

Be sure to refer to Google’s Structured Data Documentation as a guideline for recommended and required properties for Vacation Rental structured data.

Certain required and recommended properties will also call for users to nest other Types of markup in the property. For example, one of the required properties to be eligible for this rich result is ‘containsPlace’, and Google expects you to nest the Accommodation Type under that property. This means that you need to create markup for the Accommodation Type, before linking it to the containsPlace property.

Nesting your markup and connecting entities using your Schema Markup can be challenging especially if you are new to implementing structured data. If you’re looking to implement proper vacation rental structured data on your site, our Schema App team can help.

Eligibility Criteria

It’s important to note that eligibility criteria apply, and this rich result is exclusively reserved for vacation rentals, not hotels.

Additionally, you can only list vacation rentals on Google if you are:

• A registered property management business with a direct booking website
• Already listed on a booking site that’s integrated with vacation rentals on Google

Shared rooms, partial houses, and peer-to-peer rentals aren’t currently eligible for integration.

So what does Google consider a “vacation rental property”? In order to be eligible, your property must:

• Provide a furnished space that is private to the guest/renter
• Accept short-term, overnight reservations
• Be managed and cleaned between stays

Expanding on these criteria, there are three different groups that can deliver vacation rental listings:

• Connectivity partner: Ex. Hostaway – a tool that manages vacation rentals across multiple channels
• Property managers: Ex. You run your own B&B
• Online travel agencies and metasearch providers: Ex. Aggregator sites like Expedia

This feature is limited to websites that meet certain criteria, and additional steps are required in order to integrate. Once you’ve completed the Vacation Rental Partner integration, you simply need to mark up your site with the appropriate structured data, allowing Google to crawl it to generate the listing feed. To delve into the specifics and ensure compliance, review Google’s Starter Guide Overview.

What Does a Vacation Rental Rich Result Look Like?

Visually, this rich result has not changed dramatically from the pre-existing search enhancements that closely resembled this new rich result. What has changed is how you can achieve this enhanced result through structured data.

The Impact of Achieving a Vacation Rental Rich Result

Achieving this rich result comes with many implications, some more beneficial than others.

On the positive side, it contributes to a zero-click search experience, aligning with Google’s user-centric focus. However, the flip side is the potential for intensified price comparison, which can be both advantageous and detrimental. While it facilitates user comparison and enhances visibility, it may pose a challenge by demanding more competitive pricing.

In addition to this, the rise of zero-click searches will impact aggregator sites, as users find answers directly on the SERP, potentially rendering aggregator sites obsolete.

In a highly competitive space like vacation rentals, this rich result becomes a game-changer. Without it, smaller businesses might struggle to rank on the SERP, particularly when contending with larger sites boasting higher domain authority and substantial investments in SEO and advertising.

Given the existing trend of price comparison across various platforms, this rich result simply expedites the inevitable research and decision-making process for users.

To stay competitive in the search landscape, it is imperative to implement this markup, ensuring your vacation rental business remains visible and relevant to user needs.

Implement Vacation Rental Structured Data On Your Site

With the many changes happening in search and with rich results coming and going at an unprecedented rate, maintaining an agile structured data solution is crucial.

The Schema App Highlighter ensures the dynamic and continuous updating of your structured data to align with any content or pricing changes made to your site. This agility is key to staying competitive, as outdated Schema Markup can jeopardize your eligibility for the targeted rich result.

For efficiency and adaptability, we recommend leveraging the Schema App Highlighter to seamlessly synchronize your markup with evolving website content and structured data requirements. Interested in learning more about the Schema App solution? Click here to get started.

The post New Vacation Rental Rich Results on Google appeared first on Schema App Solutions.

On November 29, 2023, Google announced they expanded their markup support for organization details. This means they’re using more properties from Schema.org’s Organization type to showcase the relevant information on Google’s knowledge panels and other visual elements such as Attribution.

This announcement comes two days after they introduced Profile Page and Discussion Forum rich results. Let’s dive in.

What You Need To Know About Organization Structured Data

Organization Structured Data is used to describe an organization (like a corporation, NGO, or school). It is often added to a website’s home page or about page since these pages tend to contain important information about an organization.

Previously, Google only supported Logo rich results for the Organization type. This required web publishers to use the logo and url properties to feature an organization’s logo in search results.

However, this update expands the number of properties that Google will support for the Organization type. In addition to logo and url, Google recommends web publishers use properties such as:

• name
• description
• legalName
• sameAs
• address
• duns
• taxID
• And more.

As part of this update, Google has also merged the documentation for Logo structured data with the Organization structured data feature guide. You can test your Organization structured data using Google’s Rich Results Test to determine if your markup is valid for the associated rich result.

Do you need to add all the recommended properties for Organization structured data? Probably not.

Most of the recommended properties are pretty straightforward. However, certain recommended properties, in particular, the identifier properties – iso6523Code, duns, leiCode, naics, globalLocationNumber, vatID, and taxID – may not be present on your website since they aren’t usually relevant to website visitors.

It is a general structured data best practice to only add Schema Markup for content that exists on the page itself. However, identifiers, like the ones listed above aren’t typically something that users visiting your site would be looking for.

Conversely, Google can use this information to consolidate the various identifiers as a single Organization entity in their Knowledge Graph. In cases like this, the content of these properties does not have to be visible to users on your website for you to add them in your markup.

Google is more strict about the visibility of content for rich results like Products and Review Snippets, which are more prone to fraudulent representation that can undermine consumer trust. However, metadata like identifiers is more critical for Google’s semantic understanding of entities than for the visual representation in the SERPs.

What you get from implementing Organization structured data

Adding Organization markup to your site will make it eligible to be shown on knowledge panels like the new merchant knowledge panel or other visual elements like Attribution. That way, users can easily find accurate information about your organization on Google.

Historically, the knowledge panels that appear on the right side of the SERP feed off data from Google’s knowledge graph and other sources like Wikipedia and authoritative websites. But with this update, Google can now tap into your structured data to provide users with even more accurate information about your organization.

The information in your Organization markup is arguably more accurate than an external source like Wikipedia because your organization owns the website and controls the information that appears there. Your structured data should be a trustworthy source, provided it is descriptive and up-to-date.

Structured Data to Reflect More E-E-A-T

These recent rich result updates underline Google’s ongoing prioritization of high-quality content from authoritative and trustworthy sources. Particularly at a time when AI-generated content is becoming more widespread, evidence of trustworthiness and reputation for the Organizations and People authoring and publishing content is paramount.

The Discussion Forum documentation states that markup for this type is used in features like Discussions and Forums and Perspectives, the latter of which surfaces “hidden gems” of unique expertise on a topic from those hard-to-find places.

Both the Profile Page and Discussion Forum structured data documentation include recommended properties for InteractionCounter to indicate things like the number of other accounts being followed, the number of likes of other entities’ posts, and the number of posts for a Person or Organization. These are properties that humans often reference when gauging the authority or trustworthiness of a source, so it would make sense that Google would want simplified access to this information in the form of structured data as well.

Google’s documentation for Article structured data now also recommends marking up author pages with profile page structured data.

This indicates two things:

1. Google wants more information about authors connected to the articles they write
2. Google is consuming structured data from multiple URLs about those authors

In essence, high-quality content from trusted sources is much more effective for keeping users happy with the search results they receive, but it’s also effective for training AI. Whether Google is focusing on advancing in the AI field, or trying to get a handle on the wild west of AI content proliferating on the web, it’s logical for them to encourage the application of structured data for types and properties that contribute to this effort.

Conclusion

In the October Google Search News Update, John Mueller recommended that SEOs “use a CMS hosting platform or plugin that makes it easy for you to add and remove structured data” to save time and make quick changes.

All these updates further demonstrate how important it is to have an agile structured data solution to stay ahead of your competitors. Furthermore, it is equally crucial to implement your structured data correctly and keep it up-to-date with Google’s changing requirements. This significantly impacts how Google understands your organization as an entity and how the information about your organization shows up in the SERP.

With the right expertise and agility to implement structured data on your site, you can leverage these new structured data opportunities to control how your brand is represented on the SERP and improve the search engine’s understanding of your content for more relevant search results.

Need help implementing an agile and scalable structured data solution across your site? Contact us today to learn more about our end-to-end Schema Markup solution.

The post Google Expands Markup Support for Organization Information appeared first on Schema App Solutions.

It provides a structured framework from which new knowledge can be gained through inferencing, allowing for the exploration and understanding of complex relationships within diverse datasets.

At Schema App, we map the content on your website to types and properties in the Schema.org vocabulary. As a result, we create content knowledge graphs. Content knowledge graphs are a more specific type of knowledge graph. They have the same structure and function but are built based on the content on your website.

The goal of any form of marketing is communication: you want to communicate your information to the world. Your content needs to be properly understood to connect with the right people at the right time and through the right channel.

This is hard enough to do successfully between people, but it becomes even more difficult when machines become conduits for this information.

Not only must we anticipate the needs and interests of our audience, but this information needs to be translated into a machine-readable, processable, and searchable format.

Industry Use Cases for Knowledge Graphs

If you’re familiar with the concept, it’s probably due to Google’s Knowledge Graph which popularized the term in 2012. However, knowledge graphs have proven to be valuable across various industries beyond the scope of SEO.

Social Media Sites

Meta constructed its own network of interconnected data points from publicly available information on their social platforms. These data points represent real-world entities and their relationships, creating a graph encompassing people, interests, activities, and more.

For example, when a user clicks the “Like” button on Facebook, this information is represented in the form of triples about that user. In the context of a knowledge graph, these triples consist of Subject-Predicate-Object relationships. If a user likes a particular movie (Object), the triple could be (User – Likes – Movie).

These triples expand the knowledge graph, creating new connections between users and their interests, activities, and affiliations. By analyzing the generated triples, Facebook gains insights into users’ interests, hobbies, preferences, and social connections.

As an example, if a user likes multiple posts related to hiking, the platform understands the user’s interest in outdoor activities. With this enriched knowledge graph, Facebook can personalize users’ experiences. Users see content in their feeds that aligns with their interests, creating a more engaging experience.

Advertisers can leverage this data to target specific demographics based on their interests and behaviours.

Cultural Heritage Institutions

Cultural heritage institutions, including galleries, libraries, archives, and museums, grapple with the daunting task of managing vast amounts of unstructured, semi-structured, and structured data that is stored in silos. The absence of efficient applications to manage this information often leads to manual efforts in collecting and processing this data, resulting in high labour costs and outdated information.

To address these challenges, cultural heritage researchers are turning to knowledge graphs as an innovative and dynamic solution. The following illustration showcases a digital cultural heritage management project that has constructed a knowledge graph using data from the Chinese Palace Museum.

Heritage Science Journal, 2023

Additionally, the integration of deep learning algorithms with these knowledge graphs further refines digital cultural heritage management, enhancing visualization capabilities and making it more intelligent and cohesive. These systems working in tandem is one example of the relationship between knowledge graphs and AI.

Enterprises

Enterprises like large consulting firms have harnessed the power of knowledge graphs to optimize information management. With vast networks of consultants, sometimes in the hundreds of thousands, they often face the challenge of matching the right expert to specific projects.

A specific consulting firm with 300,000 consultants, partnered with SemanticArts to create a knowledge graph detailing each consultant’s specialization, industry experience, skills, and availability. To streamline access to this data, SemanticArts also prototyped a chat service to leverage the knowledge in the graph database.

This is only one example of knowledge graphs being used to standardize and unify information for a chat service. Chatbots act as translators, allowing users to query knowledge graphs in natural language, rather than having to learn graph query languages like SPARQL. This seamless integration of knowledge graphs and chatbots not only enhances internal processes but also exemplifies the potential of this technology in modern enterprises.

With the introduction of LLMs, many enterprises are also exploring how knowledge graphs can be used to ground them to provide accurate and efficient information to users on their sites.

Google’s Knowledge Graph

Arguably the most well-known use case, Google’s Knowledge Graph began with Freebase, a project started by Metaweb in 2007. Freebase was a huge collection of structured data described as “synapses for the global brain.” It became a significant linked open data project in 2008.

Google acquired Freebase in 2010, incorporating this extensive knowledge base into its proprietary Knowledge Graph. Upon releasing their knowledge graph, Google introduced the concept of “strings not things”, announcing their pivot from lexical, keyword-based search, to semantic search.

Google continued to maintain Freebase before giving its content to the Wikidata community in 2014. When Freebase became read-only in 2015, it held over 3 billion facts about nearly 50 million entities.

Google embraced the knowledge graph to harness the intricate connections between entities on the web, adding crucial context to web data.

Knowledge Panels: Google’s Knowledge Graph Brought to Life

Now that you know the history and purpose of Google’s knowledge graph, it’s important to be able to identify how this information is presented in search. Enter – Google’s Knowledge Panel.

The Knowledge Panel is the box that appears on the right side of the search results page when you search for well-known entities (celebrities, businesses, landmarks, etc.).

The Knowledge Panel provides a snapshot of information about the entity you searched for, sourced from Google’s Knowledge Graph. It offers a quick overview, including key facts, images, links to official websites, and sometimes interactive elements like maps or social media profiles.

For example, here is our co-founder, Mark van Berkel’s knowledge panel.

In essence, Google’s Knowledge Graph is the extensive database that powers the Knowledge Panel. It is a compilation of information from one or more pages that presents answers to search queries in the rich results, enhanced SERP results, and knowledge panels we’ve come to associate with authoritative and trusted content.

Even on a smaller scale, organizing data and establishing clear connections between entities is vital for search engines and machines to understand your content.

The good news is that you, too, can manage your content and entities as a knowledge graph for better search engine comprehension. By doing so, you can increase the likelihood of earning a knowledge panel for your business to build authority in search.

However, before you dive into this journey, it’s essential to implement semantic Schema Markup and establish your content’s entities.

The Semantic Building Blocks of a Content Knowledge Graph

To form a content knowledge graph, your content (i.e. plain text, images, etc.) needs to be available in machine-readable code. In the context of SEO, this code is represented by the Schema.org vocabulary.

This informal ontology, of over 840 types and 20+ properties per type, can be applied to web content in the form of Microdata, RDFa, or JSON-LD. Once applied, it is expressed as Schema Markup, and enables machines to understand information about your content and differentiate between things, like local businesses and products.

Moreover, properties can be added to each Type to provide further context to this data. Does the local business serve a specific area? Does the product come in different sizes or colours?

This is information that users were querying about mostly by way of keywords, or “strings”. Schema.org’s ability to define and connect information would turn data into a graph of things and transform the capabilities of search in the process.

Schema.org’s vocabulary has allowed unstructured content (i.e. text, images, etc) to be understood as distinct entities. This provides the foundation upon which knowledge graphs are built.

Developing Your Content Knowledge Graph

By using this markup to then develop your knowledge graph, you are establishing semantic relationships between not only your own content, but to external databases, adding more context to your content.

Developing your own knowledge graph enhances your organization’s ability to manage and utilize its data efficiently, facilitating informed decision-making processes. It also significantly improves user experience by enabling accurate and personalized search results that are directly aligned with user queries. This can lead to more targeted and quality traffic engaging with your site.

But, most exciting of all, is that a knowledge graph promotes interoperability among different data sources and systems, fostering innovation and enabling the development of new products, services, or insights for your organization.

As search is shifting toward AI-powered systems, this innovative approach is becoming increasingly important to stay ahead.

The Knowledge Graph Process

Learning to implement Schema Markup is much like learning another language, one that allows your web content to be understood by machines. Every time you mark up a thing on your page, you are asserting that this thing exists and defining how it relates to other things in the world.

This approach is foundational to the development of a knowledge graph, illustrated in the Data, Information, Knowledge, Wisdom (DIKW) Pyramid below. This hierarchy of information and insight shows that enriching data with context and connection is essential. The more we do so, the more inference and wisdom can be drawn from it.

Data

Whether you’re running an automotive business, a medical office, or a software company, if you have an online presence, you have data. You may have internal data like sales and inventory, and external data like the content on your website. Your content contains data about the products or services provided, location information, and blog content that demonstrates your areas of expertise.

Data is raw and simple, and in this state often lacks semantic significance.

Information

However, simply creating content is not enough. Machines have a harder time interpreting plain texts or images than most humans.

Without structuring this data about your business, machines struggle to interpret it accurately. To bridge the gap between human understanding and machine comprehension, it’s crucial to structure your data to transform it into machine-readable information.

This is where an ontology, like Schema.org, comes in. By applying the Schema.org vocabulary to your data, it becomes structured and subsequently has the potential to become connected. Data becomes information when it is related to other data. For example, the text “Mark van Berkel” on its own is a data point, but it doesn’t give us useful information.

But if the Schema.org vocabulary were used to express that Mark van Berkel is the name of a Person who knows about Semantic Technology and the Semantic Web, and is the founder of Schema App, this provides useful information about the entity Mark van Berkel as an entity that machines can more readily comprehend.

Finding which information to connect to other information can be tricky. This is another factor we take into account in our tools. Because of our background in semantic technologies, we are passionate about connecting your content.

This is why we developed the Schema Paths Tool to simplify the process and save time. The Schema Paths tool provides different pathways for how two entities on your site might connect using the Schema.org properties and types.

By simply inserting the two Types you want to connect, you can see every possible predicate to connect them. You can then choose the one that most appropriately articulates their relationship in the knowledge graph of your content.

Knowledge

However, applying an ontology can only get you so far.

In an interview with Steve Macbeth of Microsoft, he notes that “Semantics without the ability to connect to other data is almost as valueless as no semantics…[S]emantic data [is] only valuable in my opinion when it can be bridged to other data.”

This encompasses the “Knowledge” portion of this process, which further evolves the information that has been distinguished within your content. It represents a collection of information that is useful, typically in the form of triples connected to other triples. This essentially builds a knowledge graph by connecting it to other knowledge graphs.

All of these connections represent contextual information about a particular topic. For example, we can express that Mark knowsAbout the Semantic Web by connecting his knowledge graph to Semantic Web, which is an entity defined by Wikidata.

By linking to other knowledge graphs like Wikidata, we can be more explicit with machines about our information so that they can disambiguate the information about the entity. Your content can inform and be informed by other structured data on the web.

Thanks to this collaborative effort, new knowledge may be inferred and accessed through semantic search.

Wisdom

Wisdom, in this sense, takes existing knowledge derived from knowledge graphs and uses it to make inferences, actionable insights, and educated assumptions to generate new knowledge.

Unlike data and information, which reflect the past, wisdom guides present actions and future aspirations, emphasizing the practical application of knowledge.

What Can You Do With a Content Knowledge Graph

The versatility of knowledge graphs provides limitless flexibility in their applications. Despite being a longstanding concept, various industries continue to leverage knowledge graphs as foundational frameworks for organizing information for many different use cases.

Improve Search

By understanding the relationships between different entities, knowledge graphs enable search engines to offer more relevant results and simplify information discovery for users. They enhance navigation with related links and suggested searches, making it easier for visitors to find what they need.

At Schema App, we’ve been implementing semantic Schema Markup and entity linking to help customers develop their knowledge graph. By having a knowledge graph, search engines can better match your page to a user search query. This drives more qualified traffic and increases click-through rates (CTR).

Ground LLMs

If you want to deploy an AI chatbot to assist your customers, it’s critical that it provides accurate information every time. The problem, however, is that LLMs can’t fact-check like humans do. They respond to queries based on patterns and probabilities, sometimes resulting in incorrect or fabricated responses, known as “hallucinations.”

This means the AI needs to understand specific things about your business, like what you sell and how things are related, to give the right answers to customers. Businesses can address this challenge by utilizing their own knowledge graph, containing accurate information about their products or services, to train the AI chatbot effectively.

The pros and cons of Knowledge Graphs vs. Large Language Models. Image source: Unifying Large Language Models and Knowledge Graphs: A Roadmap

Analyze Your Content

Formatting and structuring your content in the form of a knowledge graph allows you to categorize and quantify your content library and identify gaps. It also enables a deeper level of analysis to answer questions like:

• Which schema.org Types are used most often?
• How many entities are identified on each page?
• How many properties are being used?
• How much of your content is being marked up?

Your knowledge graph can also be used to easily assess your content qualitatively, by answering questions such as:

• How do your entities compare to the search terms you’re targeting with your content?
• Are you linking to entities from external authoritative knowledge bases? If so, which ones?
• Are there any missing that should be present considering your area of expertise?

The Importance of Knowledge Graphs in SEO

Knowledge graphs establish semantic relationships between different pieces of information. They enhance the overall user experience and credibility of a website, which are also factors considered by search engines in their ranking algorithms. By leveraging knowledge graphs, websites can enhance their SEO efforts, leading to increased organic traffic and improved online presence.

For SEO purposes, knowledge graphs are invaluable for delivering precise, tailored search results that go beyond just the string of words typed into search. Empowered by knowledge graphs, search engines can now infer context around a query and fill in gaps that would otherwise remain limited to the keywords used in the query.

This deeper comprehension ensures highly relevant search results, increasing the likelihood of user clicks and qualified traffic, and ultimately boosting CTR for relevant pages.

Developing your own marketing knowledge graph is essential for optimizing your semantic SEO strategy. It helps in preparing your content for the future of search and driving meaningful traffic to your pages.

Interested in developing your own content knowledge graph for your organization but don’t know where to start? Schema App takes care of the technical aspects so that you can take full advantage of what structured data can do without getting mired in the weight of the work.

Contact our team today to get started.

The post What is a Content Knowledge Graph? appeared first on Schema App Solutions.