Schema, taxonomies, content models: these decisions are about how your business describes itself. That’s not a technical problem. It’s a business problem.
The leadership team decides that AI readiness is a priority. Someone mentions schema, taxonomies, and context engineering. Everyone nods. It goes on the roadmap. The IT team is asked to handle it.
Three months later, something has been done, technically. But you’re still not showing up in AI-generated answers. A competitor just got cited in an industry report and you weren’t mentioned once. Search still isn’t working the way it should.
You don’t have the language to ask the right questions. And you’re running out of time to figure it out.
Here’s the problem: context engineering wasn’t designed by the wrong system. It was designed by the wrong people.
The term is everywhere in martech circles right now. But it’s rarely explained in operational terms.
Context engineering is the practice of structuring your content so that machines like search engines, CMS platforms, AI tools, onsite search, and recommendation engines can understand what your content is about, who it’s for, and when it should surface.
It includes taxonomy design, content models, schema markup, and metadata standards and - very importantly - governance. These are not IT problems. They are business decisions with a technical implementation layer.
“Taxonomy is the shared vocabulary of your organisation. It determines how your systems understand what your content is about. If that language is inconsistent, every system downstream behaves inconsistently.” – Alison Sainsbury, Aline DX
Taxonomy encodes how you categorise your products and services, how you segment your audiences, and what you mean by “topic”, “format”, “region”, and “audience”. IT can build a taxonomy field in a CMS. They cannot decide what the terms should be, or why the distinctions matter.
And taxonomy goes well beyond content models. For it to work, the same controlled vocabulary needs to run consistently across your entire martech stack: your analytics platform, your DAM, your CRM, your campaign tagging, your email segmentation should all be using identical terms.
When every system is using the same terms, your recommendation engine can surface the right content, your workflow automation can trigger on the right signals, and your personalisation logic can act on context you designed rather than context it has to infer.
When the vocabulary is inconsistent, those systems start filling in the gaps themselves. They make assumptions. They hallucinate context. Each automated decision pulls a little further from the intent you started with.
A well-governed taxonomy keeps pulling the machine back to the context you built – consistently, across every touchpoint.
Content models work the same way. When your team designs a content model, you’re making structural decisions at the template and page type level – deciding what fields and attributes apply to every article, every market insight, every regulatory update as a class of content. Those decisions shape what your platform can personalise, filter, recommend, and surface.
A developer can implement that structure. A marketer must design and govern it.
The taxonomy reflects system logic, not business logic
IT teams build taxonomies based on what the platform requires, not how the business actually describes its content. You end up with categories that make sense to a developer but confuse everyone else, and that often don’t match the language your customers or search engines use.
Schema gets treated as a "compliance task"
When schema markup is a technical checklist, the result is schema that satisfies a validator but adds no real context. A page might have a perfectly valid Organisation schema applied, but with none of the product-specific, audience-specific, or content-type signals that would actually help an AI answer a customer’s question.
Nobody owns governance when the build is done
Taxonomy and schema are not set-and-forget. They need to evolve with your content strategy, your product set, and your audiences. IT teams move on to the next project. Without a business owner who understands why the structure exists, it drifts. Tags get added informally. Legacy terms accumulate. The shared language stops being shared.
The good news is that this is learnable and executable work. It doesn’t require a data scientist or a six-figure platform investment. It requires the right people making the right decisions in the right order, and then working closely with IT to implement them.
That means:
Starting with your taxonomy before you touch a platform
Agreeing on a canonical vocabulary that every system in your martech stack can consume
Translating that vocabulary into schema properties that search engines and AI tools can read
And designing measurement and governance so the structure holds over time, not just at go-live.
👉 The business side designs the context engineering model.
👉 IT builds the infrastructure that carries it.
☑️ Both are essential. Neither works without the other.
Coming soon: Content with Context: A Step-by-Step Guide to AI-Ready Content Structure
An on-demand course teaching digital, content, and marketing practitioners how to design taxonomy, build content models, implement schema, and enable search and AI – using practical frameworks built from 20+ years of enterprise project experience.
Register your interest now to get early access to the free first chapter, and exclusive intro pricing.
Launching August 2026.