Structured Data Extraction
Reading the machine-readable blocks a page already publishes, instead of parsing the visible text with selectors.
Most commercial pages carry a block of structured data for search engines: JSON-LD in a script tag, sometimes microdata in attributes. It usually holds the fields you were about to extract by hand, already typed and already named.
Reading it is cheaper in every dimension. There are no selectors to maintain, no layout to break, no dependence on where a number sits visually, and the values arrive as a currency and an amount rather than as a formatted string you have to reverse.
It has limits worth stating. The block is published for search engines, so it can be optimistic, incomplete or stale relative to what a shopper is quoted. On anything where the difference matters, such as price enforcement, treat it as a starting point and verify against the flow a buyer actually walks.
The practical rule is short: check for structured data first, fall back to selectors second, and record which of the two produced each field. A dataset mixing both without saying so is impossible to debug when the numbers disagree.
Where the fields live
JSON-LD sits in a script tag with a type of application/ld+json and holds an object graph: a product with an offer, an article with an author, a listing with a location. It is the most common form and the easiest to parse.
Microdata and RDFa put the same information into attributes on the visible markup. Older, fiddlier, still present on plenty of large sites.
Both are static text in the response, which means they usually survive without JavaScript rendering even when the visible content does not.
Checking before writing selectors
One request tells you whether the parsing work is needed at all:
Is the data already there
# pull the structured block, if any
curl -s -x login_c_US:password@proxy.sotaproxy.com:10000 https://target.example/product \
| grep -A 30 'application/ld+json' | head -40
# and check whether the price is in it before building a selector
curl -s -x login_c_US:password@proxy.sotaproxy.com:10000 https://target.example/product \
| grep -o '"price"[^,]*'- Structured data often survives when the rendered page does not, which makes it the cheapest path on script-heavy sites.
- Store the source of each field. When the block and the page disagree, you want to know which number you kept.
- For MAP work and anything with a cart, the block is a hint and the quoted price is the evidence.
What it is not
It is not always accurate
It is published for search engines and can lag the page or omit conditions that apply at checkout.
It is not always present
Plenty of pages carry none. The check costs one request and answers the question immediately.
It is not a replacement for the flow
A price in the block is not the price in the cart, and the difference is exactly what some jobs exist to find.
It is not harder to collect
It is static text in the response, so it usually needs no rendering at all.
Related terms
See this in practice
Ready to use structured data extraction?
SotaProxy gives you access to rotating residential, mobile, datacenter, and ISP proxies. No minimum commitment.
Get started