Invalid Schema Types: Fixing schema.org Types in JSON-LD

What an invalid type finding means

Every entity in JSON-LD carries an @type. The value is a name from the schema.org vocabulary, and it is the single most important word in the block: it tells a parser which properties to expect and which search features the entity could qualify for. schema.org type names are exact identifiers, not descriptions. Product is a type; Products, product and Product Page are not.

When a name does not match a defined term, a JSON-LD processor still builds a node, but the node has a type nobody recognises. Google's systems have no feature for it, other consumers have no definition for it, and the properties hanging off it lose their context. The practical effect is close to having no markup at all for that entity, with the added cost that the block still looks finished to anyone reading the source.

It helps to separate three situations that often get mixed up:

The JSON Checker checks each type against schema.org, so its finding is about the first row: a word that is not in the vocabulary at all.

The invalid types that turn up most

Most invalid types fall into a handful of patterns. Once you know them you can usually spot the problem by eye before looking anything up.

Where invalid types come from

Plugins that offer a drop-down list of types almost never produce a misspelt type. The problem tends to come from places where a person typed the name or where a template builds it from other data:

• Hand-written blocks pasted into a page builder, a header snippet or a Custom HTML block. One typo is enough, and nobody re-reads the block after it goes live.
• Old tutorials and forum answers. Some examples online have always been wrong, and some use terms that schema.org has since marked as superseded, such as the reviews property that was replaced by review.
• Free-text fields fed into @type. A theme option labelled "Business type" lets the site owner write "Dental Practice", and the template drops that straight into the markup. Dentist is the real type; "Dental Practice" is not.
• Translation and localisation. Multilingual plugins sometimes translate every string in a template, including the type names. Organización is not a schema.org type in any language.
• Prefixes that need a context. "@type": "schema:Product" only works if the @context defines the schema prefix. With the usual "@context": "https://schema.org" it produces an unknown type.
• A missing at sign. Writing "type": "Product" creates an ordinary property called type that schema.org does not define, and the entity ends up with no type at all.

The full address of a type, such as "@type": "https://schema.org/Product", is valid JSON-LD and resolves to the same term. It is unusual and harder to read, so most sites stick to the short name, but it is not an error.

Checking a type name properly

The authoritative list is schema.org itself. The full hierarchy page at schema.org/docs/full.html lists every current type in a tree starting from Thing, and each type has its own page at schema.org/ followed by the exact name. When you check a type, compare it character by character with the heading on that type's page. Capital letters in the middle of a name, such as the P in WebPage or the B in LocalBusiness, are part of the identifier.

A few habits make the check quicker and more reliable:

• Look at the breadcrumb on the type's page. It shows where the type sits, for example Thing, Organization, LocalBusiness, FoodEstablishment, Bakery. That tells you which properties it inherits and whether a more specific type exists below it.
• Watch for pending and retired terms. schema.org marks some types as pending, meaning they are proposals still under discussion, and some as superseded. Pending types are valid in the vocabulary but widely ignored by consumers; superseded ones should be replaced with the term the page points you to.
• Test in the Schema Markup Validator. It reads any schema.org markup, not just Google features, and shows each detected entity with its type. An entity that comes up with a strange type or no recognised properties usually has a bad name.
• Do not rely on the Rich Results Test alone. It lists only the types Google has rich results for. An invalid type simply does not appear, which is easy to mistake for "no problem found".

Types inside nested objects

Invalid types are not only a top-level problem. Every nested object that has its own @type needs a real name too, and it should be a type the parent property expects. These are the pairings the checker most often sees go wrong:

Here is a LocalBusiness block with four invalid types, followed by the corrected version.

{
  "@context": "https://schema.org",
  "@type": "Hairdresser",
  "name": "Larkspur Hair Studio",
  "address": {
    "@type": "Address",
    "streetAddress": "14 Mill Lane",
    "addressLocality": "Matlock",
    "postalCode": "DE4 3AA",
    "addressCountry": "GB"
  },
  "geo": { "@type": "GeoCoordinate", "latitude": 53.138, "longitude": -1.556 },
  "parentOrganization": { "@type": "Organisation", "name": "Larkspur Group" }
}

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HairSalon",
  "name": "Larkspur Hair Studio",
  "url": "https://www.example.co.uk/",
  "telephone": "+44 1629 000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "14 Mill Lane",
    "addressLocality": "Matlock",
    "postalCode": "DE4 3AA",
    "addressCountry": "GB"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": 53.138, "longitude": -1.556 },
  "parentOrganization": { "@type": "Organization", "name": "Larkspur Group" }
}
</script>

The first block parses without complaint, which is exactly why it survives unnoticed. Only a check against the vocabulary reveals that the business, its address, its coordinates and its parent company all have types that do not exist.

The fix, step by step

Edge cases: arrays, pending terms and extensions

More than one type on an entity

JSON-LD allows @type to be an array, and schema.org permits an entity to belong to several types. A shop page for a printed book can reasonably be ["Book", "Product"], because it is both. Every name in the array must be valid, though, and adding a parent alongside its own child adds nothing: ["Organization", "LocalBusiness"] says the same as LocalBusiness alone, because every LocalBusiness is already an Organization.

Pending types

Terms in schema.org's pending area are real proposals with their own pages, so they are not invalid in the strict sense. They can change or be withdrawn, and search engines generally do not act on them unless their own documentation says they do. If you use one, pair it with a stable type where possible and check the term again when schema.org publishes a new release.

Custom or extension vocabularies

You can technically add terms from other vocabularies by defining them in @context. That is valid JSON-LD, but most consumers of schema.org markup will ignore anything outside schema.org, and a mistake in a custom context can break how the rest of the block is read. For ordinary websites, stay within schema.org and use additionalType for anything extra.

Types that sound too broad

Thing and CreativeWork are valid, so they will not trigger an invalid type finding. They are rarely the best choice, and a page marked up only as Thing tells a machine almost nothing. Treat them as a sign the type was never properly chosen rather than as an error.

Stopping invalid types coming back

• Never let free text become a type. Any CMS field, theme option or spreadsheet column that feeds @type should be a fixed list of valid schema.org names.
• Keep a short allow-list. Most sites use fewer than twenty types. Write them down with the exact spelling and have developers copy from that list rather than typing names from memory.
• Exclude markup from translation. In multilingual plugins, mark JSON-LD templates or type strings as not translatable, so only the human-readable values change between languages.
• Add a build check. A small script in your deployment can parse each JSON-LD block and compare every @type against the allow-list, failing the build on anything unknown.
• Recheck after schema.org releases. Terms are occasionally superseded. A quick look at the release notes a couple of times a year catches anything your site still uses.

For the other JSON-LD findings, start at JSON-LD Fixes. If the checker also reports missing fields once the types are corrected, that is normal: a real type brings its own requirements, which the JSON-LD Schema Guide explains.