The knowsAbout Property Explained: Declaring Expertise Machines Can Read

Every professional bio claims expertise in prose. Almost none of them declare it in a format a retrieval system can match against a query without first parsing a paragraph and guessing.

What knowsAbout actually is

knowsAbout is defined at schema.org/knowsAbout as a property of Person, Organization and a handful of other types, and it accepts three kinds of values: a plain text string, a full Thing object, or a URL pointing at a page that itself describes the topic, most usefully a Wikipedia or Wikidata entry. Most implementations use plain strings because they are the simplest to write and still fully valid, but the URL form is worth knowing about because it lets you point at an already-disambiguated concept instead of a string an engine has to interpret fresh.

The property sits inside your Person schema alongside jobTitle and sameAs, part of the full block covered in the Person schema JSON-LD guide. Where jobTitle answers "what is your role" and description answers "who are you in one paragraph," knowsAbout answers a narrower, more useful question for retrieval purposes: "which specific subjects should an engine associate with this entity when a query touches on them."

Why topics beat adjectives

The single most common mistake in a knowsAbout list is filling it with the language of a marketing bio rather than the language of a search query. "Strategic thinking," "innovative solutions" and "customer-centric growth" are adjectives dressed as expertise, and they match nothing a real query contains. Buyers and retrieval systems alike search in nouns: "HIPAA compliance," "vendor risk assessment," "Series A term sheets." An entry only earns its place in the list if you could imagine someone typing it, close to verbatim, into a search box or asking an AI assistant about it directly.

This matters more than it looks, because knowsAbout is one of the few places in your entire structured presence where you get to state, flatly and in the engine's own vocabulary, which queries you want to be considered for. Vague entries waste that opportunity; specific, buyer-language entries spend it well.

Three ways to write an entry, and when each is worth it

Plain strings cover most needs; reach for a URL or Thing object only for a topic with a genuinely established reference page.

A full example combining forms, for a privacy consultant:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://yoursite.com/#person",
  "name": "Your Name",
  "knowsAbout": [
    "HIPAA compliance",
    "healthcare data privacy",
    "vendor risk assessment",
    {
      "@type": "Thing",
      "name": "privacy impact assessment",
      "sameAs": "https://en.wikipedia.org/wiki/Privacy_impact_assessment"
    }
  ]
}

Mixing forms inside the same array is valid JSON-LD. Use the plain string for topics with no obvious canonical reference page, and reach for the URL or Thing form only when a genuinely relevant Wikipedia or Wikidata entry exists, which is also the groundwork covered from the entity side in creating a Wikidata item step by step.

How many entries, and how specific

Five to eight entries is a workable range for most individual professionals. Fewer than that and the list looks thin next to a real body of work; more than that and it starts to read as a keyword dump rather than a genuine specialization, which is itself a weak signal. Specificity matters more than breadth: "supply chain risk" is serviceable, "supplier concentration risk in single-source manufacturing" is a phrase that maps to an actual, narrower query pattern and sets you apart from every generalist claiming the broader term.

Audit before you write the list

The list should be built from your actual published record, not from aspiration. Before writing a single entry, pull together what you have actually written, spoken about, or been quoted on over the last two years, articles, talks, interviews, case studies, and extract the topics that repeat. Anything that shows up in three or more of those places is a legitimate candidate. Anything you have never actually written about, no matter how relevant it feels to your ambitions, does not belong in the array yet.

The reason this order matters is mechanical, not just honest: a retrieval-based system checking whether your entity actually supports a knowsAbout claim will look for corroborating content elsewhere on your site or across the web, a process covered generally in how retrieval-augmented generation works. A knowsAbout entry with zero supporting content is not neutral; it is a claim the retrieval step cannot verify, and unverifiable claims tend to get quietly discounted rather than taken at face value.

knowsAbout versus the similar-sounding properties

schema.org has several properties that sound like they overlap with knowsAbout, and mixing them up is common enough to be worth untangling directly. about describes what a specific piece of content, an Article or a CreativeWork, is about; it belongs on the content, not on the person who wrote it. mentions describes topics a piece of content references in passing without being centrally about them. knowsAbout is different from both because it sits on the Person or Organization entity itself, making a standing claim about ongoing expertise rather than describing the subject of one specific document. An article can have about set to "GDPR fines" as a one-time subject, while its author's Person entity carries "GDPR fines" in knowsAbout as a durable claim that should hold across many pieces of content, not just this one.

Getting this distinction right matters when you are marking up a blog: each BlogPosting gets its own about reflecting that specific piece, while your Person entity's knowsAbout array stays stable and only changes when your actual area of focus shifts. Confusing the two, for instance copying every article's about value straight into your permanent knowsAbout list, produces exactly the bloated, unsupported array covered in the mistakes above.

knowsAbout at the Organization level

The property is not exclusive to Person entities. An Organization can carry its own knowsAbout array describing the company's collective expertise, which matters once you have split your identity into a Person and Organization pair as covered in Person schema versus Organization schema. The two lists do not have to match exactly. A consultancy's Organization-level knowsAbout might list broader service categories, while the founder's Person-level knowsAbout lists the specific niches they personally are known for, with meaningful overlap but not identical wording. Keeping both lists internally consistent with the actual services offered and the actual person's actual track record is what lets an engine cross-reference the two entities as mutually reinforcing rather than as two disconnected, competing claims about who knows what.

One last practical note: keep the wording of shared topics identical between the two entities where they genuinely overlap. If your Person entity says "vendor risk assessment" and your Organization entity says "vendor risk management" for what is functionally the same service, you have created two slightly different strings for one concept, which weakens the cross-reference instead of strengthening it. Pick one phrasing and reuse it verbatim everywhere it appears, in schema, on the page, and in your bio.

Common mistakes

• Marketing adjectives instead of topics. "Growth mindset" is not a subject anyone searches for; "cohort-based retention analysis" is.
• An unsupported list. Ten confident entries with published work backing up two of them.
• Copying a competitor's list wholesale. Their knowsAbout array reflects their published record, not yours, and reusing it just associates you with topics you cannot actually back up.
• Never revisiting it. Expertise shifts as a career shifts; a list frozen at the moment your site launched stops matching your current published work within a year or two.
• Overloading with dozens of entries. Past roughly eight to ten, the array reads as an attempt to rank for everything rather than a genuine specialization, which weakens rather than strengthens the entity.

Validating the property

Paste your Person schema into the schema.org validator and confirm the knowsAbout array parses as expected, each entry showing either as a plain value or, for the object form, with its nested name and sameAs intact. Validation only confirms the JSON is well-formed; it says nothing about whether the entries are honest or supported, which is a manual check you have to run yourself against your actual published content, ideally on the same schedule you review the rest of your machine-readable identity.