Schema.org Vocabulary Drift Monitor avatar

Schema.org Vocabulary Drift Monitor

Pricing

from $2.00 / 1,000 monitor rows

Go to Apify Store
Schema.org Vocabulary Drift Monitor

Schema.org Vocabulary Drift Monitor

Monitor the official Schema.org JSON-LD vocabulary for watched term changes, replacements, removals, and release drift.

Pricing

from $2.00 / 1,000 monitor rows

Rating

0.0

(0)

Developer

Defenestrator

Defenestrator

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

11 days ago

Last modified

Categories

Share

Monitor the official Schema.org JSON-LD vocabulary for watched term changes, replacements, removals, and release drift.

This Actor is for SEO, structured-data, product-catalog, marketplace, knowledge-graph, and data-platform teams that rely on Schema.org terms such as Product, Offer, JobPosting, SoftwareApplication, MerchantReturnPolicy, or Dataset.

It is not a website crawler, rich-results validator, or generic JSON-LD extractor. It watches the upstream Schema.org vocabulary itself so you can decide whether production markup rules, schema mappings, validators, or structured-data generators need review.

Unofficial tool. Not affiliated with Schema.org, Google, Microsoft, Yandex, Yahoo, or any standards body. Always verify important markup and SEO decisions against the official Schema.org pages and the search/platform-specific structured-data documentation you rely on.

What it does

  • Fetches the official latest Schema.org JSON-LD vocabulary from https://schema.org/version/latest/schemaorg-current-https.jsonld.
  • Normalizes classes, properties, data types, and enumeration values into deterministic dataset rows.
  • Emits rows for watched IDs and text terms.
  • Flags terms with supersededBy targets or attic-layer status.
  • Optionally emits pending-layer terms.
  • Compares against prior run rows passed in baselineRows to detect changed, new, or removed terms.
  • Emits a summary row with vocabulary counts and source hashes so scheduled runs stay non-empty and trendable.

Why run it repeatedly

Schema.org evolves. Structured-data templates, SEO playbooks, marketplace product feeds, job-posting feeds, and knowledge-graph ingestion code can drift away from the current vocabulary or keep using terms that have been replaced. Run this Actor on a schedule and feed the previous dataset rows back into baselineRows to detect upstream semantic changes.

Input

{
"watchIds": ["Product", "Offer", "JobPosting", "SoftwareApplication", "MerchantReturnPolicy", "Dataset"],
"watchTextTerms": ["return policy", "price", "employment", "software", "dataset"],
"expectedIds": [],
"baselineRows": [],
"includeVocabularySummaryRows": true,
"includeDeprecatedRows": true,
"includePendingRows": false,
"includeAllVocabularyRows": false,
"emitNewRowsWhenBaselineProvided": true,
"emitRemovedBaselineRows": true,
"alertOnAnySemanticChange": true,
"maxRows": 500
}

Key fields

  • watchIds: exact Schema.org terms to always emit. Bare names like Product are normalized to schema:Product.
  • watchTextTerms: case-insensitive text terms matched against IDs, labels, comments, domains, ranges, and replacement targets.
  • expectedIds: terms that must be present. Missing expected terms create high-priority rows.
  • baselineRows: rows from a previous run of this Actor. Matching rows enable drift detection. A partial watchlist baseline compares only the rows it contains; new-term detection requires a complete prior vocabulary plus its summary row.
  • includeAllVocabularyRows: emit the whole vocabulary. This is useful for offline inventory but can create thousands of rows.

Output rows

Rows are written to the default dataset. Common fields include:

  • rowType: vocabulary_item, vocabulary_summary, expected_missing, removed_baseline, or source_error.
  • termId, termName, termKind, termLabel, termComment.
  • domainIncludes, rangeIncludes, subClassOf, supersededBy, and layers.
  • isDeprecatedOrReplaced, isPending, isAttic.
  • matchedWatchIds, matchedWatchTerms.
  • changedSincePrevious, newSincePrevious, removedSincePrevious.
  • semanticHash, previousSemanticHash, sourceHash, sourceSemanticHash.
  • priority, riskScore, alert, alertReasons, inventoryNotes, recommendedAction.

Existing deprecated, replaced, attic, or pending terms are labeled as baseline inventory on a first run. They become alerts only when a supplied baseline shows a new or changed condition. Watched terms remain easy to find without presenting old vocabulary history as a new incident.

The key-value store OUTPUT record contains run-level counts, hashes, row-type counts, priority counts, and sample rows.

Example use cases

  • SEO team watches Product, Offer, Review, MerchantReturnPolicy, and JobPosting terms weekly.
  • Marketplace engineering team stores a baseline and alerts when a watched property’s domain/range or replacement target changes.
  • Knowledge-graph team emits all vocabulary rows once, then schedules smaller watchlist runs for the terms used in ingestion schemas.
  • Compliance or content-platform team checks if old terms have moved to attic or acquired replacement targets.

Limitations

  • This Actor monitors the Schema.org vocabulary, not how search engines interpret or support individual structured-data types.
  • It does not crawl your site and does not validate your page markup.
  • Pending Schema.org terms may not be supported by search/rich-results products.
  • supersededBy and attic status are strong review signals, not automatic legal, SEO, or product decisions.
  • The source is a public official JSON-LD file; if the source is unavailable, the Actor emits/fails with a clear source error rather than silently using stale data.

Pricing

From $2 per 1,000 result rows.

This Actor uses Apify Pay Per Event (PPE) pricing:

  • apify-actor-start: $0.00005 per run start.
  • apify-default-dataset-item: $0.002 per dataset row (Monitor row).
  • Platform usage is included in the event price; users do not pay a separate platform-usage pass-through.
  • A dataset row is one monitored result, source, or drift-check row emitted by the Actor. Run cost scales with the number of rows produced and the limits you choose.

Use Apify's max total charge setting before starting a run if you want a hard spend cap.