Number 11 in our series on KOS skills for modern technical communicators
You’ve built the vocabulary. You’ve encoded the hierarchy. You’ve aligned your terms, tagged your labels, and wired your ConceptScheme into the content pipeline. The knowledge infrastructure is solid.
Now someone searches for “why won’t my account let me in” and your perfectly governed terminology, your carefully maintained “authentication error” Concept with all its altLabels and mappings, returns nothing useful. Because the search engine is matching keywords, not understanding meaning.
This is the gap semantic search closes. And it’s the gap that technical communicators, with their deep understanding of user language and content structure, are well placed to bridge.
Here is my poem to set the stage:
The user types what they feel, not what we filed;
— CJ Walker and AI Pals
our labels precise, their language more wild.
Semantic search listens beyond the word’s skin:
it finds what they mean, not just what they typed in.
Where We Are on the KOS Ladder
In Post 10 last week, we completed the vocabulary layer with SKOS, giving our concepts formal, machine-readable labels, hierarchies, and mappings. The KOS ladder now looks like this:
Raw data → Structured data → Vocabularies/Taxonomies → Ontologies → Knowledge Graphs → URIs → SPARQL → SHACL → Semantic Services → SKOS → Semantic Search
Semantic search is the point where all that foundational work pays off for real users. It is the layer that turns your knowledge infrastructure into a discovery experience; the place where a user’s natural, imprecise, sometimes misspelled query connects to the right content because the system understands meaning rather than just matching strings.
For technical communicators, this is where your work becomes visible to the people it’s meant to serve.
What Semantic Search Actually Is
Traditional keyword search is exact matching. The engine looks for documents that contain the words in the query. Type “authentication error” and you get results containing those words. Type “why can’t I log in” and you get results containing those words, which may have no overlap at all with your authentication error content, even if that’s precisely what you need.
Semantic search understands that “why can’t I log in” and “authentication error” refer to the same underlying problem. It does this through a combination of techniques:
- Vector embeddings
convert text into numerical representations that capture meaning. Words and phrases with similar meanings cluster together in this mathematical space, so “log in failure” and “authentication error” end up close together even if they share no words. - Knowledge graph integration
connects queries to structured concept relationships. If your knowledge graph knows that “log in” is an altLabel for the “sign in” Concept, and that “sign in” is related to “authentication,” a search for “log in problem” can traverse those relationships to surface authentication error content. - Natural language processing (NLP)
interprets the grammatical structure and intent of a query, not just its keywords. It recognises that “how do I fix an authentication error” is a troubleshooting query, and surfaces procedural content rather than conceptual definitions. - SKOS-powered query expansion
uses your controlled vocabulary to automatically broaden searches. A query for “API key” expands to include content tagged with “authentication token,” “access key,” and “bearer token” because your ConceptScheme defines them as altLabels for the same Concept.
The practical result: users find what they need the first time, using the language they naturally reach for, rather than the language your documentation team preferred.
Why Technical Communicators Are Central to Semantic Search
Here is a belief worth challenging: that semantic search is a technology problem to be solved by engineers, and technical communicators just write the content that goes into it.
That belief is wrong, and understanding why it’s wrong is the key to unlocking the career opportunities this skill creates.
Semantic search is only as good as the semantic structure underneath it. A vector embedding model trained on poorly organised, terminology-inconsistent content will produce poorly organised, terminology-inconsistent results. A knowledge graph with missing relationships will fail to connect related content. A SKOS vocabulary with incomplete altLabels will miss the user queries that don’t use preferred terms.
Every one of those failure modes is a content quality problem, not an engineering problem. And content quality is a technical communicator’s domain.
Specifically, technical communicators contribute to semantic search in ways that engineers cannot:
- Vocabulary architecture
The altLabels, broader/narrower relationships, and mappings you build in SKOS directly feed query expansion. Your decisions about what counts as a synonym, what counts as a narrower concept, and what counts as a related term determine what the search system can and cannot connect. - Content tagging
Semantic search surfaces content based on concept tags, not just full-text indexing. The quality of your tagging decisions determines whether the right content appears for the right query. - Query modelling
Technical communicators who understand user language, the terms users actually reach for rather than the terms subject matter experts prefer, are invaluable for training and evaluating semantic search systems. - Gap analysis
When semantic search fails, it’s often because content doesn’t exist for a particular user need. Technical communicators who can read search logs and identify where queries return poor results are doing content strategy, not just documentation.
The Technical Communicator’s Semantic Search Toolkit
You don’t need to build search engines. You need to understand the components well enough to contribute to them and to advocate for content quality as a search quality input.
Controlled Vocabularies and SKOS
Your existing SKOS skills are the foundation. The prefLabel/altLabel structure you maintain directly enables query expansion. The broader/narrower hierarchy enables concept-based result clustering. The related property enables “see also” recommendations driven by semantic relationships rather than editorial guesswork.
A simple example: if your SKOS ConceptScheme defines “installation error” as broader than “dependency conflict,” a search platform configured to use your vocabulary can return “dependency conflict” articles in response to a search for “installation error,” because it knows the relationship exists.
Semantic Tagging and Content Annotation
Semantic search needs content to be tagged with Concepts, not just written with keywords. This means applying your SKOS ConceptScheme as the controlled vocabulary for content metadata, so that articles, topics, and pages are labelled with the concepts they address.
Topic: “Resolving Dependency Conflicts”
Concepts: :DependencyConflict (primary), :InstallationError (broader), :ErrorResolution (related)
Audience: :Developer
Product: :PlatformV3
The richer and more accurate this tagging, the better the semantic search results. This is precision work that requires both content expertise and vocabulary knowledge; exactly the combination technical communicators bring to the work.
Search Log Analysis
Search logs are one of the most valuable and underused resources in a documentation team’s toolkit. They tell you what users actually search for, which queries return poor results, and where the gap between user language and documentation language is widest.
A technical communicator who can read search logs, identify high-volume zero-result queries, and trace them back to vocabulary gaps or missing content is contributing directly to search quality. This is a strategic skill that surfaces quickly in performance reviews and stakeholder conversations.
Relevance Evaluation
Semantic search systems need human evaluation to assess whether their results are actually relevant. This is called relevance assessment or relevance judging, and it requires someone who understands both the content and the user need. Technical communicators are natural relevance judges.
A relevance assessment task might look like this: given the query “how do I reset my API credentials,” rate each of the following ten results as highly relevant, partially relevant, or not relevant. The ratings feed back into the search ranking model, improving future results.
Real-World Scenarios
The Support Ticket That Shouldn’t Exist
A software company’s documentation team notices that “password reset” is generating a high volume of support tickets despite having comprehensive documentation on the topic. Search log analysis reveals the problem: users are searching for “how do I change my login details,” and the search engine, running on keyword matching, is returning account settings articles rather than the password reset procedure.
The technical communicator responsible for the vocabulary adds “login details” and “change password” as altLabels to the relevant Concept in the SKOS ConceptScheme. The search platform, configured to use the vocabulary for query expansion, now connects “login details” queries to the password reset content. Support ticket volume for that topic drops by 35% within two weeks.
No engineering change was required. The fix was vocabulary.
The Onboarding Search That Worked
A developer documentation team implements semantic search powered by their SKOS vocabulary. A new developer, unfamiliar with the product’s preferred terminology, searches for “how to authenticate my app.” The system recognises “authenticate” as semantically close to the “authentication” Concept, expands the query using the altLabel relationships in the ConceptScheme, and returns the correct getting-started guide, the OAuth flow documentation, and two relevant code samples.
The developer finds what they need in one search. The team’s search satisfaction score improves. The vocabulary work that made it possible is invisible to the developer, which is precisely how it should be.
The Multilingual Search Problem
A technical communications team manages documentation in eight languages. Users searching in German for “Anmeldefehler” (login error) were not finding content tagged with the equivalent English Concept because the search index was language-siloed.
The team implements language-tagged SKOS labels and configures the search platform to use Concept-based matching across language variants. A search in German for “Anmeldefehler” now finds content tagged with the “authentication error” Concept in any language, with results presented in the user’s preferred language. Cross-language search satisfaction improves significantly, and the approach scales cleanly as new languages are added.
Common Pitfalls and How to Avoid Them
| Pitfall | What Goes Wrong | How to Avoid It |
| Treating semantic search as purely an engineering problem | Content quality issues go unaddressed; search results reflect vocabulary gaps | Embed a technical communicator in every semantic search implementation project from day one |
| Incomplete altLabel coverage | User queries using natural language return no results despite relevant content existing | Conduct regular search log analysis; add altLabels for high-volume zero-result queries |
| Tagging content inconsistently | Search ranking is unreliable; similar content surfaces inconsistently | Establish and enforce tagging governance; audit tags quarterly |
| Ignoring multilingual query patterns | Non-English users get poor results even when content exists | Implement language-tagged SKOS labels; test search in every supported language |
| Skipping relevance evaluation | Search ranking drifts; the system optimises for proxies rather than actual user need | Schedule quarterly relevance assessment sessions with technical communicators as judges |
| Confusing semantic search with AI search | Overselling capabilities or misunderstanding what the system can do | Understand the distinction between vector-based, knowledge-graph-based, and hybrid approaches before making claims |
Career Opportunities
Semantic search sits at the intersection of content strategy, information architecture, and search engineering; a space where technical communicators with the right skills are genuinely scarce and therefore genuinely valuable.
Here are some sample roles:
Search Content Strategist
Owns the relationship between content structure and search performance. Conducts search log analysis, manages vocabulary development for query expansion, and defines content tagging governance. A growing role in enterprise technology, e-commerce, and SaaS organisations.
Knowledge Discovery Specialist
Focuses on the full user discovery journey, from search through to content consumption and task completion. Combines search expertise with content design and UX awareness. Often found in large documentation teams or product organisations with complex help ecosystems.
Semantic Search Analyst
Conducts relevance assessment, analyses search performance metrics, and identifies vocabulary and content gaps. A more technical variant of the role that may involve working directly with search platform configuration. Natural progression for technical communicators with strong analytical skills.
Information Architecture Lead
Owns the structural layer beneath search: taxonomy, content modelling, metadata schema, and vocabulary governance. Semantic search quality is a direct output of this role’s decisions. Senior IC or team lead level; strong salary premium over traditional technical communicator roles.
AI Content Systems Engineer
As large language models and retrieval-augmented generation (RAG) systems become standard in enterprise documentation, technical communicators who understand how semantic search feeds AI-generated answers are moving into hybrid content and AI roles. Early-stage but growing rapidly.
Industry demand is particularly strong in enterprise software, financial services, healthcare, and e-commerce; anywhere that users need to find precise information quickly across large content estates.
A Light Learning Path
The goal at this stage is practical orientation: enough understanding to contribute to semantic search projects and to identify where your vocabulary skills are already relevant.
Weeks 1 to 2:
Understand the landscape
Elasticsearch, Solr, and Algolia are the search platforms you’re most likely to encounter in documentation contexts. Each has good introductory documentation. You don’t need to build anything; you need to understand what these platforms can do and what inputs they need from content teams. The Elasticsearch “What is semantic search?” documentation is a good starting point.
Weeks 3 to 4:
Audit your own search
If your organisation has a search function on its documentation or help centre, spend time with it as a user researcher would. What queries do users run? What returns poor results? Where does the gap between user language and documentation language show up? Search logs, if you can access them, are the richest source of insight. Even a few hours of manual query testing will reveal patterns.
Month 2:
Connect vocabulary to search
Review how your existing SKOS vocabulary (or controlled vocabulary in whatever form it exists) is or isn’t connected to your search platform. Are altLabels used for query expansion? Are Concepts used as content tags? Identify one specific improvement you could make and make the case for it.
Month 3 onward:
Build the practice
Establish a quarterly rhythm of search log review, vocabulary gap identification, and relevance assessment. This is the practice that turns semantic search from a project into a capability. Document your findings and share them with stakeholders; the business impact is easy to quantify in terms of support ticket deflection, time-to-find metrics, and user satisfaction scores.
Your Next Career Move
Semantic search is where the KOS ladder’s investment pays off in terms that every stakeholder understands: users find the right content faster, support costs drop, and documentation quality becomes measurable in business terms rather than just word counts and review cycles.
For technical communicators, this is a genuinely exciting moment. The skills needed to make semantic search work well: vocabulary governance, content tagging, user language analysis, relevance evaluation, are skills we already already have or can develop naturally from our existing practice. The engineering layer is real, but it’s not the constraint. The constraint is almost always the content and vocabulary quality underneath.
That’s your domain. And increasingly, organisations are beginning to understand that.
Keep Building: Firehead Resources for Search-Smart Technical Communicators
The skills in this post don’t live in isolation. Semantic search, keywording, vocabulary design, and content structure are part of a connected skill set that the Firehead Training Academy is designed to help you build, one layer at a time.
Make Search Better: An Introduction to Keywording by Clemency Wright is the most direct companion to this post. Clemency trained at Getty Images as a keyworder and search vocabulary editor, and this course teaches the practical discipline of keywording digital content to improve discoverability. If semantic search is the architecture, keywording is the craft that feeds it. Together, they give you both the theory and the hands-on technique to make content genuinely findable.
An Introduction to Content Operations by Rahel Bailie shows how structured vocabulary and content strategy connect in real documentation workflows. Semantic search is only as powerful as the content systems that support it; this course helps you understand how to build and govern those systems.
DITA Concepts by Tony Self, PhD anchors all of this in structured authoring. DITA’s topic-based, modular approach to content creates exactly the kind of clean, machine-readable documentation that semantic search engines thrive on.
And if you want the full picture of where these skills fit in a modern technical communication career, our TechComm Trilogy gives you the strategic context that ties everything together.
Subscribe to Ignite!, our newsletter, for industry news, skills learnings, and new course announcements: Ignite!
Firehead works with technical communicators at every stage of this journey, from those exploring semantic search for the first time to experienced practitioners ready for senior roles in search strategy and knowledge architecture.
Contact us about opportunities, explore our training courses at firehead-training.net, and get in touch to talk about where you are now and where you want to go.
Firehead. Visionaries of potential.
