Somebody has to check. The architects and designers decide how content should be structured for retrieval — and then a rendering quirk hides half the body from crawlers, the schema silently breaks in a deploy, and an AI assistant confidently describes a product you discontinued last spring. The gap between "structured correctly in theory" and "parsed correctly in practice" is an engineering gap.
A relevance engineer owns that gap: the pipelines, markup, and monitoring that determine what retrieval systems actually receive, and the evidence of what they do with it.
- Relevance engineering is the technical layermaking the structure real in markup, feeds, and rendering — and proving it.
- Machines see a different page than you doJS-dependent content, blocked resources, and broken schema all silently narrow what gets indexed.
- Monitoring is half the jobwhat AI systems say about you drifts, and nobody emails you when it does.
- It is testableunlike strategy, this layer has pass/fail states you can automate.
What the job actually consists of
- 01Structured data as code
Schema generated from real page data, validated in CI, so a content edit can't silently break machine-readability.
- 02Render verification
Diffing what crawlers receive against what browsers show — the classic silent killer on JS-heavy stacks.
- 03Access control
robots directives, llms.txt, and bot policy as deliberate decisions about which systems may read what.
- 04Retrieval testing
Regularly asking the actual assistants the questions your pages target and logging what they cite and claim.
- 05Freshness plumbing
Sitemaps, feeds, and update signals so corrections propagate instead of stale claims living on in caches.
Strategy decides what machines should see. Engineering is the only layer that can tell you what they actually saw — everything else is hope with a style guide.
How the work gets measured
- Schema validity across the site staying at 100% through deploys, not just on launch day.
- Parity between rendered and crawled content on the pages that matter.
- Citation share in the retrieval test suite trending up; factual errors about you trending to zero.
- Time-to-propagation — how fast a published correction shows up in fresh AI answers.
- Crawl coverage and freshness in the server logs, the ground truth under everything.
Relevance engineer versus technical SEO?
Technical SEO is the ancestor. The successor targets a wider set of consumers — LLM crawlers, answer engines, embedding pipelines — where quoting and synthesis, not just ranking, are the outcomes.
Is this a full-time role?
At scale, yes. Below scale it is a hat the engineering-minded person on the content team wears — the test suite and CI validation still pay for themselves at fifty pages.
Where does this overlap with the architect and designer roles?
The architect and [designer](/blog/what-is-a-relevance-designer) specify the structure; the engineer implements the machine-facing parts and instruments the results. Spec, then build, then measure.
How these roles fit together
One library, different layers. Content design makes a single page work for the person reading it. Content architecture decides what pages exist and how they relate. Content engineering makes producing them repeatable. Relevance design and relevance architecture make the result legible to the retrieval systems deciding who gets surfaced. Resonance architecture is the layer those all serve: whether any of it lands with an actual human once it is retrieved.
Nobody hires all six. Small teams get one person wearing several of these hats badly until the seams show. The names matter less than noticing which layer is failing, because the fixes live in different places.
