Chapter 4: Why Your Website Isn't Enough (Understanding Structured Data)
In the last chapter, I told you how I spent 2024 building human-readable solutions to my disambiguation problem --- a links page, a name disambiguation page --- before stumbling into the realization that machines had their own language for everything I'd been doing in English.
Now it's time to learn that language.
This chapter is the technical foundation of the book. If Chapter 3 was the "why," this is the "how." I'm going to show you exactly what structured data looks like, how it works, and what it does for your digital identity. Some of it will involve code. Don't let that scare you. You don't need to be a developer to implement this. You just need to understand what you're looking at and why it matters.
• • •
The Problem With Letting Google Figure It Out
Here's what most people don't realize: Google is always building a profile of you, whether you help or not.
It crawls your website. It indexes mentions of your name. It looks at social media profiles, directories, articles, and any other place your name appears. Then it tries to assemble all of that into a coherent picture of who you are and what you do.
Sometimes Google gets it right.
Sometimes it doesn't.
And as we've already established, when you share a name with a comedian, a rapper, and a fictional character, Google's guessing game becomes a real problem. Without structured data, you're leaving your digital identity up to interpretation.
Google might confuse you with someone else who shares your name. It might show incomplete or outdated information about your career. It might fail to connect you to the organizations you lead or the work you've done. Or it might present you as "one of several possibilities" instead of the definitive result.
That ambiguity costs you visibility, credibility, and opportunities.
Structured data is how you stop leaving it to chance.
• • •
What Structured Data Actually Looks Like
I introduced Schema.org in the last chapter --- the shared vocabulary that Google, Microsoft, Yahoo, and Yandex created in 2011 so that website owners could communicate with search engines in a language machines actually understand. Now let's look at what that communication actually looks like in practice.
Structured data is a way of formatting information so that machines can process it without having to interpret human language. Instead of writing "Kenny Kane is a CEO in Austin, Texas" in paragraph form on your About page, you mark that information up in code:
{ "@context": "https://schema.org", "@type": "Person", "name": "Kenny Kane", "jobTitle": "Chief Executive Officer", "worksFor": { "@type": "Organization", "name": "Firmspace" }, "address": { "@type": "PostalAddress", "addressLocality": "Austin", "addressRegion": "TX" } }
This is JSON-LD, the format Google prefers for structured data. It's placed in the <head data-preserve-html-node="true"> section of your website, invisible to human visitors but completely readable by search engines.
When Google crawls your site and finds this markup, it doesn't have to guess. It knows your name is Kenny Kane, your role is Chief Executive Officer, you work for an organization called Firmspace, and you're based in Austin, Texas.
No ambiguity. No interpretation. Just facts.
If that code block looks intimidating, I get it. I'm not a developer either. But here's what I want you to understand: you don't need to write this from scratch. Most website platforms (WordPress, Squarespace, Wix) have plugins or built-in tools that generate schema markup for you. What matters is knowing what information needs to be there and why. The code is just the container.
• • •
The Schema Types That Matter for Your Identity
Schema.org has grown to over 800 types since its launch. Most of them --- Product, Recipe, Event, LocalBusiness --- are designed for businesses and commerce. But a handful of types are directly relevant to individuals building a professional presence online.
Person Schema
This is your foundation. It defines who you are, what you do, where you're located, and how you're connected to the broader web. At minimum, your Person schema should include your name, job title, employer, location, and links to your other profiles online.
Organization Schema
This connects you to the companies, nonprofits, or projects you lead or work for. When your Person schema references an Organization that has its own established web presence, you're not just claiming a title --- you're linking your identity to a verified entity.
Article and BlogPosting Schema
These mark up your published writing so search engines understand authorship. Every blog post or article on your site should have schema that identifies you as the author. This builds a pattern over time: Google begins to associate your name with published expertise in specific topics.
SameAs Property
This is one of the most important properties for disambiguation. It's a list of URLs that all represent the same person --- you. Your LinkedIn, your Crunchbase page, your Amazon author profile, your X, your Wikidata entry. Each one tells search engines: "All of these pages are about the same Kenny Kane."
When you implement these correctly, you're not just optimizing for search rankings. You're building a knowledge graph --- a web of connections that tells search engines exactly who you are and how you fit into the broader digital ecosystem.
• • •
Why Location Matters More Than You Think
One of the simplest but most powerful things you can add to your structured data is geographic information.
I mentioned this briefly in the last chapter, but it deserves its own section because most people overlook it entirely.
For me, that meant explicitly stating: Austin, Texas.
The comedian Kenny Kane is in Los Angeles. The rapper Kenny Kane is in Memphis. I'm in Austin. That single data point --- my location --- immediately differentiates me from the other people who share my name.
Location isn't just a detail. It's context. It tells search engines where you operate, what markets you're connected to, what communities you're part of, and what local coverage might reference you.
When someone searches "Kenny Kane Austin" or "Austin CEO," I want to be the definitive result. And when Google is trying to decide which Kenny Kane someone is looking for, having clear geographic data helps it make the right choice.
Location also supports other parts of your digital presence. If you're speaking at events, getting media coverage, or working with local organizations, that geographic context reinforces the connection. It's one more signal that says, "This is the Kenny Kane who's based here, who works in these industries, and who leads these companies."
If you take nothing else from this chapter, add your city and state to your schema markup. It's five minutes of work that does more for disambiguation than a dozen blog posts.
• • •
The DisambiguatingDescription Property
In Chapter 3, I told you how I'd built a disambiguation page on my website --- writing in plain English which Kenny Kane I was and which ones I wasn't. What I didn't know at the time was that Schema.org had a property designed for exactly this purpose.
It's called disambiguatingDescription, and it does precisely what the name suggests. It's a short, structured statement that clarifies who you are when your name might be confused with someone else's.
Here's what mine looks like in code:
{ "@type": "Person", "name": "Kenny Kane", "disambiguatingDescription": "American business executive, CEO of Firmspace and Testicular Cancer Foundation, author of The Accidental Nonprofiteer" }
That one sentence does enormous work. It immediately distinguishes me from the comedian and the rapper (and the fictional character). It highlights my primary roles and credentials. And it gives search engines a clear, machine-readable way to categorize me.
Disambiguation isn't just for people with common names. It's for anyone whose identity might overlap with someone else in search results. If you work in a crowded industry, share a name with another public figure, have a career that spans multiple fields, or want to ensure you're recognized for specific work --- this property helps search engines show the right version of you in the right context.
Think of it as the elevator pitch that only machines hear.
• • •
Connecting to Authority
The most valuable thing structured data does is connect you to entities that already have authority in Google's knowledge graph.
This is where structured data goes from useful to powerful.
For me, that means linking to Firmspace (which has its own Wikipedia page), the Testicular Cancer Foundation (an established nonprofit with significant digital presence), Gryt Health (a health tech company with a Crunchbase profile), my books on Amazon and Goodreads, and my profiles on LinkedIn and Crunchbase.
Each of these connections is a signal. It tells search engines that I'm not just claiming to be a CEO or author. I'm verifiably connected to organizations and platforms that validate those claims.
Here's what that looks like in practice:
{ "@type": "Person", "name": "Kenny Kane", "sameAs": [ "https://www.wikidata.org/wiki/Q137101943", "https://www.google.com/search?kgmid=/g/11gbhmd9kg", "https://www.linkedin.com/in/kenny-kane", "https://twitter.com/kennykane", "https://www.instagram.com/kennykane", "https://www.amazon.com/author/kennykane", "https://www.crunchbase.com/person/kenny-kane" ], "worksFor": [ { "@type": "Organization", "name": "Firmspace", "sameAs": "https://en.wikipedia.org/wiki/Firmspace" }, { "@type": "Organization", "name": "Testicular Cancer Foundation", "sameAs": "https://www.testicularcancer.org" } ] }
Notice the sameAs property connecting me to my Wikidata entry, my Knowledge Graph ID, and every major platform where I have a verified presence. And notice how each organization I work for has its own sameAs linking to its most authoritative source.
The more authoritative connections you can establish in your schema, the stronger your knowledge graph becomes. You're not building in isolation. You're plugging into a web of verified entities that Google already trusts.
This is also why the work you do in Chapters 5 and 6 matters so much. Publishing books creates Amazon and Goodreads author pages. Building a Wikidata entry creates a verified entity in the knowledge graph. Each one becomes a node you can connect to from your schema, and each connection makes the whole system stronger.
• • •
Why This Matters for AI-First Search
Here's something most people don't think about yet: structured data isn't just for Google anymore.
AI-powered search engines like ChatGPT, Claude, Perplexity, and You.com are increasingly important in how people discover information. And these systems rely heavily on structured data to generate answers.
When someone asks an AI, "Who is Kenny Kane?" I want the response to be clear and accurate. Not a guess. Not a blend of multiple people. Just me.
Structured data is how you ensure AI systems have the right information to work with. It's how you make sure that when these tools pull facts about you, they're pulling from authoritative, verified sources rather than making inferences based on incomplete data.
This shift toward AI-first search makes structured data more important than ever. Traditional SEO focused on ranking in the top 10 blue links. AI-first search focuses on being cited as the authoritative answer. And the systems generating those answers are built to consume exactly the kind of machine-readable, structured information we're talking about in this chapter.
Structured data is how you become the answer, not one of several possibilities.
• • •
What You Need on Your Website
If you're ready to implement this (and you should be), here's what it actually looks like in practice.
Minimum Viable Schema (start here):
Person schema with your name, roles, and location. Organization schema for companies you lead or work for. SameAs links to your social profiles and author pages. A disambiguatingDescription if you share a name with anyone else online.
Advanced Schema (for stronger presence):
Your Knowledge Graph ID (if you have one --- we'll cover how to find this). Your Wikidata ID (once you create an entry, which is the next chapter). Author markup on every blog post. Article schema for all published work. BreadcrumbList schema for site navigation. ContactPoint for official contact information.
You can implement schema manually by adding JSON-LD to your site's <head data-preserve-html-node="true"> section, or use plugins if you're on WordPress or other CMS platforms. Squarespace (which I use) has built-in options for basic schema and allows custom code injection for more advanced markup. The key is making sure the information is accurate, complete, and consistent with what appears elsewhere on the web.
Validation tools you should use:
Google's Rich Results Test will show you what Google can extract from your markup. The Schema.org Validator checks your code against the official specification. Google Search Console's structured data report shows you ongoing issues and coverage.
Run your site through these after every update. Errors in your schema are worse than no schema at all --- they tell Google your information is unreliable.
• • •
Common Mistakes to Avoid
Inconsistent information. If your schema says you're in Austin but your LinkedIn says you're in New York, search engines don't know which to trust. Consistency across all platforms is critical. Before you implement schema, audit every profile you have and make sure the basics --- name, title, location, employer --- match everywhere.
Overstating your credentials. Don't claim roles or achievements you can't verify. Search engines cross-reference your schema with other sources. If the information doesn't match, it hurts your credibility rather than helping it.
Using outdated schema types. Schema.org evolves. The vocabulary that was current three years ago may have been superseded by better, more specific properties. Check the Schema.org documentation when you're implementing to make sure you're using current types and formats.
Not connecting to authoritative entities. Simply listing "CEO" as your job title isn't as powerful as linking to the organization's official website, Wikidata entry, or Wikipedia article. Authority comes from connections, not claims.
Forgetting to update. Your schema should evolve as your career does. New job? Update it. Published a book? Add it. Changed locations? Reflect that. Stale schema is almost as bad as no schema --- it tells search engines your information may not be current.
• • •
The Foundation for Everything That Follows
Implementing structured data won't make you go viral. It won't generate instant traffic. It's not a silver bullet.
But it does something more valuable: it gives you control over how machines understand your identity.
In a world where search engines decide what shows up when people look for you, where AI systems determine how you're described and cited, where Knowledge Panels shape first impressions, and where ambiguity costs you opportunities --- structured data is one of the few things you can control directly.
You can't control how other sites link to you. You can't control how algorithms rank your content. But you can control the information you provide about yourself. You can make sure that when search engines and AI systems are trying to figure out who you are, they have all the context they need to get it right.
This chapter gave you the vocabulary and the framework. The next chapter gives you the case study.
In Chapter 5, I'll walk you through exactly how I took everything we've discussed here and built a complete Wikidata entry, a Google Knowledge Graph connection, and a validation loop across three platforms --- all in a single day. Not the theory. The actual project, hour by hour.
The technical foundation is set. Now let's build on it.
• • •