Search & Discovery·Guide
The structured data this platform emits
Most "add schema markup" advice treats structured data as a single yes/no feature: either your site "has schema" or it doesn't. It's not one thing. It's a set of specific JSON-LD blocks, each aimed at a specific search feature. The useful question is which jobs you actually bought, and which checklist boxes you can ignore.
The jobs
What schema is for, not a type inventory
"Has schema" is not a switch
A BreadcrumbList, an Article, and an ImageObject are different jobs. Stamping a generic WebPage block on every URL is the checklist version of this, not the useful one.
Image rights are ImageObject
License, credit, copyright, creator, EXIF when present. That's what Google Image Search and the Licensable badge read. Alt text and file names are not a substitute.
Interior pages stop at crumbs
About and Services don't get a full WebPage block on top. BreadcrumbList already does the half of WebPage that matters here. The rest is cargo cult.
Not every URL wants to be discovered
Hidden public pages omit JSON-LD. Product pages are not Product schema. A vault link is a handoff, not a result.
The checklist vs the jobs
Every public route that emits schema gets a BreadcrumbList. On top of that, most route types get exactly one additional, purpose-built block, not a generic "page" schema stretched to cover everything. Hidden pages, posts, and galleries skip the JSON-LD; noindex still applies. That's the handling: specific jobs, not a site-wide stamp.
| Job | What fires |
|---|---|
| Site identity (home) | Organization + BreadcrumbList |
| Interior CMS page | BreadcrumbList only |
| Published blog post | Article + BreadcrumbList |
| Public photo page | ImageObject (license, credit, copyright, creator, EXIF when present) + BreadcrumbList |
| Public portfolio | ImageGallery + BreadcrumbList |
Why ImageObject is the one that matters most for images
The license, credit, copyright, creator, and EXIF fields on ImageObject aren't decorative. They're the fields Google Image Search and the Licensable-badge system read to decide whether to show licensing information on an image result. They're written for that crawl, not for a chat unfurl card (Open Graph handles that separately, on the same URL). Image licensing as a problem of its own is Licensable badge vs. IPTC.
Why interior CMS pages stop at BreadcrumbList
Interior CMS pages don't get a full WebPage schema block layered on top. That's a deliberate line, not a gap someone forgot to close. In practice, WebPage schema is mostly useful for two things, sitelinks search-box eligibility and reinforcing breadcrumb display, and BreadcrumbList already covers the breadcrumb half on its own. The marginal value of a full WebPage block on top, for a photographer's About or Services page, is low. It's the kind of box a generic "schema checklist" would tell you to tick without explaining what it buys you.
What's notably absent
Commerce product pages get an Open Graph card (skipping private storage, so a product image never leaks through a chat preview), but they aren't part of this JSON-LD list. If you're building a workflow that depends on Product schema specifically (price, availability, review markup showing directly in a Google result), that's not something to assume is happening here.
Vault URLs sit outside this entirely: no schema, no fat OG card. A vault link is a private handoff, not a page meant to be discovered or unfurled.
No schema.org encyclopedia here
This page stops at which jobs fire and why, not a tutorial on what ImageObject or BreadcrumbList mean as schema.org types. The values ImageObject reads (license, credit, copyright, creator) are the photo's own rights fields, not something you paste as markup.
Schema is a map, not a checkbox
Know which block fires on which URL. Don't buy a "we added schema" claim that won't say which types.
Also in Guides: Licensable badge vs. IPTC · Hide from search, noindex, and private · What Search Console is for