Schema Markup for SEO: What Worthwhile Sites Actually Implement

Most schema markup for SEO is theater. Someone installed a plugin, ticked twelve types, and called it technical work. The JSON-LD in the source does not match the page. The ratings are invented. The FAQs exist only in the script tag. Google has been telling people not to do this for years. A lot of sites still do it.

Worthwhile sites implement a short list of types that Google actually documents, and they keep those types in lockstep with what a human can see. That is the whole job. Schema does not create rankings out of thin air. It helps Google understand an already crawlable page, and it can unlock specific search features when the markup is eligible.

Start with Google's own inventory, not a schema generator's upsell. The current list of features lives in the Search Gallery. If a type is not in that gallery, do not add it because a plugin offered a checkbox.

What schema markup for SEO actually buys you

Structured data is a machine-readable description of the page. Google prefers JSON-LD. You put it in the HTML. Google may use it to understand the page and, for some types, to show a richer result. Google does not guarantee the rich result. That is written into the documentation and it is the first thing agencies forget to tell a client.

For a typical company marketing site, the win is clarity, not a magical SERP takeover. Article markup can help Google pick a better title, image, and date. Breadcrumbs can show a path. Organization and Person markup help Google connect the site to a real entity. WebSite markup describes the site itself. None of that replaces unique titles, internal links, or pages that answer a search.

If the HTML is a mess, schema will not save it. If the HTML is clear, schema should describe that page and nothing else.

This article is not an AEO playbook. Answer engines care about extractable answers and citations. That is a content architecture problem. Schema is the smaller, stricter job of labeling what is already on the page for Google Search. Keep those jobs separate or you will ship markup for a feature Google no longer shows.

The only rule that matters

Only mark up content that is visible to the user. Only use types Google documents for Search. Only include properties you can stand behind if a reviewer opens the page and the Rich Results Test side by side.

Google's general structured data guidelines are the policy, not a suggestion. Misleading structured data can get ignored or, in worse cases, trigger a manual action. Fake reviews, hidden FAQs, and markup that describes a different page than the URL are the usual ways teams get there.

• Match the type to the page: a blog post is BlogPosting or Article, not Product.
• Match the properties to visible text: headline, dates, author, breadcrumb labels.
• Prefer one JSON-LD graph you control over three plugins fighting in the head.
• Delete types you cannot explain in one sentence.

Article and BlogPosting

If you publish articles, this is the type worth implementing well. Google supports Article, NewsArticle, and BlogPosting. For a personal or company blog, BlogPosting is the honest type. NewsArticle is for news. Do not pick NewsArticle because it sounds more important.

Google's Article structured data documentation lists recommended properties, not a pile of required fields. Add the ones that apply: headline, image, datePublished, dateModified, and author. That is enough for most marketing blogs.

Author markup that does not lie

If the byline on the page says Zlatko Marjanovic, the author object should be a Person with that name and a URL that identifies the person. That URL can be an about page or a profile. Do not stuff the publisher name into author.name. Do not merge two authors into one string. Google's author best practices are explicit on both points.

If a CMS defaults the author to the company on every post, fix the CMS. Schema that says Organization wrote a first-person essay is worse than no author markup. The visible page and the JSON-LD have to agree.

Dates and images

Use ISO 8601 timestamps. Include timezone if you can. datePublished is the first public date. dateModified moves when the advice changes, not when you fix a typo. Images should represent the article, be crawlable, and meet Google's size guidance if you care about article enhancements. A tiny logo is not an article image.

BreadcrumbList

Breadcrumbs are useful when they exist in the UI. Mark them up when the trail is on the page. Do not invent a BreadcrumbList that describes an information architecture nobody can click.

Follow Google's breadcrumb documentation. Each item needs a name and an item URL, in order, ending at the current page. The visible trail and the markup should use the same labels.

On a Next.js or Webflow blog, generate breadcrumbs from the real route: Home, Blog, Article title. If the design hides breadcrumbs on mobile, they still need to exist in the DOM if you mark them up. Hidden-only markup is the same class of problem as FAQ schema with no FAQs.

Person, Organization, and WebSite

These three types describe the entity, not the article body. They belong on the site in a consistent way. They do not belong as twelve duplicated blobs on every URL unless you know why.

Organization

Use Organization when the publisher is a company. Google's Organization documentation is the source. Name, URL, logo, and sameAs links to real profiles are the useful core. SameAs should be profiles you actually control. Do not add a Wikipedia URL you do not have, and do not add a fake Crunchbase page.

A personal site can still have an Organization node if there is a studio entity, plus a Person node for the public face. Keep the relationship honest. Person worksFor Organization, or Organization has a founder Person. Do not mark a freelancer as a multinational.

Person

Person markup is how you connect bylines, the about page, and the sameAs set. Name, URL, jobTitle, and image should match the about page. If you claim expertise, the visible bio has to support it. Schema is not a place to become a Principal Architect overnight.

WebSite

WebSite describes the site. Name and URL are the baseline. The Sitelinks search box feature is a separate, optional property: potentialAction with SearchAction. Only add it if site search works, returns real results, and the target URL is documented correctly.

Google's sitelinks search box documentation is easy to fail. If your search is a JavaScript filter that does not have an indexable results URL, skip the SearchAction. A broken search box in the SERP is worse than no search box.

What not to implement

This is the section most schema posts skip, because the skipped types are how tools justify their price.

FAQPage is not a Google rich result anymore

As of 7 May 2026, FAQ rich results no longer appear in Google Search. Google documented this on the FAQPage structured data page. Search Console reporting and Rich Results Test support were scheduled to follow. Do not add FAQPage markup to chase a SERP feature Google retired.

Visible FAQs on a page can still help a human and can still be cited by other systems. That is content. It is not a reason to ship FAQPage for Google rich results. I do not enable FAQ schema on this site for that reason. If you already have FAQPage JSON-LD, Google has said unused structured data does not by itself cause Search problems, so you do not need a panicked deletion project. You also should not add more of it as an SEO tactic.

No fake ratings, no fake reviews

AggregateRating and Review markup belong on pages with real, eligible reviews under Google's review snippet policies. Self-serving reviews, invented star ratings, and '5.0 from 12 happy clients' with no visible reviews are spam. Do not put them on a service page to look trustworthy. Do not let a theme add them by default.

HowTo, Product, Event, and the rest

HowTo rich results were already restricted. Product belongs on product pages with real offers, not on a consulting homepage. Event belongs on events. LocalBusiness belongs on a business with a real location you want in local features. If the page is not that thing, skip the type. A personal consulting site does not need Product with a fake offer catalog.

How to implement JSON-LD without drifting

Generate schema from the same fields the page renders. If the title in the CMS is the H1, it is also headline. If the author reference is the Person, it is also author. Hand-maintained JSON-LD in a custom code block will rot the first time someone edits the article in the CMS and forgets the snippet.

1. Pick JSON-LD. Do not mix Microdata, RDFa, and JSON-LD on the same template unless you enjoy debugging.
2. Put Article or BlogPosting on article templates only.
3. Put BreadcrumbList on templates that render breadcrumbs.
4. Put Organization and WebSite in a global component you control, once.
5. Put Person on the author surface and reference that Person from articles.
6. Validate a homepage, a service page, and an article after every template change.

On Next.js, I keep schema in the same data layer as metadata. On Webflow, I either bind CMS fields into a single embed or inject a small, reviewed snippet. I do not paste a 400-line generator output into project settings and hope.

If you are already doing a technical pass, schema is one line item, not the whole audit. The crawl, canonicals, and redirects still come first. I keep that sequence in the technical SEO audit checklist.

Validate it, then keep it from rotting

Use the Rich Results Test on the live URL. Use URL Inspection in Search Console to see what Google actually got. Check the Unparsable structured data report if it appears. Then re-test after the next design release, because schema often lived in an old embed that the new component library never received.

Eligibility is not appearance. A valid BlogPosting test does not mean you will get a special layout. It means you did not ship garbage. That is the correct bar.

If you want schema that supports retrieval and citations, that is a different article. Start with AEO strategy for B2B sites for architecture, then come back here for the types Google still documents. If you need someone to implement the markup instead of writing a slide about it, that is closer to a technical SEO consultant than a content agency.

If your source is full of types you cannot map to the page, send the URL. I will tell you what to keep, what to delete, and what to generate from the CMS so it does not drift again.