All posts

Schema Markup for Directory Websites: A Practical Guide

Which structured data types a directory actually needs, where to put them, the mistakes that cause invalid markup, and why markup matters more now that AI answers cite structured sources.

Your AI chat can build this directory.

Describe the niche, watch the agent design the fields and fill the catalogue. Free plan, no card.

Start free

Schema markup does not directly raise rankings. It does three other things that matter more for a directory than a ranking bump would.

It drives rich results, which lifts click-through on the same position. It tells search systems your page is a set of comparable entities rather than an article. And it makes your data extractable, which is how you end up cited inside AI answers rather than skipped.

Here is what to implement and where.

The four types a directory needs

On entry pages: the specific entity type. LocalBusiness for physical businesses, and its subtypes where they exist. Person for professionals and freelancers. Product or Service where those fit. Organization as the fallback.

Be as specific as the vocabulary allows. Dentist beats MedicalBusiness beats LocalBusiness. Specificity is how a machine understands what your directory is about at the entity level.

On category and collection pages: ItemList. This declares that the page is an ordered set of things, with each entry as a ListItem pointing at its own URL. This is the type most directories skip and it is the one that says "this is a directory page" rather than "this is an article with links".

Everywhere: BreadcrumbList. Cheap, universally supported, produces the breadcrumb trail in results, and helps establish site hierarchy.

On entries that collect them: Review and AggregateRating. Star ratings in search results are one of the strongest CTR improvements available. Only mark up reviews you actually display, and only genuine ones.

Optional types worth considering

FAQPage on category pages and entry pages that carry a real question and answer block. Rich result support has narrowed over time, but the structural clarity still helps with extraction into AI answers.

Offer where entries have pricing you display.

GeoCoordinates and areaServed for anything with a geographic dimension. Coverage area is often the thing a buyer filters on and it is frequently left unstructured.

OpeningHoursSpecification where hours matter. For a nursery directory, hours are a decision criterion, not a detail.

Map your schema to your markup

This is the part that connects data modelling to structured data, and most guides miss it.

If your entries carry typed attributes, those attributes should appear in the markup rather than being buried in a description string.

For gunsmiths, a regulatory weapon category and a partner-armoury delivery flag are the distinguishing facts about an entry. If they live only in prose, nothing can extract them. Expressed as structured properties, they become the reason your page is the only citable answer to a question containing that constraint.

The general rule: anything a visitor filters on should be structured in the markup, not just rendered on the page.

Schema.org will not have a purpose-built property for every niche attribute. Use additionalProperty with PropertyValue for the ones it does not cover. It is valid, it is understood, and it beats leaving the fact unstructured.

Where to put it

JSON-LD in a script tag, in the head or body. Google recommends it, it is easier to generate and easier to debug than microdata, and it does not entangle your markup with your templates.

One block per entity. On a category page that means one ItemList block plus one BreadcrumbList block, not thirty separate blocks.

The mistakes that break it

Marking up content that is not on the page. The most common cause of a manual action for structured data. If the rating is in the markup it must be visible to the user.

Fabricated aggregate ratings. Do not mark up a rating you invented or averaged from nothing. This is explicitly against the guidelines and it is enforced.

Wrong entity type. Using LocalBusiness for a remote freelancer, or Product for a service. The type is a claim about what the thing is.

Incomplete required properties. Each type has required and recommended fields. Missing required ones invalidates the block silently.

Markup on thin pages. Structured data on a page with nothing to say does not rescue it. It just describes the emptiness more precisely.

Forgetting it after a migration. Nothing visibly breaks when markup disappears, which is why it goes unnoticed for months. Check every page type after any platform change.

Testing

Three tools, all free, all worth using.

The Rich Results Test for whether a page qualifies for a specific rich result. Test one URL per page type, not one URL total.

The Schema Markup Validator for general validity against the vocabulary, including types Google does not use for rich results.

Search Console's enhancement reports for errors at scale across your site. This is where you catch a template-level mistake affecting four hundred pages.

Test per template. A directory has three or four page types and a mistake in one template affects everything built from it.

Why this matters more in 2026

Two shifts.

AI Overviews appear on roughly half of Google queries. The systems assembling those answers favour sources whose facts are structured and extractable. A directory with genuinely unique typed data, expressed in markup, is unusually citable material. A directory with the same facts trapped in prose is not.

Entity signals now carry more weight than keyword matching. Post-March 2026, rankings favour sites with demonstrable topical authority, structured data and external citations. Markup is one of the clearest ways to establish what entities your site is authoritative about.

Neither of these makes markup a ranking factor in the direct sense. Both make it a prerequisite for the visibility that replaced ranking.

A realistic implementation order

If you are starting from nothing, do it in this sequence.

  1. BreadcrumbList everywhere. Easiest, universally useful.
  2. The correct entity type on entry pages. Highest value per hour.
  3. ItemList on category and collection pages. The directory-specific one.
  4. Your typed attributes as properties, using additionalProperty where needed.
  5. Review and AggregateRating, once you genuinely collect reviews.
  6. FAQPage, on pages where you have added real question blocks.

On a hosted platform most of this is applied at the template level and you do not implement it yourself. Verify it rather than assuming, since coverage varies and the gap is usually ItemList or the niche attributes.

FAQ

Does schema markup improve rankings?

Not directly. It improves click-through via rich results and makes your content extractable, which is where the practical benefit sits.

Can I mark up user-submitted listings?

Yes, with the usual caveat that markup must match visible content and the content should be moderated first.

What if my niche attributes have no schema.org property?

Use additionalProperty with PropertyValue. Valid and widely understood.

How often should I check it?

After any template change or migration, and a quarterly look at Search Console enhancement reports otherwise.

Is JSON-LD better than microdata?

For practical purposes yes. Easier to generate, easier to validate, and recommended by Google.

Describe your niche and see the typed schema an agent designs →

Related reading

Stop reading, start one

Everything above is easier to do than to read about. Describe a niche in your AI chat and see what the agent proposes.

Start free, no card