Your JSON-LD and Schema Markup Never Reach the Model

Direct answer

For a standard web-search result card in my research process, I do not receive the webpage’s raw structured markup.

I am not shown:

• The page’s JSON-LD blocks
• schema.org entity objects
• Microdata or RDFa
• Open Graph tags as a structured object
• Twitter Card tags
• Raw <meta> tags
• Canonical-link declarations
• Author objects
• Publisher objects
• Breadcrumb schema
• Article schema
• FAQ schema
• Review schema
• Product schema
• Organization schema
• sameAs links
• Raw HTML
• The DOM
• Search-engine knowledge-graph identifiers
• An extracted entity graph

Some of those signals may have been used upstream by the search provider, indexer, or page parser to produce the title, date, snippet, thumbnail, or specialized result. But they are not exposed to me as inspectable source fields on the standard result card.

The distinction is:

Structured metadata may influence the result without being included in the result I receive.

What is actually exposed on the standard card

In this research environment, a standard search result generally gives me something conceptually close to:

Reference ID
Title
URL
Textual snippet or extracted passage
Publication date, sometimes
Crawl/fetch freshness information, sometimes
Result type
Source word-limit instruction
Result position through ordering

It does not resemble this:

{
	"headline": "How People Use ChatGPT",
	"author": {
		"@type": "Person",
		"name": "John Smith",
		"url": "..."
	},
	"publisher": {
		"@type": "Organization",
		"name": "OpenAI",
		"logo": "..."
	},
	"datePublished": "2025-09-15",
	"dateModified": "2026-01-02",
	"about": [...],
	"mentions": [...],
	"citation": [...],
	"breadcrumb": [...],
	"sameAs": [...]
}

Even when the webpage contains exactly that JSON-LD, I normally do not receive it in that form.

Publicly documented OpenAI web-search output similarly exposes search sources principally as URLs and exposes response citations with a title and URL. The documented source and citation schemas do not include author, JSON-LD, schema type, Open Graph, or arbitrary page metadata fields. (OpenAI Platform)

Field-by-field: what may exist versus what I see

The ChatGPT interface can display publisher logos, source previews, images, maps, and rich restaurant information in certain experiences. Those are presentation or specialized-result features; they do not imply that the underlying standard card gives me the complete webpage schema. (OpenAI Help Center)

Author information specifically

On a standard card

There generally is not a dedicated structured author field such as:

{
	"author_name": "Jane Doe",
	"author_url": "https://example.com/jane-doe",
	"author_type": "Person"
}

An author may still appear in:

• The title
• The snippet
• The visible URL
• The publication name
• The page text after opening
• A byline in the extracted article
• A PDF’s title page
• Search-result prose such as “By Jane Doe”

But that means the author is present as text, not necessarily as a dependable, normalized metadata field.

Consequently, if I need to establish authorship, I should open the page and verify the byline or methodology section. I should not assume that a person mentioned in the snippet is the author.

After opening the page

The extracted page may include something like:

By Jane Doe
Published July 15, 2026
Updated July 20, 2026

That gives me usable text, but it still may not be delivered as:

{
	"author": "Jane Doe",
	"date_published": "2026-07-15",
	"date_modified": "2026-07-20"
}

I generally perform that interpretation myself from the extracted content.

Publication and modification dates

Dates are among the few metadata-like values that may appear separately, but their exact origin is not usually exposed.

A displayed date could have been obtained from:

• JSON-LD datePublished
• JSON-LD dateModified
• An <article> element
• Open Graph metadata
• A visible page byline
• An XML sitemap
• An RSS feed
• Search-index records
• URL patterns
• Search-provider inference

I normally do not receive a provenance trace such as:

Publication date source:
script[type="application/ld+json"] → NewsArticle.datePublished

Therefore, I can see a result dated July 15, 2026 without knowing whether that date came from structured markup, visible text, or the search provider’s index.

This matters because publishers frequently:

• Replace publication dates with update dates
• Update pages without changing dates
• Put several dates on one page
• Use incorrect structured metadata
• Reuse article templates
• Migrate old articles to new URLs
• Change headlines and metadata after publication

For serious research, the displayed card date is an initial clue. The page itself should be opened and checked.

Publisher and domain information

The publisher is usually discernible from:

• The domain
• The title
• The URL
• The snippet
• The source display in the interface

But I generally do not receive a complete organization object such as:

{
	"publisher": {
		"name": "Pew Research Center",
		"legal_name": "The Pew Research Center",
		"domain": "pewresearch.org",
		"logo": "https://...",
		"same_as": [
			"https://www.wikidata.org/entity/...",
			"https://www.linkedin.com/company/..."
		]
	}
}

There is also no exposed guarantee that:

• The domain owner authored the article
• The displayed publisher is the original research organization
• The page is not syndicated
• The source is not republishing another organization’s work

That has to be determined through source inspection.

Canonical URL and URL normalization

A result gives me a destination URL. That URL may already be normalized, but I am not ordinarily shown:

• The raw discovered URL
• Redirect chain
• HTTP status history
• HTML canonical tag
• AMP equivalent
• Mobile equivalent
• Tracking parameters removed
• Alternate-language versions
• Syndicated-original relationship

For example, I may receive:

https://example.com/research/report

The search system may originally have encountered:

https://www.example.com/research/report/?utm_source=newsletter

or:

https://example.com/amp/research/report

or a redirect URL.

I usually see only the result URL eventually returned to me. I do not get an explanation of the canonicalization process.

That means a rigorous research audit should preserve:

1. The raw URL returned by the search system
2. A separately calculated normalized URL
3. The final URL after opening and redirects
4. Any declared canonical URL discovered independently

The previous source register mostly retained the URL made available by the search result. It was not a forensic redirect-and-canonicalization log.

Snippets may be assembled from multiple metadata sources

The snippet can look like ordinary prose, but it may be derived from richer underlying information.

Possible sources include:

• Visible body text
• Meta description
• Open Graph description
• JSON-LD description
• Search-index passages
• Anchor text from other pages
• Query-matched sentences
• Automatically generated summarization

The critical limitation is that I am usually not told which of those produced the snippet.

Suppose the card says:

OpenAI analyzed 1.5 million conversations to understand how consumers use ChatGPT.

That might be:

• A sentence from the article
• A meta description
• A generated result summary
• A passage extracted from elsewhere on the page
• A combination of multiple passages

Therefore, the snippet should not be treated as a verbatim quotation unless the opened page confirms it.

Knowledge-graph or entity information

I do not normally get a structured list such as:

{
	"entities": [
		{
			"name": "OpenAI",
			"type": "Organization",
			"wikidata_id": "Q24283660",
			"confidence": 0.99
		},
		{
			"name": "ChatGPT",
			"type": "SoftwareApplication",
			"wikidata_id": "Q115564437",
			"confidence": 0.98
		}
	]
}

The search provider may use entity recognition, knowledge graphs, embeddings, or semantic indexing internally. Those values are not normally included in the card I inspect.

I therefore cannot see:

• Entity-confidence scores
• Knowledge-graph IDs
• Topical categories
• Search-intent classifications
• Semantic embedding vectors
• Query-document similarity
• Entity salience
• Sentiment
• Reading level
• Content quality score
• Spam probability
• Originality score
• Source reputation score

I can infer entities from the title and snippet, but that is my analysis of the text rather than an exposed search-result field.

Embedded links and citations inside the webpage

The standard result card does not normally contain a structured inventory of:

• Every outbound link
• Academic citations
• References
• Footnotes
• Related articles
• Downloadable datasets
• Author-profile links
• Social-profile links
• Source-document links

After opening a webpage, the extracted representation may expose links as individually clickable identifiers. That allows me to follow a methodology PDF, dataset, source report, or related page.

Conceptually, the opened page might provide:

The full methodology is available here. [Link 12]
Download the dataset. [Link 13]
Read the working paper. [Link 14]

But I do not necessarily receive a semantic relation such as:

{
	"links": [
		{
			"url": "...",
			"relation": "methodology"
		},
		{
			"url": "...",
			"relation": "dataset"
		}
	]
}

The relationship must be inferred from anchor text and surrounding context.

Images and visual metadata

A standard card may be associated with an image or thumbnail, but I generally do not receive the page’s complete image metadata.

Not normally exposed:

• Raw og:image
• Image width and height
• Image MIME type
• Alt text
• Caption
• Credit
• Photographer
• Copyright owner
• EXIF metadata
• Dominant colors
• Image hashes
• Image similarity
• Whether the image is original or syndicated

Dedicated image-search results may expose more image-specific information, and ChatGPT Search can visually present images with source links. OpenAI’s documentation confirms that images can appear at the top of search responses and that users can inspect their sources. (OpenAI Help Center)

But an image being displayed does not mean I receive all the underlying webpage image schema.

Rich results are different from rich webpage metadata

This distinction is useful.

Rich webpage metadata

Information embedded by the publisher:

• JSON-LD
• Open Graph
• Microdata
• RDFa
• Meta tags
• Structured author data
• Product properties
• Recipe properties
• Location data

Rich search result

A specialized result assembled by the search system:

• Product card
• Restaurant card
• Map
• Image card
• News card
• Weather forecast
• Sports result
• Finance chart

The search system may use publisher markup to create a rich result, but it can also use:

• Merchant feeds
• Licensed databases
• Search-provider knowledge graphs
• Partner APIs
• Page extraction
• User reviews
• Geospatial databases
• Other external data providers

So a product result containing price, merchant, rating, and image does not necessarily mean those values were copied from that page’s JSON-LD. They may have been aggregated from several systems.

Structured data by result type

Standard web result

Potentially visible:

• Title
• URL
• Snippet
• Date
• Reference ID
• Ordering
• Result classification
• Internal word limit

Not visibly exposed:

• Raw webpage schema
• Author object
• Entity list
• Open Graph object
• Canonical metadata
• Backlinks
• quality scores

News result

Potentially visible:

• Headline
• Publisher
• Publication time
• URL
• Snippet
• Image

Not necessarily exposed:

• Author
• NewsArticle JSON-LD
• News keywords
• Dateline
• Article section
• Paywall status as a formal field
• Syndication provenance

PDF result

Potentially visible after opening:

• Parsed text
• Page count
• Page locations
• Links
• Screenshots

Possible document-contained metadata that may not be separately exposed:

• PDF author
• PDF creator application
• Creation timestamp
• Modification timestamp
• DOI
• XMP metadata
• Embedded attachments
• Document outline

A paper’s authors and DOI may appear in the parsed text, but not necessarily as normalized fields.

Image result

Potentially visible:

• Image
• Source page
• Title or caption
• Host domain
• Reference ID

Potentially absent:

• Author
• License
• EXIF
• Embedded IPTC metadata
• Exact original image URL
• Complete dimensions
• Structured subject entities

Product result

Potentially visible:

• Product title
• Image
• Price
• Merchant
• Rating
• Availability
• Variant

These are genuinely structured values, but they belong to a dedicated commerce result rather than the standard web card.

Restaurant or local result

Potentially visible in supported ChatGPT experiences:

• Restaurant name
• Location
• Reservation availability
• Date/time/party-size interaction
• Map presentation
• Links to more information

OpenAI documents clickable restaurant results, reservation flows, and map output in certain ChatGPT Search experiences. (OpenAI Help Center)

Again, this is a specialized entity result, not a raw export of the restaurant webpage’s schema.

Search API versus what I see in this environment

There are two overlapping but distinct systems worth separating.

OpenAI Responses API web search

The public API documentation describes:

• Search actions
• Search queries
• Source URLs
• Open-page actions
• Find-in-page actions
• URL citations containing:
  • title
  • url
  • character-index positions in generated text

The documented source object itself is essentially:

{
	"type": "url",
	"url": "https://example.com"
}

The documented URL citation is effectively:

{
	"type": "url_citation",
	"title": "Example title",
	"url": "https://example.com",
	"start_index": 100,
	"end_index": 112
}

There is no documented arbitrary page-metadata object containing JSON-LD, author, publisher, schema types, or Open Graph values. (OpenAI Platform)

The internal research interface available to me here

The search output I receive is more reader-friendly than that minimal public source object. It commonly includes:

• Title
• URL
• Snippet or extracted content
• Crawl information
• Word-limit metadata
• Internal result reference

However, I still do not receive the page’s raw JSON-LD or a normalized metadata graph.

What might be happening upstream

The following is an inference, not exposed tool data.

A modern search pipeline may use some combination of:

• HTML title
• Visible headings
• Main content extraction
• Structured article markup
• Open Graph metadata
• XML sitemaps
• RSS feeds
• Link analysis
• Anchor text
• Entity recognition
• Language detection
• Publication-date extraction
• Deduplication
• Canonicalization
• Semantic embeddings
• Freshness signals
• User and location context
• Search-provider data
• Licensed content feeds

OpenAI states that ChatGPT Search may rewrite the user’s request into targeted queries and may use third-party search providers. The public explanation does not disclose the complete ranking or extraction pipeline or enumerate all page-level metadata consumed. (OpenAI Help Center)

So it would be reasonable to assume structured markup may contribute upstream. It would not be accurate to claim that I can see or audit its contribution.

A precise model of the data layers

Layer 1: Publisher’s webpage

May contain:

HTML
Visible text
JSON-LD
Microdata
RDFa
Open Graph
Twitter Cards
Canonical tags
Author metadata
Images
Links
Sitemaps
Feed metadata

Layer 2: Search-provider index

May derive:

Normalized title
Canonicalized URL
Passage index
Publication date
Entities
Language
Freshness
Duplicate clusters
Authority signals
Semantic vectors
Image associations
Result classifications

I cannot inspect this layer directly.

Layer 3: Search result returned to the tool

Typically contains:

Title
URL
Snippet
Date, sometimes
Result reference
Result type
Limited retrieval metadata

Layer 4: Opened-page representation

May contain:

Extracted main text
Headings
Links
Some visible byline/date information
Page sections
PDF pages

But generally not:

Raw DOM
Raw headers
Raw JSON-LD
Every meta tag
Every script
Complete network requests
Complete redirect history

Layer 5: My research record

I then derive:

Publisher
Likely author
Publication date
Methodology
Sample size
Denominator
Claims
Source type
Quality classification
Exclusion reason
Citation status

These are my structured research extractions, not original result-card fields.

What an ideal enriched research card would contain

For your kind of research, a much better result object would look like this:

{
	"discovery": {
		"query": "LLM consumer use case survey",
		"engine": "search-provider-name",
		"position": 3,
		"retrieved_at": "2026-07-26T12:00:00Z"
	},
	"url": {
		"raw": "https://example.com/report?utm_source=x",
		"normalized": "https://example.com/report",
		"final": "https://www.example.com/report",
		"canonical": "https://example.com/research/report"
	},
	"page": {
		"title": "Consumer Uses of Generative AI",
		"description": "A national survey...",
		"language": "en",
		"content_type": "text/html",
		"date_published": "2026-04-12",
		"date_modified": "2026-04-20"
	},
	"people": {
		"authors": [
			{
				"name": "Jane Doe",
				"url": "https://example.com/people/jane-doe"
			}
		]
	},
	"organization": {
		"publisher": "Example Research Center",
		"domain": "example.com"
	},
	"schema": {
		"types": [
			"Article",
			"Report"
		],
		"json_ld": true,
		"open_graph": true
	},
	"media": {
		"primary_image": "https://example.com/chart.png",
		"thumbnail": "https://example.com/thumb.jpg"
	},
	"search": {
		"snippet": "The study surveyed 5,000 adults...",
		"snippet_source": "body_passage",
		"relevance_score": 0.91,
		"authority_score": null
	},
	"research": {
		"opened": true,
		"primary_source": true,
		"sample_size": 5000,
		"population": "U.S. adults",
		"used": true,
		"cited": true
	}
}

The actual standard result card is much thinner than this. Most of the research section would need to be extracted after opening the page, and values like the relevance score may not be exposed at all.

Bottom line

For the standard result card:

• Yes, richer webpage metadata may exist and may affect how the search result is generated.
• No, I generally do not receive the raw JSON-LD, schema.org graph, author object, Open Graph tags, canonical tags, or entity data.
• Author, publisher, and dates may appear as ordinary text or as limited displayed metadata.
• Specialized result types—products, images, restaurants, maps, news, finance, weather—can contain genuinely structured rich content.
• Those specialized values are not equivalent to receiving the source webpage’s raw structured markup.
• After opening a page, I can extract much more information from visible content, but I still generally do not receive a complete raw structured-data dump.

The most accurate description is:

The card is a thin, query-oriented representation of a richer indexed document—not a transparent export of everything the search system knows about that document.