probeo

Why does @context need to point to schema.org for structured data to work?

jsonld-context-not-schema-org page

The issue

A JSON-LD block whose @context points somewhere other than schema.org is read against a vocabulary search engines don’t use. Its properties mean nothing to them, so the block earns nothing, and it looks complete in the source.

The cause is usually a theme, a plugin or an old template that declares its own vocabulary URL. The block parses and has a context, which makes this harder to spot than a missing one.

Scope

Each block is checked on its own. Blocks that already reference schema.org are unaffected, and fixing one block doesn’t change the others.

How to check you have it

  • In probeo: the page reports @context does not reference schema.org, as a warning.
  • By hand: view the page source and read the @context of each JSON-LD block. Anything that isn’t a schema.org URL is the problem.
  • With a validator: paste the block into the Schema Markup Validator and check that the types it finds are schema.org types.

The fix

Replace the @context value with "https://schema.org".

Then confirm that each type and property in the block exists in schema.org, since a custom vocabulary may have used names schema.org doesn’t define.

Done when: every block’s context is schema.org, its types and properties are schema.org terms, and the check above comes back clean.

Do not

  • Do not keep a proprietary context alongside schema.org without a reason.
  • Do not assume search engines will read schema.org when a different context is declared.

FAQ

Does Google accept http://schema.org or only https://schema.org?

Google currently accepts both HTTP and HTTPS for schema.org context. However, schema.org officially recommends HTTPS, and validators increasingly flag HTTP as outdated. Using HTTPS avoids ambiguity and aligns with the current specification.

What if the CMS generates a custom context URL automatically?

Some CMS platforms and structured data plugins inject their own vocabulary URLs. These typically wrap or extend schema.org but are not recognized by search engines. Override the CMS output to use schema.org directly, or configure the plugin to emit standard schema.org context.

Can schema.org context be combined with a custom vocabulary in the same block?

Technically yes. @context can be an array containing both schema.org and a custom namespace. Search engines will process the schema.org portion and ignore custom terms. This adds complexity without clear benefit for SEO purposes.

How does this differ from missing @context entirely?

Missing @context means no vocabulary reference exists at all—properties are undefined strings. Non-schema.org @context means a vocabulary exists but search engines do not recognize it. The symptom is the same (no structured data features), but the cause and fix differ. Missing context requires adding @context. Wrong context requires changing the URL.

Does a trailing slash on the schema.org URL matter?

Google treats “https://schema.org” and “https://schema.org/” as equivalent. Both resolve correctly. Convention and documentation use the version without trailing slash. Either works, but consistency with official examples avoids confusion.

Will search engines eventually support vocabularies beyond schema.org?

There is no indication of this. Schema.org was specifically created as a shared vocabulary between Google, Bing, Yahoo, and Yandex. Search engines have no incentive to expand support to arbitrary vocabularies. For SEO-relevant structured data, schema.org remains the only viable context.

Which product detects this

Probeo checks this on every page of your site as part of Site Clarity. This page explains one instance; the product tells you every page that has it.