La semana pasada un cliente me preguntó: «Tenemos un archivo schemas.ts en el código, pero ya nadie sabe por qué está ahí ni qué hace cada bloque». No es una excepción. En al menos la mitad de los proyectos que reviso hay un archivo JSON-LD perdido que alguien dejó en su día, sin documentación, sin un objetivo claro y, a menudo, sin que nadie sepa ya si es correcto.
Es una lástima, porque los datos estructurados son justo el tipo de información que buscan con avidez sistemas de IA como ChatGPT, Perplexity y los AI Overviews de Google. Es contexto legible por máquinas que dice: «esto es quiénes somos, aquí estamos y estas son las respuestas a las preguntas frecuentes». Sin ese contexto, un modelo de lenguaje tiene que adivinar a partir de texto no estructurado. Con ese contexto, obtiene una fuente directa y fiable.
En este artículo te explico los tres tipos de schema más habituales —Organization, LocalBusiness y FAQPage— con ejemplos concretos que puedes implementar hoy mismo.
Por qué los datos estructurados siguen importando en la era de la IA
Los datos estructurados (casi siempre JSON-LD) existen desde 2011 gracias a schema.org, un proyecto impulsado conjuntamente por Google, Bing, Yahoo y Yandex. El objetivo original era sencillo: ayudar a los buscadores a entender el contenido para mostrar resultados enriquecidos: reseñas con estrellas, horarios de apertura, desplegables de preguntas frecuentes en los resultados de búsqueda.
Lo que ha cambiado es que el «lector» de tus datos estructurados ya no es solo un crawler que indexa para una lista de resultados. Ahora también es un modelo de lenguaje que analiza tu contenido para formular una respuesta a un usuario que ni siquiera va a entrar en tu web. Si alguien pregunta a ChatGPT «qué empresas de Utrecht (Países Bajos) hacen consultoría de IA», la probabilidad de que tu JSON-LD se tenga en cuenta en la respuesta es muchas veces mayor que la de que se interprete un texto de marketing.
Esto se debe a que los datos estructurados no son ambiguos. Una frase como «Estamos en el centro de Utrecht» obliga al modelo a interpretar y hacer suposiciones. Un objeto PostalAddress con addressLocality: "Utrecht" no necesita interpretación: es un hecho que se puede extraer directamente.
Para entender la estrategia más amplia que hay detrás de este tipo de optimización, te recomiendo leer también qué es GEO exactamente: los datos estructurados son solo una pieza de un rompecabezas más grande.
Los tres tipos de schema que casi siempre necesitas
Organization: ¿quién eres, de verdad?
El schema Organization es la base. Responde a la pregunta que los sistemas de IA no suelen poder contestar: ¿qué es esta empresa y por qué debería confiar en ella? Este schema debería ir en tu página de inicio y, preferiblemente, repetirse (o referenciarse) en cada página a través de tu layout.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "WeArkMedia",
"url": "https://wearkmedia.nl",
"logo": "https://wearkmedia.nl/logo.png",
"description": "Desarrollo web nativo de IA y optimización GEO/AEO para empresas que quieren que las encuentren ChatGPT, Perplexity y los AI Overviews de Google.",
"sameAs": [
"https://www.linkedin.com/company/wearkmedia",
"https://twitter.com/wearkmedia"
],
"contactPoint": {
"@type": "ContactPoint",
"email": "hallo@wearkmedia.nl",
"contactType": "customer service"
}
}
Lo importante aquí es que sameAs no es decorativo. Este campo vincula tu empresa con fuentes externas verificables: tu LinkedIn, tu página de Wikipedia (si existe), tu perfil de Crunchbase. Los modelos de IA usan este tipo de referencias cruzadas para determinar si una entidad es «real». Un schema Organization sin sameAs es como un perfil de LinkedIn sin contactos: técnicamente válido, pero poco convincente.
La description no la copies directamente de tu meta description. Escribe una frase concreta sobre qué haces y para quién: no «somos una agencia líder», sino qué ofreces, a quién y por qué te diferencias.
LocalBusiness: clave si quieres que te encuentren físicamente
Si tienes una ubicación física (una oficina, una tienda, una consulta), LocalBusiness (o un subtipo más específico como ProfessionalService, Restaurant o Store) es esencial. Este schema es la razón directa por la que los asistentes de IA pueden responder preguntas del tipo «cerca de mí».
{
"@context": "https://schema.org",
"@type": "ProfessionalService",
"name": "WeArkMedia",
"image": "https://wearkmedia.nl/kantoor.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Vredenburg 40",
"addressLocality": "Utrecht",
"postalCode": "3511 BD",
"addressCountry": "NL"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 52.0907,
"longitude": 5.1214
},
"telephone": "+31-30-1234567",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "17:30"
}
],
"priceRange": "€€€"
}
El ejemplo mantiene la dirección real de WeArkMedia en Utrecht (Países Bajos); si tu negocio está en España, sustituye estos campos por los datos de tu local.
Hay dos errores habituales. El primero: se olvidan las coordenadas geo, cuando son justo lo que usan los sistemas para calcular distancias en búsquedas de «lo más cercano». El segundo: el @type suele ser demasiado genérico. No uses LocalBusiness por defecto si existe un subtipo más específico; con un tipo concreto (como Dentist, Accountant o MarketingAgency, cuando esté disponible), Google y los sistemas de IA pueden ajustar mucho mejor la coincidencia con la intención.
Este es justo el tema que desarrollo con más detalle en GEO para negocios locales, donde también explico cómo gestionar varias sedes.
FAQPage: el schema más infravalorado para AEO
Si hay un tipo de schema que influye directamente en si te citan en una respuesta de IA, ese es FAQPage. ¿Por qué? Porque entrega literalmente la estructura de pregunta-respuesta que un modelo de lenguaje necesita para reutilizar tu contenido en su propia respuesta, a menudo palabra por palabra.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "¿Cuánto cuesta una web nativa de IA?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Una web nativa de IA se entrega por fases. El coste depende del número de páginas, del número de idiomas y de las integraciones con sistemas existentes. Pide un presupuesto basado en tu propio alcance, con horas por fase."
}
},
{
"@type": "Question",
"name": "¿Los datos estructurados funcionan también sin un equipo técnico?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Sí. La mayoría de los CMS y frameworks permiten añadir JSON-LD mediante plugins o fragmentos de código sencillos. No necesitas un desarrollador dedicado para implementar el schema de Organization o FAQPage."
}
}
]
}
La trampa aquí es rellenar el schema FAQPage con preguntas de marketing («¿Por qué elegirnos?») en lugar de con preguntas que la gente hace de verdad a un buscador o a un asistente de IA. Fíjate en la sección «People Also Ask» de Google o prueba tú mismo en ChatGPT y Perplexity qué preguntas aparecen sobre tu tema. Redacta respuestas que se entiendan por sí solas: una respuesta debe ser comprensible sin volver a leer la pregunta, porque así es exactamente como un modelo de lenguaje la extrae.
Lo he desarrollado con más detalle en la guía práctica de AEO, incluida la forma de decidir qué preguntas vale la pena responder.
De un archivo suelto a un sistema que funciona: implementación práctica
¿Dónde colocas esto en tu código?
Si ya tienes un lib/schemas.ts (o algo parecido), la estructura lógica es exportar funciones que generen objetos JSON-LD a partir de tu contenido, no cadenas estáticas. Algo así:
// lib/schemas.ts
export function generateOrganizationSchema() {
return {
"@context": "https://schema.org",
"@type": "Organization",
name: "WeArkMedia",
url: "https://wearkmedia.nl",
// ...
};
}
export function generateFAQSchema(faqs: { question: string; answer: string }[]) {
return {
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: faqs.map((faq) => ({
"@type": "Question",
name: faq.question,
acceptedAnswer: {
"@type": "Answer",
text: faq.answer,
},
})),
};
}
Esto evita que tus schemas se desvinculen de tu contenido, un problema muy habitual cuando se actualiza el texto de las FAQ en la página pero el schema que hay detrás no crece al mismo ritmo. La incoherencia entre el contenido visible y los datos del schema es justo lo que no quieres: socava la confianza tanto de Google como de los crawlers de IA.
Prueba y valida antes de publicar
Usa Rich Results Test de Google y el validador de Schema.org antes de publicar nada. Un error muy común es una errata en @type (por ejemplo, Organisation con ortografía británica en lugar de Organization): el schema falla en silencio, sin mostrar ningún error en tu web, y solo te das cuenta cuando te preguntas por qué nada funciona.
Tampoco olvides comprobar que tu robots.txt no esté bloqueando a los crawlers de IA que precisamente deberían leer estos datos. Consulta la guía de robots.txt para crawlers de IA si tienes dudas sobre si tu configuración es correcta.