A web page is text that a search engine must interpret. Structured data eliminates this interpretation: it explicitly declares that a number is a price, a date is an event date, or a person is the author. The format chosen by Google for this declaration is JSON-LD\u2014a block of code isolated in the page header that has no effect on the visual display. <\/p>\n
The direct effect on ranking is zero, and this must be stated clearly to avoid false expectations. No markup will move a page up the rankings. What it produces is a rich result in search listings: star ratings, prices, availability, expandable FAQs, readable breadcrumbs, or recipe images. This display occupies more screen real estate and attracts more clicks at the same position. <\/p>\n
The indirect effect is more profound. A correctly marked-up site becomes a source that automated systems understand without ambiguity\u2014which matters more and more as engines generate answers rather than lists of links. Properly declaring your entity, services, and authors is no longer a marginal optimization; it is how an organization makes itself readable. <\/p>\n
JSON-LD is placed in a dedicated script tag, usually in the document header. It is neither visible nor indexed as text, and it does not replace page content. Markup that declares information absent from the page is a violation of Google’s guidelines and exposes you to a manual action. <\/p>\n<\/div>\n
Three syntaxes have historically coexisted to express the same thing. Microdata and RDFa are inserted into the visible HTML by adding attributes to existing tags. JSON-LD lives separately in a standalone block. <\/p>\n
Google has explicitly recommended JSON-LD for several years for a practical reason: because the markup is separate from the content, it can be generated, modified, and validated without touching the template. On a site where content is produced by multiple people, this separation prevents an editorial change from breaking the markup without anyone noticing. <\/p>\n
The other two formats are still read and interpreted, so there is no urgency to migrate a site that uses them correctly. However, mixing two formats on the same page produces competing declarations and unpredictable results. Use only one format per page, and preferably JSON-LD. <\/p>\n
Schema.org is a shared vocabulary maintained jointly by the major search engines. It defines hundreds of types and thousands of properties, which can be discouraging at first glance. In practice, about ten types cover almost all the needs of a professional site. <\/p>\n
Organization declares the company itself, its name, logo, contact details, and official profiles. LocalBusiness and its subtypes specify the physical establishment, its hours, and service area. Article covers editorial content, Product covers product pages, FAQPage covers frequently asked questions, BreadcrumbList covers breadcrumbs, Person covers authors, and Service covers offerings. <\/p>\n
The selection principle is simple: choose the most specific type available. Declaring a restaurant as LocalBusiness works, but declaring it as Restaurant conveys more information. A dental practice benefits from using Dentist rather than MedicalBusiness. This precision requires the same effort and improves understanding. <\/p>\n
A well-marked-up page does not declare three independent blocks; it declares a set of interconnected entities. The graph structure allows you to state that this article is authored by this person, who belongs to this organization, which publishes this site. <\/p>\n
Technically, this involves grouping entities in an array and giving them stable IDs, then referencing them by these IDs rather than re-copying their properties. The benefit is twofold: the file remains readable, and search engines consolidate information from one page to another around the same identifiers. <\/p>\n
Not all types produce a specific display. Here are the ones that yield a visible result, in order of frequency on business sites. <\/p>\n
It declares questions and their answers, allowing for an expandable display under the search result. The gain in screen real estate is clear and the implementation cost is low, since the content already exists on the page. The condition to follow is strict: every question and answer declared must be visible to the visitor, even if they are collapsed in an accordion. <\/p>\n
It replaces the raw URL displayed under the title with a readable path. The effect on click-through rate is modest in isolation, but it applies to every page on the site and only requires automatic generation from the site structure. It is the markup with the best effort-to-coverage ratio. <\/p>\n
Price, availability, average rating, and review count appear directly in the results. The impact on click-through rate is the strongest of all markups. The constraint is proportional: declared reviews must be real, collected on the site, and visible. Declaring an aggregate rating without displayed reviews is a frequent and penalized violation. <\/p>\n
It consolidates the entity with Google and cross-references information from the Business Profile. It does not trigger a spectacular display, but it contributes to the consistency of local signals, a subject detailed in our local SEO<\/a> guide. <\/p>\n <\/p>\n <\/a><\/p>\n The syntax is simple; errors are almost always logical rather than technical.<\/p>\n The first rule is strict correspondence between the markup and the page. A declared price must be the displayed price. A declared publication date must match the visible one. This requirement seems obvious, yet it is constantly violated by markup automatically generated from poorly maintained fields. <\/p>\n The second rule is the stability of identifiers. An entity should keep the same ID from one page to another and from one year to the next. Changing an organization’s ID with every redesign is equivalent to creating a new entity and losing the accumulated consolidation. <\/p>\n The third is reasoned completeness. Filling in mandatory properties followed by recommended properties is enough. Piling on dozens of optional properties adds nothing and lengthens a file that will need maintenance. Five well-populated types are better than fifteen incomplete ones. <\/p>\n The fourth concerns special characters. Markup is JSON, so internal quotes must be escaped and line breaks encoded. An unhandled ampersand or a poorly encoded curly apostrophe is enough to make the entire block invalid, and the failure is silent: the engine simply ignores the markup. <\/p>\n Validation is the step everyone skips and the one that reveals half the problems.<\/p>\n The Schema.org Validator checks compliance with the vocabulary: existing types, authorized properties, and correctly typed values. Google’s Rich Results Test checks something else: eligibility for a rich result, including the properties Google requires beyond what Schema.org allows. <\/p>\n The two are complementary, and markup can pass the first while failing the second. Using both prevents you from prematurely concluding that markup is correct just because no syntax errors appear. <\/p>\n This is the most important and most neglected precaution. Pasting your code into the validator tests what you wrote. Testing the live URL tests what the server actually sends after plugins, caching, and potential rewrites. The discrepancy between the two is frequent, and that is precisely where duplicate declarations hide. <\/p>\n Search Console then provides long-term monitoring by markup type, with errors reported across all crawled pages. It is the only place where you can see that a problem affects four hundred product pages and not just the one you tested. <\/p>\n Six errors appear in almost every audit we conduct.<\/p>\n None of these errors are difficult to fix. They persist because no one looks at the markup once it has been implemented, even though it lives and degrades like the rest of the site. <\/p>\n Priorities differ depending on the activity. Here is what we systematically implement based on the profile. <\/p>\n Organization for the entity, LocalBusiness if an establishment receives the public, Service for each offering with its service area, BreadcrumbList everywhere, FAQPage on pages that include them, and Person for the author of editorial content. This foundation covers the essentials and is generated from the template. <\/p>\n Product on every page, with Offer for price and availability, AggregateRating if reviews actually exist, BreadcrumbList for the category path, and Organization at the site level. The point of focus is automatic generation across thousands of pages: a template error is instantly replicated everywhere. <\/p>\n Article or BlogPosting depending on the nature, with an identified author, publication and modification dates, and an image. The author declaration deserves particular care as it contributes directly to expertise signals, a subject we cover in our SEO services<\/a>. <\/p>\n Commerce combines both the highest potential for rich results and the greatest risk of mass error. A false product declaration doesn’t affect one page; it affects the entire catalog in a single deployment. <\/p>\n The declared price must match the price actually paid, including all taxes for individual customers, and the currency must be explicit. Stores that display a tax-exclusive price on the front end and declare the same amount in their markup produce misleading results that eventually get flagged. <\/p>\n Availability poses a synchronization problem. An out-of-stock product that continues to declare itself as available generates frustration and degrades trust in the domain. The declaration must link to the actual stock status, not a fixed value in the template. <\/p>\n Finally, variants. A product available in several sizes or colors can be declared as a single entity with a price range, or as several distinct entities. The choice depends on the chosen URL structure, which itself depends on the platform\u2014a subject covered in our WordPress vs Shopify<\/a> comparison. Both approaches work; mixing them on the same catalog does not. <\/p>\n On large catalogs, the rule of thumb is to test the template on three representative products before deploying, then check Search Console for the following two weeks. An error replicated across eight hundred pages is fixed as quickly as it spread, but you still have to see it. This is one of the checkpoints in an e-commerce SEO<\/a> service. <\/p>\n A methodological point that applies to all projects. Markup expresses the site structure; it does not create it. A site with a confusing hierarchy produces confusing breadcrumbs, and no declaration will fix a poorly conceived architecture. <\/p>\n This is why we handle markup at the moment the architecture is designed, using the same logic as that explained in our semantic silo<\/a> method. Entity identifiers, relationships between pillar pages and child pages, category hierarchy: all of this is decided once, then mechanically translated into markup. <\/p>\n On a new project, this requirement is formalized in the website specifications<\/a>, just like performance thresholds. It then costs a few hours. Added after launch, it requires revisiting every template and checking every type, which represents several days. <\/p>\n The case of multilingual sites deserves a mention. Each language version carries its own markup, with the language declared and entity identifiers shared between versions. The organization remains the same entity regardless of the language, which the declaration must reflect; otherwise, the engine sees four distinct organizations with the same name. <\/p>\n The budget question always comes up, and the answer depends primarily on the number of templates, not the number of pages.<\/p>\n On a standard service site, count on one day for inventory and cleanup, one day to design the graph and set the foundation, and half a day per remaining specific template. A twenty-page showcase site with three templates can be handled in two to three days. <\/p>\n On a store, add the product template and the category template, plus verification time on a representative sample. The catalog size itself doesn’t change the cost since the markup is generated, which explains why a store with eight hundred references costs no more to mark up than a store with fifty. <\/p>\n This budget is modest compared to the effect, making it one of the highest-yield interventions in an SEO project. The sites we deliver in our portfolio<\/a> all launch with this foundation in place, which avoids having to revisit it. <\/p>\n A useful clarification, because the subject attracts excessive promises.<\/p>\n Markup does not move a page up in the results. A poorly written page on a slow site without authority will stay where it is, regardless of the quality of its declarations. The gains observed after markup come from improved click-through rates, not a change in position. <\/p>\n It also does not guarantee a rich result. Eligibility is a necessary condition; display remains a Google decision made on a query-by-query basis. A perfectly marked-up page may show no enhancements for months, then suddenly display them. <\/p>\n Finally, it does not compensate for any technical flaws. A site whose pages take five seconds to load has a problem that markup won’t touch, and which must be treated first, as detailed in our article on Core Web Vitals<\/a>. The order of priorities matters: technical accessibility, content, architecture, then markup. <\/p>\n The method we apply consists of five stages and generally spans two to three days of work for a medium-sized site.<\/p>\n Inventory first: what templates exist, what markup is already produced and by what. This step almost always reveals forgotten automatic generations inherited from an old plugin. <\/p>\n Cleanup next: deactivate competing sources to keep only one emitter per type. This is the step that solves the most problems and it produces no new content. <\/p>\n Graph design: define stable identifiers for the organization, establishment, and authors once and for all. These IDs will be used on all pages and must not change. <\/p>\n Implementation by template, starting with the one that covers the most pages. Markup placed on the article template instantly covers the entire blog, whereas markup placed page by page is never finished. <\/p>\n Validation finally, on live URLs and not on code, followed by monthly monitoring in Search Console during the first quarter. This final step catches regressions caused by updates, which are the main cause of degradation over time. It is part of what a serious maintenance contract<\/a> covers. <\/p>\n A word on internal documentation. On sites where multiple people intervene, writing a page describing the chosen entity IDs and the expected type per template prevents a subsequent developer from starting with different conventions. This page takes half a page and saves hours of untangling two years later. <\/p>\n JSON-LD explicitly declares what a page contains so the engine doesn’t have to guess. It doesn’t win positions; it wins screen real estate and clicks, and it makes the company readable by automated systems whose importance is growing. <\/p>\n Three rules are enough to avoid almost all problems. Only declare what is visible on the page. Have only one generation source per type. Test the live URL rather than the written code, because the discrepancy between the two is precisely where errors reside. <\/p>\n Start with BreadcrumbList and FAQPage, which cover many pages for little effort, then add the Organization and LocalBusiness foundation. The rest is handled template by template, in order of the number of pages covered. It is a short, measurable intervention whose effect can be seen in Search Console within a few weeks. <\/p>\n A note on markup maintenance. Schema.org types and properties evolve, and Google’s requirements for rich results change even faster: some types have lost their eligibility, others have gained it. An annual markup review, aligned with the site’s technical review, is enough to stay up to date without dedicated permanent monitoring. This check takes one hour and prevents discovering after the fact that a display disappeared six months ago. <\/p>\nWriting Clean Markup: Rules to Avoid Errors<\/h2>\n
Validate, and Above All, Validate the Actual Output<\/h2>\n
The Two Tools to Use, in This Order<\/h3>\n
Test the Live URL, Not Pasted Code<\/h3>\n
The Most Frequent Markup Errors<\/h2>\n
\n
Markup by Site Type<\/h2>\n
Service Provider Site<\/h3>\n
Online Store<\/h3>\n
Editorial Site and Blog<\/h3>\n
Markup on an Online Store: A Special Case<\/h2>\n
Markup is Decided with the Architecture, Not After<\/h2>\n
The Cost of Complete Markup<\/h2>\n
What Markup Will Not Do for You<\/h2>\n
Implementing Markup on an Existing Site<\/h2>\n
Key Takeaways<\/h2>\n
Frequently asked questions<\/h2>\n
\n