Cuando un equipo de marketing de seguros me pregunta por schema, casi siempre la pregunta viene con una expectativa: "¿qué marcado tengo que poner para que me salgan estrellitas en Google?". La respuesta corta es que en seguros no hay estrellitas que ganar. Y la respuesta larga es que el schema igual vale la pena, por razones que tienen más que ver con cómo Google y la IA entienden quién eres y qué vendes.
Esta guía explica qué tipos de datos estructurados tienen sentido para una aseguradora, un broker o una insurtech, con ejemplos en JSON-LD que tu equipo de desarrollo puede adaptar. Y parte por lo que cambió este año, porque buena parte de las guías que rankean hoy para "schema para seguros" quedaron desactualizadas.
¿Qué cambió en los datos estructurados en 2026?
El 7 de mayo de 2026 Google dejó de mostrar resultados enriquecidos de FAQ en la búsqueda. Fue el cierre de un proceso que empezó en agosto de 2023, cuando Google limitó esos resultados a sitios de gobierno y salud y eliminó los de HowTo. Según reportó Search Engine Journal, en junio se retiraron el filtro y el informe de FAQ en Search Console, y el soporte en la API de Search Console terminó en agosto.
Lo importante para una aseguradora: el marcado FAQPage sigue siendo válido. La documentación de Google dice que puede quedarse en el sitio sin causar problemas, aunque ya no produzca resultados visibles. Entonces la pregunta útil pasa a ser qué schema ayuda a que los buscadores y los motores de respuesta entiendan tu producto sin ambigüedades.
¿Para qué sirve el schema en una aseguradora si no da resultados enriquecidos?
Para tres cosas concretas.
Identidad de marca. El marcado Organization le dice a Google cuál es tu nombre legal, tu logo, tus perfiles oficiales y tus datos de contacto. En un mercado donde hay aseguradoras con nombres parecidos, filiales de grupos internacionales y bancos que venden seguros de terceros, esa claridad evita confusiones en el panel de conocimiento y en las respuestas de IA.
Relación entre entidades. Qué producto pertenece a qué compañía, qué persona escribió y revisó cada contenido, qué página es la oficial de cada producto. Son relaciones que un humano deduce leyendo, pero que un sistema automático agradece tener explícitas.
Señales de confianza en contenido YMYL. Seguros es una categoría Your Money or Your Life. Marcar autor, revisor y fecha de revisión no es un factor de ranking directo, pero sí conecta la página con información verificable sobre la experiencia de quien está detrás.
Una aclaración honesta: no hay evidencia pública sólida de que ChatGPT o Perplexity lean el JSON-LD de forma directa al armar sus respuestas. Lo que sí sabemos es que Google usa los datos estructurados para entender el contenido, y que los AI Overviews se apoyan en el índice de Google. El schema es una pieza más de un contenido bien hecho, y no va a arreglar una página de producto que no explica qué cubre.
¿Qué tipos de schema.org usar en una aseguradora?
schema.org no tiene un tipo específico para "póliza de seguro" ni para "compañía de seguros". Hubo propuestas en la comunidad de schema.org para crear un tipo Insurance como subtipo de FinancialProduct, pero hasta hoy no se ha incorporado. Así que se trabaja con los tipos existentes:
| Qué quieres marcar | Tipo recomendado | Dónde va |
|---|---|---|
| La compañía | Organization (o Corporation) | Home y página "Quiénes somos" |
| Un broker o agencia con oficinas | InsuranceAgency | Home y fichas de sucursal |
| Un producto de seguro | FinancialProduct | Página de producto |
| Planes y precios referenciales | Offer dentro de FinancialProduct | Página de producto |
| Preguntas frecuentes | FAQPage | Página de producto o de ayuda |
| Artículos y guías | Article con author (Person) | Blog y centro de ayuda |
| Revisión experta | WebPage con reviewedBy y lastReviewed | Páginas de producto y guías |
| Navegación | BreadcrumbList | Todo el sitio |
InsuranceAgency es un subtipo de FinancialService y, a su vez, de LocalBusiness, pensado para agencias y corredores con presencia física. Para una aseguradora que vende de forma directa y no atiende público en sucursales, Organization suele ser más apropiado.
Schema de organización para una aseguradora
Este es el marcado base, que va en la home. Nota el uso de @id: permite que las demás páginas del sitio hagan referencia a la organización sin repetir todos los datos.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.aseguradora-ejemplo.cl/#organizacion",
"name": "Aseguradora Ejemplo",
"legalName": "Compañía de Seguros Generales Ejemplo S.A.",
"url": "https://www.aseguradora-ejemplo.cl/",
"logo": "https://www.aseguradora-ejemplo.cl/logo.png",
"taxID": "76.XXX.XXX-X",
"sameAs": [
"https://www.linkedin.com/company/aseguradora-ejemplo",
"https://www.instagram.com/aseguradoraejemplo"
],
"contactPoint": {
"@type": "ContactPoint",
"contactType": "siniestros",
"telephone": "+56-600-XXX-XXXX",
"areaServed": "CL",
"availableLanguage": "es"
}
}
El contactPoint de siniestros es un detalle útil: es uno de los datos que más se busca junto al nombre de la marca, y conviene que la información oficial esté explícita.
Schema para coberturas y planes de un seguro
Acá está la parte más interesante. FinancialProduct es un subtipo de Service, así que hereda propiedades como provider, areaServed, category y hasOfferCatalog. Con eso se puede describir el producto, sus coberturas y sus planes.
{
"@context": "https://schema.org",
"@type": "FinancialProduct",
"@id": "https://www.aseguradora-ejemplo.cl/seguro-auto/#producto",
"name": "Seguro de Auto Full Cobertura",
"description": "Cubre daños propios, robo, pérdida total y responsabilidad civil hasta UF 1.000. Deducible desde UF 0.",
"category": "Seguro automotriz",
"url": "https://www.aseguradora-ejemplo.cl/seguro-auto/",
"provider": { "@id": "https://www.aseguradora-ejemplo.cl/#organizacion" },
"areaServed": { "@type": "Country", "name": "Chile" },
"hasOfferCatalog": {
"@type": "OfferCatalog",
"name": "Coberturas incluidas",
"itemListElement": [
{ "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Daños propios" } },
{ "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Robo y hurto" } },
{ "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Responsabilidad civil hasta UF 1.000" } }
]
},
"offers": [
{
"@type": "Offer",
"name": "Plan deducible UF 3",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "0.95",
"priceCurrency": "CLF",
"unitText": "mes",
"description": "Prima mensual referencial desde UF 0,95 para autos de hasta 5 años"
}
}
]
}
Dos advertencias. La primera: cualquier precio marcado tiene que coincidir con lo que aparece visible en la página. Si publicas "desde UF 0,95" en el schema, tiene que estar escrito así en el HTML. La segunda: "CLF" es el código ISO 4217 de la Unidad de Fomento, lo que evita que un sistema interprete el monto como pesos. En Perú usarías "PEN" para soles o "USD" si el producto se comercializa en dólares.
Sobre las exclusiones: no existe una propiedad estándar para "qué no cubre". Lo recomendable es mantenerlas en el HTML visible, con lenguaje claro, y si tienes un bloque de preguntas frecuentes, incluir una pregunta del tipo "¿Qué no cubre este seguro?" en el FAQPage.
Schema de FAQ en seguros después de mayo de 2026
¿Vale la pena seguir marcando las preguntas frecuentes? Mi recomendación es sí, siempre que la página tenga preguntas reales visibles y las respuestas estén bien escritas. El marcado no molesta, deja explícita la estructura de pregunta y respuesta, y puede ser útil para otros buscadores y sistemas que lean datos estructurados.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "¿El seguro me cubre si otra persona maneja mi auto?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Sí, si el conductor tiene licencia vigente. Si es menor de 25 años, el deducible aumenta a UF 15, según el artículo 8 de la póliza."
}
}
]
}
Lo que no conviene hacer es inventar FAQs solo para tener marcado, ni poner preguntas en el JSON-LD que no aparecen en la página.
Schema de autor y revisión experta
En seguros, esta es la parte que más recomiendo trabajar. Un artículo sobre preexistencias en seguros de salud escrito por una persona identificable, y revisado por un médico auditor con nombre y cargo, tiene más respaldo que uno firmado por "Equipo editorial".
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Qué son las preexistencias en un seguro de salud",
"datePublished": "2026-06-10",
"dateModified": "2026-09-01",
"author": {
"@type": "Person",
"name": "Carolina Pérez",
"jobTitle": "Especialista en seguros de salud",
"worksFor": { "@id": "https://www.aseguradora-ejemplo.cl/#organizacion" },
"url": "https://www.aseguradora-ejemplo.cl/autores/carolina-perez",
"sameAs": ["https://www.linkedin.com/in/carolina-perez-ejemplo"]
},
"publisher": { "@id": "https://www.aseguradora-ejemplo.cl/#organizacion" }
}
Para la revisión técnica, la propiedad reviewedBy pertenece a WebPage (no a Article), junto con lastReviewed. Se puede marcar en la página que contiene el artículo:
{
"@context": "https://schema.org",
"@type": "WebPage",
"url": "https://www.aseguradora-ejemplo.cl/blog/preexistencias-seguro-salud",
"lastReviewed": "2026-09-01",
"reviewedBy": {
"@type": "Person",
"name": "Dr. Andrés Muñoz",
"jobTitle": "Médico auditor"
}
}
Cada autor necesita una página propia en el sitio con su trayectoria, sus áreas de especialidad y enlaces a perfiles externos. El schema apunta a esa página, y esa página es la que le da contenido real a la señal.
¿Qué errores de schema vemos en sitios de seguros?
- Marcar reseñas propias. Google no muestra estrellas para reseñas que una organización publica sobre sí misma (las llamadas reseñas autoatribuidas). Marcar un aggregateRating de testimonios propios no suma y puede considerarse contrario a las directrices.
- Usar Product para un seguro. El tipo Product está pensado para bienes, y los requisitos de los resultados de producto de Google no calzan con una póliza. FinancialProduct describe mejor lo que vendes.
- Precios en el marcado que no están en la página. O peor, precios desactualizados. Si el precio cambia seguido, mejor no marcarlo.
- Schema duplicado o contradictorio. El plugin del CMS genera un Organization, el tema genera otro y el equipo de desarrollo agrega un tercero con otro nombre. Conviene revisar el código fuente de la home y dejar un solo bloque por entidad.
- Marcado de autor sin página de autor. Un nombre en el JSON-LD que no lleva a ninguna parte aporta muy poco.
¿Cómo valido el schema de mi sitio de seguros?
Con dos herramientas gratuitas. El Schema Markup Validator (validator.schema.org) revisa que el marcado sea válido según schema.org, incluidos los tipos que Google no usa para resultados enriquecidos, como FinancialProduct. La Prueba de resultados enriquecidos de Google muestra solo lo que Google puede usar para resultados especiales (Organization, Breadcrumb, Article, entre otros). Usa las dos, porque miden cosas distintas.
Por dónde empezar
Si hoy tu sitio no tiene nada, el orden que recomiendo es: Organization en la home, BreadcrumbList en todo el sitio, FinancialProduct en las cinco páginas de producto con más cotizaciones, y autor y revisor en las guías de salud y vida, que son las más sensibles. Es un trabajo de pocos días para un desarrollador, y deja ordenada la base para todo lo que venga después.
El schema es una de las piezas técnicas del trabajo que hacemos con aseguradoras y brokers, junto con la arquitectura por ramo, las páginas de producto y la medición. Puedes ver el enfoque completo en nuestra página de SEO y GEO para aseguradoras.
Preguntas frecuentes
¿Existe un schema específico para pólizas de seguro?
No. schema.org no tiene un tipo Insurance o InsurancePolicy. Lo más cercano es FinancialProduct, que es el tipo que recomendamos para páginas de producto de seguros.
¿Debo quitar el marcado FAQPage de mi sitio?
No es necesario. Google indicó que el marcado puede quedarse sin causar problemas. Si las preguntas son reales y útiles, mantenerlo no tiene costo.
¿El schema ayuda a aparecer en ChatGPT?
No hay evidencia directa de que ChatGPT lea el JSON-LD. Ayuda de forma indirecta, porque mejora cómo Google entiende tu contenido, y porque obliga a ordenar información (autor, producto, precios, coberturas) que después también mejora el HTML visible. Si quieres ver cómo combinamos schema, contenido y GEO para seguros, lo explicamos en nuestra página de industria.
Fuentes: Google Search Central, "Changes to HowTo and FAQ rich results" (agosto 2023); Search Engine Journal, "Google Drops FAQ Rich Results From Search" (2026); schema.org, tipos FinancialProduct, InsuranceAgency y WebPage; discusión sobre un tipo Insurance en el repositorio de schema.org.