Have you ever had this experience: searching for a question, and in the results someone else’s answer has an FAQ card, star ratings — visually it immediately catches your eye, while your own page is just a dry line of title? Behind this is多半 structured data at work. Mark it right, and rich results, knowledge panels, FAQ cards can all appear — click-through rate takes off directly. But marking it wrong is worse than not marking at all — you’ll be judged as manipulating, and rich result eligibility gets revoked directly. Not worth it.
Many site owners either don’t dare to mark, or mark randomly trying to蹭 cards. This article explains the correct approach to structured data from scratch — format, types, verification, all connected in one line.
What is structured data
Structured data is a machine-readable description written in schema.org vocabulary, telling search engines “this is the title, that’s the author, here’s the price.” JSON-LD places this description inside a <script> tag, doesn’t intrude into the body HTML — cleanest, and won’t easily get broken by layout changes.
It doesn’t change how the page looks, it only gives crawlers extra clues. Mark accurately, and search engines more easily understand content meaning,进而 showing star ratings, prices, FAQ and other rich result styles in results — visually more eye-catching, CTR rises accordingly. This is the most direct and stable benefit source of structured data.
Why use JSON-LD
Early on there was Microdata and RDFa, embedding markup into HTML tags — during maintenance they easily get tangled with styles, and break as soon as you change the template. JSON-LD is an independent block, decoupled from layout — no matter how the frontend changes, it doesn’t affect the markup. It’s now the absolute mainstream choice, migration cost is low, and teams can pick it up fast.
Google also explicitly recommends JSON-LD. Place it in <head> or <body>, crawlers can read both. Migrating old site microdata to JSON-LD is a one-time but worthwhile technical debt cleanup — don’t let old markup continue planting mines in the dark.
Common type reference
Article marks the article body and author; FAQPage marks Q&A pairs — easiest to get FAQ rich cards; HowTo marks steps; Product/Offer marks products and prices; BreadcrumbList marks breadcrumbs. Choose according to the content’s real form, don’t mismatch — otherwise you’ll confuse the signals instead, and crawlers will understand even less.
One page can carry multiple types at the same time — for example, an article page marks both Article and BreadcrumbList. Organize types clearly with @graph, so search engines can simultaneously get both “this is an article” and “its position in the site” — two layers of information, more complete understanding.
Markup must match visible content
This is a hard rule: what’s written in schema must actually be visible on the page. Marking FAQ but the page doesn’t have that question, marking ratings but there’s no review system — both will be treated as fraud. Light case: rich result eligibility revoked; heavy case: penalized, all time invested previously goes down the drain.
Many people fabricate ratings and reviews to “蹭 rich results” — this equals actively stepping on the red line. Markup is a magnifying glass, it reflects real content; don’t force-mark what the content doesn’t have, otherwise sooner or later the algorithm will catch you, backfiring on the whole page’s rankings, and other optimizations you’ve done get discounted too — very not worth it.
Deployment and verification
After writing, use Google’s Rich Results test tool, paste the URL or code, check for syntax errors and missing fields; GSC’s “Enhancements” report continuously monitors pages with deployed markup, errors are汇总 here — saves the huge workload of manually checking page by page.
Verification isn’t one-time: template changes, redesigns can all cause JSON-LD to misalign or go missing. Include it in release checks, regularly review GSC Enhancements report — rich result eligibility can stay stable long-term. Don’t wait until the display style drops before checking, by then traffic has already been actually affected for several days.
Common mistakes
Mistake one: type doesn’t match content, randomly marking FAQ to蹭 cards. Mistake two: JSON syntax errors (missing a bracket, quote), the whole block fails. Mistake three: markup content inconsistent with page, judged as manipulation. Mistake four: multiple types’ @graph written messily, relationship confusion leaves crawlers grasping at straws.
Mistake five: only deploy without verifying, keeps reporting errors after launch without knowing. All of these can be avoided with four steps: “write correct types + content consistent + test with tools + continuously monitor reports” — the most worry-free approach for structured data, and avoids turning something that should add points into something that gets you penalized.
Coordination with site architecture
Structured data is built on individual pages, but its effect depends on whether the whole site can be crawled smoothly. If the architecture has multi-level deep links and important pages are hidden deep, even the best schema might not发挥 because crawlers can’t reach it — so markup and architecture need to be planned together.
I recommend getting your flat site architecture sorted first, so important pages are closer to the homepage and internal links are smoother, then add schema. Architecture solves “can reach,” schema solves “can understand” — running both lines in parallel is the complete approach structured data should have, don’t only do half.
Difference between structured data and OG tags
Some people confuse schema and Open Graph. OG is for social sharing, determines what a link looks like on WeChat, X; schema is for search engines and AI, determines how content is understood. They don’t conflict — social cards use OG, search rich results use schema, each handles its own area.
A common misconception is thinking that adding OG means you don’t need schema. Social and search are two different things — no matter how beautiful OG is, it won’t give you FAQ cards or star ratings. You need to play both cards: OG manages the sharing facade, schema manages search performance — combined, content shines both off-site and on-site. Miss one card, and content loses out on one end, exposure and clicks both get discounted.
Figure: Structured Data Guide Key Points (compiled by YunyingGO)
| Type | Suitable content | Rich result benefit |
|---|---|---|
| Article | Articles | Author/body endorsement |
| FAQPage | Q&A | FAQ card |
| HowTo | Steps | Step rich result |
| Product | Products | Price/rating stars |
Landing in five steps
- Migrate old site Microdata/RDFa to JSON-LD, independent block for easy maintenance
- Choose types by content form, Article for articles, FAQPage for Q&A
- Verify page by page that markup content matches visible content, delete fabricated fields
- Use Rich Results test + GSC Enhancements report to verify and continuously monitor
- Include structured data checks in every release process, prevent redesigns from breaking it
