Schema markup and AEO : a practical guide for businesses

Your site may include all the information it needs: services, products, prices, address and opening hours.

The question is whether machines clearly understand what each piece of information means, or whether they have to work it out.

That's what schema markup helps with. It's structured data added to the page's code that states, in a specific way, what each element represents.

This is also where a common misunderstanding starts.

Schema is often presented as the mechanism that will put your business into ChatGPT's answers. That isn't true.

Schema is technical infrastructure, not a complete strategy. It helps machines understand your page's content correctly, but it doesn't make your business stand out on its own.

It's worth implementing, but it doesn't guarantee that an AI engine will cite your business.

Let's look at it in practice.

What is schema markup?

Schema markup is code behind the scenes of the page that states what each key element of the content represents.

For example, it specifies:

• what the company's name is,
• what its address is,
• which number corresponds to a product's price,
• what the opening hours are,
• which part of the page is a question and which is the matching answer.

The visitor doesn't see this code. Machines, though, read a clear statement, instead of trying to infer what each element means from its position and format on the page.

The key difference is explicitness.

A person sees "€12.50" under a product and understands it's the price.

A machine may have to work out whether the number refers to:

• the product's price,
• shipping,
• an old price before a discount,
• some other charge.

Schema clears up the number's meaning and states that it's the product's price in euros.

That doesn't mean the machine automatically treats every piece of information declared in the schema as correct.

It still examines the visible content and the page's overall reliability. Schema's role is to state clearly what each element means.

The code is usually written in a format called JSON-LD. Google recommends this format because it's easier to manage and maintain.

It does, though, need to be updated when the details it describes change, such as:

• prices,
• opening hours,
• the address,
• services,
• contact details.

It isn't something you add once and then ignore while the site's content changes.

Above all, schema doesn't replace real content.

If a page doesn't include clear, useful and truthful information, no code can fill that gap.

Schema describes content that already exists. It can't stand in for missing substance.

Which schema type does each page need?

For each page you choose the most specific schema type that correctly describes its content.

For a dental practice, for example, you use the Dentist type, which belongs to the more specialised categories of LocalBusiness.

The more specific and precise the type, the more clearly you describe what the page's entity represents. That helps you use properties that genuinely fit the business or content, and follow the requirements of the platform you want to support more correctly.

A page can also include more than one connected entity and different types of structured data, depending on its content.

• Hotel or accommodation — Hotel — Key fields: address, geo, starRating, amenityFeature
• Restaurant or bar — Restaurant — Key fields: address, openingHoursSpecification, servesCuisine, priceRange
• Café — CafeOrCoffeeShop — Key fields: address, openingHoursSpecification, priceRange
• Medical clinic — MedicalClinic — Key fields: medicalSpecialty, address, openingHoursSpecification
• Physician or medical practice — Physician — Key fields: medicalSpecialty, address, openingHoursSpecification
• Dental practice — Dentist — Key fields: address, openingHoursSpecification, telephone, medicalSpecialty
• Law firm — LegalService — Key fields: address, areaServed, telephone
• Accounting firm — AccountingService — Key fields: address, areaServed, telephone
• Physical store — Store or a more specific subtype — Key fields: address, geo, openingHoursSpecification
• Product page offered for sale — Product with Offer — Key fields: name, sku, brand, offers.price, offers.priceCurrency, offers.availability
• Article or guide — Article or BlogPosting — Key fields: headline, datePublished, dateModified, author
• Company details — Organization — Key fields: name, url, logo, sameAs, contactPoint
• FAQ page with visible questions and answers — FAQPage — Key fields: mainEntity, Question, acceptedAnswer

availableService isn't a property of the Dentist type. In Schema.org it's used on the Hospital, MedicalClinic and Physician types and takes specific medical values, such as MedicalProcedure, MedicalTest or MedicalTherapy.

If a dental practice's services need to be described, they can be declared as separate Service entities linked to the practice through provider, or through a properly structured OfferCatalog.

For an accounting firm, the AccountingService type is more precise and preferable to the generic ProfessionalService, which has been deprecated in Schema.org because of confusion with Service.

In practice, a page can combine more than one schema type.

A restaurant, for example, might use:

• Restaurant on pages that present the business's details,
• Article on its article pages,
• FAQPage on pages that genuinely function as FAQs and present visible questions and answers.

A stable @id can be used to connect different references to the same entity consistently. It isn't, however, a mandatory Google requirement for LocalBusiness.

The rule isn't "put Organization on every page."

The rule is to connect the entities correctly, so you don't declare the same business in different, conflicting ways.

A correct Restaurant example might look like this:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.gr/#restaurant",
  "name": "The Restaurant Name",
  "url": "https://example.gr",
  "telephone": "+302310000000",
  "priceRange": "€€",
  "servesCuisine": "Greek",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Street",
    "addressLocality": "Thessaloniki",
    "postalCode": "54622",
    "addressCountry": "GR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 40.6293,
    "longitude": 22.9503
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": [
      "Tuesday",
      "Wednesday",
      "Thursday",
      "Friday",
      "Saturday",
      "Sunday"
    ],
    "opens": "12:00",
    "closes": "23:00"
  }]
}

There are two things to watch in the data format.

Values are written the way the machine expects, not the way they usually appear in everyday text.

For example:

• the currency is declared as EUR,
• decimals are written with a dot, like 12.50,
• availability is declared with standard values like https://schema.org/InStock,
• days are declared with Schema.org's standard DayOfWeek values, such as Monday, or the full URL https://schema.org/Monday.

Translated free-text values, such as Δευτέρα, aren't used in the dayOfWeek property.

At the same time, @id can act as a stable identifier for the business and help systems connect different references to the same entity consistently.

For a product page, a basic example might be:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Koroneiki Olive Oil 500ml",
  "sku": "OIL-500-KOR",
  "brand": {
    "@type": "Brand",
    "name": "Your Brand"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.gr/products/oil-500-kor",
    "price": "12.50",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

You don't need to write the code by hand.

Most CMSs and many SEO plugins can generate it automatically. Automatic generation, though, doesn't guarantee the implementation is correct.

A tool might:

• pick an overly generic type,
• pull in the wrong details,
• create a second schema that conflicts with the theme's,
• use old or incomplete information.

In these cases, errors are common. That's why checking the implementation is essential.

Does schema help AI engines cite you?

Its effect appears to be smaller than it's often presented.

The Ahrefs study tracked 1,885 pages that added JSON-LD between August 2025 and March 2026 and compared them with 4,000 control pages. It measured citations in Google AI Overviews, Google AI Mode and ChatGPT for 30 days before and 30 days after the schema was added.

Adding schema was associated with:

• a 2.4% increase in citations in Google AI Mode,
• a 2.2% increase in citations in ChatGPT,
• a 4.6% decrease in AI Overviews.

The two positive changes were statistically indistinguishable from zero. AI Overviews recorded a small relative drop, but the researchers themselves note that it can't be attributed to schema with any certainty.

There's also an important limitation: the study looked at pages that were already heavily cited by AI systems. Every page in the sample had more than 100 citations in AI Overviews before the schema was added.

So the study doesn't prove what happens for new or uncited pages. It also examined different schema types together, not the effect of each type separately.

The safe conclusion isn't that schema has no value.

The conclusion is that it shouldn't be presented as a direct way to raise citations from AI engines.

Pages that get cited by AI engines are indeed more likely to have schema. But that's a correlation, not proof that schema caused the citation.

Schema is found more often on sites that are better maintained overall, include higher-quality content, and have more mentions and links from other sources.

So it's a sign of the site's overall care, not necessarily the reason a page gets cited.

Google itself states that structured data isn't required for its generative AI features, and that there's no special schema for AEO.

It emphasises:

• useful, original content,
• the page's crawlability,
• the overall user experience.

The reason is also technical.

Google has processed JSON-LD systematically for years. For Google, structured data must correspond to the page's actual content.

For AI answer engines more broadly, there is no public documentation that lets us assume JSON-LD on its own will be used in a particular way. Substantive information that you want users — and potentially machines — to understand is safer when it also appears clearly in the visible content.

That doesn't mean schema is useless.

Its correct role is:

• to offer technical clarity,
• to help identify the business clearly,
• to make a page eligible for the rich results that are still supported.

What changed with FAQPage?

Until recently, when a page used FAQ schema, Google could show its questions in expandable boxes under the page's result.

These were the so-called FAQ rich results.

On 7 May 2026, Google stopped showing FAQ rich results in search results. On 15 June 2026 it also removed the related documentation from Google Search Central.

As this appearance is no longer supported, FAQPage markup no longer produces an FAQ rich result on Google.

The FAQPage type wasn't removed.

It remains valid and doesn't need to be removed simply because Google no longer shows FAQ rich results. It just no longer gives you a separate appearance in search results.

This change had already started to show in 2023.

From August 2023, Google had limited FAQ rich results mainly to government and health sites.

In May 2026, FAQ rich results were withdrawn completely.

What didn't change is that FAQPage remains a valid schema.org type. It remains available as a schema.org type. Whether another engine or service reads or uses it depends on that service and shouldn't be assumed.

It stopped offering a separate appearance in Google, but kept its validity as a schema type.

The core value stays in the page's real, visible questions and answers. Those can be read by people and machines, whether markup is present or not.

FAQPage can be kept where there are real questions and answers, provided it's implemented correctly and matches the visible content exactly.

An example might be:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "How much does an AEO audit cost?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "The answer that accurately corresponds to the page's visible content."
    }
  }]
}

In June 2025, Google also announced the retirement of seven more results features based on structured data, from Course Info to Vehicle Listing.

It clarified that the change wouldn't affect pages' rankings. Those specific special appearances would simply stop being shown over time.

The rich result types Google supports change over time.

The conclusion isn't "don't use schema."

The conclusion is that you shouldn't build your whole strategy on one specific rich result.

Must schema match what the visitor sees?

Yes.

A mismatch with the visible content can make structured data ineligible for rich results or put it in breach of the relevant guidelines.

You must not declare:

• reviews that don't appear on the page,
• ratings the visitor doesn't see,
• prices different from the real ones,
• services that aren't presented,
• questions that don't exist in the visible content.

Google itself asks that structured data describe the page, not add information that stays hidden from the user.

Structured data must correspond accurately to the questions, answers and substantive claims the visitor sees. It must not add different, hidden or misleading information.

Word-for-word matching isn't always required, when the same information is expressed in a standard, machine-readable form.

If the schema doesn't match the page, at best it may be ignored.

For serious or repeated violations of the guidelines, a manual action from Google can follow.

The correct order is always the same:

1. You create the real content.
2. You show it clearly on the page.
3. You add the schema that describes it.
4. You check that the visible content and the schema convey the same real information consistently.

You don't use schema to declare information more favourable or more impressive than what the customer actually sees.

How do you check schema is applied correctly?

You can use three free tools, each serving a different purpose.

Rich Results Test

Google's Rich Results Test shows whether Google recognises structured data that can be used for a supported rich result.

A valid result means the page meets the technical conditions. It doesn't mean the rich result will definitely appear.

Schema Markup Validator

The schema.org Schema Markup Validator checks the schema's syntax and structure more generally.

It can also check types that aren't tied to a Google rich result.

Search Console

Search Console shows problems across many pages at once, but only for the schema types Google tracks and reports.

It isn't a general validator for every schema that might exist on the site.

When you check, you look at:

• whether the schema is detected,
• whether the correct type was chosen,
• whether required fields are missing,
• whether the values have the right format,
• whether there are two declarations describing the same information in different ways.

The four most common errors are these.

1. Too generic a type

For example, Organization or LocalBusiness on a dental practice instead of Dentist.

The generic type isn't necessarily wrong, but it doesn't let you use all the specialised fields that add value.

2. Mismatch with the page

For example:

• different opening hours in the code and in the footer,
• ratings that appear nowhere,
• a different price in the schema and on the product page.

3. Incomplete fields

For example:

• a product page that offers the product for sale but declares a price or availability without a properly structured Offer,
• Article without useful fields like datePublished, author or image,
• LocalBusiness with an incomplete address.

When required fields are missing, the object may not be eligible for the corresponding Google rich result.

It may, however, stay syntactically valid, or have other elements of it used.

4. Duplicate or conflicting schema

The site's theme might declare one schema and a plugin create a second, with a different phone number, a different address or a different business type.

One correct, consistent schema is worth more than three different, half-correct declarations.

The fact that a plugin shows a "schema enabled" label doesn't mean the implementation is correct.

One of the most useful checks can be done even without a tool.

Read what the schema declares and examine each piece of information separately:

• Does it actually appear on the page?
• Is it up to date?
• Does it match what the visitor sees?
• Is it declared the same way in all the related places?

If the schema includes substantive information or a claim not supported by the page's visible content, that information must either be added clearly to the page or removed from the schema. Technical elements, such as a stable @id, a sameAs URL or a standard value, don't need to appear word-for-word to the visitor.

When is schema not a priority?

When the site's basic problems haven't been solved yet.

If your site doesn't include substantive content, implementing schema shouldn't be the first priority.

No markup can turn three generic paragraphs into a reliable, useful source.

First you have to clarify:

• what the business does,
• who it serves,
• why someone should trust it,
• what real questions customers ask,
• how the business answers them.

Schema comes afterwards, to describe this information to the machines.

The same applies when there are basic technical problems.

A site that loads in eight seconds, pages that don't work properly on mobile devices, and content that can't be found by crawlers are more important problems.

These have to be dealt with before adding one more LocalBusiness block.

You also need a clear picture of maintenance.

In a small business, the basic schema is implemented at first and then needs checking when these change:

• prices,
• contact details,
• opening hours,
• services,
• the site's structure.

If you keep one thing from this article, keep the right order.

Schema isn't decoration, and it isn't a trick for better rankings.

It's how you describe, in a standard form, content that already exists and appears clearly on the page.

Declare the business type correctly, choose the right type for each page, keep the data updated and in full agreement with what the visitor sees, and re-check the implementation after every substantive change.

Businesses that have answered their customers' real questions clearly and publicly create a better foundation for machines to understand what they offer and when they're relevant to a query.

Schema gives machines a standardised description of the entities and information already present on the page.

It doesn't write them for you.

At Praion we don't treat schema as a separate task. We design it together with the content and the structure of the site, because that's the only way it can gain real value.

Schema markup can improve how machines recognise a page's content. It doesn't guarantee a specific ranking or rich-result appearance. AEO aims to improve a business's ability to be found, understood and potentially appear in relevant AI answers — it doesn't guarantee a citation, recommendation, ranking or result. Answer engines continuously change how they select sources.