El schema markup son datos estructurados, normalmente en JSON-LD, que explican a un sistema qué es el contenido de una página sin que tenga que deducirlo. Para IA su valor es quitar ambigüedad: dejar claro quién eres, qué ofreces y cómo se conectan tus páginas. Lo que no hace es garantizar que aparezcas en ChatGPT, Perplexity o Gemini, y conviene decirlo desde el principio. Este es el criterio con el que lo implemento en mi sitio como parte del posicionamiento en IA.

Qué dice Google

La introducción de Google a los datos estructurados deja cuatro cosas claras:

  • Sirven para que Google interprete la página, y bien implementados pueden mejorar su apariencia en los resultados.
  • El formato recomendado es JSON-LD, por ser más sencillo de implementar y mantener.
  • No garantizan que una página aparezca como resultado enriquecido.
  • Deben coincidir con el contenido visible. No conviene marcar información que los usuarios no pueden ver, y es preferible incluir pocas propiedades recomendadas pero completas y precisas que muchas con datos incorrectos.

Sobre las funciones de IA de la Búsqueda, la documentación de Google indica que no hace falta añadir marcado especial ni datos estructurados específicos para aparecer en ellas; recomienda verificar que tus datos estructurados coincidan con el texto visible. Por eso no te prometo que un schema te haga aparecer en una respuesta de IA.

Los schemas que implemento y para qué

Person: quién eres

Es el que más trabajo, porque define a la persona detrás del sitio. Con @id le doy un identificador único que conecto desde el resto de las páginas; con knowsAbout declaro los temas de mi especialidad; con sameAs enlazo mis perfiles verificados; y con url apunto a la página que me describe, en mi caso /quien-soy, la misma que enlazo en la firma de cada artículo. Un ejemplo mínimo:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://www.tudominio.com/#person",
  "name": "Tu nombre",
  "url": "https://www.tudominio.com/sobre-mi",
  "jobTitle": "Tu cargo",
  "knowsAbout": ["SEO técnico", "Meta Ads"],
  "sameAs": ["https://www.linkedin.com/in/tu-perfil"]
}

Incluye solo datos que puedas verificar. Por eso quité de mi propio schema una propiedad que no podía respaldar.

Article: qué es cada artículo

Cada post lleva author, datePublished y dateModified. El autor referencia a la misma entidad Person, y las fechas deben ser reales: actualizar dateModified sin cambiar el contenido es engañar, no ayudar.

Service: qué ofreces

Define cada servicio, con areaServed y provider, y lo conecta con la misma entidad.

FAQPage: preguntas y respuestas

Lo uso porque empareja preguntas reales con respuestas directas y ordena el contenido para cualquier lector. No lo presento como una vía asegurada hacia las respuestas de IA: Google no lo exige para sus funciones de IA, y no he medido ese efecto.

Cómo implementarlo bien

  1. Usa JSON-LD, no microdatos.
  2. Genera los schemas con funciones reutilizables en lugar de escribirlos a mano en cada página.
  3. Conecta las entidades con @id, para que el Person, el Service y el Article pertenezcan a la misma marca.
  4. Mantén el schema consistente con el contenido visible y con el enlace del autor.
  5. Prefiere pocas propiedades completas a muchas dudosas.

Cómo validarlo

Pasa cada tipo de página por la prueba de resultados enriquecidos de Google y revisa los informes de estado de Search Console después de publicar. Para comprobar si un asistente te reconoce, pregúntale directamente y repite la prueba varios días: una respuesta aislada no es una medición.

Relacionados:

Fuentes