Your website may list your services, products and business information. But the fact that this information appears on a page does not mean the relationships between those details are clearly communicated to search engines.
Is a page promoting a service, selling a product, or offering an informational article? Who is the organization providing the service? Are the author and the publisher of the content the same?
Schema and structured data let you answer these questions in a standard, machine-readable format. When implemented correctly, they help explain the meaning of a page and allow eligible content to be considered for supported search features. Source: Google structured data guide
In this guide, we will cover choosing the right types, implementing JSON-LD, the validation process and sustainable structured data management for businesses.
What Is Structured Data?
Structured data is code that tells search engines what the information on a web page means, using a standard, machine-readable format. It makes it explicit whether a piece of text on the page is a product name, a price, an author or a business address. This information is usually prepared using the Schema.org vocabulary.
For example, on a recipe page, cooking time, calories and ratings can be marked up with structured data; on a product page, price, stock status and reviews can be. Google may use this information to show rich results such as star ratings, prices or FAQs on eligible pages; however, rich result display is not guaranteed.
Structured data can be added in three formats:
- JSON-LD: Added to the page code as a separate
<script>block. It is the format Google recommends and the easiest to maintain. - Microdata: Markup is written as attributes inside HTML tags.
- RDFa: Similar to Microdata, it is added with HTML attributes.
You can prepare JSON-LD code for your own page with the free Schema Markup Generator and check your existing markup with our SEO Site Analysis tool.
What Is the Difference Between Schema and Structured Data?
Although these concepts are often used together, they refer to different things:
| Concept | Function |
|---|---|
| Structured data | An approach to organizing information through defined fields and relationships. |
| Schema.org | A shared vocabulary used to describe entities such as organizations, services and products. |
| JSON-LD | A data format that can be used to add these definitions to a web page. |
For example, on a consulting page, Service can describe the service and Organization can describe the organization providing it. The provider property establishes the relationship between the service and its provider. Source: Schema.org Service definition
Google supports the JSON-LD, Microdata and RDFa formats. Because it is easier to implement and maintain, Google recommends using JSON-LD in most cases. Source: Supported structured data formats
Why Is Structured Data Important for SEO?
Structured data helps search engines interpret the information your business provides more clearly. On eligible pages, it can also make you eligible for rich results.
However, three different situations need to be kept apart:
- The markup being technically valid.
- Meeting the requirements of a specific Google search feature.
- That feature actually being displayed in search results.
Even when the first two conditions are met, Google does not guarantee rich result display. Structured data alone should not be treated as a promise of higher rankings. Source: Google structured data policies
For businesses, a healthy goal is to describe the right content with the right types, reduce technical errors and measure the performance of eligible search appearances.
Which Schema Type Should Be Used on Which Page?
Type selection should not start with the question "What is the maximum amount of markup we can add?" First, the main purpose of the page should be determined.
| Page or entity | Type to consider | Purpose of implementation |
|---|---|---|
| Organization information | Organization | Defining the identity of the business |
| Physical business or branch | An appropriate LocalBusiness subtype | Describing local business information |
| Service detail page | Service | Linking the service to its provider |
| Product detail page | Product | Defining product information |
| Blog post | BlogPosting or Article | Describing the article, author and publisher |
| Page hierarchy | BreadcrumbList | Indicating the page's position within the site |
Google support and required properties are not the same for every type in the table. The existence of a type in Schema.org does not mean there is a dedicated rich result for it in Google. The targeted search feature should be checked against Google's current list of supported features. Source: Google structured data gallery
For example, Service can be used to describe a service; this usage does not promise a special "service card" display.
Advanced Implementation: Model Entities, Not Just Pages
On large sites, adding an independent code snippet to every page can create inconsistencies over time. The same organization may be described under different names on different pages, or plugins may generate conflicting information.
For this reason, it is useful to prepare an entity model before implementation:
- What information will be used to define the organization?
- Will each service have its own identity?
- Which publisher will blog content be linked to?
- Where is the primary data source in which this information is managed?
It is important that the name, URL and other identifying details in the organization information are accurate. Google's Organization documentation explains that this markup can help understand the organization and distinguish it from similar ones. Source: Organization structured data
In technical design, using stable @id values makes it easier to connect the same entity across different definitions. The goal here is to establish a manageable identity system across the entire site.
Service Markup Example with JSON-LD
The example below links a service to the organization that provides it. The example.com addresses are placeholders; they should be replaced with real, permanent addresses before implementation. The description should also accurately reflect the service offered on the relevant page.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "SEO Performans",
"url": "https://example.com/"
},
{
"@type": "Service",
"@id": "https://example.com/schema-hizmeti/#service",
"name": "Schema ve Yapılandırılmış Veri",
"serviceType": "Yapılandırılmış veri optimizasyonu",
"url": "https://example.com/schema-hizmeti/",
"description": "Web sayfalarındaki yapılandırılmış verilerin analizi ve optimizasyonu.",
"provider": {
"@id": "https://example.com/#organization"
}
}
]
}
</script>In this example, @graph keeps related definitions together. provider links the service to the organization through its @id value. The properties used for Service are based on the Schema.org service model. Source: Service properties
This is a starting example for a service detail page. The main content of an informational blog post like the one you are reading, on the other hand, should be modeled as an article. Copying the same service code onto every page does not describe the page's real purpose.
How Should Structured Data Be Managed on Dynamic Sites?
The real challenge of advanced implementation is less about adding the code for the first time and more about keeping the data up to date.
If the visible content is updated when a product price changes but the JSON-LD still shows the old price, two conflicting pieces of information exist. Similar problems can occur with service descriptions, business addresses and publication dates.
The following approach can be used to make maintenance easier:
- Define a shared data source. Visible content and markup should be fed from the same record wherever possible.
- Generate at the template level. Fields appropriate to the page type should be created through central rules.
- Define how missing data is handled. Made-up values should not be added to unknown fields.
- Refresh the cache together. Content changes should be reflected in the structured data as well.
- Test the output. Check the final page delivered to visitors, not just the data in the admin panel.
When generating JSON-LD from CMS inputs, a safe JSON serialization method should be used. Concatenating strings by hand can produce faulty output because of quotation marks and special characters.
How to Test Structured Data
Validation is not limited to checking whether the JSON syntax is correct.
1. Check the Schema Model
With the Schema Markup Validator, you can check types, properties and data relationships. This check is not the same as rich result eligibility in Google.
2. Check Eligibility for Google Features
The Rich Results Test is used to examine the rich result types that Google supports. If a Service definition does not appear as a rich result in the tool, that alone does not mean it is invalid in terms of Schema.org. The features Google supports and the scope of the vocabulary are different. Source: Google structured data explanations
3. Review the Match with the Content
Markup must accurately represent the content the page offers. Misleading or outdated claims, or claims not presented to the user, should not be added. An automated test returning no errors does not prove that all quality guidelines are met. Source: Structured data quality guidelines
4. Monitor After Launch
For supported types, Search Console reports should be monitored; after template, theme or plugin updates, sample pages should be validated again. Markup that works in a development environment can change at launch. Source: Google implementation and monitoring recommendations
Sample Implementation Scenario: A Multi-Service Business Site
This scenario was prepared to explain the method; it does not contain actual client results.
Let's imagine a consulting business with 25 service pages and a blog it publishes on regularly. The theme, the SEO plugin and custom code each generate structured data separately.
An initial review shows that the organization name is written in different ways, some blog pages are defined as services, and descriptions of discontinued services remain in the code.
In this case, the implementation plan can be built as follows:
| Phase | Work to be done | Expected output |
|---|---|---|
| Inventory | Finding the components that generate markup | List of sources and page types |
| Modeling | Defining relationships between organization, services and articles | Consistent data model |
| Cleanup | Fixing conflicting output and outdated information | Up-to-date templates |
| Pilot | Testing selected service and blog pages | Validated examples |
| Rollout | Applying the rules to the relevant templates | Manageable site-wide implementation |
Success is not measured only by the question "How many pages got schema?" The reduction in faulty definitions, information staying up to date and the performance of eligible search appearances are also evaluated.
SEO Performans' Schema and Structured Data Service
To build and maintain the right schema model across your entire site, you can explore our structured data optimization service.
At the core of SEO Performans' Schema and Structured Data service is an implementation plan that fits the business's content and can be sustained over time.
The work is approached through reviewing existing markup, determining the model suited to each page type, planning technical changes and validating the results.
For your business, this process clarifies the following questions:
- Which pages have missing or faulty markup?
- Which types genuinely match your content?
- Are your theme and plugins generating conflicting data?
- Which fixes are the priority?
- How will accuracy be maintained when content is updated?
In this way, structured data work goes beyond a one-time code addition and becomes part of technical SEO management.
Frequently Asked Questions
Does Every Page Need Schema?
Adding the same markup to every page is not the right approach. Priority should go to implementations that accurately describe the page's content and are meaningful for the business.
Is Using an SEO Plugin Enough?
A plugin can make generating markup easier. However, you still need to check separately that the selected types, properties and output are correct. Custom templates and multiple data generators may require additional review.
Do More Schema Types Produce Better Results?
The goal is not to increase the number of types. It is to describe the entities and relationships on the page accurately, consistently and up to date.
When Are Results Visible?
Technical fixes can be tested after launch. How they show up in search results depends on recrawling, indexing and Google's decision on whether to display them. No fixed timeline or rich result guarantee should be promised.
Find Out Your Website's Structured Data Needs
Having schema code on your site does not mean the right types are used or that the information stays up to date. To identify gaps and priorities, the page content and the technical output need to be reviewed together.
Evaluate your website's Schema and Structured Data needs with SEO Performans and determine actionable improvement steps.
Request a Free SEO Analysis