Schema Markup and Entity SEO in 2026: describe your brand clearly to Google
Schema markup translates the visible relationships between your business, services, authors, articles and locations into a machine-readable model. This guide explains how to build, validate and measure a coherent JSON-LD architecture without treating markup as a ranking shortcut.
Clarify what the page genuinely shows before adding markup. Then use JSON-LD with persistent
@id values for the principal entities: Organization on the home or company page, LocalBusiness for a real physical establishment, Service on a service page, Article or BlogPosting on an editorial page, and BreadcrumbList for its place in the site hierarchy. Follow Search Central for features supported by Google and Schema.org for the broader vocabulary. Valid schema is neither a ranking guarantee nor a rich-result guarantee.[1][2]Structured data is not hidden SEO copy that replaces the words, images and evidence a visitor can see. If the company has one name on the website, another in its logo and conflicting details across public profiles, JSON-LD will not magically resolve the inconsistency. Its value is to express already clear information in a consistent model that search systems can process with less ambiguity.
This article focuses specifically on semantic markup and entity architecture. For the wider organic strategy, visit our SEO optimization service. Pair it with our AI search optimization guide for generative discovery and the Google Maps SEO guide for local acquisition.
Schema markup is a relationship model, not a keyword list
It identifies an entity
Markup states that the main subject is a company, local business, service, person, article or another real concept. The most specific truthful type should represent that subject.
It supplies properties
It expresses verifiable details such as a name, canonical URL, logo, address, author, publication date and area served through a shared vocabulary.
It connects relationships
It can link an article to its author and publisher, a service to its provider, and a page to its logical position in the navigation hierarchy.
Google uses structured data as explicit clues about a page and to evaluate eligible content for supported search appearances. Search Central is the authority for what Google Search supports and how eligibility works. Schema.org provides a much wider vocabulary, including types and properties that Google does not present as a dedicated rich result.[1] That distinction prevents two common mistakes: expecting every valid type to generate a special result and removing useful semantic data merely because it has no dedicated Search gallery feature.
How does schema markup affect SEO?
Separate three outcomes when evaluating impact: understanding, eligibility for a search appearance and ranking. Accurate markup can help Google interpret the meaning of a page. When a supported feature and all applicable rules are satisfied, the page may become eligible for a rich result. Google nevertheless states that correctly implemented structured data does not guarantee that a rich result will appear. Markup on its own is not a promise of a higher organic position.[2]
| Claim | Accurate assessment | How to evaluate it |
|---|---|---|
| “Schema helps Google understand the page.” | Yes, when it is accurate, relevant and consistent with visible content. | URL Inspection, rendered HTML and validation tools |
| “Valid schema guarantees a rich result.” | No. Technical validity is only one eligibility condition. | Search Console enhancement reports and real search-result observation |
| “Every Schema.org type has a special Google appearance.” | No. Google supports the features listed in its own Search gallery. | Check the current documentation for the specific type |
| “More markup is always better.” | No. Irrelevant, invisible or misleading properties can violate quality guidelines. | Compare every property against the visible page and source data |
| “Service schema automatically creates service-review stars.” | No general Google rich result is promised for Service; it can still serve as a semantic layer. | Validate the vocabulary and track supported Google features separately |
The business case should be equally disciplined. Measure whether clearer search presentations improve qualified impressions, clicks or conversions, but do not credit every movement to markup. Content quality, query demand, competition, indexing, page experience and search-layout changes can move at the same time.
Build an entity graph instead of isolated snippets
On many websites, the problem is not missing schema but several systems describing the same company as unrelated objects. The theme creates one Organization, the SEO plugin creates another, and a custom block inserts a third publisher with a different name. A stable @id lets page-level objects refer to the same entity. A company might use https://example.com/#organization for the organization and https://example.com/#website for the website.
This diagram illustrates a recommended content model; it is not a diagram of Google’s ranking systems. Every node should have a real, visible counterpart on the site. Do not invent a Person merely to appear expert when there is no accountable author profile. Do not declare LocalBusiness when the organization has no qualifying establishment.
Create a human-readable identity dictionary first
Before writing code, document the legal name, trading name, primary URL, preferred logo, company description, contact details, official profile URLs, physical locations, real service areas, principal services and author profiles. Assign an owner to each field and define how a change is propagated to WordPress, the Business Profile and other public sources. This simple governance step prevents technically valid but factually obsolete markup.
On a multilingual website, the real-world organization normally remains the same entity. Its language-specific WebPage, Article, headline, description and inLanguage values differ. Connect those localized pages to the common organization rather than creating four unrelated companies. Language URLs, canonicals and hreflang annotations are a separate international SEO layer and must still be implemented correctly.
Use @graph to express shared relationships
An @graph can place several connected entities in one JSON-LD script. It is not mandatory, but it often makes responsibilities clearer: the WebSite belongs to the Organization, the Service is provided by it, the BlogPosting has it as publisher, and each of those references the persistent identifier instead of copying partial company details. The important feature is consistent identity, not the number of scripts.
Which schema type belongs on which page?
The best primary type reflects the page’s actual purpose. Marking a professional service as Product simply because Product has a visible result, or describing an online-only firm as a physical shop, is misleading. Google’s general guidelines require markup to represent the main content and recommend the most specific applicable type.[2]
| Page | Primary type | Related entities | Google Search note |
|---|---|---|---|
| Home or about page | Organization or an applicable subtype | WebSite, logo, official profiles and contact details | Can help with disambiguation and selected visual elements |
| Physical location page | The most suitable LocalBusiness subtype | Address, telephone, hours, geo and parentOrganization | Subject to Google’s Local business documentation |
| Service landing page | Service | provider, areaServed and serviceType | Schema.org semantics; no general dedicated rich-result promise |
| Blog article | Article or BlogPosting | author, publisher, headline, image and dates | Documented for Article search appearances |
| Site hierarchy | BreadcrumbList | ListItem entries and destination URLs | Documented for breadcrumb appearance |
| Author profile | ProfilePage with Person | sameAs, expertise and authentic publications | Must meet ProfilePage requirements |
Several relevant objects can appear on one page. A blog page can describe its main content as BlogPosting, its author as Person, its publisher as Organization and its path as BreadcrumbList. Linking these objects through @id references usually produces a clearer model than leaving them as disconnected fragments.
Do not assume that a subtype is safer merely because it is more specific. It must still be true. A marketing consultancy with an office is not automatically a Store. A national service business may use Organization for the provider and reserve LocalBusiness for a genuine customer-facing establishment. Document the decision so a future plugin change does not silently replace it.
Organization schema: the source of brand identity
Use it in the right place
Google recommends adding the full Organization information to the home page or a single page that describes the organization. It does not need to be repeated in full on every URL. Other objects can reference its stable @id.[3]
Use the right scope
Prioritize useful, verifiable details such as name, URL, logo and genuine contact information. Do not fill sameAs with unrelated directories or accounts the brand does not control or clearly represent.
Show the Organization JSON-LD example
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Company",
"url": "https://example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
},
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer service",
"telephone": "+00-000-000-0000"
},
"sameAs": [
"https://www.linkedin.com/company/example"
]
}
</script>This is a model, not company data to paste unchanged. Replace the domain, name, logo, telephone number and profile URL with information users can verify on the site. If no telephone number is published, remove the property rather than inventing one. Google’s Organization documentation has no universal required property and recommends supplying the relevant properties that apply to the organization.[3]
LocalBusiness and Service do not describe the same thing
LocalBusiness represents a particular physical business or branch. Service represents an activity or offer delivered by a provider. An agency office and a “technical SEO audit” are not the same entity. The establishment can have an address and opening hours; the service can have a provider, service type and actual area served. Connect them rather than merging their properties.
Google’s LocalBusiness documentation asks publishers to choose the most specific suitable subtype, provide the applicable required and recommended fields, and keep them aligned with the page.[4] Service-area businesses, hidden residential addresses and virtual offices must also comply with Google Business Profile rules. Schema markup cannot override profile eligibility or create a legitimate location.
Show the Service JSON-LD example
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Company",
"url": "https://example.com/"
},
{
"@type": "Service",
"@id": "https://example.com/technical-seo/#service",
"name": "Technical SEO Audit",
"serviceType": "Technical SEO audit",
"url": "https://example.com/technical-seo/",
"provider": { "@id": "https://example.com/#organization" },
"areaServed": [
{ "@type": "Country", "name": "United Kingdom" },
{ "@type": "Country", "name": "France" },
{ "@type": "Country", "name": "Germany" }
]
}
]
}The areaServed property does not prove that a company operates in a country and it is not a local-ranking switch. Language, delivery capability, contractual terms, contact options and visible business information should support the claim. Because Google does not document a general dedicated Service rich result, the primary purpose of this example is semantic clarity.[7]
Businesses with several locations
Create a useful, original and maintainable page for every genuine branch. Show its name, address, telephone, opening hours, map or directions, accessible services and any location-specific information. Each establishment can use its own LocalBusiness @id and connect to the principal company with parentOrganization. Duplicating the same generic copy across hundreds of city pages while changing only the place name does not create local value.
Local visibility is not a JSON-LD-only project. Business Profile verification, accurate categories and hours, authentic reviews, locally relevant links and a technically accessible landing page work together. Use our Google Maps SEO guide for the complete local workflow.
How should Article, BlogPosting and Breadcrumb connect?
Article markup can help Google understand the headline, representative images, publication and modification dates, and authorship. Google recommends adding relevant recommended properties, supplying suitable high-resolution images and linking an author URL to a page that genuinely identifies that author.[5]
Author
Use a real person or organization. The byline and profile must identify the same entity, while the profile visibly explains relevant expertise and publication history.
Dates
datePublished should represent first publication and dateModified a meaningful later revision. Do not change dates automatically to manufacture freshness.
Images
The marked image should be relevant, accessible and large enough for the intended appearance. Do not substitute a generic company logo for the article’s representative visual.
BreadcrumbList describes a page’s path through the site hierarchy. It need not copy every item in a visual menu. Choose a concise route that helps a searcher understand context, such as “Home → Insights → Technical SEO → Schema Guide.” Google expects at least two ListItem entries and allows the last item’s item URL to be omitted.[6]
Should every FAQ section receive FAQPage markup?
Google retired the FAQ rich-result feature on May 7, 2026 and removed its feature documentation in June 2026.[10] Continue publishing genuinely useful answers for readers, navigation and long-tail relevance, but do not present automatically generated FAQPage markup as a route to expandable Google results. Other systems may still interpret the Schema.org type; use Google’s current support list for Google Search decisions.
Entity SEO: brand evidence beyond schema markup
Entity SEO is not the practice of adding more keywords around a brand name. It is the work of helping search systems distinguish the same real-world person, organization, service and place across relevant pages. JSON-LD is only one layer. An informative about page, accountable team profiles, accurate contact data, clear service descriptions, editorial responsibility, trustworthy external profiles and real-world reputation all reinforce identity.
- The legal name, trading name and logo remain consistent across primary brand surfaces.
- The principal Organization
@idis stable; article publishers and service providers refer to it. - Author pages contain authentic biographies, relevant expertise and links to actual work.
- Service claims are supported by visible process, scope, evidence or case material.
- Language versions share the organization identity while localizing page data and
inLanguage. - Business address, telephone number and hours are current on the site, markup and public profile.
sameAscontains only profiles that the brand controls or that clearly represent it.
No single property guarantees a Knowledge Panel or a citation in an AI answer. Google says Organization markup can help it understand administrative details and disambiguate one organization from another; selected properties may influence visual elements such as a logo or information in a knowledge panel.[3] That statement must not be repackaged as a “Knowledge Panel activation code.”
Governance for a four-language website
Assign a content owner for each language and maintain one shared business-data dictionary. When a telephone number or logo changes, the team should know which visible pages, JSON-LD templates and external profiles require an update. A central theme component or a reliable plugin can manage shared entities, but every translation setup must be tested for the correct URL, dates, author, breadcrumb and language value.
Localization should preserve facts while adapting language. A translation system must not turn an Organization into a different business type or silently broaden its area served. Conversely, service names, descriptions, calls to action and examples should reflect how the target market actually searches and buys. This division preserves both technical consistency and local relevance.
Evidence before assertion
A property is stronger when a reader can verify it. If markup says an agency offers multilingual ecommerce development in three countries, the site should explain the service, markets, delivery method and contact path. If an author is marked as a specialist, a useful profile should describe their experience. Markup organizes evidence; it should not manufacture it.
Test before launch, observe after launch
Schema Markup Validator
Check syntax and general modelling against the Schema.org vocabulary. Passing this validator does not confirm eligibility for a particular Google Search feature.
Rich Results Test
Review critical and non-critical issues for structured-data types supported by Google. Inspect the rendered code and the exact entity selected by the tool.
URL Inspection
Confirm that Google can access the live URL, that rendered HTML contains the intended markup and that indexing and canonical signals point to the expected page.
| Check | Frequency | Warning example | Response |
|---|---|---|---|
| Template validation | After every theme or plugin release | Publisher or image disappears | Test representative URLs and correct the regression |
| Search Console reports | Weekly | Sudden fall in valid items | Compare affected templates with deployment dates |
| Business data | Monthly and after every change | Hours or address mismatch | Update the source dictionary and all dependent channels |
| Supported-feature list | Quarterly | Google documentation changes | Remove obsolete markup from the priority queue |
| Organic appearance | Trend-based review | CTR changes materially | Segment by query, device, country and result type |
An increase in valid items is not the same as an increase in traffic. Track impressions, clicks, click-through rate and qualified conversion separately. Organic performance can fall after a design release while structured data remains valid; technical accessibility, page intent, competition and search-interface changes require separate investigation.
Nine common schema-markup mistakes
1. Marking invisible information
Adding ratings, prices, questions or services that users cannot see merely to obtain a search feature can violate structured-data quality rules.
2. Choosing a misleading primary type
Describing a service company as Product, an online-only operation as a physical LocalBusiness or an ordinary post as NewsArticle distorts the page.
3. Creating several organization identities
The theme, SEO plugin and custom code produce separate names and @id values for the same company, fragmenting publisher and provider references.
4. Publishing fake review markup
Ratings that are hidden from users, fabricated or misleadingly self-serving can create manual-action risk and damage trust beyond search.
5. Relying on obsolete feature support
A plugin’s green status does not mean Google still displays the marked type. Prioritizing retired appearances wastes implementation and reporting time.
6. Using non-canonical identifiers
Redirect chains, mixed protocols and outdated paths in logo, author, article or service identifiers make the entity graph unstable.
7. Refreshing dates automatically
Setting dateModified to today on every page view, without a substantive edit, does not represent a trustworthy content update.
8. Mixing language versions
An English page with another language’s headline, inLanguage value or breadcrumb destination signals faulty localization.
9. Testing only on installation day
Theme, CMS and plugin updates can break or duplicate markup. Representative templates need regression checks after every material release.
Plugin, theme or custom JSON-LD?
The right implementation depends on the content model and maintenance capacity. A reputable SEO plugin can manage the basic Organization, WebSite, Article and Breadcrumb graph for a conventional company site. A multi-location operation, specialist service catalogue or headless build may need a central data model and custom output. Whichever method is chosen, do not allow two systems to generate competing versions of the same entity.
| Method | Strength | Risk | Suitable use |
|---|---|---|---|
| SEO plugin | Fast, maintainable and editor-friendly | Defaults may be inaccurate or duplicated | Standard company and editorial websites |
| Theme template | Closely connected to the page model | May disappear when the theme changes | Controlled custom WordPress themes |
| Custom plugin or data layer | Centralized and scalable modelling | Higher engineering and testing responsibility | Multiple locations, integrations and custom post types |
| Manual page-level script | Direct control for one isolated case | Copying, ownership and maintenance errors | Limited prototype, not a durable system |
Audit current output before changing tools. Searching source code for application/ld+json is a useful start but not sufficient: check the rendered DOM and count the Organization, Article and Breadcrumb entities. Record which properties each plugin owns before disabling it. Test on representative pages rather than removing the entire live schema layer in one step.
When website architecture and design define the content model before schema implementation, long-term maintenance becomes easier. Headline, featured image, author, dates, provider and location fields can come from one controlled editorial source rather than being retyped in several plugins.
A practical ownership rule
Give each entity type one system of record. The SEO plugin might own WebSite, Organization, Article and Breadcrumb, while a custom integration owns location or service data. Write this boundary down. If a later plugin update introduces a new graph, the team can quickly identify the overlap instead of discovering duplicate objects after Search Console warnings appear.
A 30/60/90-day schema and entity SEO plan
Inventory and foundation
Catalogue current JSON-LD blocks, plugins and relevant Search Console reports. Approve the business-data dictionary. Consolidate Organization and WebSite identities, then correct discrepancies between the home page, contact details and public profiles.
Connect templates
Implement service, location, article, author and breadcrumb templates in commercial priority order. Test several representative URLs in every language with Rich Results Test, Schema Markup Validator and URL Inspection.
Monitor and govern
Add regression checks to the release process. Report valid items, impressions, clicks and qualified outcomes separately. Remove obsolete or unsupported markup from priority workflows and assign owners to mutable data fields.
How should work be prioritized?
The objective is not to deploy the entire Schema.org vocabulary. It is to reduce ambiguity on commercially and editorially important pages. Fix the central Organization identity first if it is fragmented. Prioritize LocalBusiness templates when branch discovery matters, and Article, author and breadcrumb data when editorial acquisition matters. At each stage, prove that structured properties come from visible, maintained information.
- The principal Organization identity and official fields have been approved.
- The primary entity for every important page template has been documented.
- Google-supported appearances are distinguished from the wider Schema.org semantic layer.
- URLs, headlines, breadcrumbs and
inLanguagevalues have been checked in all four languages. - Article images, logos and profile URLs are crawlable and stable.
- Critical issues are fixed and misleading or invisible properties are removed.
- Search Console trends and real result appearances have owners and a review calendar.
Define a measurable baseline
Record the number of affected templates, valid items, warnings, organic impressions and qualified conversions before deployment. Annotate every release date. Compare equivalent periods and segment results by country, language, device and query class. This will not isolate schema as a laboratory experiment, but it prevents vague success claims and makes regressions easier to detect.
Schema markup and Entity SEO FAQ
Does schema markup directly improve rankings?
Google does not present it as a direct ranking guarantee. Accurate markup can support understanding and eligibility for supported rich results, but it does not replace useful content, technical accessibility or the wider signals used by search systems.
Should a site use JSON-LD or Microdata?
Google can process JSON-LD, Microdata and RDFa. It generally recommends JSON-LD when the site setup permits it because a separate script is often easier to implement and maintain.[1]
Should full Organization schema appear on every page?
No. Google recommends the home page or one page that describes the organization. Page-level objects can refer to the stable Organization @id instead of duplicating the complete record on every URL.
Does Service schema create a Google rich result?
Service is a valid Schema.org type, but Google’s Search gallery does not document a general dedicated Service rich result. It can still clarify meaning and relationships, but should not be sold as a guaranteed special appearance.
Is installing a schema plugin enough?
No. Review the types, values and identifiers it produces, compare them with visible information, and verify that the theme or another plugin is not generating a duplicate graph.
Can a schema error cause a manual action?
A simple syntax error usually affects processing or eligibility for the related feature. Spammy, misleading or invisible structured data can lead to a structured-data manual action.[2]
Should ordinary business sites still use FAQPage schema?
Useful questions and answers remain valuable for readers, but Google stopped showing the FAQ rich-result feature on May 7, 2026. Ordinary companies should not expect expandable FAQ results and should not prioritize FAQPage markup for that Google appearance.[10]
Can the same schema be used across four languages?
The persistent Organization identity can be shared, but each page needs its own URL, localized headline and description, breadcrumb path and accurate inLanguage value. The visible content and structured data must agree within each language version.
How should schema success be measured?
Monitor validity and errors in Search Console, impressions and clicks in performance reports, actual result appearance through representative checks, and commercial value in analytics or CRM. Do not treat correlation after a release as automatic proof of causation.
Sources and methodology
Claims about Google Search appearances and eligibility rely on Search Central documentation. General type and property definitions rely on the Schema.org vocabulary. Sources were reviewed on September 7, 2026.
- Google Search Central — Understand how structured data works.
- Google Search Central — General structured data guidelines, updated July 10, 2026.
- Google Search Central — Organization structured data.
- Google Search Central — LocalBusiness structured data.
- Google Search Central — Article structured data.
- Google Search Central — Breadcrumb structured data.
- Google Search Central — Structured data features supported by Google Search.
- Google Search Central Blog — Simplifying the search results page, June 12, 2025 and subsequent updates.
- Schema.org — Schemas and type hierarchy.
- Google Search Central — FAQ rich-result feature retired on May 7, 2026.
- Google Search Central — ProfilePage structured data.
Fix the brand data architecture before adding more code
Levent Global Media can audit duplicated or inaccurate markup, design a four-language entity graph and align WordPress templates with information that visitors can actually see and verify.
