WordPress data handling deserves a harder look than it usually gets. The advice for years has been to spin up a Custom Post Type, bolt on a few ACF fields and move on. Compare that with how healthcare handles information and the WordPress version starts to look like a digital junk drawer. Healthcare builds knowledge graphs so everyone shares the same meaning, while we keep treating the database as a flat spreadsheet.
In 14 years of refactoring legacy sites I have lost count of the ones where product dimensions were stored as strings in one place and integers in another. Calling that a clean code problem undersells it; the structure itself is broken. Healthcare did not pull ahead on data because it had better servers. It pulled ahead by paying for shared ontologies and semantic infrastructure, and by agreeing on what things are before anyone wrote code for how they look.
Ontologies versus a pile of post meta
WordPress developers think in custom post types. Knowledge graphs ask you to think in entities and relationships instead. Healthcare defines every gene and chemical compound against ontologies such as Uberon or ChEBI, so nobody has to guess what a term means. The vocabulary is controlled and shared.
Most WordPress sites, by comparison, are a pile of disconnected wp_postmeta rows. Search for a product and the database has no idea that the manufacturer is a separate entity with attributes of its own. To the database it is a string in a column. That becomes a real bottleneck the moment you try to scale the site or wire an AI feature into it.
The naive approach
Most of the time the data just gets dumped into a meta field like this. It works today, and it is unreadable to a machine or to the next developer unless they already know the exact magic string keys.
// The "I just need it to work" approach
update_post_meta( $post_id, 'med_info', 'Paracetamol 500mg' );
update_post_meta( $post_id, 'usage', 'Twice daily' );A semantic approach
Anchoring the data in an open standard such as Schema.org is what keeps it useful past the next redesign. JSON-LD turns a WordPress post into a node in a wider web of data, and one hook is enough to emit structured data that search engines and AI agents can read.
<?php
/**
* Inject semantic JSON-LD into the head based on CPT data.
*/
function bbioon_inject_knowledge_graph_schema() {
if ( is_singular( 'treatment' ) ) {
global $post;
$schema = [
'@context' => 'https://schema.org',
'@type' => 'MedicalScholarlyArticle',
'name' => get_the_title( $post ),
'author' => [
'@type' => 'Organization',
'name' => 'Clinic Authority'
],
// This is where we link to a shared ontology identifier
'sameAs' => 'https://www.wikidata.org/wiki/Q37060'
];
echo '<script type="application/ld+json">' . wp_json_encode( $schema ) . '</script>';
}
}
add_action( 'wp_head', 'bbioon_inject_knowledge_graph_schema' );What healthcare got right
Healthcare pulled ahead by splitting pre-competitive semantics from competitive advantage. Hospitals compete on patient care; they do not compete over the definition of the word “patient.” That split is the useful part of the semantic infrastructure model for the rest of us.
- Standardize how the data moves, not only the data itself. REST or GraphQL with a strict schema beats a proprietary endpoint nobody else can call.
- Treat vocabularies as infrastructure. If you are building a directory, borrow a shared thesaurus or external identifiers like GeoNames or LEI instead of inventing your own category names.
- Build it incrementally. Healthcare has been cataloging findings for centuries, so nobody expects knowledge graphs out of one sprint. Fix one post type, then the next.
Open standards also outlive any single theme or plugin, which is most of the point. Anyone who has migrated a site with 50,000 rows of unstructured meta knows what a missing semantic anchor costs in billable hours. Time spent on data architecture now is time you do not spend racing technical debt later.
My guide on banishing messy text covers the cleanup side of this in more detail.
If knowledge graph work like this is eating your dev hours, I take that kind of job on. I have been wrestling with WordPress since the 4.x days.
Encoding systems instead of documents
Healthcare did not win by scanning paper. It won by encoding how the medical system works. A WordPress build is the same kind of exercise: the pages are the visible part, and underneath you are writing a computable model of somebody’s business. If that model is broken at the database level, no AI feature or fresh UI will rescue it. Refactor the data into a graph and stay on open standards.
