|
Tiempo de lectura
9 min
Structured data SEO: rich results
Structured data is a layer of code that tells Google what is on a page: a product, a recipe, a local business, an event, a rating, or a answered question. In SEO, the usual approach is to implement it with JSON-LD following the Schema.org vocabulary, because it lets you describe content without mixing it into the visible HTML. Its goal is not to "decorate" the site, but to help search engines interpret entities, properties, and relationships. When Google trusts that markup and the page meets its requirements, it can show rich results such as prices, availability, breadcrumbs, stars, or extra information in the snippet. Even so, rich results are not guaranteed: they depend on content quality, result-type eligibility, the query, and Google's systems. They are also relevant for AI search, because Google and Microsoft have confirmed that they use structured data in their artificial intelligence features.
Structured data in SEO (not an Excel table)
Searching "structured data" in Spain brings up IBM, AWS, and SQL. On this page it is something else: Schema.org markup (almost always JSON-LD) to tell Google what the URL is — product, business, article, event — with properties that are also visible on screen. It does not add stars by magic. It reduces ambiguity. If the HTML says EUR 29 and the JSON-LD says EUR 19, the markup gets in the way.
Rich results are the possible consequence: price, stock, recipe, event. Google does not owe them. Search Central: markup does not guarantee the format. How the classic snippet is written: title and meta.
Which types make sense (and which do not)
Product + Offer on real product pages. LocalBusiness or Organization with true NAP and hours. Article + author on editorial pages. BreadcrumbList if the breadcrumb exists. Course, Event, Recipe, JobPosting only if the page is that. Do not mark AggregateRating if there are no visible reviews of your own. FAQ as a rich result is very limited; a useful question block still serves the reader, not as a snippet trick.
A thin product page is not fixed with schema. First the content that sells: product pages. Map by template: one type, fields that come from the CMS, zero duplicate plugins painting the same Product twice.
JSON-LD without tangling the CMS
JSON-LD goes in a separate script; you do not need to wrap every <span>. One source of truth: catalog price, inventory stock, indexable image. If stock changes daily, the markup changes with the page, not a static JSON from a year ago. In WordPress or Shopify, one generator; not three.
Variants (size, color): Product/Offer must not mix SKUs. Bundles: mark the set or the component, not both as if they were the same. Rich Results Test and a sample per template, not only the homepage.
Validate and monitor
Valid does not equal eligible does not equal shown. Search Console (enhancements / rich results) warns after a theme change. Review after a migration or redesign. General report: use Search Console.
It helps generative systems understand entities; it does not put you into AI Overviews by itself. That is authority and a clear answer: AI Overviews.
What can cost you a manual action
Invented reviews, stars from another site, a schema type that is not the page, data hidden from the user. Search Central treats that as misleading markup. Removing FAQPage "because there is no rich result anymore" is not urgent; inventing an Event for an ongoing service is a bad idea.
Schema is precision, not a ranking shortcut. A technical SEO implements it when the content is already true in HTML.
Technical data and signals that affect crawling and indexing
Google recommends JSON-LD over Microdata and RDFa for structured data in Google Search, which makes it the cleanest option for most SEO implementations. It is also relevant that Google and Microsoft confirmed in 2025 the use of structured data in AI features, though the direct impact on specific citations is still debated by independent analyses. In 2026, FAQPage no longer generates rich results in Google, but well-structured questions still add semantic clarity. I would prioritize correct markup, equivalent visible content, and periodic monitoring over accumulating Schema types without purpose.
Conclusion
In short: structured data helps Google and AI understand your site, but it works best when it describes real, visible, well-organized content. If competitors show stars, prices, or extra information, do not copy their markup without checking whether your page meets the requirements. Start with the templates with most SEO value, use JSON-LD, validate before deploying, and review Search Console after each technical change. The winning combination is not Schema alone, but useful content, clear architecture, consistent data, and an implementation that does not promise more than the page delivers.
Frequently asked questions about structured data SEO: rich results
Does structured data guarantee rich results?
No, structured data does not guarantee that Google will show rich results. Markup helps interpret the page and can make it eligible for certain rich results, but the final decision depends on Google. The query, content quality, page authority, guideline compliance, and the result type available at any moment all influence it. Implement them as a semantic clarity signal, not as a promise of stars, prices, or special modules in every result.
Which Schema types help a local business?
A local business usually benefits from LocalBusiness or a more specific subtype if it fits the activity, plus Organization and BreadcrumbList when the architecture allows it. Markup can include name, address, phone, hours, URL, logo, and location data, as long as they match what the user sees on the page. If there are several locations, create one page per location with its own data. Product, Service, or Event can also be used if the site offers real, detailed information about those elements.
Can I add structured data without rewriting all the code?
Yes, you can usually add structured data without changing all the site HTML, especially if you use JSON-LD. That format is added as a separate script block and can be generated from the CMS, a plugin, the theme, or a custom integration. Still, control the source of each data point to avoid duplicates, empty fields, or outdated information. Ideal is to implement it by template: products, articles, categories, locations, or services, validating several representative URLs before rolling it out at scale.
Does Google penalize marking up data that is not visible on the page?
Google can apply manual actions if structured data is misleading, spammy, or does not represent the visible content of the page. Marking nonexistent reviews, different prices, events that do not appear, or invented ratings is bad practice. The basic rule is simple: Schema should describe what the user can verify on the page. It should also use a markup type that fits the real content. If there is doubt, be conservative, validate with official tools, and fix issues before they escalate.
Need a marketing team?
Let’s talk and grow your business

Let's build something remarkable

