Schema.org Vocabulary Drift Monitor
Pricing
from $2.00 / 1,000 monitor rows
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
Maintained by CommunityActor 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
supersededBytargets or attic-layer status. - Optionally emits pending-layer terms.
- Compares against prior run rows passed in
baselineRowsto 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 likeProductare normalized toschema: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, orsource_error.termId,termName,termKind,termLabel,termComment.domainIncludes,rangeIncludes,subClassOf,supersededBy, andlayers.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, andJobPostingterms 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.
supersededByand 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.00005per run start.apify-default-dataset-item:$0.002per 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.