Like a lot of people, I watched the AI boom closely. I paid attention to the hype, the risks, the ethics. Internally, we talked a lot about how AI might change how we work. What I wasn’t focused on enough was how fast it was changing how students search.
That gap became obvious the day a client asked me, very plainly: “What are you doing about AI?”
I gave a thoughtful answer. It just wasn’t the right one.
What they were really asking was how we were preparing for a world where prospective students start their college search with AI, not Google, and not a university website.
I didn’t have a good answer. So I did what I usually do and went down a few deep rabbit holes.
The good news: I came back with the beginnings of one.
One of the most important pieces of a real GEO strategy turns out to be something unglamorous but critical: schema. You hear that a lot right now, “Add schema.” But no one really explains what that means or how to do it well.
That’s what this article is about. Explaining schema in plain English, and why it matters for higher ed websites trying to stay visible in an AI-driven world.
What is a Schema? What does it do?
Schema is structured data that describes what the content on a web page represents, using a shared vocabulary defined by Schema.org.
Sorry, are any of you still awake? That sounds very clinical and dry, doesn’t it?
Let me start again. Schema is a little block of code that is aimed at machines (like AI), not people, which explicitly tells those machines the context for the content on that page, rather than hoping that it will guess correctly.
Think of schema as the difference between writing something clearly and making sure a machine understands what you meant.
When you write a web page, humans can usually tell what it’s about. A page titled “Biology, BS” with course lists, faculty names, and career outcomes clearly reads as an academic program to a person.
To a machine, though, it’s just a pile of headings, paragraphs, and links.
Schema is a way to tell that machine, explicitly:
“This page isn’t just content. It represents an undergraduate degree program in biology, offered by this institution, leading to a Bachelor of Science.”
If you want AI to accurately reflect the intent of the content on your website, providing effective schema is a great way to accomplish that. If you want AI to give people an accurate view into your offerings and differentiators, you are going to want to put schema blocks on your pages.
Schema vs Metadata
If this sounds a lot like HTML page metadata, you’re not wrong. There’s overlap, but they serve different purposes.
Metadata is information about the page itself, mostly intended for browsers, search engines, and social platforms. It helps control how a page is indexed or displayed, but it doesn’t reliably describe what the content actually is. It also doesn’t express relationships, entities, or intent in a structured way.
That’s where schema comes in. Schema tells AI systems what a page represents. Using commonly accepted schema types published at Schema.org, you can explicitly identify which pages represent your institution, which describe academic programs, which are faculty profiles, which are events, and so on.
So when a prospective student asks an AI assistant whether your school offers a chemical engineering program, the AI doesn’t have to guess. It can answer with accuracy and confidence.
Schema.org
If you head over to Schema.org, you’ll find extensive documentation covering hundreds of different schema types. And yes, it’s a lot. Most of them are things you’ll never use on a higher ed website, and none of it is particularly higher-ed specific. It can feel overwhelming very quickly.
If your reaction is, “Do I really have to use this?” that’s a fair question.
The short answer is: Yes, if you want AI systems to reliably understand your content. Right now, schema.org is the standard those systems recognize.
The good news is that you don’t need to use much of it. A relatively small set of well-chosen schema types will get you most of the value, and fast.
What schema types are most impactful for higher ed websites?
As you look through these schema types and the pages they are recommended for, you may ask: should I or should I not put more than one of these on a page? The answer is, you definitely should put more than one on a page if they are relevant and will be kept up to date as the page content is updated.
On the other hand, don’t use schema types where they may suddenly fall out of date, and therefore inaccurate. It’s better to leave it out than have it be incorrect.
(Note: You may notice some overlap here. That’s because CollegeOrUniversity is a subtype of Organization. In most cases, you’ll want both, but you should treat CollegeOrUniversity as the primary representation of your institution.)
Example (this script would go in the <HEAD> area of the page):
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "EducationalOccupationalProgram",
"name": "Bachelor of Arts in Basketweaving",
"description": "An undergraduate Bachelor of Arts program in Basketweaving focusing on traditional and contemporary weaving techniques, design principles, and materials studies.",
"educationalCredentialAwarded": "Bachelor of Arts",
"educationalLevel": "Undergraduate",
"timeRequired": "P4Y",
"provider": {
"@type": "CollegeOrUniversity",
"name": "Digital Wave University",
"url": "https://www.digitalwaveuniversity.edu"
},
"url": "https://www.digitalwaveuniversity.edu/academics/undergraduate-programs/ba-basketweaving/"
}
</script>
Any web page that includes an FAQ block (and only where those FAQs are visible on the page)
Example (this script would go in the <HEAD> area of the page):
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Does Digital Wave University offer online degree programs?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. Digital Wave University offers a selection of undergraduate and graduate degree programs that can be completed fully online or in a hybrid format."
}
},
{
"@type": "Question",
"name": "Is Digital Wave University accredited?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. Digital Wave University is accredited by a recognized regional accrediting agency."
}
},
{
"@type": "Question",
"name": "Where is Digital Wave University located?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Digital Wave University is located in Philadelphia, Pennsylvania, with both on-campus and online learning options available."
}
},
{
"@type": "Question",
"name": "How do I apply to Digital Wave University?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Prospective students can apply through the Digital Wave University website by completing the online application and submitting the required materials."
}
}
]
}
</script>
Additional Optional Types
There are a few other schema types that you may or may not elect to include. When deciding whether or not to include them, try to balance what the relative gain might be versus how challenging it will be to keep it properly synchronized.
You can use the Event type for any actual events with dates, times, and locations that you keep up to date.
You can use Person for leadership or faculty bios, but you should only do so if the bios will be consistently maintained, meaning the information they contain will stay accurate accurate, match what is visible on the page, is reviewed at least once per academic year, and is updated whenever time-sensitive content changes. If you cannot guarantee that level of care for a field, it is better to omit it than let it become outdated.
You can use Course for course description pages, but you should only do so if they will remain accurate over time.
Validation
Okay. You have injected Schema blocks into all of the pages of your site. How do you know if you are doing it right? Once again, Schema.org comes to your rescue.
The Schema.org site has a validator available (https://validator.schema.org/) to test your pages. You can even copy and paste code snippets into it to validate them before you place them on your page. Every code snippet that I included in this article was manually validated by Schema.org before inclusion.
Conclusion
While this is far from a comprehensive overview of how to incorporate Schema types into your site, hopefully my article has at least somewhat demystified this one aspect of optimizing your site for AI. This won’t make your site “AI-proof,” but it will make it legible. And in a world where AI is increasingly doing the reading for your prospective students, that’s no longer optional.
With his skill in envisioning how a design will both work for the end-user and interact with the backend, Bruce oversees application architecture and database design. He’s a key Content Management System (CMS) consultant, specializing in CMS selection, build-out, and training.
Posted on February 11, 2026 by Bruce Cronlund in Commentary
I was late to the Generative Engine Optimization (GEO) conversation. Embarrassingly late.
Like a lot of people, I watched the AI boom closely. I paid attention to the hype, the risks, the ethics. Internally, we talked a lot about how AI might change how we work. What I wasn’t focused on enough was how fast it was changing how students search.
That gap became obvious the day a client asked me, very plainly: “What are you doing about AI?”
I gave a thoughtful answer. It just wasn’t the right one.
What they were really asking was how we were preparing for a world where prospective students start their college search with AI, not Google, and not a university website.
I didn’t have a good answer. So I did what I usually do and went down a few deep rabbit holes.
The good news: I came back with the beginnings of one.
One of the most important pieces of a real GEO strategy turns out to be something unglamorous but critical: schema. You hear that a lot right now, “Add schema.” But no one really explains what that means or how to do it well.
That’s what this article is about. Explaining schema in plain English, and why it matters for higher ed websites trying to stay visible in an AI-driven world.
What is a Schema? What does it do?
Schema is structured data that describes what the content on a web page represents, using a shared vocabulary defined by Schema.org.
Sorry, are any of you still awake? That sounds very clinical and dry, doesn’t it?
Let me start again. Schema is a little block of code that is aimed at machines (like AI), not people, which explicitly tells those machines the context for the content on that page, rather than hoping that it will guess correctly.
Think of schema as the difference between writing something clearly and making sure a machine understands what you meant.
When you write a web page, humans can usually tell what it’s about. A page titled “Biology, BS” with course lists, faculty names, and career outcomes clearly reads as an academic program to a person.
To a machine, though, it’s just a pile of headings, paragraphs, and links.
Schema is a way to tell that machine, explicitly:
“This page isn’t just content. It represents an undergraduate degree program in biology, offered by this institution, leading to a Bachelor of Science.”
If you want AI to accurately reflect the intent of the content on your website, providing effective schema is a great way to accomplish that. If you want AI to give people an accurate view into your offerings and differentiators, you are going to want to put schema blocks on your pages.
Schema vs Metadata
If this sounds a lot like HTML page metadata, you’re not wrong. There’s overlap, but they serve different purposes.
Metadata is information about the page itself, mostly intended for browsers, search engines, and social platforms. It helps control how a page is indexed or displayed, but it doesn’t reliably describe what the content actually is. It also doesn’t express relationships, entities, or intent in a structured way.
That’s where schema comes in. Schema tells AI systems what a page represents. Using commonly accepted schema types published at Schema.org, you can explicitly identify which pages represent your institution, which describe academic programs, which are faculty profiles, which are events, and so on.
So when a prospective student asks an AI assistant whether your school offers a chemical engineering program, the AI doesn’t have to guess. It can answer with accuracy and confidence.
Schema.org
If you head over to Schema.org, you’ll find extensive documentation covering hundreds of different schema types. And yes, it’s a lot. Most of them are things you’ll never use on a higher ed website, and none of it is particularly higher-ed specific. It can feel overwhelming very quickly.
If your reaction is, “Do I really have to use this?” that’s a fair question.
The short answer is: Yes, if you want AI systems to reliably understand your content. Right now, schema.org is the standard those systems recognize.
The good news is that you don’t need to use much of it. A relatively small set of well-chosen schema types will get you most of the value, and fast.
What schema types are most impactful for higher ed websites?
As you look through these schema types and the pages they are recommended for, you may ask: should I or should I not put more than one of these on a page? The answer is, you definitely should put more than one on a page if they are relevant and will be kept up to date as the page content is updated.
On the other hand, don’t use schema types where they may suddenly fall out of date, and therefore inaccurate. It’s better to leave it out than have it be incorrect.
Organization
Example (this script would go in the <HEAD> area of the page):
CollegeOrUniversity
(Note: You may notice some overlap here. That’s because CollegeOrUniversity is a subtype of Organization. In most cases, you’ll want both, but you should treat CollegeOrUniversity as the primary representation of your institution.)
Example (this script would go in the <HEAD> area of the page):
Website
Example (this script would go in the <HEAD> area of the page):
BreadcrumbList
Example (this script would go in the <HEAD> area of the page):
EducationalOccupationalProgram
Example (this script would go in the <HEAD> area of the page):
FAQPage
Example (this script would go in the <HEAD> area of the page):
Additional Optional Types
There are a few other schema types that you may or may not elect to include. When deciding whether or not to include them, try to balance what the relative gain might be versus how challenging it will be to keep it properly synchronized.
You can use the Event type for any actual events with dates, times, and locations that you keep up to date.
You can use Person for leadership or faculty bios, but you should only do so if the bios will be consistently maintained, meaning the information they contain will stay accurate accurate, match what is visible on the page, is reviewed at least once per academic year, and is updated whenever time-sensitive content changes. If you cannot guarantee that level of care for a field, it is better to omit it than let it become outdated.
You can use Course for course description pages, but you should only do so if they will remain accurate over time.
Validation
Okay. You have injected Schema blocks into all of the pages of your site. How do you know if you are doing it right? Once again, Schema.org comes to your rescue.
The Schema.org site has a validator available (https://validator.schema.org/) to test your pages. You can even copy and paste code snippets into it to validate them before you place them on your page. Every code snippet that I included in this article was manually validated by Schema.org before inclusion.
Conclusion
While this is far from a comprehensive overview of how to incorporate Schema types into your site, hopefully my article has at least somewhat demystified this one aspect of optimizing your site for AI. This won’t make your site “AI-proof,” but it will make it legible. And in a world where AI is increasingly doing the reading for your prospective students, that’s no longer optional.
Tagged With These Topics
About Bruce Cronlund
With his skill in envisioning how a design will both work for the end-user and interact with the backend, Bruce oversees application architecture and database design. He’s a key Content Management System (CMS) consultant, specializing in CMS selection, build-out, and training.