What is schema markup?

What is schema markup?

Schema markup uses Schema.org vocabulary to describe information through named types, properties, and relationships in a supported data format. It gives software an explicit representation of the page’s real subject matter. The vocabulary is broader than Google’s search features, so accurate schema does not automatically imply eligibility for a particular rich appearance.

• Schema.org’s getting-started guide, accessed October 8, 2026, introduces the difference between presentation and meaning.

  A heading tells the browser how to display text. A typed description tells a consumer what the text represents, such as a person, organization, service, or creative work.

• Structured data is the broader concept, and schema is one vocabulary used to express it.

  The format is another layer. JSON-LD can encode those statements in a data block, while Microdata and RDFa attach meaning through HTML attributes. The representation should fit the real published information.

• A service website can describe its verified organization and actual offering without inventing a local office or qualification.

  The markup should clarify existing facts rather than become an alternative set of marketing claims. Readers still need an accurate visible explanation; hidden descriptions cannot substitute for it.

• The useful implementation question is what each statement means.

  A large recognized graph can still describe the wrong subject or connect unrelated entities. Choose the actual purpose, examine appropriate type and property definitions, and verify the delivered description instead of treating entity count as a quality metric.

• Structured data is the broader information representation.

  Schema.org supplies vocabulary, while a consumer such as Google applies its own feature rules.

How does the type hierarchy guide selection?

The type hierarchy guides selection by connecting more specific descriptions with broader concepts and inherited properties. Choose a type that accurately represents the subject, not merely the one associated with a desired search appearance. A page can discuss a service without itself being the service, and its provider is a different entity from that offering.

• Schema.org’s data model describes a hierarchy that can involve multiple inheritance.

  A more specific item can share properties through broader types. This makes the vocabulary reusable, but it does not mean that every available property has a meaningful value for every real-world instance.

• Read the current type page rather than selecting from a plugin’s abbreviated menu alone.

  Check its definition, inherited relationships, and examples. A similarly named type can describe something different from the resource at hand. The visible content and verified subject should settle the decision, not a superficial keyword match.

• For an organization, confirm that the description concerns the real entity.

  For an article, identify the actual creative work and its author relationship. A shared header containing business details does not automatically make every article’s main subject the business itself. Preserve that distinction when the template emits several connected items.

How should properties and expected values be read?

Read a property by its meaning and expected value types, then determine whether the page supports an accurate value. Some relationships can use an object, text, or a resource reference depending on the vocabulary and consumer. A validator accepting a string does not prove that the string conveys the complete relationship required for the intended feature.

• Schema.org’s data-model guidance describes flexible domains and ranges.

  Expected values are not equivalent to a universally rigid closed schema. Consumer-specific requirements can be stricter. Keep broad vocabulary conformance separate from the exact object structure a supported Google feature requires.

• A nested object can describe a provider more clearly than a bare name when the verified identity and relationship matter.

  That extra structure still needs accurate facts. Adding an address or credential merely to make the object look complete would create unsupported statements rather than improve the description.

• Inspect property spelling and capitalization.

  Vocabulary identifiers have defined forms; a similar-looking invented key does not necessarily express the intended property. A parser may accept an unknown JSON key while the vocabulary consumer interprets nothing useful from it. Syntax validity is therefore a narrower check than semantic representation.

• When a value is unavailable, omit it or improve the underlying verified source where appropriate.

  Do not convert an empty field into plausible text automatically. Missing information and inaccurate information are different conditions, and the latter cannot be repaired by a validator reporting that the resulting object parses.

How can a service be separated from its provider?

An offering and its provider are different subjects. Describe them separately and connect the offering to its provider through the provider property. A business may provide several services with different scope or availability, so copying all organization details into every offering can misrepresent distinctions the customer needs to understand.

• Schema.org’s Service definition, accessed October 8, 2026, describes the vocabulary for an offering and its relationships.

  Its provider property identifies who supplies the service. The Organization definition describes the organization itself. Read those roles before creating one undifferentiated object for the entire website.

• A specific repair offering can have a geographic scope different from the organization’s full operating area.

  Its hours can also differ from general contact availability. These are factual differences, not reasons to invent additional local branches or separate companies. The model should reflect the actual offering and responsible provider.

• A broker is another role when an entity arranges an exchange rather than supplying the service directly.

  The Service vocabulary distinguishes that relationship. Do not assign it casually based on a business category or confuse lead-routing activity with firsthand service provision when the actual commercial role is different.

• Google’s introduction warns against assuming that every vocabulary item corresponds to a supported dedicated feature.

  A recognized Service description can communicate information without establishing the search appearance the business expects. Select supported feature requirements separately from the accurate service model.

• This minimal example uses reserved addresses to show the Service/provider relationship.

  It describes a hypothetical offering and organization, rather than verified details of a real business:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Boiler maintenance",
  "provider": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example Heating"
  }
}

The offering’s name identifies the work. The provider identifies who supplies it. A real implementation needs its own verified names and stable identifiers; the example does not establish Google feature eligibility.

Why are service area and physical address different facts?

Service area describes where an offering is provided, while a physical address describes a location associated with an entity. Those facts can differ substantially. A business serving customers across a region does not thereby have an office in every named place. Publish only the verified relationship rather than turning an area list into unsupported location claims.

How should service hours differ from contact access and offer terms?

Operating schedules and access channels describe different relationships from offer terms. A service’s fulfillment hours can differ from its contact desk’s availability. Verify each property’s purpose before generating values, so the description does not imply unsupported booking terms, prices, or access conditions merely because a plugin exposes convenient fields.

• Schema.org’s Service vocabulary describes hoursAvailable, availableChannel, and offers as different concepts.

  A means of accessing a service can differ from the service’s fulfillment conditions. Use the definitions and verified business information instead of assigning all contact details to whichever field a plugin happens to expose.

• A telephone option can be available while the underlying work is scheduled later.

  A request form can accept inquiries without guaranteeing immediate attendance. The visible explanation should preserve those limits, and machine-readable descriptions should not turn general contact availability into an unsupported promise of continuous service provision.

• Offer information also requires actual terms.

  A generic starting-price sentence may not describe every job. Verify the currency and applicable customer conditions where the supported offer description requires them. Do not invent a fixed price or use a placeholder amount to eliminate a validation warning when the real service is quoted individually.

What do entity identity and page references contribute?

Entity identity and page references clarify which subject a description concerns and which resources describe or identify it. Keep those meanings distinct. A page URL, an entity identifier, and an external identity reference need not represent the same relationship, so review their purpose before copying one convenient address into every field across the graph.

• Schema.org’s data-model documentation discusses identifiers and relationships such as about, mainEntityOfPage, and sameAs.

  These are not interchangeable lists of links. A page can mention several subjects while describing one primary item, and an official identity reference differs from an ordinary contextual source citation.

• A canonical tag expresses the preferred representation among equivalent pages.

  It does not automatically define the identity of the provider or author described on those pages. A single organization can have many resources without becoming a new organization every time a page slug changes.

• Use consistent verified references where the same entity appears across templates.

  Contradictory names or unrelated identifiers can make output confusing even when every block is technically readable. Inspect the actual graph emitted by different producers rather than assuming that a shared plugin setting guarantees consistency everywhere.

• Do not use identity links to imply affiliation or endorsement.

  An authoritative-looking profile should identify the stated subject, not merely resemble its topic or industry. The relationship is a factual assertion. It cannot borrow legitimacy from an unrelated institution simply because its address looks trustworthy.

How do Microdata scope and nested items affect meaning?

Microdata scope and nesting determine which item a property describes. A misplaced scope can attach a person’s name to an organization or a review value to the wrong subject. Inspect the actual HTML relationships rather than checking attributes individually, because syntactically plausible markup can express a different graph from the one the visible layout suggests.

• Schema.org’s Microdata guide explains itemscope, itemtype, and itemprop, including nested items.

  The enclosing item establishes context for its properties. A nested item can supply the value of a relationship, but its own properties need to remain associated with that nested subject.

• Component boundaries can change those relationships.

  A reusable card may introduce a scope while surrounding markup assumes its properties belong to a parent. A layout refactor can move an attribute into another container. Review the parsed result after changes rather than treating the rendered visual arrangement as proof of correct item ownership.

• JSON-LD can express nested relationships separately from visible HTML attributes, but it has its own output-consistency requirements.

  Switching format does not establish that the underlying facts or entity links became accurate. The implementation must still represent the intended items and their correct associations.

• Choose a maintainable approach for the actual system.

  If HTML scopes are difficult to preserve across components, review alternatives with appropriate testing. Do not claim that one encoding automatically creates better rankings; compare maintainability with the actual consumer requirements while retaining accurate visible information.

How should machine-readable time and status values be formatted?

Machine-readable time and status values need representations appropriate to the property and consumer, while preserving the actual visible fact. A human phrase can be ambiguous to software. Check the documented value form instead of inserting a display string automatically or assuming that any accepted text conveys the intended event, interval, or status accurately.

• Schema.org’s getting-started guide discusses machine-readable representations of dates and other information.

  Formatting is a semantic task as well as a syntax task. A scheduled date, publication date, and last substantive edit can describe different events even when the CMS stores them in similar fields.

• Check timezone meaning where a time is involved.

  A date-only fact should not be expanded into an invented precise timestamp. An actual local appointment or event time should not silently become another timezone. Use the verified source and applicable feature instructions rather than derive artificial precision from a convenient server default.

• Enumerated states need the correct defined meaning.

  A displayed status label may not correspond directly to a vocabulary value. Read the current property and enumeration definitions before mapping application states. An unsupported or misleading mapping remains wrong even when a generic JSON parser accepts the string.

• Avoid placeholder durations and fabricated counts.

  If the page does not establish how long something takes, schema should not invent an interval because the property exists. Improve the underlying factual explanation where appropriate or omit the unsupported statement, keeping the description honest about what the published resource actually provides.

How should collections and breadcrumb relationships be modeled?

Collections and breadcrumb relationships should express the actual grouped resources and navigational context rather than imply that the listing itself is one individual service or article. Distinguish the collection from its members. A template can describe both appropriately, but each item needs a justified identity and relationship consistent with the visible information people can access.

How should vocabulary validation and Google feature tests be separated?

A broad vocabulary check and a consumer-specific eligibility test inspect different requirements. One can recognize schema statements that have no dedicated supported Google appearance. Read each result’s purpose before calling a generic item invalid or claiming that a successful schema check establishes eligibility for every rich result and display context.

• Google’s validation guidance recommends feature-specific testing, while Schema.org’s data-model guidance describes flexible vocabulary use.

  The broader model can support consumers beyond Google. That does not override Google’s own required property forms or content guidelines for its supported features.

• Start with readable output.

  Then inspect the selected type, property meanings, and relationships. Finally check the applicable feature requirements and visible facts. This sequence helps distinguish malformed serialization from a semantic mistake or an unsupported search expectation, rather than changing types at random until one tool shows a green result.

• A noindex instruction and other access restrictions require separate review of the live resource.

  Testing a pasted data block does not prove the public page can be processed. A 404 error can also leave an otherwise readable description detached from the intended working page.

• Warnings deserve factual interpretation.

  A recommended property may be unavailable legitimately; another message may reveal a wrong value or incomplete relationship. Do not fill fields with invented ratings or credentials merely to clear the report. Technical acceptance cannot make an unsupported assertion true.

How can template and plugin changes create conflicting schema?

Several data producers can describe one subject differently, or retain stale page-specific statements after the visible resource changes. Inspect delivered output across relevant page classes and navigation states. The existence of a configured schema feature does not establish that the public graph is coherent, current, or consistent with the visible page after every component change.

• Google’s general guidelines require representative current information.

  A plugin can emit an old author while the template shows the new one. An organization block can use a different identity from application code. Those conflicts need source reconciliation, not indiscriminate removal of every additional item.

• JavaScript SEO becomes relevant when route transitions update some content but retain another page’s data.

  Test direct entry and meaningful transitions. An owner’s loaded session can hide a public initialization gap, so inspect what the current resource actually delivers under relevant anonymous conditions.

• A shared business record can provide consistent verified information, while page-specific statements come from their appropriate records.

  Review the boundary and generated output. Centralization helps only when the source values and relationships are correct; it can spread the same false location or credential across the entire site otherwise.

• After a change, test representative classes and the actual state that previously failed.

  Confirm accurate facts and supported relationships without manufacturing expected results. The immediate verified outcome is a coherent delivered description, not an automatic search-position improvement inferred from using one plugin or framework.

How should a schema repair be validated and reported?

Validate a repair by checking the delivered description against visible facts, the selected vocabulary meanings, and the intended consumer’s requirements. Confirm the relevant public routes and references still work. A clean validator establishes only its checked conditions, while search display and customer outcomes require separate observations rather than a promise attached to the corrected markup.

• Google’s general guidelines distinguish technical and quality requirements.

  Keep that distinction in the repair account. A syntactically readable false service area is still misleading, while a truthful generic description may have no dedicated supported Google appearance.

• Illustrative diagnosis, not client data.

  A shared service template copies the organization’s broad contact hours into every specialized offering. The business verifies that one service has narrower availability. The developer changes the source relationship so the service description reflects its actual schedule without altering unrelated organization contact information.

• The review checks visible explanation and machine-readable output together, including representative unaffected offerings.

  It confirms that no fictitious address, rating, or credential was added to satisfy a warning. Feature validation is run only for the intended supported purpose, with any unavailable properties or display limits described honestly.

• Report the corrected statement and tested conditions rather than a fabricated visibility result.

  That evidence makes the change reviewable and keeps schema tied to the actual resource. The next technical decision can then address a real remaining relationship or delivery issue instead of expanding the graph without a useful purpose.

Continue the public-page review

Use our website SEO checker for preliminary public-page observations. Review vocabulary and delivered facts through the procedures above. Our technical SEO services connect verified representation issues with appropriate publishing and template repairs.