schema
Use when adding, fixing, or reviewing structured data: JSON-LD for articles, products, FAQs, breadcrumbs, organizations, and local businesses, and what to do when markup doesn't earn a rich result.
Install
npx skills add https://github.com/fcakyon/claude-codex-settings/tree/main/plugins/seo-skills/skills/schema
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install fcakyon-claude-codex-settings@llmmart
git clone https://github.com/fcakyon/claude-codex-settings.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole fcakyon/claude-codex-settings collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Schema markup
Structured data tells a search engine what a page is rather than making it rank. Done right it earns a richer result and makes the page easier for an engine to summarize. Done wrong it earns a manual action.
Four rules govern everything below:
- Mark up only what the page visibly shows. Schema describing content a reader can't see is a spam signal, and it's the single most common reason markup gets penalized rather than ignored.
- Use JSON-LD, in a
<script type="application/ld+json">in the head or at the end of the body. Google recommends it, and it's the only format you can add without touching the page's markup. - Only claim types and properties the engine actually supports for a rich result. Valid schema.org markup with no supported result does nothing for search, which is fine, but don't promise a rich result it can't produce.
- Validate before it ships, then watch Search Console. Markup that validates can still be wrong about the page.
Choosing the type
| Type | Use on | Required |
|---|---|---|
| Organization | Homepage, about page | name, url |
| WebSite | Homepage, to declare a site search | name, url |
| Article, BlogPosting | Posts and news | headline, image, datePublished, author |
| Product | Product pages | name, image, offers |
| SoftwareApplication | App and SaaS pages | name, offers |
| FAQPage | A page with real questions and answers | mainEntity |
| HowTo | Step-by-step instructions | name, step |
| BreadcrumbList | Any page with breadcrumbs | itemListElement |
| LocalBusiness | A location page | name, address |
| Event | Events and webinars | name, startDate, location |
references/schema-examples.md has a complete, valid block for each of these plus a combined @graph and a Next.js pattern. references/required-properties.json is the same table in the form the bundled validator reads, so adding a type means editing both.
When a page needs several types, prefer one @graph array over several separate script tags: entities can then reference each other by @id instead of repeating themselves.
Reviewing existing markup
A fetch of the page shows only server-rendered JSON-LD. CMS SEO plugins commonly inject it client side, so absence in fetched HTML is not absence on the page. Report what the server HTML contained, then send them to the Rich Results Test, which renders JavaScript.
When markup exists but earns nothing, check in this order: a required property missing, a value in the wrong shape (dates must be ISO 8601, URLs absolute, enumerations exact), the type having no rich result to earn, or the markup describing something the page doesn't show.
From this skill directory, run node scripts/validate_schema.mjs <jsonld-file> on any block before you hand it over. It parses the JSON, checks each type against the required properties in references/required-properties.json, and catches the two value shapes that fail most often: a date that isn't ISO 8601 and a relative URL. It's mechanical, so a clean result means the syntax is right and nothing more.
Then point the user at the Rich Results Test at https://search.google.com/test/rich-results for eligibility, and the schema.org validator at https://validator.schema.org/ for correctness against the vocabulary. Those answer different questions from each other and from the tool, so a block can pass one and fail another. None of the three can tell you whether the markup describes what the page actually shows, which is the accuracy rule above and still yours to check.
Handing it over
Give the complete block, ready to paste, with the page's real values filled in rather than placeholders. Say where it goes, name any property you had to leave out and why, and note which rich result it makes the page eligible for, with eligible being the honest word. Google decides whether to show one.
Sources
- Google Search Central, Intro to how structured data works: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
- Google Search Central, Structured data general guidelines: https://developers.google.com/search/docs/appearance/structured-data/sd-policies
- Google Search Central, Search gallery of supported result types: https://developers.google.com/search/docs/appearance/structured-data/search-gallery
- schema.org: https://schema.org/
Files (claude-codex-settings)
-
references
-
required-properties.json 470 B
{ "Article": ["headline", "image", "datePublished", "author"], "BlogPosting": ["headline", "image", "datePublished", "author"], "BreadcrumbList": ["itemListElement"], "Event": ["name", "startDate", "location"], "FAQPage": ["mainEntity"], "HowTo": ["name", "step"], "LocalBusiness": ["name", "address"], "Organization": ["name", "url"], "Product": ["name", "image", "offers"], "SoftwareApplication": ["name", "offers"], "WebSite": ["name", "url"] } -
schema-examples.md 8.2 KB
# Schema examples Valid JSON-LD for the types that come up most. Replace every value with the page's real content. Each block goes in a `<script type="application/ld+json">` tag. ## Organization ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example", "url": "https://example.com", "logo": "https://example.com/logo.png", "description": "One sentence on what the company does.", "sameAs": [ "https://x.com/example", "https://www.linkedin.com/company/example" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "email": "support@example.com" } } ``` ## WebSite with site search The `SearchAction` only matters if the site has a working search results page at that URL pattern. ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://example.com/#website", "name": "Example", "url": "https://example.com", "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://example.com/search?q={search_term_string}" }, "query-input": "required name=search_term_string" } } ``` ## Article or BlogPosting ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "The post title, under 110 characters", "description": "The meta description or a one-sentence summary.", "image": ["https://example.com/images/post-16x9.jpg"], "datePublished": "2026-07-25T09:00:00-07:00", "dateModified": "2026-07-25T09:00:00-07:00", "author": { "@type": "Person", "name": "Author Name", "url": "https://example.com/authors/author-name" }, "publisher": { "@type": "Organization", "name": "Example", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/blog/post-slug" } } ``` `author` as a real `Person` with a URL to a real author page carries more weight than a bare string, and it's what makes the experience and expertise signals legible. ## Product `offers` is required. Omit `aggregateRating` and `review` unless real ratings exist on the page. ```json { "@context": "https://schema.org", "@type": "Product", "name": "Product Name", "image": ["https://example.com/images/product.jpg"], "description": "What the product is.", "sku": "SKU-123", "brand": { "@type": "Brand", "name": "Example" }, "offers": { "@type": "Offer", "url": "https://example.com/products/product-name", "priceCurrency": "USD", "price": "49.00", "availability": "https://schema.org/InStock", "priceValidUntil": "2027-01-01" }, "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "127" } } ``` ## SoftwareApplication For a SaaS or app page. A free tier is `price: "0"`, not an omitted `offers`. ```json { "@context": "https://schema.org", "@type": "SoftwareApplication", "name": "Product Name", "applicationCategory": "BusinessApplication", "operatingSystem": "Web", "description": "What the product does.", "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" } } ``` ## FAQPage Only for questions and answers actually visible on the page. An FAQPage describing hidden or invented questions is the classic penalized case. ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does setup take?", "acceptedAnswer": { "@type": "Answer", "text": "Most teams finish in under ten minutes." } }, { "@type": "Question", "name": "Is there a free plan?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, with up to three projects." } } ] } ``` ## HowTo ```json { "@context": "https://schema.org", "@type": "HowTo", "name": "How to do the thing", "totalTime": "PT15M", "step": [ { "@type": "HowToStep", "name": "First step", "text": "What to do.", "url": "https://example.com/guide#step-1" }, { "@type": "HowToStep", "name": "Second step", "text": "What to do next.", "url": "https://example.com/guide#step-2" } ] } ``` ## BreadcrumbList `position` starts at 1. The current page is the last item and conventionally omits `item`. ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com" }, { "@type": "ListItem", "position": 2, "name": "Features", "item": "https://example.com/features" }, { "@type": "ListItem", "position": 3, "name": "Analytics" } ] } ``` ## LocalBusiness Name, address, and phone must match what the page shows and what other listings say. ```json { "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Example Studio", "image": "https://example.com/images/storefront.jpg", "url": "https://example.com/locations/austin", "telephone": "+1-512-555-0100", "address": { "@type": "PostalAddress", "streetAddress": "100 Congress Ave", "addressLocality": "Austin", "addressRegion": "TX", "postalCode": "78701", "addressCountry": "US" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"], "opens": "09:00", "closes": "17:00" } ] } ``` ## Event ```json { "@context": "https://schema.org", "@type": "Event", "name": "Event Name", "startDate": "2026-09-15T10:00:00-07:00", "endDate": "2026-09-15T11:00:00-07:00", "eventAttendanceMode": "https://schema.org/OnlineEventAttendanceMode", "eventStatus": "https://schema.org/EventScheduled", "location": { "@type": "VirtualLocation", "url": "https://example.com/webinars/event-name" }, "organizer": { "@type": "Organization", "name": "Example", "url": "https://example.com" } } ``` ## Several types on one page Use one `@graph` and let entities reference each other by `@id` rather than repeating the organization on every entity. ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example", "url": "https://example.com" }, { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com", "publisher": { "@id": "https://example.com/#organization" } }, { "@type": "BlogPosting", "headline": "The post title", "datePublished": "2026-07-25T09:00:00-07:00", "image": ["https://example.com/images/post.jpg"], "author": { "@type": "Person", "name": "Author Name" }, "publisher": { "@id": "https://example.com/#organization" }, "isPartOf": { "@id": "https://example.com/#website" } }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com" }, { "@type": "ListItem", "position": 2, "name": "Blog" } ] } ] } ``` ## Next.js Render it server side so it's in the HTML a crawler receives. In the App Router, a script tag in the page or layout is enough. ```tsx export default function Page() { const schema = { "@context": "https://schema.org", "@type": "BlogPosting", headline: post.title, datePublished: post.publishedAt, author: { "@type": "Person", name: post.author.name }, }; return ( <> <script // biome-ignore lint/security/noDangerouslySetInnerHtml: JSON-LD has no safe typed alternative dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }} type="application/ld+json" /> <article>{/* ... */}</article> </> ); } ``` Build the object from the same data that renders the page, so the two can't drift apart. Hard-coding schema values separately from the visible content is how markup ends up describing a page that has since changed.
-
-
scripts
-
validate_schema.mjs 3.7 KB · in bundle
-
-
SKILL.md 4.5 KB
--- name: schema description: "Use when adding, fixing, or reviewing structured data: JSON-LD for articles, products, FAQs, breadcrumbs, organizations, and local businesses, and what to do when markup doesn't earn a rich result." license: MIT --- # Schema markup Structured data tells a search engine what a page is rather than making it rank. Done right it earns a richer result and makes the page easier for an engine to summarize. Done wrong it earns a manual action. Four rules govern everything below: - Mark up only what the page visibly shows. Schema describing content a reader can't see is a spam signal, and it's the single most common reason markup gets penalized rather than ignored. - Use JSON-LD, in a `<script type="application/ld+json">` in the head or at the end of the body. Google recommends it, and it's the only format you can add without touching the page's markup. - Only claim types and properties the engine actually supports for a rich result. Valid schema.org markup with no supported result does nothing for search, which is fine, but don't promise a rich result it can't produce. - Validate before it ships, then watch Search Console. Markup that validates can still be wrong about the page. ## Choosing the type | Type | Use on | Required | | --- | --- | --- | | Organization | Homepage, about page | `name`, `url` | | WebSite | Homepage, to declare a site search | `name`, `url` | | Article, BlogPosting | Posts and news | `headline`, `image`, `datePublished`, `author` | | Product | Product pages | `name`, `image`, `offers` | | SoftwareApplication | App and SaaS pages | `name`, `offers` | | FAQPage | A page with real questions and answers | `mainEntity` | | HowTo | Step-by-step instructions | `name`, `step` | | BreadcrumbList | Any page with breadcrumbs | `itemListElement` | | LocalBusiness | A location page | `name`, `address` | | Event | Events and webinars | `name`, `startDate`, `location` | `references/schema-examples.md` has a complete, valid block for each of these plus a combined `@graph` and a Next.js pattern. `references/required-properties.json` is the same table in the form the bundled validator reads, so adding a type means editing both. When a page needs several types, prefer one `@graph` array over several separate script tags: entities can then reference each other by `@id` instead of repeating themselves. ## Reviewing existing markup A fetch of the page shows only server-rendered JSON-LD. CMS SEO plugins commonly inject it client side, so absence in fetched HTML is not absence on the page. Report what the server HTML contained, then send them to the Rich Results Test, which renders JavaScript. When markup exists but earns nothing, check in this order: a required property missing, a value in the wrong shape (dates must be ISO 8601, URLs absolute, enumerations exact), the type having no rich result to earn, or the markup describing something the page doesn't show. From this skill directory, run `node scripts/validate_schema.mjs <jsonld-file>` on any block before you hand it over. It parses the JSON, checks each type against the required properties in `references/required-properties.json`, and catches the two value shapes that fail most often: a date that isn't ISO 8601 and a relative URL. It's mechanical, so a clean result means the syntax is right and nothing more. Then point the user at the Rich Results Test at https://search.google.com/test/rich-results for eligibility, and the schema.org validator at https://validator.schema.org/ for correctness against the vocabulary. Those answer different questions from each other and from the tool, so a block can pass one and fail another. None of the three can tell you whether the markup describes what the page actually shows, which is the accuracy rule above and still yours to check. ## Handing it over Give the complete block, ready to paste, with the page's real values filled in rather than placeholders. Say where it goes, name any property you had to leave out and why, and note which rich result it makes the page eligible for, with eligible being the honest word. Google decides whether to show one. ## Sources - Google Search Central, Intro to how structured data works: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data - Google Search Central, Structured data general guidelines: https://developers.google.com/search/docs/appearance/structured-data/sd-policies - Google Search Central, Search gallery of supported result types: https://developers.google.com/search/docs/appearance/structured-data/search-gallery - schema.org: https://schema.org/
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.