Skip to main content

Schema Markup for Directory Websites: What Actually Shows Up in Google in 2026

Half the schema markup on a typical directory site renders nothing anymore. Here's what Google still supports for listing pages in 2026 — LocalBusiness, ItemList, BreadcrumbList, reviews — checked against Search Central on 27 August 2026, plus the manual action written specifically for list pages.

DirectoryLaunch Team15 min read
Schema Markup for Directory Websites: What Actually Shows Up in Google in 2026

If you copied your directory's structured data from an SEO checklist written before 2025, a meaningful chunk of it renders nothing in Google today. FAQPage stopped appearing on 7 May 2026. HowTo has been dead since 2023. The sitelinks searchbox went away in November 2024. Google quietly deleted the documentation for five more types in September 2025 and one more in January 2026. None of that markup throws an error. It just sits in your <script type="application/ld+json"> producing nothing, and the Rich Results Test won't tell you, because Google removed those types from the test too.

The more interesting problem for a directory isn't the dead markup. It's that the two types you most want — LocalBusiness with a star rating, and ItemList for a carousel — both come with conditions that directory sites are unusually likely to trip. One of them is a manual action Google wrote specifically for pages that list things. This piece walks the whole surface: what still renders, what the conditions are, and where a claim flow can quietly make your listing pages ineligible. Everything below was read off Google Search Central on 27 August 2026 and linked so you can check it.

The markup on your listing pages that no longer renders anything

Start by deleting, because it's the fastest win and it costs nothing to verify.

TypeStatusWhere Google says so
FAQPageStopped appearing in Search 7 May 2026; docs removed 15 June 2026Search Central changelog
HowToNo longer shown, desktop or mobileSearch Central changelog
Sitelinks searchboxFeature removed November 2024Search Central changelog
Course info, estimated salary, learning video, special announcement, vehicle listingDocs removed September 2025Simplifying search results
Practice problemDocs removed January 2026Update on our efforts

The FAQPage removal is the one that catches directory sites, because FAQ blocks are a standard pattern on programmatic city and category pages — the DirectoryLaunch local SEO pages ship one, and plenty of other stacks do the same. The visible FAQ is still worth having: it's real content, it answers a real question, it gives a thin city page something to be about. The JSON-LD wrapper around it is what stopped doing anything.

Google's own documentation URL for FAQPage now 301-redirects straight to the changelog entry announcing its removal, which is about as blunt as deprecation gets. You can confirm that yourself in one line:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" \
  https://developers.google.com/search/docs/appearance/structured-data/faqpage
Careful with the confident claim that dead markup is harmless

The common advice is "leave it, Google ignores unsupported structured data." That's probably true in practice, but it is not a sentence Google actually writes anywhere in the structured data guidelines or the intro — I looked. What Google does say is that markup must describe content visible on the page. If your FAQPage JSON-LD is still accurate about a FAQ that's still on the page, leaving it costs you nothing but bytes. If you removed the visible FAQ and left the markup, that's a different and worse situation.

LocalBusiness: the one sentence that decides your whole review strategy

LocalBusiness is the natural type for a listing detail page in a local directory. Required properties are trivially few — address and name. Recommended ones cover most of what a listing page already displays: telephone, url, geo, priceRange, openingHoursSpecification.

Then there are review and aggregateRating, and Google's LocalBusiness documentation attaches the same bolded qualifier to both:

This property is only recommended for sites that capture reviews about other local businesses

That qualifier is written for you. A directory is, by definition, a site that captures reviews about other businesses — so unlike almost every site on the web, you are the intended user of review markup on LocalBusiness. That's a real advantage and worth taking seriously.

The hard rule sits on the review snippet page, and it's stated as ineligibility rather than as a recommendation:

If the entity that's being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.

Read that as a question about control, not about who owns the domain. Google's example is a review of entity A placed on entity A's own website — including through an embedded third-party widget. A directory sits on the safe side of that line as long as the business being reviewed doesn't get to decide which reviews appear.

Three more technical guidelines from the same page that directories routinely break:

  • "Don't aggregate reviews or ratings from other websites." Scraping Google Business Profile ratings into your listings and marking them up as your own aggregateRating is the single most common version of this. It's also the tempting one, because a freshly imported directory has no ratings of its own.
  • "Provide review information about a specific item, not about a category or a list of items." A category page that shows an average rating for "Plumbers in Austin" is not a reviewed item.
  • Ratings must be sourced directly from users, and you shouldn't "rely on human editors to create, curate, or compile ratings information for local businesses."

Google's Manual actions report documents the corresponding penalty rows in plainer language — including "Review written by the site or person providing the service" and "No mechanism for submitting a new review," which requires that a page showing reviews either lets users submit one or clearly shows where the reviews came from.

Where a claim flow quietly makes your listings ineligible

Here's the part that isn't in any schema guide, because schema guides aren't written by people who build directories.

A directory that seeds itself from a CSV import has a listing-ownership problem: every listing belongs to the admin who imported it, and no business owner can update their own hours. The fix is a claim flow — the owner verifies by email domain, ownership transfers, and from then on they edit the listing themselves. It's the right feature. It's also the exact mechanism that moves a page across Google's control line.

Once a business owns its listing, the question becomes: what else can they touch? If claiming a listing gives the owner the ability to delete, hide, reorder or reply-and-suppress the ratings on it, then the entity being reviewed now controls the reviews about itself — on a page marked up as LocalBusiness. That's the ineligibility condition, word for word, on pages you specifically added review markup to in order to win stars.

The fix is a permissions decision, not a markup decision:

  1. Claimed owners edit listing facts — hours, phone, description, photos, categories.
  2. Claimed owners never edit, delete, hide or reorder ratings and reviews. Replies are fine; replies are visible and additive.
  3. Review moderation stays with the directory operator, on directory-wide rules applied the same way to every listing.

That separation is worth writing down explicitly in your admin role definitions, because it's the kind of thing a well-meaning "let owners manage their page" ticket erodes six months later. If you can't guarantee the separation — say you've promised paid listing owners moderation control as part of the package — then don't ship review markup at all, and treat the ratings feature as on-site engagement rather than an SEO play. Google's own guidance is that ratings are costly at low volume anyway: three friends voting five stars distorts a low-traffic listing's sort order long before it distorts anything in Search.

Every directory has category and city pages that list things, so ItemList looks like the obvious markup. The rich result it powers is the structured data carousel — a horizontally scrollable strip of your own entities in the results page. It is genuinely attractive. It is also, as of the documentation's last update on 21 January 2026, still beta and geographically fenced:

This feature is in beta and you may see changes in requirements or guidelines, as we develop this feature. This feature is also only available in European Economic Area (EEA) countries, Turkey, and South Africa, on both desktop and mobile devices.

Query types are restricted per region too — in Turkey it's only hotels, vacation rentals and local businesses; the EEA list is broader and covers hotels, vacation rentals, ground transportation, flights, local businesses, things to do and shopping. And there's an interest form to fill in. If your directory serves a US or APAC audience, the carousel is not currently a thing you can earn by writing better markup.

The eligibility mechanics matter even if you're in scope, because they encode an assumption about site architecture:

  • ItemList must be combined with LocalBusiness (or a subtype), Product, or Event. Nothing else qualifies.
  • The markup goes on a summary or category page with at least three entities, each linking out to a standalone detail page on the same domain. Anchor links within one page are explicitly unsupported.
  • Paginated categories need an ItemList on every page covering that page's entities. Infinite scroll: mark up what's initially in the viewport.

That's a fair description of how a normal directory is already built, which is the good news. It also means the markup is a poor fit for a single-page "top 50" listicle, which is what most sites reach for ItemList to describe.

The manual action Google wrote for list pages

This one deserves its own heading because it's aimed squarely at directories. From the Manual actions report issue table:

Structured data issues on list page — Pages with a list of items need to have each item marked up individually. Aggregating data from multiple items into one structured data element is against our spam policies.

In practice that means: don't take twelve plumbers on a category page and emit one LocalBusiness object describing the category. Each entity gets its own object, nested as itemListElement items. It's the kind of shortcut a templating layer produces naturally when someone wires markup to page-level variables instead of to the loop.

Two neighbouring rows from the same table are worth knowing if your directory lists software, tools or services rather than local businesses:

Company marked as product — A company has been labeled as a product in structured data.

Non-product labeled as product — A non-product, or generic item, has been marked as a product.

An AI-tools or SaaS directory is exactly where this goes wrong. A SaaS company is an Organization; its plan might be a Product; the company itself is not. Reaching for Product because it supports price and rating properties you want is the mistake, and Google names it.

Worth calibrating the stakes honestly, though. Google's own description of the penalty scope:

A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search.

So the downside is losing the enhancement, not tanking the site. That's a reason to be careful, not a reason to be frightened.

BreadcrumbList gets no attention because it produces the least glamorous result — the path line above your URL in the SERP. It's also the only type on this page with no eligibility gate, no beta programme, no regional fence and no way to get it wrong that ends in a manual action. Three required properties on each ListItem: item, name, position.

The one caveat from the feature availability section: "This feature is available on desktop in all regions and languages where Google Search is available." Desktop. If your directory's traffic is 70% mobile, adjust your expectations accordingly — but it still costs you about twenty lines to emit and it's the type most likely to actually render.

For a directory the breadcrumb trail is genuinely informative, because your URL structure carries meaning: category → region → city → listing. That maps onto a breadcrumb almost mechanically, which is the whole argument for designing directory URLs around the taxonomy rather than around database IDs.

What schema does for AI answers

Short version, from Google's guide on optimizing for generative AI features (last updated 10 July 2026), under a heading literally called "Mythbusting generative AI search: what you don't need to do":

Overfocusing on structured data: Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add. However, it's a good idea to continue using it as part of your overall SEO strategy, as it helps with being eligible for rich results on Google Search.

The same section says llms.txt files "will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them," that there's no requirement to "chunk" content, and that you don't need to rewrite pages specifically for AI systems. Google's framing of the whole AEO/GEO category: "optimizing for generative AI search is optimizing for the search experience, and thus still SEO."

That is one search engine's position on its own products, not a universal law about every assistant that crawls the web. But it's the only sourced position available, and it's the opposite of most of what's being sold under the GEO label right now.

An audit prompt you can run on your own listing page

Rather than reading your JSON-LD by eye, paste it into a model with the rules attached. This is the version I'd use — it encodes the specific traps above rather than generic "is this valid schema" checking, which the Rich Results Test already does better.

What to do tomorrow morning

In roughly this order, because the order is by effort-to-payoff:

  1. Grep your templates for FAQPage and HowTo. Decide per instance whether the visible content stays (usually yes) and the JSON-LD goes (usually yes). Ten minutes.
  2. Ship BreadcrumbList on listing detail pages if it isn't there. No gate, no risk, maps onto your URL taxonomy for free.
  3. Open your claim flow's permission matrix and confirm claimed owners cannot modify ratings on their own listing. If they can, either change that or pull review/aggregateRating off your LocalBusiness markup. Don't leave both in place.
  4. Check your category-page markup emits one object per listing, not one object per page. This is the manual-action row written for your site type.
  5. Check whether you're in an EEA, Turkish or South African market before spending a sprint on ItemList carousel eligibility. If you aren't, ship ItemList for structure and move on — the carousel isn't available to you yet.
  6. Re-read the review-snippet guidelines once a quarter. It changed in July 2026 with a new bullet on undisclosed incentivized reviews. It'll change again.

And one expectation to set with whoever asked you to "add schema": Google is explicit that "using structured data enables a feature to be present, it does not guarantee that it will be present," and that a structured data problem costs you the rich result, not your rankings. The upside Google publishes is click-through, not position — its own case studies cite a 25% higher CTR at Rotten Tomatoes and 82% at Nestlé for pages that show as rich results. That's a real number to chase. It's a different number from the one most people think they're chasing.

If you're weighing whether to hand-roll all of this or start from a stack that already emits it, our comparison of directory builders covers the trade-off honestly, including where the alternatives beat us.