Datos estructurados para médicos, clínicas y especialidades

Los datos estructurados permiten describir de forma explícita quién presta un servicio de salud, qué especialidad ofrece, dónde atiende y cómo se relacionan sus páginas. En Chile, una implementación correcta puede complementar el posicionamiento orgánico y el SEO local de médicos, clínicas, centros médicos y consultas particulares.

La expresión schema para medicos y clinicas suele utilizarse para referirse al marcado basado en Schema.org. Sin embargo, no basta con copiar un bloque genérico: cada tipo debe corresponder a la entidad visible en la página y sus propiedades deben coincidir con información real, verificable y actualizada.

Google distingue entre las propiedades que reconoce para determinadas funciones de búsqueda y el conjunto más amplio de tipos y propiedades disponibles en Schema.org. Por eso, la documentación del Centro de la Búsqueda de Google debe ser la referencia para saber cómo puede comportarse el marcado en sus resultados, mientras que Schema.org sirve como vocabulario general para describir entidades y relaciones (Google, Introducción al funcionamiento del marcado de datos estructurados).

Qué es el schema para médicos y clínicas y por qué importa en Chile

Schema.org es un vocabulario estandarizado que permite representar entidades como personas, organizaciones, ubicaciones, servicios, artículos y eventos. En un sitio de salud, puede ayudar a separar conceptualmente:

• El médico o profesional que presta la atención.
• La clínica, consulta o centro médico.
• La especialidad o servicio ofrecido.
• La sede y sus datos de contacto.
• Los artículos informativos y sus responsables editoriales.
• Las preguntas frecuentes relacionadas con una página.
• Las relaciones entre profesionales, organizaciones, servicios y ubicaciones.

Los datos estructurados no reemplazan el contenido visible, la arquitectura web, la velocidad de carga, la accesibilidad ni la calidad editorial. Tampoco garantizan una posición determinada ni la aparición de un resultado enriquecido. Google indica que la implementación debe cumplir sus directrices y que, aun cuando el marcado sea válido, no existe garantía de que se muestre una función especial en los resultados (Centro de la Búsqueda de Google).

Diferencia entre Schema.org y los resultados enriquecidos

Conviene separar tres conceptos:

1. Vocabulario: Schema.org define tipos y propiedades como Physician, MedicalClinic, Dentist, MedicalService o MedicalSpecialty.
2. Sintaxis: el vocabulario puede expresarse, entre otros formatos, mediante JSON-LD, Microdata o RDFa. La documentación de Google explica los formatos admitidos para sus funciones de búsqueda (Google, Introducción al marcado).
3. Función de búsqueda: Google decide si un contenido puede optar a una apariencia determinada según sus propias políticas, requisitos técnicos y evaluación del contenido.

Por lo tanto, una clínica puede tener un marcado válido en Schema.org sin que eso implique necesariamente estrellas, preguntas desplegables u otro elemento visual en Google.

Por qué es especialmente útil para negocios de salud

Los sitios de médicos y clínicas suelen combinar información institucional, perfiles profesionales, servicios, ubicaciones y contenidos informativos. Sin una estructura semántica clara, un buscador debe inferir esas relaciones a partir del texto, los enlaces y la arquitectura de la página.

El marcado permite expresar relaciones de manera más precisa. Por ejemplo:

• Una persona es un médico.
• Ese médico trabaja para una organización.
• La organización atiende en una dirección determinada.
• La clínica ofrece una especialidad.
• Una página de servicio explica un procedimiento o prestación.
• Un artículo fue escrito o revisado por un profesional identificado.

En el sector sanitario, la exactitud es prioritaria. No se deben añadir credenciales, afiliaciones, certificaciones, servicios o reseñas que no estén visibles y respaldados por información real. Un artículo de Schema App recomienda incluir, cuando corresponda, la autoridad que reconoce o regula un servicio médico, junto con estudios o referencias relevantes (Medical Service Page Best Practices).

Aplicación al contexto chileno

Para una empresa de servicios de salud en Chile, la implementación debería considerar, como mínimo:

• Nombre comercial y razón social cuando corresponda.
• RUT únicamente si existe una razón clara para publicarlo y se cuenta con autorización para hacerlo.
• Teléfono con código de país +56.
• Dirección completa de la sede.
• Comuna, ciudad y región correctamente escritas.
• País como CL o Chile, según el formato esperado por la propiedad.
• Horarios reales de atención.
• Enlaces a perfiles oficiales, como sitio institucional o perfiles profesionales verificables.
• Consistencia con Google Business Profile, directorios sanitarios y otras fuentes propias.

El marcado debe reflejar la realidad del negocio. Si una clínica tiene varias sedes, no conviene reutilizar una única dirección en todas las páginas: cada ubicación debe modelarse según corresponda y mantener una relación clara con la organización principal.

Tipos de datos estructurados para médicos, clínicas y especialidades

El tipo correcto depende de la entidad que describe la página. No existe un único schema universal para todas las páginas de salud.

Physician: para el perfil de un médico

Physician es un tipo de Schema.org destinado a describir a un médico. La documentación oficial contempla tipos más específicos, como IndividualPhysician y PhysiciansOffice, según el caso (Schema.org, Physician).

Puede utilizarse en una página individual que muestre información como:

• Nombre completo.
• Fotografía profesional.
• Especialidad.
• Descripción de experiencia.
• Lugares donde atiende.
• Organización o clínica asociada.
• Teléfono o mecanismo de contacto publicado.
• Enlaces a perfiles oficiales mediante sameAs.
• Horarios o disponibilidad, si están realmente informados.

La página debe contener esos datos de forma visible. No es recomendable crear un perfil marcado para un profesional que solo aparece mencionado brevemente en una página de equipo.

Una estructura conceptual habitual sería:

• Physician para la persona.
• worksFor para la clínica u organización.
• medicalSpecialty para la especialidad.
• workLocation o una relación equivalente para el lugar de atención, siempre validando el dominio y rango de cada propiedad en Schema.org.

Dentist: para dentistas y clínicas dentales

En una clínica dental, Dentist puede ser más específico que utilizar solamente un tipo médico genérico. En una consulta de soporte de Google sobre una clínica dental se señala precisamente que, aunque un tipo general pueda ser válido, Schema.org dispone de tipos más específicos para dentistas (Colocar datos estructurados para una clínica dental).

Esto no significa que todas las páginas de una clínica dental deban utilizar Dentist. La elección depende de lo que realmente describe la URL:

• Perfil de una persona dentista: Dentist puede ser apropiado.
• Organización con varias áreas y profesionales: puede ser necesario combinar una organización sanitaria con perfiles individuales.
• Página de un tratamiento o servicio dental: conviene describir el servicio y relacionarlo con su proveedor.
• Sede física: se debe modelar la ubicación con sus propios datos locales.

MedicalClinic: para una clínica o centro médico

MedicalClinic resulta apropiado cuando la página representa una clínica, consulta o centro de atención médica como entidad organizacional o local.

Las propiedades habituales pueden incluir:

• name
• url
• logo
• image
• telephone
• address
• geo
• openingHoursSpecification
• medicalSpecialty
• sameAs
• parentOrganization o subOrganization, cuando corresponda

No todas las propiedades son obligatorias en todos los contextos. Además, la validez sintáctica no asegura que una propiedad sea útil para Google. Se debe verificar cada propiedad en la documentación del tipo y en la documentación específica de la Búsqueda.

Para una clínica con varias sucursales, una arquitectura razonable puede considerar:

• Una entidad principal para la organización.
• Una entidad por sede.
• Una relación explícita entre organización y sede.
• Una página individual para cada ubicación cuando tenga información suficiente y diferenciada.

MedicalOrganization: para la organización sanitaria

MedicalOrganization puede servir como base cuando la página representa una organización del ámbito de la salud y no existe un subtipo más preciso que refleje mejor el caso.

Debe evitarse escoger tipos por intuición comercial. Por ejemplo, una empresa que vende insumos médicos no necesariamente debe marcarse como clínica. El tipo debe corresponder a la entidad que aparece en el contenido, sus funciones y la información que puede verificarse.

La documentación oficial de Schema.org mantiene un listado amplio de tipos y propiedades disponibles. Antes de implementar, conviene revisar el tipo más específico que corresponda a la organización, profesional o servicio (Schema.org, documentación completa).

MedicalService, MedicalProcedure, MedicalTest y MedicalTherapy

Las páginas de especialidades y prestaciones pueden requerir tipos relacionados con servicios médicos. La elección depende del contenido:

• MedicalService: para un servicio de salud descrito como prestación.
• MedicalProcedure: para un procedimiento médico.
• MedicalTest: para un examen o prueba.
• MedicalTherapy: para una terapia o intervención descrita en términos apropiados para el contenido.

Una página de servicio debería indicar claramente:

• Qué servicio representa.
• Quién lo ofrece.
• En qué ubicación está disponible.
• Qué especialidad se relaciona con él.
• Qué autoridad o institución reconoce el servicio, si corresponde.
• Qué referencias o estudios respaldan el contenido informativo.

Schema App recomienda considerar nombre, código médico cuando exista, autoridad reconocedora, estudios relevantes, ubicaciones, proveedores y contenido adicional para páginas de servicios médicos (Medical Service Page Best Practices).

No se deben inventar códigos médicos, aprobaciones regulatorias ni referencias. Si un dato no está disponible o no es necesario, es preferible omitirlo.

Article y autoría profesional

Para el blog de una clínica, Article puede ayudar a representar el contenido editorial. La página debería identificar de manera visible:

• Autor.
• Fecha de publicación o modificación, si se muestran.
• Título.
• Imagen principal, cuando corresponda.
• Organización editorial.
• Profesional que revisó el contenido, solo si efectivamente realizó esa revisión.

El marcado no reemplaza una política editorial ni convierte automáticamente un texto en contenido médico confiable. En temas sanitarios, la transparencia sobre autoría, fuentes y revisión profesional debe existir en el contenido visible, no solo en el código.

FAQPage: uso limitado y sin promesas de visibilidad

FAQPage puede representar una página de preguntas y respuestas frecuentes cuando las preguntas y respuestas están visibles para los usuarios. No debe utilizarse para ocultar contenido, añadir preguntas irrelevantes o repetir bloques en muchas URLs.

La elegibilidad y apariencia de las funciones de preguntas frecuentes dependen de las políticas y documentación de Google. Por eso, debe implementarse como una representación semántica del contenido real, no como una táctica para garantizar más espacio en los resultados (Google, Introducción al marcado).

Reseñas y AggregateRating

Las reseñas requieren especial cuidado en negocios locales y servicios de salud. No se deben marcar calificaciones:

• Copiadas desde una plataforma sin autorización o sin correspondencia clara.
• Generadas por el propio negocio.
• Sin una fuente verificable.
• Que no estén visibles en la página.
• Que mezclen opiniones de diferentes sedes o servicios sin explicación.

Aunque Schema.org contemple propiedades de valoración, la posibilidad de mostrar estrellas depende de los requisitos de Google y de sus políticas. Una valoración estructurada no garantiza una apariencia enriquecida. El contenido debe ser auténtico, verificable y coherente con la experiencia que se presenta en la página (Google, Introducción al marcado).

Guía de implementación en sitios de salud chilenos

1. Inventariar las entidades del sitio

Antes de escribir código, crea un inventario de URLs y entidades:

URL o sección	Entidad principal	Tipo posible
Página principal	Organización	MedicalClinic o MedicalOrganization
Perfil profesional	Médico	Physician o Dentist
Página de sede	Ubicación	Organización local o entidad de sede
Página de especialidad	Servicio o especialidad	MedicalService y MedicalSpecialty
Página de procedimiento	Procedimiento	MedicalProcedure
Página de examen	Examen	MedicalTest
Artículo informativo	Contenido editorial	Article
Preguntas frecuentes	Preguntas y respuestas	FAQPage

La tabla es una guía inicial, no una asignación automática. El tipo definitivo debe revisarse según el contenido visible y la documentación de Schema.org.

2. Definir una identidad estable con @id

Cuando se utiliza JSON-LD, es recomendable asignar identificadores estables a las entidades. Así, el profesional de una página de perfil puede relacionarse con el mismo profesional mencionado en un artículo o en una página de especialidad.

Ejemplo conceptual, sin etiqueta script:

{
  "@context": "https://schema.org",
  "@type": "Physician",
  "@id": "https://www.ejemplo.cl/profesionales/nombre-apellido#physician",
  "name": "Nombre Apellido",
  "url": "https://www.ejemplo.cl/profesionales/nombre-apellido",
  "medicalSpecialty": "Especialidad publicada en el perfil",
  "worksFor": {
    "@id": "https://www.ejemplo.cl/#organization"
  }
}

Este ejemplo es ilustrativo. Los nombres, URLs, especialidades y relaciones deben reemplazarse por datos reales. No conviene reutilizar un @id si identifica entidades distintas ni modificarlo de forma arbitraria después de cada publicación.

3. Implementar primero la organización y las sedes

La página principal debería explicar claramente:

• Nombre de la clínica o centro.
• Servicios principales.
• Comunas o ciudades atendidas.
• Teléfonos y canales de contacto.
• Enlaces a sedes.
• Enlaces a perfiles oficiales.
• Horarios de atención.

Para una dirección chilena, revisa la separación entre:

• Calle y número.
• Oficina, piso o local.
• Comuna.
• Ciudad.
• Región.
• Código postal, si está disponible y es correcto.
• País.

No agregues coordenadas geográficas estimadas. Si se utiliza geo, debe corresponder a la sede real.

4. Relacionar profesionales, servicios y ubicaciones

Una implementación útil no consiste en añadir muchos bloques independientes, sino en construir relaciones coherentes:

• La clínica ofrece una especialidad.
• El profesional presta un servicio.
• El servicio está disponible en una sede.
• El artículo explica un tema relacionado y tiene un autor identificable.
• La página de contacto representa la misma organización que la página principal.

Estas relaciones pueden expresarse mediante propiedades como provider, employee, worksFor, availableService, location o subjectOf, siempre que sean válidas para el tipo utilizado. La compatibilidad entre tipos y propiedades debe verificarse en Schema.org y en el validador correspondiente.

5. Mantener consistencia con el SEO local

Los datos estructurados deben coincidir con:

• Nombre visible en el sitio.
• Ficha de Google Business Profile.
• Dirección publicada en la señalética y canales oficiales.
• Teléfono vigente.
• Horarios de atención.
• Nombre de cada sede.
• URLs canónicas.
• Reseñas y valoraciones mostradas.

Si una sede cambia de comuna, teléfono u horario, la actualización debe propagarse a todas las capas relevantes. El marcado antiguo puede crear contradicciones con el contenido visible y con otras fuentes locales.

Esta revisión puede formar parte de un servicio de Posicionamiento Orgánico y SEO, especialmente cuando incluye SEO local, Search Console, sitemap XML, rendimiento y consistencia de datos de negocio.

6. Elegir el método de integración

En la mayoría de los sitios, JSON-LD facilita la separación entre contenido y marcado. Puede integrarse desde:

• Un CMS mediante campos estructurados.
• Plantillas del sitio.
• Un sistema de componentes.
• Un desarrollo web a medida.
• Una capa de generación desde una base de datos interna.

La fuente de datos debe estar centralizada. Si el teléfono se cambia manualmente en cinco plantillas distintas, es probable que alguna quede desactualizada.

En un desarrollo web a medida, conviene definir:

• Modelo de entidades.
• Reglas para generar @id.
• Campos obligatorios por plantilla.
• Reglas de normalización de teléfono y dirección.
• Control de duplicados.
• Entorno de pruebas.
• Registro de cambios.
• Revisión después de migraciones o rediseños.

El marcado no debe construirse desde campos que permitan inyección de contenido sin validación. Las entradas provenientes del CMS deben limpiarse y escaparse según el método de serialización utilizado.

7. Evitar errores comunes de implementación

Los problemas más habituales son:

• Marcar una clínica como un profesional.
• Usar Dentist para una organización que no representa a un dentista.
• Añadir servicios que no aparecen en la página.
• Publicar horarios antiguos.
• Repetir una misma dirección en todas las sedes.
• Crear varias entidades para la misma clínica sin relaciones.
• Añadir AggregateRating sin reseñas verificables.
• Marcar preguntas que no están visibles.
• Utilizar datos de prueba en producción.
• Generar JSON-LD roto por comillas o caracteres especiales.
• Mantener el schema después de eliminar una sección visible.
• Incluir una fecha de modificación que no corresponde a una actualización real.

Un equipo externo puede apoyar estos cambios mediante Desarrollo Web, incluyendo implementación responsiva, CMS, pruebas de rendimiento, accesibilidad, SSL y configuración técnica.

Checklist técnico para validar propiedades, datos locales y errores antes de publicar

Entidad y tipo

• La página tiene una entidad principal claramente identificable.
• El tipo elegido representa lo que la página muestra.
• Se revisó si existe un subtipo más específico, como Physician, Dentist o MedicalClinic.
• No se mezclaron tipos incompatibles.
• Cada @id identifica una entidad única y estable.
• Las relaciones entre organización, profesional, servicio y sede son comprensibles.
• Las propiedades utilizadas pertenecen al tipo correspondiente.
• No se añadieron propiedades solo porque aparecen en un ejemplo de otro tipo.

Contenido visible y exactitud

• El nombre del médico o clínica coincide con el contenido visible.
• La especialidad aparece realmente en la página.
• El teléfono está vigente.
• La dirección corresponde a la sede correcta.
• Los horarios marcados coinciden con los publicados.
• Los servicios estructurados están descritos en la página.
• La autoría de los artículos es visible.
• La revisión profesional solo se declara cuando ocurrió.
• Las reseñas y calificaciones tienen una fuente verificable.
• No se añadieron credenciales, certificaciones o afiliaciones no comprobadas.

Datos locales para Chile

• El teléfono utiliza el formato nacional apropiado, idealmente incluyendo +56.
• La dirección incluye calle, número y comuna cuando corresponda.
• La región y ciudad no están intercambiadas.
• La sede tiene una URL propia si dispone de información diferenciada.
• Las coordenadas, si se utilizan, corresponden a la ubicación real.
• Los datos coinciden con Google Business Profile y otros perfiles oficiales.
• Las sedes no comparten accidentalmente el mismo teléfono o dirección.
• Los horarios especiales y feriados no contradicen la información visible.
• El nombre comercial y la razón social no se confunden.

Validación del código

• El JSON-LD es sintácticamente válido.
• No existen comas finales, comillas sin cerrar ni caracteres mal escapados.
• Las URLs son absolutas, canónicas y utilizan HTTPS.
• Los enlaces no apuntan a páginas eliminadas o redireccionamientos innecesarios.
• El marcado se probó en el validador de Schema.org.
• El marcado se probó en las herramientas de resultados enriquecidos de Google cuando corresponda.
• Se revisaron advertencias y errores, no solo la ausencia de errores críticos.
• Se comprobó el HTML renderizado y no únicamente el código fuente inicial.
• Se verificó la versión móvil.
• Se revisó que no existan bloques duplicados generados por plugins o plantillas.

El validador de Schema.org ayuda a comprobar si la estructura utiliza tipos y propiedades reconocibles. Para evaluar posibles funciones de Google, se debe utilizar además la documentación y las herramientas del Centro de la Búsqueda, porque Schema.org y Google no tienen exactamente el mismo alcance (Google, Introducción al marcado).

Pruebas de publicación

• Se validó primero en un entorno de prueba.
• Se comparó el marcado antes y después de desplegar.
• Se inspeccionó una URL de cada tipo de plantilla.
• Se revisaron páginas de profesionales, sedes, especialidades y artículos.
• Se solicitó una nueva inspección en Search Console cuando el cambio lo justifica.
• Se monitorizaron errores posteriores a cambios de CMS, diseño o migraciones.
• Se documentó quién mantiene los datos.
• Existe un procedimiento para actualizar teléfonos, horarios, sedes y profesionales.

Revisión de accesibilidad, rendimiento y adquisición

Los datos estructurados no deben afectar negativamente la experiencia del usuario. Antes de publicar, comprueba también:

• El contenido principal se carga sin depender de interacciones complejas.
• Los botones de contacto son identificables por teclado y lectores de pantalla.
• La información de sede se entiende sin depender solo de un mapa.
• Las imágenes tienen textos alternativos cuando corresponde.
• La página mantiene buenos tiempos de carga.
• El formulario de contacto informa claramente qué datos solicita.
• Los enlaces hacia cotización, reserva o contacto son visibles.
• La información comercial no confunde una solicitud de cotización con una urgencia médica.
• La captación de datos respeta las políticas internas de privacidad y seguridad.

En una pyme, consulta privada o clínica en crecimiento, una arquitectura ordenada permite conectar el marcado con el CMS, los formularios, la agenda y los canales comerciales sin duplicar información. Si además existe una tienda de productos o prestaciones, conviene separar correctamente las páginas institucionales, los servicios, la cotización, la boleta o factura electrónica y la pasarela de pago como Webpay / Transbank. El schema de una organización sanitaria no debe utilizarse para describir automáticamente cualquier proceso comercial.

Implementar schema para medicos y clinicas exige más que añadir un bloque de código: requiere modelar entidades reales, mantener consistencia local, escoger tipos específicos, validar propiedades y revisar el contenido después de cada cambio. Cuando esa base se integra con una estrategia de posicionamiento orgánico, SEO local y desarrollo web a medida, el sitio queda mejor preparado para ser interpretado por buscadores y por otras herramientas que consumen datos estructurados, sin prometer resultados automáticos ni sustituir la calidad de la información publicada.