Layout is what people read; Schema.org is what parsers recognize. Styling handles the first layer, while the second is a semantic description embedded in the source. A page is complete only when both are handled.
Many designers skip this step because it feels like engineering work. When search visibility comes up, though, which types to declare and how fields map to the layout should be settled during planning. Adding markup after the page is built often means rewriting whole sections, which costs more than including it in the spec.
What Is Schema? Labels for Machines
Schema.org is a shared vocabulary maintained by Google, Microsoft, Yahoo, and Yandex. It describes the entities on a page so the source can state:
- This passage is an article (Article)
- This block is a FAQ (FAQPage)
- This image is an organization logo (ImageObject with Organization.logo)
- This figure is a selling price (Offer.price)
Once a parser knows each block’s role, it can decide whether that block is suitable as a search summary.
Preferred Format: JSON-LD
Three syntaxes are available: Microdata, RDFa, and JSON-LD. Google prefers JSON-LD because it:
- Stays separate from layout markup and does not disturb the design
- Can sit anywhere in
or - Keeps one complete data object in a single script, which is easier to maintain
- Adds almost no rendering cost and does not itself change ranking
Example:
Visitors never see this script, yet a parser can immediately tell that the organization was founded in 2010 and focuses on structured content.
Seven Schema Types Designers Need
1. Organization
Where it fits: Home and about pages (see corporate site setup notes)Why it matters: It supports brand identity and can shape the knowledge panel
Key fields: name, url, logo, foundingDate, address, contactPoint, sameAs (external profile links)
2. Article
Where it fits: Blogs, news, and insight piecesWhy it matters: It is one of the types generative summaries cite most often
Key fields: headline, author, datePublished, dateModified, image, publisher, articleBody
3. FAQPage
Where it fits: FAQ pages, the foot of product pages, and article endingsWhy it matters: It is especially likely to be picked up by summary systems, because question-and-answer format is easy to extract
Key fields: mainEntity (an array of Question and acceptedAnswer)
Each pair can be lifted on its own and used to answer a related query. For layout choices that make citation easier, see how to arrange a FAQ block.
4. Product
Where it fits: Ecommerce detail pages (see shopping platform planning notes)Why it matters: It affects exposure in shopping results and recommendation surfaces
Key fields: name, image, description, brand, offers (including price, priceCurrency, availability), aggregateRating
5. BreadcrumbList
Where it fits: Every page except the home pageWhy it matters: It helps systems understand site hierarchy and the current page’s place
Key fields: itemListElement (an array with position, name, and item)
6. LocalBusiness
Where it fits: Restaurants, clinics, and shops with a physical locationWhy it matters: It influences “near me” queries and map results
Key fields: name, address, telephone, openingHoursSpecification, geo, priceRange
7. Person
Where it fits: Author pages and team introductionsWhy it matters: It supports author credibility and experience-related quality signals
Key fields: name, jobTitle, image, sameAs, worksFor
Three Decisions in the Design Phase
List Schema Types per Page
Before drawing layouts, decide which Schema set each page needs:
| Page type | Suggested markup |
|---|---|
| Home | Organization + WebSite |
| About | AboutPage + Organization |
| Article index | CollectionPage |
| Article page | Article + BreadcrumbList + FAQPage (if Q&A exists) |
| Product index | CollectionPage + ItemList |
| Product detail | Product + BreadcrumbList + Review |
| FAQ page | FAQPage |
| Contact page | ContactPage + LocalBusiness |
| Author page | Person + ProfilePage |
Match Fields to the Layout
If the page emits Article, the layout needs an author, a publish date, an update date, and a lead image. If it emits FAQPage, it needs clear question-and-answer pairs. Markup that describes content the page does not show can be treated as a structural mismatch and penalized. One project declared extensive markup that the pages did not support, search-console warnings piled up, and cleanup took more effort than planning it properly.
Align Data Sources with Engineering
Will fields be hardcoded in the template or pulled from the content system? Settle that during design. Otherwise the team ends up filling data by hand after launch, and maintenance becomes a lasting burden.
Common Mistakes
- ❌ Markup that does not match the page: Declaring Review without a review block can be treated as a violation
- ❌ Conflicting types: Marking one block as both Article and BlogPosting when the fields clash
- ❌ Missing required fields: An Article without author or datePublished is usually ignored by summary systems
- ❌ A relative logo path: logo must be an absolute URL that includes the protocol
- ❌ Price written as decorated text:
"price": "$50"is wrong; use"price": "50", "priceCurrency": "USD"
Design and Markup Belong Together
Once generative summaries are common, visual design and structured description can no longer be separate jobs. Markup should describe what the layout actually shows, and both should be considered while planning. For how layout maps to summary slices, see page structure for the summary era. Designers who understand markup make pages easier to read correctly; fixing it after launch often costs several times more than planning it first.
The requirements phase should produce a mapping sheet: which types each page uses, where each field comes from, and who maintains it. That sheet aligns design, engineering, and content, and it is also the checklist for acceptance.
