Home·Blog·Schema.org for SEO and GEO — 7 types, real facts.
Expert guide·7 min read

Schema.org for SEO and GEO — 7 types, real facts.

Sources and copy checked October 11, 2026.

7 min read· ~1437 words· published May 26, 2026

Structured data describes a page’s content: a business, article, product or app. It can help search understand those facts, but does not guarantee rankings, a rich result or AI citations. Start with the page’s purpose, not the longest list of schema types.

Which 7 Schema.org types matter for GEO?

Choose Schema.org types for the page’s content. Match JSON-LD to visible facts. Test vocabulary and Google eligibility separately; neither valid markup nor more types guarantees an AI citation.

  • Choose the type for the page’s purpose.
  • Match JSON-LD to visible facts.
  • Do not describe a team as Person.
  • Google FAQ rich results are retired.
  • Do not add all seven types everywhere.
  • Do not invent prices, ratings or authors.
  • Separate vocabulary from Google eligibility.
Schema.orgJSON-LDBlogPostingFAQPageOrganizationProductSoftwareApplicationPersonBreadcrumbListWikidata
Contents 13

What Schema.org does for SEO and GEO

Schema.org is a vocabulary of entity types and properties. JSON-LD is one format for expressing them; Google also supports Microdata and RDFa. Markup does not replace accessible HTML, indexing or a useful answer for the buyer.

Separate three questions: is the JSON valid, is the Schema.org type appropriate, and does the page meet a particular Google feature’s requirements? Passing every check still does not guarantee display. Google AI Overviews does not require a separate AI schema stack.

PageRelevant typeCheck against the page
BusinessOrganizationName, URL, contacts
ArticleArticle / BlogPostingAuthor, headline, dates
Questions and answersFAQPageVisible questions and answers
ProductProduct + OfferPrice, currency, availability
AppSoftwareApplicationFunction, environment, terms
Expert profilePersonActual person and role
Page pathBreadcrumbListLabels, URLs, order

Organization: a business, not a keyword collection

Describe the actual business: its name, URL, logo and available contacts. A stable @id connects the article’s publisher and other references to the same organization. Do not create a different company for each locale or page.

sameAs should point to profiles identifying the same business, not any article mentioning the brand. Add an address, founding date or legal name only with accurate data. knowsAbout and areaServed do not prove expertise or act as a list of ranking keywords.

Article and BlogPosting: authors and honest dates

For an article, describe its headline, relevant image, original publication date and actual author. Google accepts Person or Organization. A collective UPLIFY article must not turn into an invented individual in its markup.

dateModified reflects a substantive update; do not rewrite datePublished for every release. An author URL helps identify the author. Do not add reviewedBy, credentials or dateReviewed without a genuine basis. These properties do not automatically establish trust.

FAQPage: reader questions, not a promised search accordion

Mark up only questions available on the page and their matching answers. An answer can sit inside an accordion if readers can expand it. Do not put hidden promises or conditions only in JSON-LD.

Google retired FAQ rich results on May 7, 2026. FAQPage remains a Schema.org type, but you cannot promise a Google FAQ result. There is no universal five-question minimum or 50–70-word rule: the reader’s task determines the number and length.

Product and Offer: an item and its selling conditions

Product describes a specific item; Offer describes an offer to buy it. Its name, image, currency, price and availability must match the current page. Do not substitute zero for a price available on request or describe an entire catalogue as one product.

Use real SKU, GTIN or MPN identifiers; do not invent them. Reviews and ratings must be genuine and meet the relevant type’s rules. The self-serving ratings restriction for Organization/LocalBusiness does not mean every product review must come from another website.

SoftwareApplication: an app, not every service

For a web app, describe its actual function, name, category and supported environment. SoftwareApplication derives from CreativeWork; it is not a Product subtype. A team’s store setup service does not become software simply because it uses automation.

Google software-app rich-result eligibility requires name, offers.price and a genuine rating or review under its rules. Do not fabricate missing data for a green test. A semantically valid app description may still fall short of this particular rich result’s requirements.

Person: an actual person and verified roles

Describe the author or expert whose profile readers can access: name, role and URL. worksFor and sameAs must reflect actual relationships and profiles. Do not automatically assign the founder as author of every article.

List a credential only when it is supported. Use Organization for a company or collective. The presence of Person alone does not prove experience, a review of the article or preferential treatment in AI answers.

BreadcrumbList: a clear path through the site

Breadcrumbs show where a page sits: home, blog, article. Match names and URLs to the real navigation and use consecutive position values. Do not add nonexistent sections just to place keywords.

Each locale needs its own labels and accessible URLs. Check canonical and reciprocal hreflang separately; BreadcrumbList does not replace them. An article does not need product entities for every e-commerce platform it mentions.

sameAs and Wikidata: check identity

A sameAs URL should unambiguously identify the same entity. A deleted or renamed profile, or one belonging to a namesake, does not help. Keep the source and date of each external identity check.

Do not create a Wikidata item solely as an SEO link or promise AI citations once it exists. Wikidata’s community sets its own criteria; a fixed number of press mentions is not a universal threshold. UPLIFY’s editorial requirements are linked in the policy below.

Build and validate markup without conflicting duplicates

First inspect what the CMS, theme and plugins already produce. Multiple blocks are allowed; conflicting prices or author identities are not. Connect the same entity using a stable @id. Do not place all seven types on every page.

Check JSON syntax, vocabulary in Schema.org Validator and supported Google features in Rich Results Test. Then inspect HTML and the rendered DOM, including JavaScript data, and URL Inspection. Record URL, locale, type, issue, owner and recheck date. Recheck after prices or templates change.

Teaching example: JSON-LD

The example below describes a fictional teaching article on example.com. It is not client data or ready-to-use markup for your site. Replace facts with your page’s visible content; do not paste it without checking.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/guides/structured-data/#article",
  "headline": "Teaching example: structured data",
  "url": "https://example.com/guides/structured-data/",
  "author": {
    "@type": "Organization",
    "name": "Example editorial team",
    "url": "https://example.com/"
  }
}

Schema.org and JSON-LD questions

What is Schema.org markup?

It describes page entities using standard types and properties. Product identifies an item, Offer its selling conditions and Article a publication. JSON-LD is a format for expressing that description, not a separate set of SEO rules.

Does schema guarantee higher rankings or GEO citations?

No. Markup helps describe content and may establish eligibility for supported search features. Correct code does not guarantee display, higher rankings or a mention in ChatGPT, Perplexity or Google AI Overviews.

How do Schema.org Validator and Rich Results Test differ?

The first checks structured data against the Schema.org vocabulary. The second focuses on Google-supported rich results. A type can be semantically valid without such a feature. Neither tool automatically verifies the truth of every fact.

Should every page include all seven types?

No. An article needs information about its publication, authors and path; a product page needs the current item and offer. Add FAQ where questions are visible. Connect businesses and people where relevant without duplicating entities.

Can I add aggregateRating without reviews?

No. Do not invent a rating or review count. Real data must also match visible content and the specific type’s rules. If the necessary facts are unavailable, do not claim eligibility for a rich result.

Can JSON-LD be added through JavaScript?

Yes, Google can process dynamically injected structured data. Check the rendered page and URL Inspection, not just initial HTML. Test access for other systems separately; do not assume they share Google’s capabilities.

Related practical checks

Sources and validation rules

Check your website’s structured data

Send your site URL, priority market and task. We work with stores, services, B2B and SaaS; agree checks and scope without a citation promise.

Add details (optional)

By sending your request, you agree to the processing of personal data.

Telegram →Message us on WhatsApp

Reply: 1 business dayNo spamNo obligation