Por Alexander Delgado — CTO, Amedik — Actualizado abril 2026
Tu sitio web médico puede tener el mejor contenido del mundo, pero si Google no sabe que el autor es un médico certificado, ese contenido compite en igualdad de condiciones con un blog anónimo de WordPress. schema.org/Physician es la etiqueta que le dice a Google, en su propio lenguaje, que detrás de ese sitio hay un profesional de la salud con credenciales verificables. Este es el paso a paso para implementarlo en WordPress.
Este artículo es parte del manifiesto de SEO técnico de Amedik, donde explicamos las dos mitades del SEO y por qué sin la parte técnica, la parte de marketing no funciona.
Physician es un tipo de schema.org derivado de MedicalBusiness que le dice a los buscadores: "esta entidad es un médico". No es un título SEO ni una meta description — es datos estructurados que Google lee, procesa y usa para decidir si tu sitio merece aparecer en resultados enriquecidos.
Cuando un cirujano plástico en Medellín tiene schema Physician correctamente implementado, Google puede:
Sin schema, Google tiene que adivinar que tu sitio es de un médico. Con schema, se lo dices explícitamente. Esa es la diferencia entre aparecer como "un sitio más" y aparecer como "el sitio del Dr. Fulano, cirujano plástico certificado, miembro de la SCCP, en Torre Médica Oviedo".
Esto confunde a muchas agencias. Los tres tipos se usan en sitios médicos pero con roles diferentes:
Cuándo: en la home o la página "Sobre el Doctor". Es el tipo principal para un médico individual.
Qué dice: "Esta entidad es un médico con nombre, especialidad, dirección de consultorio, membresías y horario."
Hereda de: MedicalBusiness → LocalBusiness → Organization
Cuándo: como autor de artículos y blogs. Vincula el contenido con la persona que lo firma.
Qué dice: "Este contenido fue escrito por esta persona, que tiene estas credenciales."
Usar con: author dentro de Article. Enlazar al mismo @id del Physician.
Cuándo: para clínicas o centros médicos con múltiples profesionales.
Qué dice: "Este negocio es una entidad de salud con ubicación, servicios y equipo médico."
Diferencia: Physician = un doctor. MedicalBusiness = una clínica.
La implementación ideal para un médico individual es: Physician en la home + Person como autor de los blogs enlazado al mismo @id. Para una clínica: MedicalBusiness en la home + Physician por cada doctor en sus páginas de perfil.
No recomendamos plugins de schema tipo "click and fill". Generan JSON-LD genérico, a menudo incorrecto, y no permiten la granularidad que un sitio médico YMYL necesita. La técnica que usamos en Amedik es un mu-plugin PHP (must-use plugin) que inyecta JSON-LD directamente en el <head> de las páginas correctas.
Conéctate al servidor por SSH y crea un archivo en /wp-content/mu-plugins/:
# Conectar al servidor ssh usuario@servidor -p puerto # Crear el mu-plugin nano /ruta/wp-content/mu-plugins/schema-physician.php
Este es un ejemplo real basado en un cirujano plástico en Medellín. Cada campo tiene un propósito SEO específico:
<?php /** * Schema Physician — Dr. [Nombre] * Inyecta JSON-LD en la home y páginas principales */ add_action('wp_head', function() { if (!is_front_page()) return; $schema = [ '@context' => 'https://schema.org', '@type' => 'Physician', '@id' => 'https://tusitio.com/#physician', 'name' => 'Dr. David Delgado', 'image' => 'https://tusitio.com/foto-doctor.webp', 'url' => 'https://tusitio.com/', 'telephone' => '+573017249759', // Especialidad médica (schema.org/MedicalSpecialty) 'medicalSpecialty' => 'PlasticSurgery', // Dirección real del consultorio 'address' => [ '@type' => 'PostalAddress', 'streetAddress' => 'Torre Médica Oviedo, Piso 7', 'addressLocality' => 'Medellín', 'addressRegion' => 'Antioquia', 'addressCountry' => 'CO', 'postalCode' => '050021', ], // Membresías profesionales (E-E-A-T) 'memberOf' => [ ['@type' => 'MedicalOrganization', 'name' => 'Sociedad Colombiana de Cirugía Plástica'], ['@type' => 'MedicalOrganization', 'name' => 'American Society of Plastic Surgeons'], ], // Geo para SEO local 'geo' => [ '@type' => 'GeoCoordinates', 'latitude' => '6.2008', 'longitude' => '-75.5758', ], // Calificación real de Google (si la tienes) 'aggregateRating' => [ '@type' => 'AggregateRating', 'ratingValue' => '4.9', 'reviewCount' => '55', 'bestRating' => '5', ], ]; echo '<script type="application/ld+json">' . json_encode($schema, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT) . '</script>'; }, 1);
Después de subir el archivo, valida el JSON-LD con dos herramientas:
Herramienta oficial de Google. Pega la URL de la home y verifica que el bloque Physician aparezca sin errores ni advertencias. Si hay campos faltantes, Google te los marca en amarillo.
Valida la sintaxis JSON-LD pura. Útil para verificar que los tipos (Physician, PostalAddress, GeoCoordinates) estén correctamente anidados antes del deploy.
El Physician en la home debe enlazarse con los blogs. Cuando el médico firma un artículo, el schema Article debe referenciar al Physician como autor con el mismo @id:
{
"@type": "Article",
"headline": "Rinoplastia ultrasónica en Medellín",
"author": {
"@type": "Person",
"@id": "https://tusitio.com/#physician",
"name": "Dr. David Delgado"
}
}
El @id es la clave: al ser el mismo en el Physician y en el autor del Article, Google entiende que es la misma entidad. Cada blog que publiques con este @id refuerza la autoridad del Physician en el knowledge graph.
En este video del canal de Amedik mostramos cómo revisamos el schema markup de cada sitio médico antes de entregárselo al cliente, incluyendo la validación de Physician y MedicalBusiness:
Plugins como "Schema Pro" o "Rank Math" generan JSON-LD automático que casi siempre es LocalBusiness genérico, no Physician. Para un sitio YMYL que compite por "cirujano plástico Medellín", la diferencia es significativa. Google quiere ver la especialidad médica, las membresías y las credenciales — no un LocalBusiness genérico que podría ser una peluquería.
El error más común: el Physician tiene un @id en la home, pero los blogs tienen un autor genérico "author": "Admin". Eso rompe el linked data. Google no puede conectar al médico con su contenido. Cada blog firmado por el médico debe referenciar el mismo @id del Physician.
Google penaliza datos estructurados engañosos. Si el médico no es miembro de la SCCP, no lo pongas en memberOf. Si tiene 20 reseñas, no pongas 55 en aggregateRating. Los datos del schema deben ser verificables y coincidir con lo que aparece en la página visible.
Si tu sitio ya tiene AIOSEO o Yoast, estos plugins inyectan su propio @graph con Organization, WebPage y BreadcrumbList. El mu-plugin de Physician debe convivir sin duplicar. La clave: usar @id diferentes y no repetir tipos. Physician en el mu-plugin, Organization en AIOSEO. Validar siempre en Rich Results Test.
MedicalBusiness. Cada página de perfil de cada médico usa Physician con su propio @id. Los blogs se vinculan al Physician que los firma como autor. Es más trabajo, pero cada médico construye su propia autoridad en el knowledge graph.aggregateRating puede causar problemas?aggregateRating no coincide con reseñas reales visibles en la página (Google Business Profile, testimonios verificables), puedes recibir una acción manual. Nuestra recomendación: solo incluirlo si los datos son exactos y verificables. Si no estás seguro, omítelo y deja que Google lo obtenga de tu perfil de Google Business.<head> directo. Webflow permite inyectar JSON-LD en el <head> vía custom code, pero no puedes hacerlo condicional por página sin JavaScript. En WordPress tienes control total: mu-plugin con is_front_page(), is_page(), is_single(). Cada página puede tener su propio schema sin conflictos.En Amedik implementamos schema médico como parte de cada proyecto de SEO técnico. Si quieres saber si tu sitio tiene el schema correcto o necesita corrección, escríbenos.
Hablar con Amedik