Automating structured data maintenance: 5 ways JSON-LD breaks and a 4-stage CI check that stops them (2026)

Structured data (JSON-LD) is at its most accurate on the day you add it. As theme updates, plugin swaps and new translations pile up, what the page shows and what the JSON-LD says start to drift apart. Because structured data is invisible, nobody notices when it breaks.

This article sets out a system for keeping structured data from breaking. It is not an introduction to writing markup; the focus is "who notices drift, when, and with what". The overall pre-publication quality process is covered in "Automated blog publishing needs a quality gate", search metrics monitoring in "Search Console and GA4 monitoring automation", and bilingual translation and hreflang in "Automating translation and updates on a bilingual website". Here we look only at structured data.

Main sources for this article: Google Search Central's structured data guidelines and documentation changelog, Google's official blog posts from 2023 to 2025, Search Console Help, Schema.org release notes, the W3C JSON-LD 1.1 specification and the HTTP Archive Web Almanac 2024. All were checked on 28 October 2026.

1. What is happening: fewer rich results, more structured data

The biggest change of the past three years is that Google has adopted a policy of simplifying the results page and keeps reducing the number of rich result types (enhanced displays with stars, steps and so on).

It started with FAQ and HowTo

On 8 August 2023, Google announced that FAQ rich results would be shown only for "well-known, authoritative government and health websites". On 13 September 2023 HowTo rich results stopped appearing on desktop as well, and the type was deprecated. At the same time Google noted that unused structured data causes no problems for Search, so there was no need to remove it in a hurry.

Seven types in 2025, FAQ in 2026

A Google blog post on 12 June 2025 announced that seven types, including Course Info, ClaimReview and Learning Video, would be phased out. The reason given was that they were rarely used and no longer added much value; the post states that rankings are not affected and that uses outside Google Search are not affected either. The Practice problem documentation was removed on 6 January 2026, and FAQ rich results stopped appearing on 7 May 2026 (the documentation was removed on 15 June).

Meanwhile, structured data use keeps growing

While the displays have shrunk, use of structured data itself has grown. According to the HTTP Archive Web Almanac 2024, the share of pages using JSON-LD rose from 34% in 2022 to 41% in 2024. Even after FAQ rich results were restricted, FAQPage use on desktop rose from 0.2% to 0.6%. Many sites, in other words, still carry types that no longer display.

RDFa scores high because Open Graph tags for social sharing (64%) count as RDFa. Google recommends JSON-LD, and this article assumes JSON-LD. Note that retired types disappear from Search Console reports and testing tools a little after they stop displaying. Do not mistake "gone from the report" for "error fixed"; that is the first rule of maintenance.

2. What structured data maintenance means: staying in sync, not adding more

Structured data maintenance is the work of keeping what the JSON-LD says correct and consistent with the page at all times. It is not the work of adding new types.

Why it breaks if you leave it alone

Structured data lives apart from the body text, usually in a script element in the head. People who edit the page do not look at the JSON-LD, and whoever wrote the JSON-LD does not hear about page changes. As long as the same information lives in two places, it will drift.

Google's general guidelines require structured data to be a true representation of the page, not mark up content that is not visible to readers, and provide up-to-date information. Violations can lead to a manual action that removes rich result eligibility (Google says this does not affect ranking).

Where it ends and other work begins

This article draws the line with other operational work as follows.

Drawing the line is about assigning ownership. Structured data belongs to neither SEO, development nor product data, so it easily ends up owned by nobody.

Accuracy still matters after a display ends

Google's introduction to structured data says it also uses markup to understand page content and to gather information about people, companies and other entities. Rich results are not the only use. A retired type does no harm if it is correct, but does harm if it is wrong. Shift the goal from "getting a display" to "staying accurate" and Google's changes stop throwing you around.

3. Five ways JSON-LD breaks

Structured data breakage falls into roughly five patterns. Each has its own detection tool and its own fix.

Pattern 1: a template change breaks it

The most common case is output changing after a theme or plugin update. Typical forms are duplicate output (an SEO plugin and the theme both emit an Organization), format changes (dates such as 28/10/2026 that are no longer ISO 8601) and missing output (the script element disappears entirely). Google's Article documentation recommends including a time zone in dates; without one, Googlebot's time zone is assumed. For sites publishing in both Japan and Europe, that can make dates appear a day off.

Pattern 2: required properties go missing

Google's feature documentation lists required and recommended properties, and items missing a required property are not eligible for rich results. The cause usually lies in the data: a product image never uploaded, or a price shown as "on request" with no number. Even with a correct template, missing source data means missing JSON-LD.

Pattern 3: it no longer matches the page

The page and the JSON-LD show different prices, or the JSON-LD carries review stars that are not on the page. Sites selling in Europe have an extra trap: the decimal separator. In the Netherlands a price appears on screen as "€ 1.299,00", but Google's Product documentation requires "." as the decimal separator. Pass the display format straight through and €1,299 is read as €1.299.

Pattern 4: retired rich result types linger

A retired type on the page is not a problem in itself. The problem is maintenance effort and misunderstanding. Writing questions into JSON-LD that are not on the page, just to get FAQ results, keeps creating work after the display is gone. And once the type leaves the reports, its errors become invisible.

Pattern 5: languages drift apart

Only one language version gets updated, or inLanguage says "ja" on every page. Translation workflows usually cover body text only, and the JSON-LD falls through the gap. Section 8 covers this.

As the table shows, three of the five (1, 3 and 5) can be made unlikely by template and data design. That is cheaper than catching them with checks.

4. Google's rich result scope: what remains and what has gone

To scope maintenance, you need to know which types Google currently uses. Google's "structured data markup that Google Search supports" page listed 25 entries as of 28 October 2026.

The main remaining types

These are the types most company websites deal with.

A typical company site needs to maintain five or six types at most. There is no need to track them all.

Retired types and how to treat them

The seven 2025 types were removed from Search Console reports, the Rich Results Test and the search appearance filters on 9 September 2025. In the bulk data export (BigQuery), the corresponding fields were announced to become NULL by 1 October 2025.

"Fine to remove" does not mean "must remove". But if you keep it, it must keep matching the page.

5. Designing for generation from templates

The most effective lever for automated maintenance is how markup is generated, not how it is checked. Build JSON-LD from the same data as the page and most of patterns 1, 3 and 5 become unlikely.

Principle 1: one source for each fact

Price, opening hours, author name and publication date should come from the same variable for both the page and the JSON-LD. Google's documentation on generating structured data with JavaScript also recommends, when using a tag manager, not duplicating information but using variables that read values from the page.

What the "good" column has in common is that nobody writes JSON-LD by hand any more.

Principle 2: map page types to schema types

Group pages by type and decide, in one table, which schema types each group outputs. That table becomes your structured data "design document".

Google's Organization documentation says company information can live on the home page or a single about page; it does not need to be on every page.

Principle 3: connect with @graph and @id

Group multiple types with @graph and connect them with @id. Give the Organization a fixed @id and have each article's publisher reference only that @id; then a company name change is a one-place edit. @id is a core feature of JSON-LD 1.1, which became a W3C Recommendation on 16 July 2020.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example B.V.",
      "url": "https://example.com/"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/en/column/sample#article",
      "headline": "Article title",
      "inLanguage": "en",
      "datePublished": "2026-10-28T09:00:00+01:00",
      "dateModified": "2026-10-28T09:00:00+01:00",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

The template fills in the values. Once you choose an @id URL, never change it, and include it in the plan if the site ever moves.

Principle 4: adding markup with JavaScript is a last resort

For products, Google warns that dynamically generated markup can make Shopping crawls less frequent and less reliable, and recommends putting it in the initial HTML. Treat tag-manager injection as a stopgap.

6. Validating in CI: four stages that block a release

If the template itself changes, the generated JSON-LD breaks too. So put a step in CI (automated tests on every change) that checks sample URLs on every deploy and blocks the release on failure.

Stage 1: syntax (does it parse as JSON?)

Extract every application/ld+json script element and check that it parses as JSON. Trailing commas, or an empty variable producing "price": ,, stop here. If it does not parse, the whole block is ignored. At the same time count whether any type appears twice, which catches duplicate output.

Stage 2: types (is it valid Schema.org?)

Check that the types and properties exist in the Schema.org vocabulary. For manual checks, use the Schema Markup Validator (validator.schema.org). The functions of Google's old Structured Data Testing Tool moved there, and on 9 August 2021 Google turned the old tool into a landing page.

Schema.org is updated about twice a year. As of 28 October 2026 the latest release is Version 30.1 of 16 September 2026 (826 types, 1,540 properties). If CI uses a vocabulary file, record which version you imported and update it every six months.

Stage 3: Google's requirements (are required properties present?)

Valid Schema.org can still miss Google's required properties and be ineligible. For manual checks use the Rich Results Test, but no official API for running it in bulk is documented (as of 28 October 2026). So in CI, check against rules that list Google's required and recommended properties for the types your site actually uses: block on missing required properties, warn on missing recommended ones.

Stage 4: consistency with the page

Open the page in a headless browser, extract values that also appear on the page (price, headline, dates) and compare them with the JSON-LD. This catches the machine-detectable part of the quality guidelines that Google says are "not easily testable using an automated tool".

Stage 4 is prone to false positives from formatting ("€ 1.299,00" versus 1299.00). Normalise numbers and dates before comparing, run it in warn-only mode for the first two to three weeks, then switch it to blocking once you know the noise level.

Choosing sample URLs

You do not need to check every page. Choose representatives for each page type, 10 to 20 URLs in total. For each type, include one "complete" page and one "likely to be missing something" page (no image, freshly translated) to catch pattern 2.

7. Monitoring after release: enhancement reports and URL Inspection

After release, use Search Console to see how Google actually read the page. Data entry mistakes and problems on pages outside your samples show up here.

Reading the enhancement reports

The "Enhancements" section shows a rich result status report per type. Three things to keep in mind: counts are items, not pages; an item with several issues counts once in the invalid total; and the examples table is limited to 1,000 rows. A valid item is one with no critical issues that "can appear" as a rich result; being valid does not guarantee display.

Tracking with the URL Inspection API

The URL Inspection API returns the rich results detected in the indexed version of chosen URLs, along with their issues, so you can pull them weekly. The quota is 2,000 queries per day and 600 per minute per site, ample for a few hundred URLs.

There is not much to look at. Fifteen minutes a week, checking only changes in invalid items and differences in the API results, is a routine that lasts. For search metrics as a whole, see "Search Console and GA4 monitoring automation".

"Fixed" versus "gone from the report"

The easy confusion is between a type disappearing from the report because it was retired and an issue actually being fixed. In BigQuery, fields for retired types become NULL, and Google warns that conditions such as NOT is_learning_videos will drop rows. Write queries that work with NULL, such as IS NOT TRUE, and your reports will survive future retirements.

8. Aligning inLanguage and hreflang on multilingual sites

The typical problem on sites aimed at both Japan and Europe is that the body has been translated but the JSON-LD's language or names still reflect the original.

inLanguage and hreflang do different jobs

inLanguage is a Schema.org property giving the language of the content, as a BCP 47 code. hreflang tells Google where the other language versions are, using ISO 639-1 language codes and ISO 3166-1 Alpha 2 region codes (ja, en, en-NL and so on).

Google says it does not use hreflang or the lang attribute to detect a page's language. Getting them wrong rarely confuses Search's language detection, but other services reading the data will receive the wrong language.

Five things to keep aligned

Google's hreflang documentation requires that each language version lists itself and every other version, and that without return links the annotations may be ignored. The structured data should be aligned so that it never contradicts this.

The last row is easy to miss. Use the registered legal name (in the Netherlands, the name with "B.V.") as the Organization's name and put language-specific trading names in alternateName, so the name does not wobble between languages.

Bring JSON-LD into the translation workflow

If the JSON-LD comes from the same data as the page, the English JSON-LD falls out of the translated data automatically. If hand-written markup remains, add the JSON-LD to the translation scope or move it into templates. Translation pairing is covered in "Automating translation and updates on a bilingual website". In CI, keep sample URLs per language and check that inLanguage matches the locale.

9. Where structured data stands in the age of AI search

We are increasingly asked whether structured data should be added "for AI search". This is an area full of guesswork, so here is only what is officially documented.

What Google officially says

Google's "AI features and your website" page states plainly that there are no additional requirements or special optimisations needed to appear in AI Overviews or AI Mode, and no need for AI text files or special Schema.org structured data. On 15 June 2026 Google added a note that llms.txt is not needed for Google Search and does not affect rankings.

The same page lists, as an SEO fundamental, making sure your structured data matches the visible text on the page. The official answer is to keep what you have accurate rather than add more for AI.

There is no need to change your maintenance approach because of AI search. How AI services other than Google use markup should not be built into your design on guesswork unless they document it. One exception worth keeping: your Organization's legal name, logo and identifiers (in the Netherlands, the KvK number) help Google, as its documentation explains, distinguish you from organisations with similar names, so keep them maintained regardless of any display.

10. Points to watch when operating in Europe

Sites that sell in both Japan and Europe face Europe-specific conditions in their structured data too. Here are three.

Price rules and structured data prices

Following the EU Omnibus Directive, the Netherlands has applied since 1 January 2023 a rule that the "was" price for a discount must be the lowest price of the previous 30 days, and the Dutch Authority for Consumers and Markets (ACM) has fined online shops for breaches. Google's Product documentation shows how to mark the original price as StrikethroughPrice. If the page's "was" price and the structured data's strikethrough price come from different data, one of them can end up out of line with the law.

Digital Product Passport and EEA displays

According to the European Commission, the EU Digital Product Passport (DPP) registry went live on 20 July 2026, and the passport becomes mandatory for certain batteries from 18 February 2027. Schema.org 30.1 added vocabulary to link products to a DPP, but Google has not said whether Search will use it. Hold the data for legal compliance and decide separately whether to output it as structured data. In the EEA, as part of Google's response to the Digital Markets Act, structured data carousels (beta) have appeared for travel, local and shopping queries since 2024.

Japan and Europe compared

The same template can face different value formats and different rules those values must satisfy by region. If you sell in both, always include price and date normalisation in stage 4.

11. Review frequency and checklist

Even with automation, some things still need a person. Decide what is checked, how often and by whom.

Suggested frequency

The more costly a mistake (price, stock), the more often it should be checked, and those checks should block every deploy.

Times are DevNJ estimates. The goal of automation is a state where 15 minutes a week is enough.

12. Cost and effort ranges

The following are DevNJ estimates, not statistics. Outsourced work is priced at €80 an hour; the Japanese version of this article converts at €1 = ¥175.

Tier 2's monthly cost is roughly any CI minutes above the free allowance; tier 3 depends on whether you use your own crawl server or a paid crawler.

Comparing with manual work

Measure the value of automation in people's time and days until detection rather than tool fees.

Going from 6–10 hours to 1–2 hours a month frees up roughly €320–720 of time a month at €80 an hour. Costs move towards the top of each range if much is still hand-written, if three or more plugins output structured data, if there are three or more languages, or if there are thousands of products.

13. Common mistakes

Here are the mistakes we see most often, with causes and fixes. All of them are cheaper to prevent by design than to catch by testing.

The second row also relates to Google's people-first content guidance, which lists changing dates without substantially changing content as a sign of search-engine-first content.

What not to do

These are the things to avoid when automating maintenance.

14. Worked examples (three fictional companies)

The following three companies are fictional and illustrate how far each would automate. They are not real businesses.

Company A only needs to stop the duplicate output and consolidate company information into one Organization, which fits within about 12 hours and €0 a month. Company B had "€ 12,50" flowing into its JSON-LD, so it regenerates prices from numeric data and outputs the 30-day "was" price from the same data. Company C has few pages, so tier 1 is enough.

15. Rollout plan: four weeks

Here is a four-week rollout. Each week's work is roughly one to two days.

1. Week 1: inventory. Group pages by type and pick two sample URLs each. List each JSON-LD type and what produces it (theme, plugin, tag manager, hand-written), and flag duplicates and retired types
2. Week 2: design document and templates. Create the page-type-to-schema table and move price, dates and language onto the same data as the page. Decide the Organization @id
3. Week 3: four CI stages. Make stages 1 and 2 blocking; start stages 3 and 4 in warn-only mode
4. Week 4: monitoring and routine. Set up weekly URL Inspection API pulls, assign an owner and a day for the enhancement reports, and schedule the quarterly review
5. Week 5 onwards: switch over. Once you know the false-positive level, make missing required properties and price or stock mismatches blocking

The key is not to block everything from day one. If noisy checks keep stopping releases, people will want to remove the checks altogether.

16. Checklist

Check these at rollout and every quarter.

Design

• A design document maps page types to schema types
• Price, dates, opening hours, author and language come from the same data as the page
• No type is emitted by two mechanisms (such as theme and plugin)
• The Organization has one @id, identical in every language

CI

• Sample URLs exist per page type and per language, 10–20 or more in total
• Releases are blocked when JSON does not parse or a type is duplicated
• The Schema.org vocabulary version is recorded and updated every six months
• Missing Google-required properties block; missing recommended ones warn
• Price and stock are compared with the page, with decimals and currency normalised

Monitoring and operations

• An owner and a weekday are set for reviewing enhancement reports
• Sample and key URLs are pulled weekly through the URL Inspection API
• The Google changelog is checked quarterly for the types your site uses
• inLanguage and hreflang are aligned on every language version and point both ways

17. Summary

• Structured data is most accurate on the day it is added and drifts from the page if left alone. Aim for "never say anything wrong" rather than "get a display"
• Google has been reducing rich results since 2023; HowTo ended in September 2023 and FAQ on 7 May 2026. Unused markup does no harm, but it still needs maintaining
• The five breakage patterns are template changes, missing required properties, mismatches with the page, retired types and language drift. Three of them become unlikely if markup is generated from the same data as the page
• On every deploy, run four CI stages (syntax, types, Google's requirements, page match); after release, review enhancement reports and the URL Inspection API weekly
• On multilingual sites, align inLanguage, hreflang and the Organization @id; for Europe, watch decimal separators and the 30-day lowest-price rule
• Google states that no special structured data is needed for AI search. Keeping what you have accurate comes first

Sources

Google Search Central (structured data)

• Introduction to structured data markup in Google Search — Google Search Central: uses of structured data
• General structured data guidelines — Google Search Central: technical and quality guidelines
• Structured data markup that Google Search supports — Google Search Central: the 25 supported entries as of October 2026
• Latest Google Search Documentation Updates — Google Search Central: FAQ end (7 May 2026)
• Changes to HowTo and FAQ rich results — Google Search Central Blog: August 2023 reduction and September HowTo end
• Simplifying the search results page — Google Search Central Blog: the seven types retired in 2025
• Here's an update on our efforts to simplify the search results page — Google Search Central Blog: further simplification in November 2025
• Article structured data — Google Search Central: no required properties
• Organization structured data — Google Search Central: placement and disambiguation
• Breadcrumb structured data — Google Search Central: desktop-only display
• Product snippet structured data — Google Search Central: required properties and decimal separator
• Merchant listing structured data — Google Search Central: strikethrough prices
• Generate structured data with JavaScript — Google Search Central: avoid duplicating information in a tag manager
• Influence your byline dates in Google Search — Google Search Central: visible dates and structured data dates
• New Search experiences in EEA — Google Search Central Blog: structured data carousels in the EEA

Google Search Central (multilingual, AI, quality)

• Tell Google about localized versions of your page — Google Search Central: hreflang return links
• AI features and your website — Google Search Central: no special structured data for AI features
• Creating helpful, reliable, people-first content — Google Search Central: caution on changing dates only

Search Console

• Rich result status reports — Search Console Help: valid and invalid definitions
• Usage limits — Search Console API: URL Inspection quotas
• Rich Results Test — Google: checking Google's requirements

Schema.org, W3C and research

• Schema.org releases — Schema.org: Version 30.1 (16 September 2026)
• Schemas — Schema.org: 826 types and 1,540 properties
• inLanguage — Schema.org: BCP 47 language codes
• Schema Markup Validator — Schema.org: checking types and properties
• JSON-LD 1.1 — W3C: W3C Recommendation of 16 July 2020
• Structured Data — HTTP Archive Web Almanac 2024: format adoption and FAQPage trend

European rules

• ACM wil einde aan nepkortingen na komst strengere regels — ACM: the 30-day lowest-price rule from January 2023
• ACM legt boetes op aan webwinkels voor nepkortingen — ACM: fines for misleading discounts
• Digital Product Passport — European Commission: DPP overview
• Batteries (Digital Product Passport) — European Commission: registry live (20 July 2026) and batteries mandatory (18 February 2027)

All sources were checked on 28 October 2026. The types and requirements Google supports change, so check the official changelog for the latest before implementing. Costs, effort and review frequencies are DevNJ's working estimates and vary with site size and setup.