JSON-LD Structured Data: The Five Schema Types That Matter for AI Search

We work with a bank that had, by every visible measure, done content right. A deep library of pages, disciplined interlinking, meta titles and descriptions on point. Humans found the site easily and read it happily. Google treated it well. And AI engines cited it almost never.

The gap took some digging to explain, because nothing visible was wrong. The problem lived in the invisible layer: the site did not speak the language of AI. There was no structured, algorithmically readable description of who this institution was, what it offered, or how its pages related. Everything the bank wanted machines to know had to be inferred from prose, and inference is where machines hedge. We built that layer from scratch, JSON-LD files reflecting the whole site's structure as well as the individual pages, woven in without touching what visitors see. The bank's content did not change. Its citability did.

What JSON-LD actually is

Strip away the jargon and JSON-LD is a machine-readable business card tucked into your page code. It is a small block of structured text, invisible to visitors, that states facts plainly: this organization has this name, this address, this logo; this page is an article by this author on this topic; these are the questions this page answers.

Prose makes machines guess. Markup lets you state. And as we covered in how AI search decides who to trust, entity clarity, a machine knowing exactly what your brand is, sits at the root of the citation decision. JSON-LD is where entity clarity starts.

The five types that matter

Schema.org defines hundreds of types. A small business needs five.

Organization. The foundation. Your legal name, logo, address, phone, and links to your official profiles. This is the block that turns "some website" into a recognized entity.

Person. The founder or principal expert. AI engines increasingly attach trust to identifiable humans with consistent credentials. If your reputation rides on a person, say so in markup.

Article. For every blog post: headline, author, dates published and modified. It tells machines the content is maintained editorial work, not boilerplate.

FAQPage. For pages structured as questions and answers. This is the friendliest format you can hand a retrieval system, since each question-answer pair is a ready-made quotable chunk.

Product or Service. Whichever fits your business. Name, description, and pricing where appropriate, so the machine knows precisely what you sell rather than approximately.

Implementation is undramatic: each type is a small script block in your page's HTML, hand-written once or generated by your CMS or an SEO plugin. Validate with Google's Rich Results Test and schema.org's validator, then move on.

The honest caveat

One thing we tell every client, including the bank: markup describes authority. It does not create it. JSON-LD is a label on the box, and the box still has to contain what the label claims. A thin site with immaculate markup is a well-labeled empty box, and models notice the mismatch between what your markup asserts and what your content demonstrates. The shape of your actual coverage has to be real first. Markup makes real authority legible; it cannot substitute for it.

Describe what you have built

The bank's story is common: a business does the hard part, years of content and structure, then loses citations for lack of a few kilobytes of description. That is a bad trade to lose.

The prerequisite for describing your authority is knowing what it covers. Topic Modeler maps the topics your site actually owns, so your markup, your hubs, and your content plan all describe the same true thing. Map the coverage first. Then label the box.