Chapter 12: Disambiguation Maintenance
Here's a confession: I don't have a disambiguation maintenance schedule.
After everything I've described in this book --- the structured data, the Wikidata entry, the Knowledge Panel, the blog, the cross-linked ecosystem --- you might expect me to have a weekly routine. A checklist I run through every Monday. A spreadsheet tracking the health of each platform connection.
I don't.
And that's actually the point.
If you build the system well, maintenance is light. The infrastructure I described in Chapters 4 and 5 --- schema markup, Wikidata, the validation loop --- is designed to be durable. It doesn't break because you didn't check it for a month. It doesn't decay because you took a week off from blogging.
My roles don't change often. I've been CEO of Firmspace and the Testicular Cancer Foundation for years. I've been CTO of Gryt Health for years. My address hasn't changed. My education hasn't changed. The core facts of my professional identity are stable.
And that stability is reflected in the infrastructure. My schema markup says the same thing it said when I first implemented it because the underlying reality hasn't changed. My Wikidata entry has the same properties because the facts are the same.
That's not neglect. That's a system working as designed.
• • •
When Maintenance Actually Matters
That said, the system isn't "set it and forget it." There are specific events that should trigger an update. If you build the ecosystem described in this book, here's what to watch for.
A role change. If you get a new job, leave a company, add a board position, or take on a new title, your structured data needs to reflect that. Update your schema markup's jobTitle and worksFor properties. Update your Wikidata entry with the new position (and an end date for the old one). Update your LinkedIn. Update your website's about page. The whole point of the system is consistency across platforms --- when one thing changes, everything needs to match.
A new publication. When I published Mission-Driven Ecommerce, I needed to add a new Book entity to my schema markup, create a landing page on my website, add the book to my Wikidata entry with proper citations, and update my Amazon and Goodreads profiles. Each book strengthens the ecosystem, but only if it's properly connected.
A new organization or entity. If you start a company, launch a nonprofit, or join an organization that has its own digital presence, you may need to create a Wikidata entity for that organization and link it to your personal entry. My Wikidata entry connects to separate entities for Firmspace, TCF, and Gryt Health. If I started a fourth organization, I'd create its entity and add the connection.
A factual correction. If someone edits your Wikidata entry with inaccurate information, or if Google's Knowledge Panel displays something incorrect, you need to catch it and fix it. This is rare, but it happens. Wikidata is publicly editable, which means someone could theoretically add incorrect properties to your entry.
A platform change. If you move your website to a new domain, change your social media handles, or if a platform you're linked to shuts down, your sameAs properties need updating. Dead links in your structured data are worse than no links --- they signal to machines that your information is stale.
A new Kenny Kane. Or whoever shares your name. The disambiguation landscape isn't static. New people with your name will emerge over time --- new professionals, new public figures, new content creators. Your system is designed to differentiate you from them, but if a new namesake becomes prominent, you may want to update your disambiguatingDescription or add additional clarity to your structured data.
• • •
The Minimum Viable Maintenance Routine
If you want a schedule, here's what I'd recommend. It's not what I do religiously, but it's what I'd tell someone who wants to be thorough.
After every major life or career event:
Update your schema markup, Wikidata entry, LinkedIn, and website. Don't wait. The longer your platforms are inconsistent, the longer machines are learning the wrong information about you.
Quarterly:
Ask AI systems about yourself. Open ChatGPT, Claude, and Perplexity and ask them who you are, what you do, and what organizations you're associated with. Compare the answers to reality. If something's wrong or missing, trace it back to the source --- is your Wikidata entry incomplete? Is your schema markup out of date? Is there conflicting information on a platform you don't control?
Check your Wikidata entry for unauthorized edits. It takes two minutes. Log in, look at the revision history, make sure nothing has been changed that shouldn't have been.
Run your website through Google's Rich Results Test to make sure your structured data is still valid. Schema.org occasionally updates its types and properties. What was valid a year ago should still be valid, but it's worth confirming.
Monthly:
Check Semrush or your preferred SEO tool for AI visibility trends. Are you still showing up? Are there new topics or prompts where you're being cited --- or where you should be?
Review your Google Search Console data. Are the search queries that lead to your site still aligned with your professional identity?
Ongoing:
Keep blogging about real work. The blog is the most dynamic part of the ecosystem. Everything else --- structured data, Wikidata, schema markup --- is relatively static. The blog is where new signals enter the system. Each post feeds the search engines, gives AI systems fresh content to index, and keeps your hub active.
• • •
The Durability Advantage
One of the best things about the infrastructure this book describes is how durable it is compared to the alternatives.
Social media requires constant feeding. Stop posting on LinkedIn for a month and the algorithm forgets you exist. Stop tweeting for a week and your visibility drops to zero. Social platforms are designed to reward recency and frequency, which means they demand ongoing effort just to maintain your baseline.
Structured data doesn't work that way. Once your schema markup is on your site, it stays there. Google reads it every time it crawls your page. AI systems reference it every time they need to understand who you are. It doesn't decay because you didn't post this week.
Wikidata doesn't work that way either. Your entry persists indefinitely. It's referenced by Google's Knowledge Graph, by AI systems, by other databases and platforms. It doesn't lose relevance because you didn't log in recently.
Your blog posts are permanent. A post you wrote six months ago still ranks in search, still gets cited by AI systems, still draws traffic from people who find it through discovery. Unlike a social media post that disappears from feeds within hours, a blog post on your domain compounds over time.
That durability is the whole point. You're building infrastructure, not running a content treadmill. The system works when you're not actively tending it because it's designed to be persistent, machine-readable, and self-reinforcing.
• • •
When to Worry
There are a few scenarios where you should actively intervene rather than trusting the system to run on its own.
AI systems start getting you wrong. If ChatGPT suddenly attributes your work to someone else, or confuses you with another person who shares your name, something has changed in the source material. Investigate. Has a competing source published conflicting information? Has your Wikidata entry been edited? Has a prominent website associated your name with someone else?
Your Knowledge Panel disappears. This can happen if Google re-evaluates the data supporting your panel. If it vanishes, check your structured data validation, make sure your Wikidata entry is intact, and verify that the cross-references between your platforms are still working.
A namesake becomes more prominent. If another person with your name suddenly gains significant public attention --- launches a viral product, appears in major media, runs for office --- your disambiguation infrastructure will be tested. This is when the disambiguatingDescription property and the specificity of your structured data earn their keep. You shouldn't need to rebuild anything, but you may want to strengthen the signals that differentiate you.
You change industries or pivot your career. A major professional shift requires more than a schema update. You'll need to rebuild parts of your narrative --- new blog posts establishing authority in the new field, updated Wikidata properties, potentially new organizational connections. The infrastructure supports the pivot, but the content needs to reflect the new reality.
• • •
The Maintenance Mindset
The real maintenance isn't technical. It's philosophical.
It's remembering that your digital identity is a living thing, even when the infrastructure is durable. The facts may not change often, but the context does. New technologies emerge. New platforms gain relevance. New ways of discovering people replace old ones.
Five years ago, nobody was optimizing for AI citation. Ten years ago, nobody had heard of Wikidata outside of the developer community. Twenty years ago, the biggest digital identity decision was whether to register your exact-match domain.
The infrastructure I've described in this book will remain relevant for years. Structured data isn't going away. Knowledge graphs aren't going away. The principle that machines need clear, consistent, machine-readable information to understand who you are --- that's permanent.
But the specific tactics will evolve. New schema types will emerge. New platforms will become important. New AI systems will change how people discover professionals.
Your job isn't to predict those changes. It's to maintain a system that's flexible enough to adapt to them. A website you control. Structured data you can update. A Wikidata entry you can expand. A blog where you can document whatever comes next.
The system doesn't need constant attention. But it does need occasional attention. And it needs you to stay curious about how the landscape is changing.
That's not a burden. That's the same curiosity that led you to pick up this book in the first place.
• • •