Welcome to The Search Session. I'm Gianluca Fiorelli, and today's guest is Jarno van Driel, a structured data and semantic SEO consultant based in Rotterdam, the Netherlands.
We look at how structured data is used today, where common misunderstandings come from, and how its role may change as search becomes more influenced by LLMs, knowledge graphs, and agentic systems.
Jarno brings a pragmatic perspective shaped by years of working directly with Schema.org and the technologies behind the semantic web.
What you’ll learn in this session:
What separates structured data from Schema.org: structured data defines how information is organized and expressed, while Schema.org provides the vocabulary used to describe its meaning.
Why structured data confusion starts with the industry, not Google: Google focuses on what matters for Search, while many SEOs rely on second-hand advice instead of reading the original specifications and use cases.
How NLP reduced the need for FAQPage markup: question-and-answer patterns could already be extracted without it, while the rich result often encouraged lazy content instead of better product descriptions.
Why structured data is not essential for LLM visibility: LLMs primarily work with natural language, although structured data may become more useful when agents can navigate knowledge graphs through shared standards.
How internal knowledge graphs create value and become more accessible: they improve operations and reveal useful relationships, while LLMs help smaller teams generate SPARQL queries without extensive technical expertise.
What machines may use to assess trust and E-E-A-T signals: aggregated information across the web provides the evidence, an entity’s own site acts as confirmation, and semantic HTML helps machines interpret the content.
How accessibility is handled in SEO: it is rarely included in standard SEO reviews, and when it is, the focus is usually on technical fixes rather than clear, accessible writing.
What the future of structured data may look like: older rich results are losing relevance, Product schema is becoming more important, and Schema.org could reset around leaner, more practical agentic use cases.
Listen to the full conversation to better understand structured data and clear up the confusion surrounding it.
Topics covered: structured data · Schema.org · rich results · FAQPage markup · product schema · LLM visibility · agentic standards · knowledge graphs · E-E-A-T · semantic HTML · accessibility · entity optimization
About the Guest
Jarno van Driel
Independent Structured Data and Semantic SEO Consultant
Jarno van Driel has more than 25 years of experience across web development, accessibility, structured data, and semantic technologies. He is known for his work with Schema.org, semantic modeling, and machine-readable content.
He began working with semantic metadata in 2008 and became an active Schema.org contributor in 2013. Since 2018, he has worked independently, helping organizations worldwide develop structured data, corporate vocabularies, knowledge structures, and internal information models.
Since December 2024, Jarno has also been a guest teacher at SEO Pro Academy, where he teaches structured data in Dutch. He also publishes The Invisible Graph, a resource focused on structured data, Schema.org, and semantic SEO, and has spoken at conferences including Friends of Search and brightonSEO.
Video Chapters
Transcript
Full conversation between Gianluca Fiorelli and Jarno van Driel.
Gianluca Fiorelli: Hi, I'm Gianluca Fiorelli, and welcome back to The Search Session. Today we are going to have maybe one of, and I will surely prove it, the longest evangelists of structured data, semantic search, and the semantic web in general.
He's from Rotterdam. He's a consultant and really started his career, somehow like me. Not really like me, but surely he started his career in this field in the last century because it was 1998.
So it sounds very, very old, but this guy is not that old at all. Especially his brain is not that old. In fact, he's someone who anticipated many things. We have been talking constantly for about 18 months, and he's also one of those whom I like because he's very balanced.
For instance, and we are going to talk about this topic, when it comes to structured data, he says, "Okay, structured data is great, but please don't overdo it."
This person is Jarno van Driel. Hey, Jarno. How are you doing?
Jarno van Driel: Hi, Gianluca. Thanks for having me. I'm doing fine.
Gianluca Fiorelli: It's my pleasure. You are in Rotterdam, right?
Jarno van Driel: Yes, the Netherlands.
Gianluca Fiorelli: Okay. So how is the summer going?
Jarno van Driel: I finally got a week of less heat. Last week, it was like 34 to 36 degrees Celsius, and the temperature dropped to 22. Yay.
Gianluca Fiorelli: Oh, that's cool. Well, I hope it is not rainy because the times I go to the Netherlands, it's quite a weird type of weather. Sun, and all of a sudden it's a kind of British weather. So sun, rain, wind.
Jarno van Driel: On average, there is a bit more sun than in the UK, but the weather is comparable.
Structured Data vs. Schema.org: What's the Difference?
Gianluca Fiorelli: Okay. And how is SEO treating you lately?
Jarno van Driel: It seems like I'm mostly spending time having tons of conversations about the sense and, most of all, nonsense around structured data, because a lot of people, especially because of ChatGPT advice, have all kinds of weird ideas about what structured data is doing.
So I'm having a lot of weird calls these days. In the past, I had to convince people to start using structured data markup, and nowadays I'm spending more of my time trying to talk them out of the idea.
Gianluca Fiorelli: Yes, that's what I was saying before. I remember you did a wonderful, and also funny, experiment once where you were substantially tagging almost every entity present on the page with structured data, if I'm not wrong.
It was a way to demonstrate that going that way, over-bloating your code with structured data information, is not the correct way to use structured data.
Jarno van Driel: No.
Gianluca Fiorelli: So, if you could say it in one phrase or a short paragraph, first of all, what is the difference between structured data and Schema.org? Because I feel people still do not understand there is a big difference between the two.
Jarno van Driel: Well, first of all, the term "structured data" is already very convoluted because "structured data" covers a lot of things. It covers Excel files, it covers tables, and it covers structured data markup, which is what we're going to be talking about. So structured data in itself can be many different things.
When we're talking about structured data markup, we're talking about annotations made in a certain syntax. That syntax can be RDFa, Microdata, or JSON-LD, whereas the syntax itself carries no meaning.
So, to convey the meaning of the data you're sharing, you need to use vocabularies or ontologies, and Schema.org is one of those vocabularies out there that helps you say, "This piece of data is about a person. He or she has this name, lives in that city, and is the author of this article."
Those are all kinds of things you can express by using the Schema.org vocabulary because it contains all those terms that are machine-readable, so to speak.
Gianluca Fiorelli: Yes, correct.
Jarno van Driel: That's the biggest difference. When people talk about schema markup, that's yet another convoluted term because schema markup can also be a plain JSON file according to the JSON schema that exists.
The technically correct terminology would be semantic metadata, but that's a bit of a mouthful. Years ago, the search engines decided to come up with a marketing term called structured data to make it explainable to the everyday person.
Gianluca Fiorelli: Yes. Maybe I can understand it because they need to talk. We usually think about Google, for instance, or even Bing, as talking to developers or even people who know webmasters, what they were calling webmasters.
But actually, one of the most important blogs from Google, for instance, is The Keyword blog, which is substantially talking to business owners and marketing people, not digital marketing people. So they need to explain things, dumb them down, and simplify them to make them understood. I love that blog because usually it's where you can find what Google is really heading to.
Sometimes you find the most interesting tidbits and strategic ideas that Google wants to push in that blog because it's talking directly to business owners, not to us. To us, it's talking about how you have to use hreflang and so on.
Using structured data versus unstructured data is the easiest way to make people visualize things. It's funny that now another terminology is coming out. It's something like structured data versus prose. Prose is used to describe talking about things without a real structure.
That is weird for me because what is structured data, poetic? It's like, you know, it's the time of Ulysses and Odysseus in the movies now. So it's the hexameter against the prose. Hexameter is structured, and prose is not.
Jarno van Driel: Well, one could easily say that a lot of marketing content out there is actually just prose. It's a lot of blah, blah, and a lot of words without actually going into depth. It's trying to sell you an emotion instead of facts.
Gianluca Fiorelli: But I don't know if that could even be defined as prose. It would be just blubbering or baroqueism, if you want to talk in literary terms.
Measure before you believe.
Advanced Web Ranking helps you measure the impact of structured data, semantic SEO, and AI optimization across both traditional search and AI search experiences. Try AWR free.
Google's Documentation: Helpful or Part of the Problem?
Gianluca Fiorelli: But again, I think that, and I don't know if you agree with me. Returning to Google, don't you think that this kind of misunderstanding about the difference between structured data, Schema.org, and eventually other definitions of things that are inside the big bucket of structured data is also somehow Google's fault?
If we look at the only existing information from Google about structured data, it is the structured data gallery, where Google explains how to use structured data to obtain rich results. Google talks about structured data just in terms of rich results. Even if it puts something like, "Structured data is important, Schema.org is important for understanding the meaning," it's just one line, and then everything else is about rich results.
Don't you think this is also Google's original sin that has caused people, especially in SEO, not to understand it?
Jarno van Driel: To be honest, I actually applaud Google for what they have done throughout all those years. I think they probably have the biggest knowledge repository on how to use structured data compared to any publisher out there. There is nobody with so many technical guidelines and so much explanation in their documentation.
Sure, that has been a path. If we look at the documentation from 15 years ago, it wasn't that good, and there has been a continuous evolution of that documentation.
But I'd love to see anybody out there do better than Google does, actually. Is it perfect? No, it's not perfect. Not even close.
Yet again, Google tries to explain the parts that actually matter to Google. Should they go as far as explaining all the theory around linked open data, which structured data markup is based on? Not really. They try to convince people to use the things that are important for their search engine. If you're curious to learn more, their documentation points to every resource there is. You can go to the W3C specifications.
I think the bigger issue, and that's a similar issue you highlighted in your recent document about open knowledge format, is that the issues actually lie with the people in our industry. People don't read the actual source.
The loudest screamers in our industry have been trying to sell us on structured data over the last couple of years because that's an easy sell, and it makes them sound advanced.
But the truth is that none of them have even spent a single minute over at Schema.org's GitHub and read about all those terms, why they're in that vocabulary, and what the use case was when we added those things to the vocabulary.
I say "we" because I'm one of the dozens of volunteers there. Everything in there ended up with a certain use case in mind. But a lot of those use cases never materialized, and now suddenly there are many people who say, "Use all those terms." Those terms were added over a decade ago and were never used, so why would they be important right now? They're not.
Gianluca Fiorelli: Yes. In fact, it's interesting how, and this is something that I like to do every year with the Web Almanac, the chapter about the implementation of structured data is evolving over the years.
I think that somehow there are certain types of Schema.org vocabulary that are very widely used. But I think, and I think you agree with me, that sometimes they are so widely used not because web owners, webmasters, developers, or even SEOs really thought about them, but because, for instance, WordPress is the biggest and most widely used CMS. All the SEO plugins, and we are thinking of the classic Yoast SEO, but also Pragmatic, if I'm not wrong, have their own structured data sections, so they implement Schema.org by default according to certain characteristics.
That's why certain types, usually the types that Google recommends using and implementing in the way Google recommends for rich results and uses for painting the SERPs, are implemented by default. So we see WebPage, Article, LocalBusiness, Organization, and so on.
Jarno van Driel: BreadcrumbList. The interesting thing, especially about the Web Almanac overview, is that if you take the top 50 classes that are used, you already have around 85% of everything that's been published.
You take the top 50 classes and remove everything that has not been part of Google's documentation. If you take out everything that is or has been a rich snippet, then suddenly you have nothing left.
Gianluca Fiorelli: Yes.
Jarno van Driel: What the Web Almanac clearly demonstrates is that 90% of the markup out there only exists because Google actually had a feature for it.
Gianluca Fiorelli: Indeed, indeed. I think that sometimes there are things Google should clarify, using the same philosophy. I'm not asking Google to change.
What I would like from Google—and you can also understand the implied business need—is to explain very well all the schema related to products.
The schema related to products also works together with the Merchant Center feed, and this feed supports not only organic merchant listings but also Google Shopping. It is so important for Google’s business ecosystem, and Google explains very well, “You can use this for a variant, you can use this for this thing, and this other one for AggregateOffer.”
I would sometimes like the same attention to detail from Google for other things because, otherwise, we see people getting very creative with schema.
Jarno van Driel: But I think the issue there lies with the people doing that and not so much with Google’s documentation.
Gianluca Fiorelli: Yes, but, for instance, think about the travel industry. When we talk about what Google calls a carousel, the ItemList for European users, it is still in beta for obtaining rich results with a carousel of items.
It is valid for retail, but it is also valid for travel. If implemented correctly, you can have a carousel of hotels where you are selling rooms in Madrid, Rotterdam, or other places.
But when it comes to hotels, Google doesn’t help. This question always comes up. I work a lot with travel, and my clients or their in-house SEOs ask me, “How can I indicate the offer of AggregateOffer?” Because Hotel formally doesn’t have the offer.
In this case, I’m lucky because there is a wonderful guide on the Schema.org website for hotels, and also for car dealers, I think, with precise indications on how to use and combine everything.
It is very old and still uses examples that are not in JSON-LD, but it is totally usable and easy to follow.
Jarno van Driel: This is an interesting one. Do you know why the documentation over at Schema.org is so extensive? The entire hotel section was actually intended to be an extension.
There was a working group that created that extension for Schema.org. That’s why it is so in-depth and contains such good examples, because they were all created by that specific working group.
Gianluca Fiorelli: That’s great.
Jarno van Driel: That’s the whole idea behind Schema.org. It’s not supposed to be just a Google thing. It’s supposed to be an open vocabulary.
Gianluca Fiorelli: I know, but, for instance, I would like Google at least to say, for the specific case of hotels, “This is the link where you can find more information.” Not necessarily because they have to, but people—it’s weird—SEOs often don’t search.
Jarno van Driel: No, that’s my whole point, which you also made in your article. All the information surrounding Schema.org is out there. Ninety-five percent of all the conversations surrounding the vocabulary and its sponsors are there on GitHub and the W3C.
But some SEOs just go through Schema.org, think they have found the magic terminology, and copy it without even looking into why it is part of that vocabulary. If you don’t understand the “why” behind it, how can you conclude that it is valid just because the word exists?
It’s like taking a dictionary and giving every word in the dictionary exactly the same weight. You have to use every word in the dictionary, or else you’re not speaking or writing correctly.
That’s not how a dictionary works, and it’s the same thing for Schema.org. That’s not how a vocabulary or ontology works. You don’t need to use everything. It lays out the options.
Gianluca Fiorelli: There is an interesting exception, still citing Google, where Google says, “Okay, I don’t tell you what the required and recommended properties are,” because Google makes this distinction.
The only case where it says, “Use as many properties as you can if they are present and visible in the content of the page,” is Organization.
It’s interesting that Google makes this exception for Organization, practically saying nothing in terms of recommendations, apart from telling you to use it once on your homepage or About page, wherever it is best to use it.
The problem is that Organization could also be useful to cite using the ID. But Google doesn’t explain what the ID is or how you can use it.
Jarno van Driel: It mostly shows examples around product variants, return shipping policies, and things like that. There, it simply uses fragment identifiers in the ID to link things together.
I think Google has good reason not to delve into the "why" and “how that works” because that’s not the role of Google’s documentation. That is how it is supposed to work, and that’s the difficult part about it. That’s why you have the actual specifications out there.
People are looking at Google, and I’ve heard this comment throughout time. It’s not up to Google to tell you what’s already in the W3C specifications. If you want to learn HTML, you look at the W3C specifications. If you want to learn JSON-LD, you look at those specifications. There, you can learn how the syntax works.
I get your point, but asking Google to be the creator of a vocabulary, explain how the syntax works, and explain how they want you to do things is too much to ask of Google. If anything, where’s Bing? Bing has been silent for a decade already.
Gianluca Fiorelli: Well, I don’t know about Yandex…
Jarno van Driel: Yandex is out of the picture. It’s sort of closed within Russia. It used to be registered in the Netherlands. The EU forced it to be sold back to Russia. It’s in Russian hands now, and due to the war in Ukraine, Yandex is out of the picture.
Gianluca Fiorelli: What other search engine collaborated with Schema.org apart from Bing?
Jarno van Driel: Originally, it was Yahoo, Bing, and Google. Later on, Yandex joined pretty quickly as well. Baidu never joined from China, but it consumed it in the background, so it was a silent consumer of structured data. I don’t know if that’s still valid these days, but 10 years ago that was the case.
You’re also seeing this in South Korea. There’s a local search engine, and it has its own documentation about what it consumes. But if you look at that documentation, it’s nearly a copy of Google’s documentation.
Now that Google, for example, has officially dropped FAQPage, I’m curious to see what those other search engines will do.
But in all honesty, the main driver for more than a decade has been Google. It’s the one search engine that tells us what it wants from us and has been actively developing new features.
No other search engine has done that. No LLM has done that. Google is the only one producing documentation surrounding structured data.
Measure before you believe.
Advanced Web Ranking helps you measure the impact of structured data, semantic SEO, and AI optimization across both traditional search and AI search experiences. Try AWR free.
FAQs, Products & Merchant Center
Gianluca Fiorelli: You cited a recurring topic: FAQs. It’s funny how FAQs suddenly became so popular again because of LLMs, even though Google deprecated them in 2023, I think, for everyone except a very few sites.
Jarno van Driel: Government and medical sites.
Gianluca Fiorelli: Yes, and now for government and really reputable health sites, they have also been deprecated. I think this case is a wonderful example of how the training data cutoff can produce disasters.
Jarno van Driel: I’m not even convinced FAQPage did much to help train LLMs with natural language parsing.
Gianluca Fiorelli: Yes.
Jarno van Driel: For years already, it has been so easy to extract FAQs because they follow a very strict pattern.
Gianluca Fiorelli: It’s one of the simplest forms of structured data in prose because it’s a question and an answer.
Jarno van Driel: Exactly. It has been easy to extract that type of information since late 2016. NLP was good enough to extract it without any guidance.
I remember working on FAQ pages specifically for large e-commerce companies before FAQPage markup was even live originally. Google already gave perfect answers based on FAQ pages, so why they ever invented the FAQPage snippet is beyond me.
NLP had no need for it, and Google was already pretty good at answering questions before it launched FAQPage, so why it ever existed is beyond me.
If anything, I think it caused a very negative pattern where everybody became lazy, stopped writing good product descriptions, and just slapped an FAQ on the page. I call that lazy.
Gianluca Fiorelli: Well, it depends. I can understand the need to use FAQs for some kinds of product pages and product descriptions.
Jarno van Driel: There are definitely use cases for FAQs, but…
Gianluca Fiorelli: Yes, but sometimes I also see even articles that are substantially structured as if they were FAQ pages. That’s because there is this sort of new myth, let’s call it that even if it’s not really a new myth, that LLMs prefer one chunk per question and answer.
Talking about myths related to LLMs and how people are trying to optimize for visibility in LLMs, what are the myths related to structured data, Schema.org, and other types that you are seeing becoming dangerously popular?
Jarno van Driel: Actually, it has been quite stagnant for a couple of years already. With Google’s shift from traditional search results to LLM-based search results, the problem is that many of the original rich results don’t fit into that AI Overview answer pattern.
Sure, we still have some traditional results if you’re patient enough and keep scrolling. But the use case for many of the rich results that were originally designed is slowly disappearing.
What we’ve seen over the last couple of years is Google cleaning up its inventory of rich results because they have lost their purpose. That’s not a bad thing. It doesn’t mean markup has become less important. It just means that one specific use case has reached the end of its life.
At this moment, the biggest use case, probably because everybody wants the agentic web to start working, is Product schema. Google has been working on it for approximately eight years, step by step aligning the Merchant Center specifications with what you can do using structured data.
Gianluca Fiorelli: Since 2018. Eight years, because they started showing rich results for popular products in 2018.
Jarno van Driel: There’s a difference between what Google is doing in Search and the discussions we’ve been having over at Schema.org. They’re highly out of sync.
I think I started the discussion around product variants around 2017, and it took only six or seven years to roll out into production. It can happen that we’ve been discussing things over at Schema.org for quite a few years before they finally show up in Google Search.
Especially around product markup, that’s not easy because Google Shopping is technically a separate environment from Google Search. The moment they want to apply things from Google Shopping to Google Organic, they need to create new algorithms, new scripts, new testing tools, new testing features, new reports in Search Console, new Rich Results Test features, and so on.
It’s actually quite involved for them to align those specifications between organic search and Google Merchant Center feeds, especially because the format of a Merchant Center feed is very simple. It’s a flat table with columns and rows, while structured data isn’t that flat. It’s a graph, so it goes left, right, up, and down.
Gianluca Fiorelli: Yes, it’s more three-dimensional.
Jarno van Driel: Exactly. Translating one into the other isn’t always as easy as you think. And as they create new terms and new data shapes, we’re also trying to evaluate, “Okay, this is what we have now, but we’re going to create something new in the future. Are there any new things we need to take into account that aren’t part of Merchant Center either, but that need to be added to Schema.org now because we’re doing that and later they show up in the Merchant Center specifications?”
Gianluca Fiorelli: And it’s maybe even more important now that Google has started to anticipate in Merchant Center some properties related to a product that are not in Schema.org. This situation makes the consolidation of the data even more problematic.
Jarno van Driel: Years ago, it used to be more problematic than it is now because I remember a time when we had different structured data models on a page for Merchant Center while, at the same time, providing a second piece of markup specifically for Google Organic.
Since those two sides didn’t communicate with each other, the markup for Organic was causing errors for Merchant Center, and the markup for Merchant Center was causing errors in Google Organic. Those were really fun times.
Every step they take makes me happy because that’s one less obstacle in the way of actually doing it in markup.
Measure before you believe.
Advanced Web Ranking helps you measure the impact of structured data, semantic SEO, and AI optimization across both traditional search and AI search experiences. Try AWR free.
Do LLMs Actually Need Structured Data?
Gianluca Fiorelli: But returning to LLMs, not just Google, what is the biggest myth you see about the role of schema for LLM visibility?
Jarno van Driel: The stubborn, persistent idea that you need structured data markup—machine-readable markup—so you can serve those LLM machines. Nope.
Yes, it’s true that LLMs are "machines," but they are totally different types of machines. LLMs are machines that take natural language into account. That’s it. Structured data markup is created for RDF-based machines.
So, in an ideal world, structured data markup ends up in an RDF-based knowledge graph, which is a fancy word for a database. It’s just a database that works with triples instead of property-value pairs. That’s the main difference between RDF-based knowledge graphs and regular databases.
Structured data markup can be directly injected into that type of database. It’s an easy format to transport and move around. It’s instantly injectable and instantly readable, so it’s a very nice, clean, and practical format.
But LLMs don’t need that format. They’re not created to work with those formats. LLMs are created to deal with natural language.
Where structured data fits in—and that’s one of the things I’m very curious about—is something Andrea Volpini from WordLift is involved in.
I think in August or September there’s going to be a workshop or meetup for the W3C. GS1 is involved, and some people from Google are involved. They’re going to talk about creating a standard so that agents can navigate knowledge graphs.
In theory, if you currently give an agent a folder full of skills, you can relatively easily tell the agent, “Here are the skills. Go travel that knowledge graph.”
The problem is that there’s no standard surrounding that. You run the risk of every company creating its own skill sets and every company offering different solutions to help agents navigate knowledge graphs.
Andrea Volpini has run some experiments over the last couple of months that indicate that if you combine knowledge graphs with agents and LLMs, you can get up to an 80% lower error rate. That sounds interesting.
But for that, we need to have new standards. What I like about this is that people from companies such as Samsung and Siemens are also going to be involved in that debate. This is not just about Search. It’s an industry-wide and possibly a new international commerce method of exporting and transferring data. That’s going to be very interesting.
Should Businesses Invest in Agent Optimization Yet?
Gianluca Fiorelli: But there is a lack of a standard, or the standards are still works in progress. I’m thinking about the article you cited before about the Open Knowledge Format.
Jarno van Driel: Format.
Gianluca Fiorelli: Which is not even a standard. But many SEOs are talking as if WebMCP were already an established standard when it is still not a standard at all.
Jarno van Driel: It’s just a suggestion so far.
Gianluca Fiorelli: Yes. I can see people on LinkedIn or X, or in talks and so on, substantially recommending the implementation of WebMCP for everything that can be of agentic use.
From my personal point of view, test it, but in an area that is not so important at a business level. You can test it there and see how it works, whether it is really working, what the results are, and how you could eventually use it for other things in the future.
Always keep looking at how the suggested standard is evolving into a confirmed, accepted standard. But putting all your eggs in that basket is still too early.
Jarno van Driel: To be honest, my opinion about that is very pragmatic. Unless you have a lot of money to burn, stay away from it. From any form of agent optimization. If you don’t have money to waste, don’t get involved. Let the standards develop. It’s going to take quite some time.
We don’t even know which of the LLMs will survive in the coming years. Before going after UCP, AGP, ACP, or whichever standard or protocol you’re considering, stop and ask yourself, “Will this platform still exist in a couple of years? Will ChatGPT actually survive?”
Again, unless you have a lot of money to burn and it doesn’t really matter if you waste $100,000 here or there, it’s probably best not to get involved in those technologies until everything has been figured out over the next couple of years.
There’s a good chance that many of those standards will disappear or merge with other ideas. I think it’s too early for many businesses.
For example, if you’re a small e-commerce shop, you’re doing quite fine. I don’t like the Shopify platform, but that’s a different discussion. You’re quite safe sitting on Shopify. It works with Google and Bing, and they make it happen for you without requiring a huge investment.
Gianluca Fiorelli: Because UCP already exists for every Shopify website.
Jarno van Driel: The same thing applies to the average local business. Make sure your Google Business Profile is properly set up and that you actually use it and all the features it offers. If there’s anything agentic that needs to happen, Google will first plug it into a Business Profile to test it.
Gianluca Fiorelli: Yes, for calls and everything else.
Jarno van Driel: Instead of wasting a lot of resources on rolling out MCP, agentic standards, and everything else, hold on as a local business. Make use of your Google Business Profile. That’s probably where your return on investment lies. Anything else is for those who can afford to play around with it.
What I’m actually expecting, especially when you look at something like the Open Knowledge Format, is based on many use cases I’ve worked on in the past where structured data wasn’t important to the public. It was important for the internal processes of the business. We had reasons to create a new database system, data warehouse, or ERP system, and we based all of that on top of Schema.org.
The biggest motivators were internal reasons: making sure everybody in the business spoke the same business language, followed the same sales rules, and followed the same content guidelines. We had all kinds of reasons to make that investment, but none of them were related to Search.
For the Open Knowledge Format and many of these standards coming out now, I think the first use cases will mainly be internal and not so much about the agentic web. The agentic web sounds cool, but it doesn’t generate that much revenue yet. The majority of revenue still comes from traditional search.
Measure before you believe.
Advanced Web Ranking helps you measure the impact of structured data, semantic SEO, and AI optimization across both traditional search and AI search experiences. Try AWR free.
Internal Knowledge Graphs: The Real Business Opportunity
Gianluca Fiorelli: Yes, indeed. I think this can also be extended to the talk about knowledge graphs in the terms of internal knowledge graphs. A good implementation of schema with IDs or a graph already creates a sort of archetypal knowledge graph of a website.
When I talk about internal knowledge graphs, I usually give an example that I’ve also used in talks. Let’s say you are in e-commerce. You use your product catalog as the basis of your knowledge graph and then create all the things related to each product.
My classic example is Star Wars miniatures for painting. For instance, the miniature of Luke Skywalker represents Luke Skywalker, the character from Star Wars, directed by...and so on.
Doing this creates an internal knowledge graph that an organization can use for different types of things, starting with the simpler business side. For instance, with a knowledge graph, I can understand whether the warehouse in New York has this product or not, how to collect it, and many other things. But it can also free your mind and help you start seeing connections between things.
Jarno van Driel: I think one of the coolest internal knowledge graph projects I’ve been part of—where I didn’t do the technical side of things and mainly guided tons of different departments in the right direction and had to create some data shapes—was more about me running around the business and making sure everybody was kept up to speed.
If you work for an international organization with, let’s say, 15,000 staff, getting an up-to-date organigram out of a business is nearly impossible. But if you work in an international organization with 15,000 colleagues, finding the right person can be true hell.
There, an internal knowledge graph just for internal purposes, which is up-to-date and knows which departments exist where, which email addresses go with those departments, which staff work for those departments, and how you can reach those people, having that information up to date sounds like a no-brainer, but in the majority of large international organizations, it’s a crime to get your hands on the right person. It’s nearly impossible. So, an internal knowledge graph can be as simple as being able to generate an up-to-date organigram.
I’ve also used it for a customer service department that had a call registry system. We turned that call registry system into a knowledge graph so that it could not only serve customer service but also serve the website. We monitored the most frequently asked questions, and that determined the order of our FAQ pages based on the questions coming in by telephone. It was updated in real time.
There was no manual labor needed to get those questions onto the site. The question and answer were already in the call registry system, so we made them available to the website. But for that, they needed to be in a knowledge graph format.
There are many reasons why a knowledge graph can be very useful internally and can actually help companies make money without ever using it for search.
Gianluca Fiorelli: Yes. In fact, I think this case of FAQs was the kind of example I used when talking about creating an internal knowledge graph as a source of inspiration, because by doing so, you can see connections between things that are not immediately evident.
For instance, in miniature painting, a knowledge graph can show you the connection between the concept of a miniature and the concept of a paint recipe. A paint recipe tells you which colors to use and in what order to paint the miniature, just like a cooking recipe. That’s why we call it a recipe.
This is interesting because, using the knowledge graph, it’s very easy to understand the possible recipes. Because you know the recipes, you can understand what related colors you can put on the product detail page of a miniature.
If you want to paint this miniature, we can suggest this recipe. For instance, if you want to paint Rebel Commandos on Endor, you might use a tropical camouflage style, or for Scarif, like in Rogue One, a tropical beach or sandy camouflage style.
This is a very practical use of a knowledge graph. The problem is that creating a knowledge graph, even if it is theoretically simple because it consists of triples, it’s so expensive.
Jarno van Driel: It depends on the skill set of the developers involved. I think that’s one of the issues. The majority of businesses do not have somebody who is experienced with graph-based information. The average database engineer does not work with graph-based information. They still work with property-value pairs and tables.
First, there’s a lack of knowledge and developers who know how to work with it. Second, the majority of businesses do not have anybody internally championing a knowledge graph. That requires somebody in-house with enough understanding and vision to see how it could apply to the business, fight for it internally, and make it happen.
To be honest, there are simply not enough of us out there to make that happen. That’s one of the reasons why knowledge graph adoption rates have been lacking so far. There are not enough people out there who actually know how to do it. Here’s the fun part: that’s where LLMs can help close the gap.
Gianluca Fiorelli: How?
Jarno van Driel: The funny thing is that, in my LinkedIn feed, I also follow a whole bunch of knowledge graph engineers. One of the earliest changes I saw was that, in the past, people were very busy writing SPARQL queries. SPARQL is the RDF equivalent of MySQL queries. It’s also based on MySQL, so to speak.
Everybody was writing those queries manually. Now they’re using LLMs, writing in human language, and the LLM writes the query for them.
Gianluca Fiorelli: Yes.
Jarno van Driel: More and more knowledge engineers are using LLMs solely and having the entire technical query backend handled by agents and LLMs in a completely automated way.
Yes, it costs you some tokens, but if you cannot find the staff to do it for you, that’s an easy way to open up the technology without needing a huge new department to make it happen. It can be run by just a few people. Even people who only have a vague idea of what they want to do can already get very far with LLMs nowadays.
The Myth of "Schema Fairy Dust" and E-E-A-T
Gianluca Fiorelli: I want to recover one thing now, returning a little bit back in time with you. You have a personal website, and, joking in the email, I told you it is quite abandoned. I was looking for things you wrote to prepare this episode. On your personal website, there is only one article, but it’s very cool.
Jarno van Driel: It contains about as much as the average website does as a whole.
Gianluca Fiorelli: In this article, you talk about schema fairy dust, which is a wonderful definition, in relation to E-E-A-T. And before, off the record, we were talking about rel="author" back in the day.
At the end of the day, rel="author" is a type. I’m actually talking about the type. And now, when it comes to articles, blog posts, and so on, rel="author" is also suggested by LLMs. It’s one of the things. One is FAQ; the other one is HowTo, which has also been deprecated by Google.
Jarno van Driel: For years already.
Gianluca Fiorelli: Yes. And then there is the Author. Author can be Author, Person, Profile, or these kinds of things. But let’s say, Author.
What structural elements on a page can help a machine calculate the trustworthiness of an entity, which can be a person who is an author or a brand that is a publisher? I mean structural elements, in addition to many other things, such as backlinks, mentions, positive mentions, and all these kinds of things.
Jarno van Driel: To start off, and here we’re getting a little bit into speculation from my end, but I personally don’t believe trust can be based on any single page.
Gianluca Fiorelli: Right, I do too.
Jarno van Driel: That’s one of the main points I have in that ridiculously long story of mine: you should never trust what an author says based on a single publication. Search engines don’t do that either. Trust is based on aggregated information. The last person they trust is the author themselves. That’s the last entity in the chain they trust.
If you want to build trust, it’s based on the aggregated information about an entity out there. Then, at the end of the chain, they look at what the homepage or the entity home says about that person.
If that information coincides with the information aggregated on the web, then it forms a confirmation layer. That’s great because it gives the data and information your domain contains a little bit of extra trust.
Trust not as in, “I trust you with my wallet,” but trust as a data accuracy score. We can place greater mathematical trust in the accuracy of the information you provide because you generally provide information that coincides with the information the search engine finds on the web.
In that regard, you cannot base trust on anything a person says. You put your money where your mouth is. If the internet says it’s the case, then you’re probably well on your way.
The problem is that people are smart. They know how to fake online profiles. SEOs have mastered it over time. There are plenty of examples from throughout the years where people created entire fake profiles just to elevate trust, and only in very few cases did that actually make money. Generally speaking, the majority of these things cost a lot of money with a very low return on investment.
I’m not saying you cannot manipulate things. Obviously, everything can be manipulated, but the question is always whether the investment is worth the effort.
If you’re looking at on-page elements, nowadays I still think it’s very important, just as it was back in 1998 and the early 2000s when I worked on accessibility, to make sure you have proper semantic HTML. Why? If you have proper semantic HTML, there are gazillions of algorithms and scripts out there that can translate HTML into Markdown.
That type of information is being used by those same data consumers of your HTML.
Measure before you believe.
Advanced Web Ranking helps you measure the impact of structured data, semantic SEO, and AI optimization across both traditional search and AI search experiences. Try AWR free.
Writing for Accessibility Is Good SEO
Gianluca Fiorelli: I don’t think it’s a coincidence that Google, for the agentic part—and it is important sometimes to be precise and say this is documentation presented by Google developers on the agentic side of Google or Chrome, while this is documentation prepared and presented by the Search team, so they are two separate things.
The developers on the agentic side of Google and Chrome are now talking about accessibility. If I were betting on how many SEOs include an accessibility audit in their large, 50-page audits, surely it would be a single-digit percentage.
Now it’s coming out, and people will say, “You have to do it,” as if it were something new. We know it’s very painful. There are few crawlers that really help you perform this kind of audit.
A very simple example is when a web designer decides that something that should be a heading is not a heading, but bold text with a larger font. This is a classic example that disrupts the semantic sequence of a page. It could be an H2 or an H3. What is it?
Jarno van Driel: We’re going to go full circle to how I got into this stuff. When we talk about accessibility, nine times out of ten, the focus for SEOs—if they even look at it—is the technical side of accessibility.
Are we using a link instead of a button? Are we providing alt text? Are we providing descriptive alt text, not just some automated thing that doesn’t make sense for the image? But that’s all technicality. There’s a whole separate world to accessibility that is much more interesting, and that’s writing for accessibility.
That means making sure content is available to people who don’t necessarily have an IQ of 120 or speak that language as their primary language. There are many immigrants in this world.
So how do you keep a text easy to read while still conveying the information it needs to convey? That’s something I almost never see anybody talk about in the SEO world. I’ve seen some presentations about it throughout the years, one here and one there.
Gianluca Fiorelli: I think, for instance, that this last example is maybe something international SEOs are used to talking about because of localization. It’s something we are used to doing.
Will a New Vocabulary Replace Schema.org?
Gianluca Fiorelli: One last question. Apart from your daily work as an international structured data consultant, you are really involved in the Schema.org Foundation and so on.
What kind of evolution do you expect to see? I don’t want to look 10 years ahead, but over the next couple of years, will structured data become more important or less important? Will there be greater adoption?
What kind of evolution do you expect to see in the structured data semantic web landscape?
Jarno van Driel: One of the things I’ve been leaning towards over the last year is looking at Schema.org as a whole. Schema.org was designed for a different era. Schema.org was designed as a vocabulary for Search in an era when LLMs didn’t exist.
Even back then, if you look at around two-thirds of Schema.org, maybe even 75% of it, it was imagined in Schema.org version 0.9.
There was a very small group of people, one or two from each search engine, who created their part of the vocabulary because each of them had to provide some input. They imagined what the future would need.
We’re now 15 years later, and it has proven that predicting the future is very difficult, even for people who actually work at those search engines. In practice, two-thirds of the vocabulary ended up never being used. So I wouldn’t be surprised if we see a reset in the coming years.
I don’t necessarily see Schema.org disappearing, but I wouldn’t be surprised if a new vocabulary emerged, one that perhaps aligns better with the agentic web.
I’m saying that without seeing any objections right now. I don’t see any conversations where people are saying Schema.org doesn’t fit into the agentic web. I just think that the majority of it no longer serves a real-life purpose.
Gianluca Fiorelli: Interesting.
Jarno van Driel: I think we need more focus. In the end, describing everything with an ontology mostly serves internal purposes. But for Search, search engines and LLMs want to rely on natural language.
The focus will be even more on specific use cases for structured data. Right now, Google is busy translating Merchant Center into markup. I’m most curious to see what will happen when that exercise is done. Once Schema.org is up to date with what is possible in Merchant Center, I’m curious to see whether new things will emerge.
By that time, agentic shopping should also have crystallized. Then the question becomes: which other types of services and products will become part of the agentic web?
We can fill that out quite easily. It’s going to be travel. Food is probably another area, and clothing, although that more or less falls under e-commerce. Food probably still has a place there as well.
Gianluca Fiorelli: Google is always experimenting a lot with recipes.
Jarno van Driel: Yes, but not only recipes, but literally food-providing services, menus, and things like that. Agentic capabilities for those still seem to be just around the corner.
So I think the biggest question is: where will we see the agentic web move next? I think markup will follow that because it will serve that use case mostly.
Gianluca Fiorelli: I can also see another kind of use, which is maybe the classic problem of helping disambiguate entities. Because even natural language algorithms sometimes fail to understand whether you are talking about entity A or entity B when their names are written exactly the same.
This may happen because of the many things surrounding written content on a website. Maybe the context is hidden in JavaScript that is not rendered, so it isn’t seen, and there is no context, and so on.
There can be many fringe cases. So perhaps a classic property, one of the first and, for me, one of the most important properties of Schema.org, such as sameAs.
Jarno van Driel: The funny thing is that, and this may sound like I’m patting myself on the back, I’m one of the people who actually pioneered entity optimization.
And going back to 2013, 2014, I was running a case study, trying to resolve issues with Panda when even Google engineers no longer had an idea why a certain website was being hit. They couldn't make sense of why it was going up or down.
And then I got a request to try to resolve that issue with structured data. And my working theory back then, and we're talking about 2014, was that Google is getting confused in the details. It's not clear enough to them that this topic is a variant of that topic, and we're not talking about exactly the same thing on those pages.
So I used structured data and entity optimization to really dive into what this page is about versus what that page is about. And we're talking 2014. That was an era when Google engineers were also experimenting with markup. Why? It was new. They were trying to see what they could do with the markup people were putting out there.
So I think, for a part, that actually helped that website and that entire case study I presented around it back in 2015, because I was lucky Google engineers were playing around with this stuff. As of 2016, 2017, I already started noticing that the ROI no longer was there in that effort. Entity optimization, where, practically speaking, SEOs were turning keywords into entities. That's all they're doing really.
Google's NLP had become so good that it already crossed the 85% benchmark in accuracy. So you're talking about back in 2017, '18-ish, that Google was wrong in 15% of the cases. Why was it wrong? Not because it was missing markup, but because the entity involved didn't have a good enough digital footprint to be recognized as an entity.
And this is the same confusion that I still see SEOs make out there, where they go like, "Entity optimization markup needs to be very specific to explain what the topic is about." No, it's not needed. What is it? Google uses SameAs and identifiers to make sure that they understand they're talking about the right organization, the right place, the right person. They couldn't care less whether it's about checkers or chess.
You know, if your terminology is not clear enough to explain whether it's Puma shoes or puma the animal, then you've got some work to do on your prose.
Gianluca Fiorelli: Yes. I totally agree.
Jarno van Driel: In that regard, yes, I'm marginally somewhere there in the background. It does help Google recognize the entity you're talking about. I hate the word understand. So yes, it helps them recognize, but if you need that little bit extra to help Google understand and recognize what that page is about, you've probably got better things to work on than additional markup.
Gianluca Fiorelli: Yes. And I think that entity recognition and entity understanding are not just in the content itself on a page; they're also in how this content is linked and can be linked by other pieces of content inside the website and outside the website.
Continue the conversation about structured data with more episodes of The Search Session:
Andrea Volpini explores how structured data can support knowledge graphs, graph-based content workflows, and shared standards that allow AI agents and systems to exchange information more reliably.
Alex Moss looks at Schema beyond rich results, explaining how structured data and strong content governance can clarify entities and relationships, reduce semantic drift, and prepare websites for emerging agentic use cases.
Gianluca Fiorelli: Jarno, in one hour and six minutes, it's wow.
Jarno van Driel: Oh, wow. That went fast.
Gianluca Fiorelli: Let's stop it here. But before, when you are not thinking about structured data and designing graphs in your head, what do you like to do?
Jarno van Driel: I'm a big fan of following certain Twitch in YouTube streams. And, unfortunately, because of my three fingers, I cannot use a game controller properly. In my mind, I'm a big gamer still, but unfortunately, physically, I cannot play a lot of games. So instead of gaming myself, I spend time following certain streamers that actually play games that I like as an alternative to being able to play them myself.
Gianluca Fiorelli: Oh, well, maybe in the future, one evolution of a technology would be to play by just looking with the eyes or something else.
Jarno van Driel: Yes, but you know, there's a certain billionaire out there called Elon Musk that's working on a neurological interface, but I'm not sure how much I trust Elon.
Gianluca Fiorelli: Yes, I'm not really a fan of a neuromancer perspective since I wouldn't like to have a chip from a private company in my head.
Jarno van Driel: Exactly.
Gianluca Fiorelli: Okay. Thank you, Jarno. It was a real pleasure to have you here. Let's see, maybe in the future to organize something else, maybe a panel with other ontologies and lovers os semantic search.
Jarno van Driel: Oh, that'd be cool.
Gianluca Fiorelli: Thank you again.
Jarno van Driel: You’re welcome. Thank you for having me.
Gianluca Fiorelli: And thanks to everybody who has watched us until now. Remember to subscribe to the channel, The Search Session, on YouTube but also on Apple Podcasts and Spotify, and to ring the bell so you will be notified of the new episodes when they come out. Thank you and bye-bye.
Podcast Host
Gianluca Fiorelli
With almost 20 years of experience in web marketing, Gianluca Fiorelli is a Strategic and International SEO Consultant who helps businesses improve their visibility and performance on organic search. Gianluca collaborated with clients from various industries and regions, such as Glassdoor, Idealista, Rastreator.com, Outsystems, Chess.com, SIXT Ride, Vegetables by Bayer, Visit California, Gamepix, James Edition and many others.
A very active member of the SEO community, Gianluca daily shares his insights and best practices on SEO, content, Search marketing strategy and the evolution of Search on social media channels such as X, Bluesky and LinkedIn and through the blog on his website: IloveSEO.net.
