Home / Knowledge / Technical SEO and Indexing / Structured Data That Helps

Technical SEO and Indexing

Structured Data That Helps

Structured data is schema markup that describes your content to search engines in a machine readable form. For directories, the useful types are LocalBusiness, Breadcrumb, FAQ and Review markup. Done right it earns rich results and clearer understanding. The rule that matters: only mark up content that is genuinely visible on the page.

Structured data is how you hand a search engine a clean, machine readable summary of what a page is about, instead of making it infer everything from prose. For a directory, where every listing page packs in a name, a location, hours, a price band and reviews, that summary is enormously useful. Done well it earns rich results and helps engines understand your catalogue. Done carelessly it earns a manual action. The line between the two is honesty.

What structured data does for a directory

Search engines read your pages, but structured data removes the guesswork. When you tell Google in JSON-LD that this page describes a business with this name, this address, these hours and this average rating, you are not just hoping the crawler parses it correctly from the layout. You are stating it plainly. That clarity can unlock rich results, the star ratings, the FAQ accordions, the breadcrumb trails that appear in search listings and lift click through. It also feeds the broader machine understanding that increasingly drives how content gets surfaced and cited.

The types that actually earn their place

LocalBusiness and its subtypes

For a listing page, LocalBusiness or a more specific subtype, such as Restaurant or Hotel, is the workhorse. Mark up the name, the full postal address, the geo coordinates, the phone number, the opening hours and the price range. Use the most specific type that fits the listing, because specificity helps engines place the entity correctly. Keep every value in sync with what the listing actually displays.

BreadcrumbList

Breadcrumb markup tells search engines how a page sits in your hierarchy and often produces the breadcrumb trail shown in results. It reinforces your site structure in a way crawlers trust. This pairs directly with the navigational work in breadcrumbs and site hierarchy, where the visible breadcrumb and the marked up one should always agree.

FAQPage

If a page genuinely answers a set of questions, FAQ markup can earn an expanded result. The catch is that the questions and answers must be visibly present on the page, not invented purely to win the rich result. Used honestly on listing pages and knowledge articles, it adds real estate in search. Used as a markup only trick, it risks a penalty.

Article and Person on knowledge pages

On your knowledge hub, Article markup with a real named author tied to Person schema signals genuine authorship. We treat that as non negotiable across our content, because it is the backbone of trust, and the same principle that makes a knowledge article credible makes its structured data meaningful.

The one rule that keeps you safe

Mark up only what is visible on the page. This single rule prevents almost every structured data penalty. If you put a five star aggregate rating in your markup but no rating is shown to users, that is a mismatch Google treats as deceptive. If you mark up hours that do not appear anywhere on the page, same problem. The markup is meant to describe the page, not to decorate it with claims the page does not make. Our internal test is blunt: if a human cannot see the fact on the rendered page, it does not belong in the schema.

This rule also has a rendering dimension. Because Google indexes the rendered mobile page, your structured data has to be present in that render. If a script injects schema only on desktop, or a tag fires it on one breakpoint, the markup is missing where it counts. This is the same parity discipline described in mobile first for directory sites, applied to your JSON-LD.

Reviews and ratings, handled honestly

Review and rating markup is powerful because stars in search results draw the eye. It is also the most abused, which is why Google scrutinises it hardest. Only mark up reviews that are real, that the business has genuinely collected, and that are displayed on the page. Never self serve a glowing aggregate rating with no underlying reviews. Never mark up reviews of yourself written by yourself. The short term lift from fake stars is never worth the manual action that follows, and recovering from one costs far more than the markup ever gained.

Use JSON-LD and keep it server rendered

Google recommends JSON-LD, placed in a script block, and it is by far the easiest format to maintain because it lives separately from your visible HTML rather than tangled through it. Generate it from the same data that populates the visible listing, so the two can never drift apart. Render it server side so every crawler on every device sees it without waiting on JavaScript. Building it from one source of truth is also what makes it sustainable across thousands of listing pages, the operator approach we describe in our building thesis.

Common structured data mistakes

  • Marking up facts that are not visible to users, the most frequent cause of penalties.
  • Choosing a type that does not match the page, such as Product markup on a category page.
  • Leaving required properties empty or malformed, so the rich result never appears.
  • Injecting schema with client side scripts that the mobile crawler never executes.
  • Letting the markup drift out of sync with the visible content after a redesign.

Validate, then keep validating

Run your templates through the Rich Results Test and schema validators before launch, and watch the structured data reports in Search Console afterward for errors and warnings that appear at scale. Because schema is generated by templates, one template bug becomes thousands of broken pages, so a recurring validation pass is worth far more than a single launch check. Fold it into the routine monitoring covered across our technical SEO and indexing pillar, and your structured data stays an asset rather than a liability.

The short version

Structured data helps a directory by handing search engines a clean description of each listing and earning richer, more visible results. Use LocalBusiness, Breadcrumb, FAQ and Article types where they genuinely fit, render the JSON-LD server side so the mobile crawler sees it, and follow the one rule that keeps you safe: mark up only what is truly visible on the page. Accurate markup compounds across the catalogue, fake markup eventually costs you everything it gained.

Kings Hospitality Group framework

Kings Hospitality Group applies a Mark Up What You Show test to every schema property: if a fact is not visible to a human on the rendered page, it does not go in the structured data, which keeps our directories clear of the markup mismatches that trigger manual actions.

Common questions

Which schema types matter most for a directory?

For listing pages, LocalBusiness or a more specific business type, plus BreadcrumbList for hierarchy. For knowledge pages, Article, Person and FAQPage. Always match the type to what the page actually is.

Can structured data get me penalised?

Yes, if you mark up content that is not visible, or fake reviews and ratings. Google issues manual actions for spammy structured data. Keep markup accurate and tied to visible content and you stay safe.

Subscribe to The Portfolio Brief

Get our field notes on building directory and hospitality brands that last. A few considered letters a year.

MA
Morten Andersen
Founder, Kings Hospitality Group
More from this author