Schema.org type fields lookup
See which properties a page type needs before you write any markup: Product needs name and image, and adds description, sku, brand, offers, aggregateRating and review as recommended. Names are case-insensitive, and a typo like Productt is rejected instead of guessed. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Type
- Product
- Schema url
- https://schema.org/Product
- Required
- name, image
- Recommended
- description, sku, brand, offers, aggregateRating, review
The properties included with that type determine whether search engines and other consumers can understand the page. This lookup accepts a familiar type name such as Article, Product, Recipe, or FAQPage and returns a practical field checklist immediately. It separates commonly required properties from recommended enhancements, uses canonical property names, and rejects unknown types clearly so automated workflows never proceed with a silent guess.
What required and recommended really mean
The structured data vocabulary does not mandate properties the way a database does. Search features, validators and other consumers set their own eligibility rules, and those can change by platform and by how a result is shown. So the required list here means the properties commonly treated as the minimum useful set for SEO work, while the recommended list usually improves completeness, eligibility or the quality of a displayed result. Some properties hold nested objects, such as offers on Product, author on Article, location on Event and mainEntity on FAQPage; the lookup names them but does not build their contents.
Using the checklist without overreaching
Start by mapping every required property to real, visible page information, then add recommended ones only when trustworthy source data exists. Never fill a rating, price, author, image, availability or date just to complete the list. Choose the narrowest accurate type for the page's main subject, remembering that a specialized type still carries the meaning of its broader parents. Editors can see required inputs first and optional additions second, and existing markup can be compared against both lists to spot what is missing.
Interpret required and recommended as an implementation checklist
Search features, validators, and downstream consumers impose their own eligibility rules, which can change by platform and presentation. For that reason, the required list in this result means properties commonly treated as the minimum useful set for SEO implementation, while recommended fields usually improve completeness, eligibility, or the quality of a displayed result. Begin by mapping every required property to real, visible page information.
Then add recommended properties when trustworthy source data exists. Never fabricate a rating, price, author, image, availability state, or date simply to fill the checklist. A shorter object grounded in page content is safer than rich markup that contradicts what visitors see.
Some listed properties contain nested objects: for example, offers on Product, author on Article, location on Event, and mainEntity on FAQPage. Use it to scope the data you need before generation and validation.
What you can do with it
Audit missing properties
Compare keys in existing markup with common minimum and enhancement fields for its declared type.
Guide content editors
Show required inputs first and recommended additions second when an editor chooses a page type.
FAQ
Does the result include nested property structures?
No. It lists commonly useful top-level properties. Nested objects such as Offer, Person, or PostalAddress must be constructed and validated separately.
Which properties does a Product need?
For a Product, name and image are the common minimum, while description, sku, brand, offers, aggregateRating and review are recommended. Map each one to information that is actually visible on the page.
What is the difference between required and recommended properties?
Required means the set commonly treated as the minimum useful for SEO work; recommended properties usually improve completeness, eligibility or how a result is displayed. The vocabulary itself mandates nothing, and each search feature sets its own rules.
Can I fill in a property I have no real data for?
No. Never invent a rating, price, author, image, availability or date just to complete the list. Shorter markup grounded in what visitors see is safer than rich markup that contradicts the page.
Which type should I choose for my page?
Pick the narrowest accurate type for the page's main subject, not a small element on it: Product for something to buy, Recipe for cooking instructions, Article for editorial content and LocalBusiness for a physical business.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/seo/schema-type-lookup \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"type":"Product"}'const res = await fetch("https://api.kit.forhosting.com/seo/schema-type-lookup", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"type": "Product"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/seo/schema-type-lookup",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"type": "Product"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/seo/schema-type-lookup", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"type":"Product"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"type":"Product"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/seo/schema-type-lookup", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"type": "Product"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "seo.schema_type_lookup",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Choosing a Schema.org type is only the first step in creating useful structured data.
Start with the exact type your page represents
Structured data works best when the selected type describes the page's main subject, not merely one small element on it. If the name is not in the supported catalog, the capability returns an input error rather than inventing a close match. That behavior is valuable in publishing pipelines because a typo such as Productt should stop the build instead of producing markup that looks plausible but has no defined meaning. Enter a Schema.org type such as Product for a purchasable item, Recipe for cooking instructions, Article for editorial content, or LocalBusiness for a physical business presence. The lookup is case-insensitive and also accepts a full schema.org type URL, which makes it convenient when values arrive from an existing JSON-LD document. The response returns the canonical type name and URL alongside two ordered property lists. Select the narrowest accurate supported type, while remembering that a specialized type still inherits the broader meaning of its Schema.org parents. The lookup focuses on popular types used in SEO implementations, not every class in the complete Schema.org vocabulary.
Interpret required and recommended as an implementation checklist
Schema.org is a vocabulary and does not universally mandate properties in the way a database schema does. This lookup names those top-level properties but intentionally does not generate nested values or validate an entire JSON-LD graph.
Use deterministic results in audits and publishing workflows
Because the lookup uses a fixed in-memory catalog with no network requests, model calls, randomness, or clock-dependent behavior, the same supported type always produces the same ordered result. A CMS can request the checklist when an editor selects a content type, mark missing required inputs, and present recommended enhancements separately. Treat the result as a practical starting point and recheck the current documentation of any search platform whose rich result is business-critical, since platform-specific policies are outside this offline catalog. That makes it suitable for repeatable content audits, form builders, schema templates, migration scripts, and continuous integration checks. An audit tool can compare existing JSON-LD keys with the response and report gaps without deciding that every recommendation is an error. A generator can use the canonical schema URL while preserving the ordered fields for a predictable interface. The API request costs $0.002, while the browser experience can use the same pure logic. Error handling is deliberately explicit: an unsupported type returns an invalid-input response containing the submitted name and the supported choices, allowing a person or calling program to correct the request quickly.
Integration use cases
Plan a JSON-LD template
Retrieve a stable checklist before designing CMS fields for a new structured-data template.
Technical questions
Are these fields required by Schema.org itself?
No. Schema.org defines a vocabulary but generally does not mandate properties. The required list represents common minimums for practical SEO implementations.
What happens when a type is not recognized?
The request returns an invalid-input error and lists the supported canonical type names. It never guesses a replacement.
Can I submit a full Schema.org URL?
Yes. A value such as https://schema.org/Product is normalized to the canonical Product type.
How much does an API lookup cost?
Each API request costs $0.002. The algorithm is deterministic and does not call an external service.