Structured data translates page content into a vocabulary machines can interpret. It can specify that an element represents an article, product, local business, offer or breadcrumb. When implemented correctly, it makes a website easier to understand and may make certain pages eligible for rich search results.

Important: Schema.org is neither a shortcut to position one nor a guarantee of appearing in Google or an AI answer. Markup must accurately describe visible content, follow the rules for the feature and remain current.

What is structured data?

An HTML page is easy for a person to read, but some relationships remain ambiguous to software. “VulcainDesign”, for example, could be a heading, brand or organisation. Schema.org vocabulary explicitly identifies the entity type and its properties.

Structured data commonly uses three formats:

  • JSON-LD, a data block separate from visual content;
  • Microdata, attributes embedded in HTML elements;
  • RDFa, another attribute-based syntax.

Google generally recommends JSON-LD where possible because it is easier to maintain without mixing markup with presentation.

What does structured data do for SEO?

It helps search engines identify the entities and relationships on a page. For supported types, a valid page may become eligible for an enhanced presentation such as product details, breadcrumbs, recipes, events or other formats subject to Google’s current rules and availability.

The key word is eligible. Technically perfect markup does not guarantee a rich result. Google also considers the query, site quality, context and its own systems.

The durable benefit is semantic: describing information that is already useful. Markup cannot compensate for thin content, an unavailable product or an inaccessible page.

Which Schema.org types should you choose?

Begin with strategic pages and use the most specific type that represents reality.

Organization or LocalBusiness

Organization can describe the company, official name, logo, URL and profiles. A business receiving customers at a physical location may use an appropriate LocalBusiness subtype, such as Restaurant, with an accurate address and hours.

Do not add a fictional address to target a city. The data must represent the real establishment and match visible information.

For a practical case, the guide to a restaurant website that wins bookings shows how local markup fits into a complete customer journey.

Article or BlogPosting

These types specify the headline, author, publication and modification dates, image and publisher of editorial content. Dates should represent genuine, meaningful updates rather than automatic changes intended to make an article look fresh.

Product, Offer and AggregateOffer

A product page can describe an item and its offer, including price, currency, availability and condition. Structured values must match what the customer sees. If prices vary, model that reality instead of artificially displaying the lowest possible amount.

Breadcrumb markup represents a page’s place in the website hierarchy. A visible breadcrumb also improves human navigation. Do not invent a route that differs from the real architecture purely for search engines.

Service

Service can describe a service, its provider and service area. Google does not necessarily offer a dedicated rich result for every Schema.org type, but the vocabulary may clarify meaning for other data consumers.

FAQPage: use carefully

FAQ markup must reflect questions and answers visible on the page. Google currently limits FAQ rich-result visibility primarily to recognised government and health sites. Adding it everywhere in the hope of taking more result-page space is not a strategy.

JSON-LD example for a restaurant

This is a simplified example. Replace all values with genuine details and extend it according to the page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Restaurant name",
  "url": "https://www.example.com/",
  "telephone": "+33 5 00 00 00 00",
  "servesCuisine": "French cuisine",
  "priceRange": "€€",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "10 Example Street",
    "postalCode": "31000",
    "addressLocality": "Toulouse",
    "addressCountry": "FR"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "12:00",
    "closes": "14:00"
  }]
}
</script>

This is not a universal recipe. A split service, multiple locations or a business without customer-facing premises needs different modelling.

Connect entities with stable identifiers

An @id lets multiple blocks refer to the same entity. An article can identify the organisation that publishes it without creating a different company on every page.

Build a coherent graph:

  • the website references the organisation;
  • articles reference their authors and publisher;
  • local pages reference the correct establishment;
  • offers reference the relevant product or service;
  • URLs, names and profiles remain consistent across pages.

This consistency prevents several contradictory entities from describing the same business.

Rules to follow

  1. Describe visible content. Important properties must not invent hidden or misleading information.
  2. Use the relevant page. Product markup belongs on the page for that product, not a generic list with no detail.
  3. Follow required properties. Every Google search feature has its own documentation.
  4. Keep values synchronised. Prices, stock, hours and dates change.
  5. Do not mark up hidden content. Visitors should be able to find the information described.
  6. Avoid spam. Fake reviews, unsuitable types and exaggerated data can remove eligibility or trigger a manual action.

How to implement Schema.org

On a CMS, an SEO plugin can generate a useful foundation, but inspect the output. Multiple plugins may produce competing blocks with different logos, canonical URLs or entity types.

A robust implementation follows these steps:

  1. inventory page templates and available data;
  2. select useful types and properties for each template;
  3. connect values to fields genuinely maintained in the CMS;
  4. generate one coherent JSON-LD graph;
  5. test standard, incomplete and multilingual cases;
  6. monitor errors after every website change.

For a store, automate price and availability from the same source that feeds the interface. Duplicate manual entry will almost certainly diverge.

Test and monitor the markup

Use two complementary tools:

  • Google’s Rich Results Test checks eligibility for supported search features;
  • the Schema Markup Validator checks vocabulary, including types without a dedicated Google rich result.

After publishing, review the available Search Console reports and inspect representative URLs. Passing in staging is not enough if caching, consent or a script later changes the public code.

Common structured-data mistakes

  • several plugins generate conflicting entities;
  • price or availability no longer matches the page;
  • an unsuitable type is selected to chase a rich result;
  • reviews come from a non-compliant source or are not visible;
  • the author is only a text string with no clear identity;
  • dates are artificially refreshed;
  • JSON syntax breaks after a change;
  • language versions share inconsistent URLs or values.

Structured data and AI engines

AI systems may consume many sources and formats, but no serious documentation supports a promise that a Schema.org block will cause a citation. Coherent entities, identifiable authors and structured information can make automated interpretation easier; they remain part of a broader picture that includes useful content, reputation, technical access and external mentions.

Treat structured data as a quality and interoperability layer, not a secret way to “rank in ChatGPT”. The guide to visibility in ChatGPT, Gemini and Perplexity explains the wider approach.

A priority action plan

  1. Business: one consistent Organization or LocalBusiness entity.
  2. Navigation: BreadcrumbList on deeper pages.
  3. Content: Article or BlogPosting with genuine authors and dates.
  4. Commerce: Product and Offer synchronised with the catalogue.
  5. Control: automated tests and Search Console monitoring.

Start with templates producing the most traffic or revenue. Ten poorly maintained types are not better than three reliable, useful types.

Frequently asked questions

Does Schema.org directly improve rankings?

Google does not describe markup as a ranking guarantee. It supports understanding and may make a page eligible for enhanced presentation, which can affect visibility and click behaviour.

Do you need a WordPress plugin?

No. JSON-LD can come from a theme, custom development or a plugin. The important part is preventing duplicates and connecting values to reliable data.

How many types can one page contain?

As many as genuinely needed to describe its content and relationships. Adding types without useful information mainly increases the risk of inconsistency.

Make your website clearer to search engines

VulcainDesign can audit existing markup, resolve conflicts and build a Schema.org graph suited to your pages, CMS and SEO objectives. Request a technical SEO audit to turn errors and opportunities into a reliable implementation plan.

Useful sources: Google Search Central - understanding structured data, general guidelines and the Schema.org vocabulary.

Tags: AI SEO Google Google Analytics JSON-LD Rich results Schema.org Structured data Technical SEO
Sébastien
About the author

Sébastien

Freelance web developer and designer in Toulouse, France, since 2009. I design and code every site myself, from the brief to launch, for small businesses, tradespeople and independent professionals who want a website that brings in clients, not just visits. 17 years in the trade, 18 Google reviews at 5/5.

See my background →