ForHosting KIT · SEO

Campos de tipos Schema.org: obligatorios y recomendados

Elegir un tipo de Schema.org es solo el primer paso para crear datos estructurados útiles.

● BetaGratis · en su navegador
Úselo desde WebAPIEmailTelegramApp pronto

Las propiedades incluidas determinan si los buscadores y otros consumidores pueden comprender la página. Esta consulta acepta nombres conocidos como Article, Product, Recipe o FAQPage y devuelve de inmediato una lista práctica de campos. Separa las propiedades habitualmente obligatorias de las mejoras recomendadas, utiliza nombres canónicos y rechaza claramente los tipos desconocidos para que los procesos automatizados nunca continúen a partir de una suposición silenciosa.

Empiece por el tipo exacto que representa su página

Los datos estructurados funcionan mejor cuando el tipo elegido describe el tema principal de la página y no solo un elemento secundario. Introduzca un tipo de Schema.org como Product para un artículo que se puede comprar, Recipe para instrucciones de cocina, Article para contenido editorial o LocalBusiness para un negocio con presencia física. La consulta no distingue mayúsculas de minúsculas y también acepta una URL completa del tipo en schema.org, algo práctico cuando el valor procede de un documento JSON-LD existente. La respuesta incluye el nombre y la URL canónicos junto con dos listas ordenadas de propiedades. Si el nombre no pertenece al catálogo compatible, la capacidad devuelve un error de entrada en vez de inventar una coincidencia aproximada. En un flujo de publicación, ese comportamiento permite que una errata como Productt detenga el proceso, en lugar de producir marcado aparentemente válido pero sin significado definido. Elija el tipo compatible más específico y exacto. Esta consulta cubre tipos populares en implementaciones SEO, no todas las clases del vocabulario completo de Schema.org.

Interprete los campos como una lista práctica de implementación

Schema.org es un vocabulario y no exige propiedades universalmente como lo haría el esquema de una base de datos. Las funciones de búsqueda, los validadores y otros consumidores establecen sus propios requisitos, que pueden variar según la plataforma y la presentación. Por eso, la lista de campos obligatorios representa las propiedades que suelen considerarse el mínimo útil para SEO, mientras que las recomendadas mejoran la integridad, la elegibilidad o la calidad de un resultado mostrado. Asocie primero cada propiedad obligatoria con información real y visible en la página. Después añada las recomendadas cuando disponga de datos fiables. Nunca invente una valoración, un precio, un autor, una imagen, una disponibilidad o una fecha solo para completar la lista. Un objeto más breve y basado en el contenido es preferible a un marcado rico que contradiga lo que ven los visitantes. Algunas propiedades contienen objetos anidados, como offers en Product, author en Article, location en Event y mainEntity en FAQPage. La consulta nombra las propiedades superiores, pero no genera valores anidados ni valida todo un grafo JSON-LD.

Integre resultados deterministas en auditorías y publicaciones

Como la consulta usa un catálogo fijo en memoria sin red, modelos, aleatoriedad ni dependencia del reloj, un mismo tipo compatible siempre produce el mismo resultado ordenado. Esto resulta útil para auditorías repetibles, creadores de formularios, plantillas de esquema, migraciones y controles de integración continua. Un CMS puede solicitar la lista cuando una persona editora selecciona un tipo de contenido, marcar los datos obligatorios ausentes y mostrar por separado las mejoras recomendadas. Una herramienta de auditoría puede comparar las claves JSON-LD existentes con la respuesta e informar de carencias sin tratar cada recomendación como un error. Un generador puede usar la URL canónica y conservar el orden para ofrecer una interfaz predecible. Considere el resultado un punto de partida práctico y consulte la documentación vigente de cualquier buscador cuyo resultado enriquecido sea esencial, pues sus políticas quedan fuera de este catálogo sin conexión. Cada solicitud API cuesta $0.002; la experiencia del navegador utiliza la misma lógica pura. Un tipo no compatible produce deliberadamente un error con el nombre enviado y las opciones admitidas para facilitar la corrección.

Planificar una plantilla JSON-LD

Obtenga una lista estable antes de diseñar los campos del CMS para una nueva plantilla de datos estructurados.

Auditar propiedades ausentes

Compare las claves del marcado existente con los campos mínimos y adicionales habituales de su tipo declarado.

Orientar a quienes editan contenido

Muestre primero los datos obligatorios y después las mejoras recomendadas al elegir un tipo de página.

¿Schema.org exige realmente estos campos?

No. Schema.org define un vocabulario, pero normalmente no obliga a incluir propiedades. La lista obligatoria refleja mínimos habituales en implementaciones SEO.

¿Qué ocurre si no se reconoce un tipo?

La solicitud devuelve un error de entrada y enumera los nombres canónicos compatibles. Nunca adivina un sustituto.

¿Puedo enviar una URL completa de Schema.org?

Sí. Un valor como https://schema.org/Product se normaliza al tipo canónico Product.

¿Incluye el resultado estructuras de propiedades anidadas?

No. Enumera propiedades superiores de uso habitual. Los objetos anidados como Offer, Person o PostalAddress deben crearse y validarse por separado.

¿Cuánto cuesta una consulta mediante API?

Cada solicitud API cuesta $0.002. El algoritmo es determinista y no llama a servicios externos.

Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.

POSThttps://api.kit.forhosting.com/seo/schema-type-lookup

¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.

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"}'
{
  "type": "Product"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "seo.schema_type_lookup",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.

Por solicitud$0.002

Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.

HTTPCódigoSignificado
401unauthorizedAPI key ausente o inválida.
402insufficient_balanceEl saldo no cubre el precio de la tarea.
404unknown_typeEl tipo de tarea no existe.
429rate_limitedDemasiadas peticiones. Use el webhook en vez de sondear.

Ver la documentación completa del KIT →