Should you really enhance your structured data with all available fields?

What do we mean by 'additional fields' in this context?

When we refer to additional fields, we mean all the Schema.org properties that exist in the standard vocabulary but that Google has not explicitly documented as usable. For example, for a Person type, Schema.org offers dozens of properties: skills, awards, colleagues, workLocation, and so on. However, Google only guarantees the use of those listed in its own Search Central documentation.

The issue? Some SEOs attempt to maximize their chances by stuffing their JSON-LD with every available property. The idea is that Google might one day use them, or that they would act as a weak signal. This statement ends that fantasy: If it’s not documented, it’s ignored.

Why does Google limit the usable fields?

The reason lies in the architecture of the search engine itself. Google cannot generate rich results for properties it hasn’t tested, validated, and integrated into its display templates. Every new field displayed in the SERPs requires development, user testing, and spam verification.

Allowing all Schema.org fields would create technical chaos. Websites could markup anything, multiply formats, and Google would lose quality control. Limiting the fields to predefined ones allows for standardized display and ensures a consistent experience for users.

Does this restriction apply to all types of markup?

Yes, without exception. Whether you are using JSON-LD, Microdata, or RDFa, and regardless of the type of content (Article, Product, Recipe, Event, Organization), only the fields listed in the official documentation of Google Search Central are taken into account for display or ranking. The rest is parsed by the crawler but does not influence anything.

This also applies to proprietary extensions. Creating your own properties outside the standard Schema.org vocabulary is technically possible, but Google will completely ignore them. The only exception is beta tests that Google sometimes announces, such as certain experimental fields in very specific verticals.

• Fields not documented by Google are parsed but never displayed or used for ranking.
• Overloading your structured data slows down parsing and complicates maintenance without any gain.
• Focus on the required and recommended fields listed in Search Central.
• Regularly check Google’s documentation: new fields may be gradually added.
• Use the rich results test to validate what Google actually sees in your markup.

Is this statement consistent with what we observe in the field?

Absolutely, and it’s even a welcome confirmation. For years, we have seen sites markup dozens of unnecessary properties in the hope of a hypothetical advantage. Audits regularly reveal bloated JSON-LD with ghost fields that no one ever checks. Google finally clarifies: anything not in the documentation is noise.

A/B testing shows that removing these unnecessary fields has absolutely no impact on the appearance rate in rich snippets or on positions. In contrast, some sites have noticed a slight improvement in crawl speed after cleaning up, probably because Google’s parser had less data to ingest. Not massive, but it’s something.

What nuances should be added to this rule?

First nuance: “currently used” does not mean “never used.” Google may decide tomorrow to leverage a field it ignored yesterday. [To be verified] But betting on this possibility to markup in advance is a gamble, not a strategy. It’s better to monitor official announcements and quickly adapt when a new field is activated.

The second nuance: some fields may be useful for other search engines or third-party tools (aggregators, voice assistants, CMS). If your visibility strategy goes beyond Google, maintaining a few additional properties may make sense. But in that case, clearly document why you are integrating them and for what purpose. Don’t leave dead code for no reason.

What are the risks of ignoring this recommendation?

The first risk is unnecessary technical complexity. Every added field multiplies maintenance points, potential errors, and incompatibilities between your templates. Teams may waste time debugging properties that no one uses. I’ve seen sites with 50 lines of JSON-LD for basic product pages when 15 lines would suffice.

The second risk is more insidious: by stuffing your structured data, you risk diluting the truly important signals. Google might interpret excessive markup as spam or, more simply, fail to properly parse crucial fields drowned in the mass. Clarity and conciseness are qualities the engine appreciates.

What actionable steps should you take for your existing pages?

First action: audit your current structured data. Export all your JSON-LD, Microdata, or RDFa, and compare each property with the official documentation of Google for the relevant type. Anything not listed in Search Central can be removed without hesitation. Automate this check if your site has thousands of pages.

Second action: simplify your templates. Many CMS or plugins generate markup by default with superfluous fields. Customize your outputs to keep only what is strictly necessary: the required fields to avoid Search Console errors, and the recommended fields to maximize your chances of appearing in rich results. Nothing more.

How can you avoid overloading your future implementations?

Adopt a simple rule: before adding a field, ask yourself if it is documented by Google and if it concrete improves your visibility. If the answer is no to both questions, abandon it. Maintain a markup checklist for each content type, based on the official documentation, and train your teams to consult it regularly.

Use Google Search Console's rich results test to validate each new implementation. This tool shows you exactly which fields are recognized and which are ignored. If a field does not appear in the report, it serves no purpose. Remove it immediately to lighten your code and facilitate future updates.

Should you anticipate future changes in markup?

No, and this is precisely the trap to avoid. Some SEOs preemptively add fields in the hope that Google will enable them later. This approach creates technical debt for a hypothetical benefit. It’s better to adopt a reactive and agile stance: monitor Google announcements, quickly test new fields when they are official, and deploy cleanly.

Subscribe to Google Search Central RSS feeds, follow their official accounts on social media, and participate in SEO forums to detect weak signals. When a new field is announced, you’ll have plenty of time to implement it before your competitors take advantage of it. Speed of execution counts more than blind anticipation.

• Audit all your JSON-LD and remove fields not documented by Google Search Central.
• Test your pages with the rich results testing tool to identify ignored properties.
• Standardize your markup templates by limiting them to the required and recommended official fields.
• Document each field used with its source in Google documentation to facilitate updates.
• Set up automated monitoring for Google announcements regarding structured data.
• Train your developers and writers never to add a field without verifying its official status.