What Is Microdata?

Scrapeless Universal Scraping API retrieves web pages for structured-data extraction workflows, including pages whose visible content is rendered with JavaScript.

Microdata is a structured-data syntax built into HTML. It lets a publisher identify a thing described on a page—such as a product, event, person, recipe, or article—and label the properties that belong to that thing. A browser still renders the same headings, links, images, and text. The extra attributes create an additional machine-readable layer for parsers, crawlers, search systems, accessibility tools, and data extraction software.

The WHATWG Microdata section of the HTML standard defines the processing model. That standards context matters because Microdata is not a visual widget or a search-engine plug-in. It is part of the document itself, and its meaning follows rules about item scope, property values, URLs, and nested items.

How Microdata Represents an Entity

Microdata represents an entity as an item with zero or more properties. An item begins on an HTML element carrying the itemscope attribute. The optional itemtype attribute supplies one or more vocabulary URLs that define what kind of entity the item represents. Descendant elements carrying itemprop contribute named values to that item.

The value does not always come from visible text. A link contributes its URL, an image contributes its source URL, a time element can contribute a machine-readable datetime value, and a meta element can carry a value that does not need to appear as ordinary prose. A parser therefore follows Microdata’s value rules instead of stripping tags and reading whatever text remains.

Two additional attributes cover relationships that simple nesting cannot express. itemid gives a typed item a global identifier when the vocabulary supports one. itemref points to elements elsewhere in the same document whose properties should be included in the item. These features help with real templates, but they also mean an extractor must implement the complete model rather than scan for isolated itemprop strings.

Microdata Attributes at a Glance

Where Schema.org Fits

Schema.org is a shared vocabulary, while Microdata is a serialization syntax. The Schema.org getting-started material documents types such as Product and Event and properties such as name, image, and startDate. A publisher can express many of those same terms with Microdata, RDFa, or JSON-LD. Changing syntax does not automatically change the vocabulary or the intended entity model.

This distinction prevents a common planning error. A team may say that it “uses Schema” when the actual questions are separate: Which vocabulary types describe the business entity correctly? Which format fits the rendering stack? Which consumers support the chosen combination? Which validation rules apply to a particular search feature? Answering those questions independently produces cleaner markup and more reliable extraction.

How Parsers Extract Microdata

A conforming extractor starts with top-level items, determines each item’s type and identifier, then resolves property values from descendants and any referenced nodes. Nested items remain structured values rather than being flattened into unrelated text. URL-valued properties are resolved against the document base URL, so the final value can differ from the literal attribute found in source HTML.

Production extraction adds another question: which document should be parsed? Server HTML may already contain Microdata, or a client application may add attributes after JavaScript executes. A raw HTTP response and a rendered DOM can therefore expose different structured data. The acquisition stage should be recorded alongside the output so downstream users know whether the dataset reflects source HTML or a browser-rendered state.

Microdata, JSON-LD, and RDFa

Microdata places properties directly on HTML elements. JSON-LD usually keeps a JSON object in a script block, separate from the visible content. RDFa also annotates markup, but it comes from the RDF data model and supports linked-data patterns beyond the typical Schema.org publishing workflow. All three can express structured data, yet they create different maintenance and extraction trade-offs.

Google Search Central’s structured-data guidance recommends JSON-LD when a site’s setup supports it because separation from presentation makes nested data easier to maintain. That recommendation does not invalidate Microdata. Microdata can be sensible when templates already bind each semantic property to a visible element and the organization wants the annotation to move with that element.

Common Microdata Failure Modes

Broken scope is the most basic failure. A property can be placed outside the element that owns the relevant item, causing a parser to attach it elsewhere or ignore it. Nested entities can also be modeled incorrectly: an address should often be an item with its own properties, not a string assembled from whatever text happens to be nearby.

Vocabulary drift creates a subtler defect. A property name may be valid for one type but not for another, or a search feature may require fields that the general vocabulary considers optional. Validation should therefore occur at two levels: syntax and data-model correctness, followed by consumer-specific eligibility checks. Passing one test does not guarantee a rich result or any particular presentation.

Duplicate truth is another risk. A site may carry Microdata next to JSON-LD and expose different prices, dates, or canonical URLs in each. Extractors should preserve provenance and either select an authoritative representation or report the conflict. Publishers should generate all structured formats from one data source rather than edit them independently.

Practical Uses Beyond Search Appearance

How to Choose and Maintain Microdata

Choose Microdata when semantic annotations naturally belong to stable, server-rendered elements and the development team is comfortable testing markup as part of the template. Prefer JSON-LD when the entity graph is complex, several visible elements contribute to one record, or content and presentation change on different schedules. Prefer RDFa when linked-data requirements make its graph model the better fit.

Maintenance should include template-level tests, representative rendered pages, vocabulary validation, and consumer-specific checks. Track the page URL, capture method, extraction timestamp, item type, raw property value, normalized value, and validation result. Those fields make changes explainable when a redesign moves an attribute or a client script delays its insertion.

For web-scale collection, acquisition and parsing should remain separate. Scrapeless Universal Scraping API can supply page content to the extraction stage, while the parser applies Microdata rules and maps the result into a stable downstream schema. Review Scrapeless pricing when estimating acquisition cost for the planned page volume.

Conclusion

Microdata is HTML-native structured data: items define entities, properties define values, and a vocabulary supplies shared meaning. It works well when semantic annotations stay aligned with stable visible elements. Reliable use depends on parsing the complete item model, capturing the right page representation, validating vocabulary rules, and tracking provenance when several structured formats coexist.