Schema.org and JSON-LD for corporate sites
Schema.org structured data labels the information on a page with a shared vocabulary, so that search engines and language models read it instead of inferring it. On corporate sites, the carrier format for that labelling is JSON-LD.
Structured data labels page information with the schema.org vocabulary and is written as JSON-LD. A correctly built graph states who you are, what you do, where you are and which question you answer — from one source. It guarantees no rich result; it guarantees that machines read you correctly.
What is schema.org structured data?
Schema.org structured data is the practice of labelling information on a page with a shared vocabulary so machines do not have to guess. A person sees that a line reading Karabaş Mah., İzmit is an address; a machine cannot. The markup states precisely that the line is a PostalAddress, which organisation it belongs to and which city it names.
The vocabulary is called schema.org; the carrier format is called JSON-LD. The two are frequently confused. Schema.org defines which words you may use — Organization, Service, FAQPage — while JSON-LD defines how those words are written into the page. The vocabulary is shared; the format is a choice.
Structured data is not a marketing layer, it is a data contract. What the page says and what the graph says have to be the same thing. In the graph published on this site the telephone, address and email fields are filled with verified values, while postal code, opening hours and coordinates are absent entirely, because they were never verified. They were not left blank and they were not invented — they were removed.
JSON-LD, Microdata or RDFa: which should you choose?
Choose JSON-LD on a corporate site. All three formats carry the same schema.org vocabulary, but JSON-LD separates the markup from the HTML: the data sits in one script block, survives design changes and is straightforward to generate server-side. Google recommends JSON-LD in its documentation. Microdata and RDFa remain valid, but cost noticeably more to maintain.
| Format | Where it lives | Strength | Weakness |
|---|---|---|---|
| JSON-LD | One script block, independent of the HTML | Easy to maintain, unaffected by design changes, supports graph relationships | The match with visible content has to be audited separately |
| Microdata | Attributes inside the HTML elements | The markup is physically attached to the visible content | Breaks easily when templates change; complex relations are awkward |
| RDFa | Attributes inside the HTML elements | Broad compatibility with the wider linked-data ecosystem | The steepest learning curve for corporate teams |
A practical rule: if your current site has Microdata and it works, do not delete it in a hurry. Build the new structure in JSON-LD first, then remove the old markup. Two formats live at the same time with different values is, on its own, the single most frequent fault type we encounter.
Which schema types should a corporate site use?
Every page carries the same corporate core: Organization, WebSite, WebPage, plus BreadcrumbList on every page except the home page. The page's own type sits on top: Service on a service page, TechArticle on a guide, ContactPage on contact, LocalBusiness on a branch page. A type that does not describe an entity genuinely present on the page is not added.
| Page type | Page-specific node | Conditional / caution |
|---|---|---|
| Home page | WebPage + ItemList (service index) |
LocalBusiness only if the address and telephone are verified |
| Service detail | Service + FAQPage |
offers is written only where a price is actually published |
| Sector / solution | Service or CollectionPage |
audience can state the target sector |
| Guide / article | TechArticle + Person (author) |
HowTo and DefinedTerm only if that content really exists |
| Frequently asked questions | FAQPage |
Question and answer must be visible on the page |
| Contact | ContactPage + ContactPoint |
NAP data identical in the footer and in the graph |
| Branch / dealer location | LocalBusiness (a separate @id per location) |
Linked to head office through parentOrganization |
| Product / e-commerce | Product + Offer |
Price, currency and availability must be real-time |
| Legal text | WebPage |
No extra type needed; markup is never forced |
If a type you are considering is missing from the table, the question to ask is this: does this type describe an entity that genuinely exists on the page? If the answer is no, it is not added. Schema.org defines more than eight hundred types; a corporate site normally needs between ten and fifteen of them.
What is @id and why does the entity graph matter?
@id is the permanent identifier given to an entity. Instead of redefining the same company on thirty-six pages, you define it once under a single @id and reference that identifier everywhere else. A search engine then sees one company mentioned on thirty-six pages, not thirty-six separate companies.
Three rules are enough for @id. One: make the identifier an absolute URL (https://www.bakibilisim.com/#organization). Two: keep the protocol and subdomain identical across the site; mixing http with https, or www with the non-www version, produces two separate entities. Three: never change an identifier again — changing it resets the entity.
The second pillar of entity clarity is the sameAs field, which lists the organisation's verifiable external profiles. This site has one verified Instagram profile, so sameAs has exactly one entry. Listing profiles that do not exist does not increase entity clarity; it reduces it.
How is schema built for multi-location and multilingual structures?
Every physical location gets its own page and its own @id, and each links to head office through parentOrganization. In a multilingual structure the graph is republished in each language: the @id values stay identical, while inLanguage and the text fields change. Identity does not vary by language.
In dealer, branch and store networks, the most common setup error is collecting every location under a single LocalBusiness node. That tells a search engine, in effect, "I have one business and its address keeps changing." The correct setup is one page per location and one identifier per location, with head office as the single, unchanging Organization node.
- Location page: its own
LocalBusinessnode, its own address, its own telephone, its own@id. - Head office: a single
Organization; locations attach to it throughparentOrganization. - Multiple languages:
inLanguagecorrect on every page, withhreflangtags and the graph confirming each other. - Consistency: name, address and telephone written identically on the page, in the graph and in business profiles.
The operational side of this setup is detailed on our dealer and branch network management and retail chain solution pages.
How do you validate structured data?
Two tools answer two different questions. The Schema Markup Validator measures vocabulary validity: are the type and property names correct? Google's Rich Results Test measures search-engine eligibility: which rich result type is this graph a candidate for? Before a corporate release, both must report zero errors.
| Tool | What it validates | What it does not validate |
|---|---|---|
| Schema Markup Validator | Vocabulary validity: type, property name, data type, syntax | Whether the markup matches the content on the page |
| Google Rich Results Test | Eligibility for the rich result types Google supports | Whether the rich result will actually be shown |
| Search Console reports | Error and warning counts on live pages over time | New pages that have not been crawled yet |
| Human review | Exact match between visible information and graph values | Cannot be automated; repeated before every release |
Direct links to the tools: Schema Markup Validator (external link, opens in a new tab) and Google Rich Results Test (external link, opens in a new tab). Paste this page's URL into both and read the output yourself — we publish our own measurements, with measurement dates, on the proof page.
Does structured data help in AI engines?
Indirectly, yes. Language models parse a page before they answer; structured data makes that parsing easier and removes ambiguity about who the entity is. But no search engine or assistant promises "add schema and we will cite you". Markup is a precondition for citability, not a guarantee of it.
Here is what is verifiable: when the same organisation name, address and description are consistent on the page, in the graph and across external profiles, entity ambiguity falls. As ambiguity falls, the chance of a model confusing you with another company falls with it. That is a description of a mechanism, not a promise about an outcome.
The answer-engine and generative-engine sides are covered in two separate guides: what is AEO and what is GEO. Structured data is the infrastructure layer beneath both; on its own it replaces neither.
Three verifiable facts, each with a source
Most claims circulating about structured data have no source. The three figures below rest on public, checkable documentation: who founded the vocabulary, what the search engine actually guarantees, and how many markup formats are recognised. Every line carries its source and access date; we publish no number without one.
2011
The year the schema.org vocabulary was published as a shared vocabulary by Google, Microsoft, Yahoo and Yandex.
Source: schema.org — Frequently Asked Questions · Accessed: 2026-07-29
0
The rich result guarantee that valid structured data provides. Google documents explicitly that markup does not guarantee the appearance.
Source: Google Search Central — Intro to structured data · Accessed: 2026-07-29
3
The number of markup formats Google recognises: JSON-LD, Microdata and RDFa. Of the three, Google recommends JSON-LD.
Source: Google Search Central — Structured data general guidelines · Accessed: 2026-07-29
Copyable JSON-LD examples
The six blocks below cover the core a corporate site needs. All of them are written with this site's real values; for your own organisation you only change the address, telephone and identifier values. Every block belongs inside the single script tag at the top of the document, as one @graph array.
Where does the script tag go?
JSON-LD is placed in the document head inside a single script tag. The skeleton below shows where the later examples go.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
/* Organization */,
/* ProfessionalService */,
/* Person */,
/* WebSite */,
/* WebPage */,
/* BreadcrumbList */
]
}
</script>Organization — corporate identity
{
"@type": "Organization",
"@id": "https://www.bakibilisim.com/#organization",
"name": "Baki Bilişim",
"url": "https://www.bakibilisim.com/",
"email": "bilgi@bakibilisim.com",
"telephone": "+905078172717",
"address": {
"@type": "PostalAddress",
"streetAddress": "Karabaş Mah. Salim Dervişoğlu Cad., Ncity AVM, Kat 2",
"addressLocality": "İzmit",
"addressRegion": "Kocaeli",
"addressCountry": "TR"
},
"founder": { "@id": "https://www.bakibilisim.com/#erdibaki" },
"foundingDate": "2019",
"sameAs": ["https://www.instagram.com/bakibilisim"],
"areaServed": [
{ "@type": "AdministrativeArea", "name": "Kocaeli" },
{ "@type": "Country", "name": "Türkiye" }
]
}Note what is missing: postalCode, openingHours and geo are not in this example, because those values were never verified. Leaving an unverified field empty and inventing a value for it produce the same result: the graph loses its credibility.
LocalBusiness — a physical location
{
"@type": "ProfessionalService",
"@id": "https://www.bakibilisim.com/#localbusiness",
"name": "Baki Bilişim",
"url": "https://www.bakibilisim.com/",
"telephone": "+905078172717",
"email": "bilgi@bakibilisim.com",
"address": {
"@type": "PostalAddress",
"streetAddress": "Karabaş Mah. Salim Dervişoğlu Cad., Ncity AVM, Kat 2",
"addressLocality": "İzmit",
"addressRegion": "Kocaeli",
"addressCountry": "TR"
},
"parentOrganization": { "@id": "https://www.bakibilisim.com/#organization" },
"knowsLanguage": ["tr", "en"],
"areaServed": [
{ "@type": "AdministrativeArea", "name": "Kocaeli" },
{ "@type": "AdministrativeArea", "name": "İstanbul" }
]
}ProfessionalService is a subtype of LocalBusiness and is more precise for consultancy and agency work. If you run a branch network, repeat this block on every location page and change only the @id, address and telephone fields.
Service — a service page
{
"@type": "Service",
"@id": "https://www.bakibilisim.com/en/services/structured-data-schema/#service",
"name": "Structured data (schema.org) implementation",
"serviceType": "Structured data engineering",
"description": "Entity graph design, JSON-LD production and validation for corporate sites.",
"provider": { "@id": "https://www.bakibilisim.com/#organization" },
"areaServed": [
{ "@type": "AdministrativeArea", "name": "Kocaeli" },
{ "@type": "Country", "name": "Türkiye" }
],
"availableChannel": {
"@type": "ServiceChannel",
"serviceUrl": "https://www.bakibilisim.com/en/contact/"
}
}The offers field is deliberately absent from this block: without a published price list, no price markup is written. If you do publish prices, add the Offer node and make its value identical to the price shown on the page.
FAQPage — question and answer
{
"@type": "FAQPage",
"@id": "https://www.bakibilisim.com/en/knowledge/schema-org-guide/#faq",
"inLanguage": "en",
"mainEntity": [
{
"@type": "Question",
"name": "Does structured data improve my rankings?",
"acceptedAnswer": {
"@type": "Answer",
"text": "It is not a direct ranking factor. It declares the subject and the
entities of a page instead of leaving them to inference."
}
}
]
}One condition applies: the question and the answer must be visible on the page. The six questions further down this page carry exactly the same wording as the block above.
BreadcrumbList — position trail
{
"@type": "BreadcrumbList",
"@id": "https://www.bakibilisim.com/en/knowledge/schema-org-guide/#breadcrumb",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home",
"item": "https://www.bakibilisim.com/en/" },
{ "@type": "ListItem", "position": 2, "name": "Knowledge Centre",
"item": "https://www.bakibilisim.com/en/knowledge/" },
{ "@type": "ListItem", "position": 3, "name": "Schema.org Guide",
"item": "https://www.bakibilisim.com/en/knowledge/schema-org-guide/" }
]
}Person — the accountable individual
{
"@type": "Person",
"@id": "https://www.bakibilisim.com/#erdibaki",
"name": "Erdi Baki",
"jobTitle": "Founder",
"url": "https://www.bakibilisim.com/en/about/",
"worksFor": { "@id": "https://www.bakibilisim.com/#organization" },
"knowsAbout": [
"Schema.org structured data",
"Answer Engine Optimization",
"Core Web Vitals"
]
}On guide and article pages the Person node is attached to the author field. In this page's TechArticle node the author value references the identifier above — the author's name is not written a second time, it is linked by identity.
How do you build an entity graph from scratch?
Seven steps: entity inventory, permanent identifier scheme, corporate core, page-type nodes, linking by identifier, matching markup to visible content, then validation and monitoring. Order matters — a graph written before the identifier scheme is fixed falls apart at the first restructure. Each step has one output and one control question.
-
01
Take an entity inventory
List the entities that genuinely exist on the site: the organisation, the accountable person, locations, services, products, content. This list is the boundary of the graph — nothing outside the inventory gets marked up.
-
02
Fix a permanent identifier scheme
Give each entity an
@idthat will not change. Protocol, subdomain and trailing slash must follow one single form across the site. Decide the identifier syntax once, then write it down. -
03
Write the corporate core
The
Organization,LocalBusiness,PersonandWebSitenodes are written once and published on every page with identical values. Unverified fields are not written at all. -
04
Add the page-type node
Each page carries its own type:
WebPage,Service,TechArticle,FAQPage,ContactPageorProduct. Every page except the home page also carriesBreadcrumbList. -
05
Link the nodes by identifier reference
Reference an entity with
@idrather than describing it again. Use one script tag and one@grapharray per page. -
06
Match the markup to visible content
Every marked-up field must have a visible counterpart on the page. A telephone number, price, rating or review that is not on the page is not marked up. This step cannot be automated; it is checked by eye.
-
07
Validate, then monitor after release
Measure vocabulary validity with the Schema Markup Validator and search-engine eligibility with the Rich Results Test. After release, watch the structured data reports in Search Console.
What are the eight most common schema mistakes?
These eight come up most often in our audits: marking up invisible content, leaving empty fields, inconsistent identifiers, two conflicting graphs, invented reviews and ratings, the wrong type, compressing a multi-location structure into one node, and never updating the graph after a migration. All eight surface within minutes of inspection.
- Marking up invisible content. Putting a question inside
FAQPagethat does not appear on the page. Fix: add the content to the page first, then mark it up. - Leaving empty fields. Values such as
telephone: ""oraddressLocality: "". Fix: if there is no value, remove the field entirely — an empty string is not a value. - Inconsistent identifiers.
@idvalues starting withhttp://on one page andhttps://wwwon another. Fix: pick one canonical form and apply it in every template. - Two conflicting graphs. Theme, plugin and hand-written code all emitting a graph at once. Fix: switch the sources off one by one until a single producer remains.
- Invented reviews and ratings. Writing
AggregateRatingwithout a real review system behind it. Fix: if there are no genuine reviews, the node is not written at all — the enforcement risk is high. - Choosing the wrong type. Marking a service page up as
Product. Fix: the type follows the real nature of the entity on the page. - Compressing a multi-location structure into one node. Collecting ten branches under one
LocalBusiness. Fix: one page and one identifier per location. - Not updating the graph after a migration. Old values surviving in the graph after a domain or address change. Fix: add a graph audit to the migration checklist.
Seven of these eight are process faults rather than technical ones: a field that nobody owns becomes a field that nobody updates. We set out who is accountable, line by line, on the why Baki Bilisim page.
What should you check before publishing?
Fourteen checks are enough. The list answers two questions: is the graph technically valid, and does everything written in the graph genuinely exist on the page? The second question is the one automated tools cannot answer, and the one that produces the most findings in our audits.
- The page has one JSON-LD script and one
@grapharray. - Every
@idvalue uses the same protocol and subdomain. - The
Organizationnode is identical on every page of the site. telephoneandaddressLocalityinsideLocalBusinessare populated.- No unverified field (postal code, coordinates, opening hours, price) has been written.
- Every page except the home page has a
BreadcrumbListmatching the visible trail. - Each page defines its own type (
Service,TechArticle,ContactPage). - Every question and answer in
FAQPageis visible on the page. dateModifiedmatches the update date shown on the page.inLanguageagrees with the page language and thehreflangtags.sameAslists verified profiles only.- No
AggregateRatingorReviewwithout a real review system. - The Schema Markup Validator output reports zero errors.
- The Rich Results Test output reports zero errors, with warnings reviewed.
If you would like this list applied to your own site, the free digital asset audit measures structured data validity as one of its five axes.
Where are the terms in this guide defined?
Every technical term used in this guide has a short definition in the glossary, at its own anchor. The six below are the ones most needed while reading this page; the complete set is in the digital visibility glossary. Definitions are kept short and self-contained, so each can be quoted on its own.
- 01 JSON-LD The linked-data format that carries structured data in a single script block, separate from the HTML.
- 02 schema.org The structured data vocabulary of types and properties shared by the major search engines.
- 03 Entity Anything that can be identified singularly — an organisation, a person, a place or a concept.
- 04 sameAs The schema.org property listing an entity's verifiable external profiles, reinforcing its identity.
- 05 Rich result A search listing that shows components beyond the standard link, driven by structured data.
- 06 DefinedTerm The schema.org type that makes glossary entries and term definitions machine-readable.
Frequently asked questions
The six questions below are the ones corporate teams ask most often about structured data. The answers appear visibly on this page and, word for word, inside the FAQPage schema — this guide's own rule applied to itself. Each answer is self-contained and stays correct out of context.
Does structured data improve my rankings?
Structured data is not a direct ranking factor, and Google states this plainly in its documentation. What it does is declare the subject and the entities of a page instead of leaving them to inference. The indirect effect comes from there: the page matches the right query, becomes eligible for rich result components, and answer engines quote the content with more confidence.
Does adding schema guarantee a rich result?
No. Google documents that valid structured data does not guarantee a rich result appearance. Markup is an eligibility condition, not a decision. Whether a rich result is shown depends on the search engine's assessment of query, device and quality. That is why our contracts commit to zero validation errors, never to a rich result.
Is the schema added by a CMS plugin enough?
On most corporate sites it is not. Plugins produce one generic core graph; services, multi-location branches, dealer networks, multilingual structures and sector-specific relationships stay outside it. Worse, if two plugins emit a graph at the same time you end up with conflicting nodes. A plugin is a starting point, not a substitute for an entity model.
May I mark up content that is not visible on the page?
No. Google's structured data general guidelines require the markup to represent content that is visible to the user on the page. Marking up invisible content does not only forfeit rich result eligibility, it also creates manual action risk. The rule is simple: if it is not on the page, it is not in the graph.
How many JSON-LD blocks should a page have?
More than one block is technically valid, but on corporate sites we recommend a single block with a single @graph array. One block prevents the same entity being defined twice with different values and makes debugging far simpler. This site publishes exactly one JSON-LD block on every page.
Do I have to change my graph when schema.org is updated?
Usually not. Schema.org preserves backward compatibility and new releases mostly add types and properties. A change is needed when a property you use is deprecated, or when a search engine changes its requirements for a rich result type. For that reason we review the graph once a year and record the review date.
Who wrote this guide?
Find out within five working days whether your current graph is actually valid.
The audit is free and creates no obligation to work with us. The report itemises AEO answerability, AI crawler access, Core Web Vitals, structured data validity and WCAG 2.1 AA gaps.
We work with corporate-scale, multi-location or multilingual organisations. One-off small jobs fall outside our scope; in that case we point you to smaller studios.