Schema JSON Optimization
Validate existing JSON-LD and suggest only relevant schemas based on the detected page type.
> Important: Do NOT blindly check for all schema types. First detect what kind of page this is, then only validate/suggest schemas that are applicable.
Step 1: Find and validate existing JSON-LD
Look for all <script type="application/ld+json"> elements:
- None found → ⚠️ WARN "No JSON-LD schema markup found"
- Found → ✅ PASS "Found N JSON-LD block(s)" → validate each:
Validation rules
- Invalid JSON → ❌ FAIL "Could not parse JSON-LD"
- Missing
@context→ ❌ FAIL - Missing
@type→ ❌ FAIL - Valid → ✅ PASS and check type-specific required fields (see Step 3)
Step 2: Auto-detect page type
Scan the HTML for signals to determine what type of page this is. A page may match zero, one, or multiple types:
| Page type | Detection signals |
|---|---|
| Article / Blog | <meta property="article:published_time">, <article> tag, blog-like URL patterns (/blog/, /post/, /news/) |
| LocalBusiness | <address> tag, <a href="tel:...">, [itemprop="telephone"], [itemprop="address"], contact page patterns |
| Product | <meta property="og:type" content="product">, price elements ([itemprop="price"]), add-to-cart buttons |
| FAQ | Multiple <details>/<summary> or FAQ-patterned heading + paragraph pairs |
| Organization | About page with company info, <meta property="og:type" content="website"> on homepage |
| BreadcrumbList | <nav aria-label="breadcrumb">, .breadcrumb class, <ol> with breadcrumb-like links |
| WebSite | Homepage with site-wide search form |
If no type is detected → only validate existing schemas, do not suggest new ones.
Step 3: Validate and suggest ONLY for detected types
Only if Article/Blog detected:
Check existing Article schema for:
| Field | Missing = |
|---|---|
headline |
⚠️ WARN |
datePublished |
⚠️ WARN |
author |
⚠️ WARN |
image |
⚠️ WARN |
description |
⚠️ WARN |
If no Article schema exists, suggest generating one:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "[from og:title, <title>, or <h1>]",
"datePublished": "[from article:published_time or <time datetime>]",
"author": { "@type": "Person", "name": "[from meta author]" },
"image": "[from og:image or first article img]",
"description": "[from meta description]",
"url": "[from canonical or og:url]"
}
Only if LocalBusiness detected:
Check for:
| Field | Missing = |
|---|---|
name |
❌ FAIL |
address |
⚠️ WARN |
telephone |
⚠️ WARN |
If no LocalBusiness schema exists, suggest generating one:
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "[from og:site_name or <title>]",
"address": "[from <address> or itemprop=address]",
"telephone": "[from itemprop=telephone or tel: link]",
"url": "[from canonical or og:url]",
"image": "[from og:image]"
}
Only if Product detected:
Check for:
| Field | Missing = |
|---|---|
name |
❌ FAIL |
offers (with price and priceCurrency) |
⚠️ WARN |
image |
⚠️ WARN |
description |
⚠️ WARN |
Only if FAQ detected:
Suggest FAQPage schema with Question/Answer pairs extracted from the page.
Only if BreadcrumbList detected:
Suggest BreadcrumbList schema from the breadcrumb navigation structure.
Key principle
DO: "This page looks like a blog post → checking for Article schema"
DON'T: "Missing LocalBusiness schema" on a blog post page
The goal is relevance, not completeness. Only flag missing schemas that would actually benefit the detected page type.
Edge cases
- A page may have multiple valid types (e.g. a product page with FAQ section → suggest both Product and FAQPage)
- A page may have existing schemas that are valid but don't match the detected type — that's fine, still validate them
- If detection is ambiguous, report what was detected and let the user decide
- Schema
@typecan be an array (e.g.["Article", "NewsArticle"])
