Claude Cursor Skill

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.

LLM Mart · 0 points · 5 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download fcakyon-claude-codex-settings-plugins_seo-skills_skills_schema-4632eb3.zip · 6 KB
Part of fcakyon/claude-codex-settings — 83 skills

Install

skills CLI npx skills add https://github.com/fcakyon/claude-codex-settings/tree/main/plugins/seo-skills/skills/schema
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install fcakyon-claude-codex-settings@llmmart
Git 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

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.

No comments yet.

Reviews (0)

No reviews yet.

Related