What is structured data?
Your page says "Boulangerie Martin, in the heart of Lyon since 1987". A human understands everything. A machine has to guess: is Martin a person's name or a company name? Is 1987 a founding year or an address? Structured data removes the guesswork: it is a block of code in JSON-LD format, placed in the page's <head>, that states the same information in the standardized vocabulary of schema.org, the one Google, Bing and AI read natively.
It is the second of the 4 conditions of GEO: being understandable. A website without structured data can rank well, but it leaves machines to interpret, and machines interpret badly.
Does it make you rank higher?
No, and that is worth saying before you lose an afternoon over it. Structured data is not a ranking factor: adding a JSON-LD block will not move you from page 3 to page 1. Google has repeated this for years, and anyone selling you the opposite is selling something else.
What it changes lies elsewhere, and it is still worth the fifteen minutes. It makes your page eligible for enhanced displays it would otherwise never get: the business panel, review stars, the breadcrumb under your link, the article card. Above all it makes your business identifiable as an entity, not just as a string of words. That second effect carries the most weight today: an answer engine that has to name a tradesperson in Nantes prefers the one whose exact name, address and trade it knows, over the one it has to infer from a paragraph of marketing copy.
The 5 schemas a small business needs
| Type | What it declares | Where to put it |
|---|---|---|
Organization / LocalBusiness | Name, business, address, hours, social profiles | Homepage |
WebSite | The site name and its canonical URL | Homepage |
FAQPage | Your questions and answers, ready to cite | Pages with a FAQ |
Article / BlogPosting | Title, author, publication dates | Every blog post |
Person | The owner or the experts, their role | Team or about page |
Use LocalBusiness rather than Organization if you have a physical address where customers visit you: it is what feeds your presence in local searches. The other types (Product, Event, Recipe...) are only worth it if your business justifies them.
A complete example to adapt
The block below combines Organization and FAQPage for a service business. Replace the values, paste it into the <head> of your homepage:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "LocalBusiness",
"@id": "https://yoursite.com/#org",
"name": "Durand Rénovation",
"description": "Interior renovation company for homeowners, Nantes and surrounding area.",
"url": "https://yoursite.com/",
"telephone": "+33 2 40 00 00 00",
"address": {
"@type": "PostalAddress",
"streetAddress": "12 rue des Artisans",
"addressLocality": "Nantes",
"postalCode": "44000",
"addressCountry": "FR"
},
"areaServed": "Nantes and surrounding area",
"sameAs": ["https://www.linkedin.com/company/durand-renovation"]
},
{
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "How fast can you start?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A quote within 48 hours, work starting within 3 weeks on average."
}
}]
}
]
}
</script>How do you link your blocks together?
This is the detail that separates improvised markup from markup that holds. In the example above, the business carries an identifier: "@id": "https://yoursite.com/#org". That identifier is an internal address, it matches no real page and does not need to exist on the web.
Its value: on your other pages, you no longer have to redeclare the whole business. A blog post can simply say "publisher": { "@id": "https://yoursite.com/#org" } and the engine knows who it is talking about. Without that identifier, every page declares a business with the same name without ever saying it is the same one, and you end up with ten blurry entities instead of one sharp one. Which is exactly what you do not want when the whole point is being recognized as an identified business.
Two rules are enough: the full entity is declared once, on the homepage, and the same identifier is reused everywhere else, byte for byte. A single capital letter of difference creates a second entity.
Which properties are actually required?
Many audits blur two notions Google keeps carefully apart, and have you rushing to fix what is only a suggestion.
- Required properties govern eligibility. Their absence produces an error in the Rich Results Test, and the enhanced display is lost. For example a
FAQPagewith noacceptedAnswer, or a local listing with nonameoraddress. - Recommended properties improve the result without being demanded. Their absence produces a warning. For an article,
image,author,datePublishedanddateModifiedfall in this category: leaving them out breaks nothing, but strips the article of its thumbnail and its freshness signal.
The practical rule: handle errors the same day, warnings at your next revision. And beware the opposite reflex, which costs more: adding a property with an invented value to silence a warning. A declared image that returns a 404 is far worse than no image at all, because it turns a harmless warning into a genuine error.
The mistakes that invalidate everything
- Invalid JSON. One extra comma and the entire block is ignored, with no visible error message. Always validate after editing.
- Declaring what is not on the page. A FAQPage whose questions do not appear in the visible content is considered misleading by Google. The schema describes the page, it does not replace it.
- Inconsistencies between pages. Two different addresses in two blocks, a name that changes from page to page: every contradiction weakens machines' trust in your data.
- The block injected by JavaScript. Some CMS plugins add the JSON-LD after the page loads. Google usually gets there in the end, but AI crawlers do not run JavaScript: to them, your markup does not exist. The block has to be in the source served by the server, the one you see with "view page source".
How to check it works?
Two tools: Google's Rich Results Test for a specific page, and our audit, which automatically checks the presence, validity and consistency of your structured data across your key pages, as part of 107 measured checks. A natural complement: the llms.txt file, which summarizes your business for AI in the same place.