Cómo validar schema y corregir 7 errores frecuentes
Para validar el schema de tu web, comprueba el código, la página publicada y los datos que describe. Son tres revisiones distintas: un JSON correcto puede contener un teléfono equivocado, y un marcado válido puede no ser apto para un resultado enriquecido de Google.
Empieza con la URL exacta de una página importante, no solo con la portada. Guarda el resultado, corrige un problema cada vez y vuelve a probar esa misma URL. Aquí tienes siete errores que conviene revisar y cómo resolverlos.
Qué comprueba un validador de datos estructurados
| Revisión | Pregunta que responde | Qué hacer después |
|---|---|---|
| Sintaxis | ¿Se puede leer el JSON? | Corregir comas, comillas y llaves |
| Vocabulario | ¿Se reconocen tipos y propiedades? | Contrastar con Schema.org |
| Requisitos de Google | ¿Cumple los campos de una función compatible? | Usar el test oficial para esa función |
| Exactitud | ¿Los datos coinciden con el negocio y la página? | Revisarlos con la persona responsable |
El Schema Markup Validator y el Test de resultados enriquecidos tienen alcances distintos. La comparativa de validadores explica cuál usar en cada caso.
1. Una coma o unas comillas impiden leer el JSON
En JSON no se admite una coma después de la última propiedad. Por ejemplo, este bloque está mal:
{"@context":"https://schema.org","@type":"Organization","name":"Empresa de ejemplo",}
La versión corregida elimina esa coma:
{"@context":"https://schema.org","@type":"Organization","name":"Empresa de ejemplo"}
Es un ejemplo mínimo para mostrar la sintaxis, no una ficha completa que debas publicar. Si un plugin genera el bloque, corrige sus ajustes o la plantilla que lo produce: editar el HTML de una sola respuesta no cambia la siguiente visita.
2. Confundir un aviso con un campo obligatorio
Un aviso puede recomendar más información sin invalidar el elemento. Un error puede indicar que falta un requisito para una función concreta de Google. No significa que todos los consumidores de Schema.org tengan idénticos requisitos.
Lee el nombre del tipo y la propiedad señalada. Añade el dato solo si existe y corresponde a esa página. No inventes un precio, una reseña o una dirección para conseguir una pantalla verde. Consulta las reglas generales de Google.
3. Teléfono, dirección u horarios que ya no son correctos
Haz una comparación manual entre el marcado, el contenido visible y la información que usa tu equipo. Un validador no sabe si el negocio cerró los sábados el mes pasado.
Una revisión práctica para un restaurante: abre la página de contacto y la carta; compara dirección, teléfono, enlace de reservas y horarios con el JSON-LD. Si hay diferencias, identifica cuál es el dato vigente antes de tocar nada. Actualiza también el sistema que alimenta esa información para que el error no vuelva.
4. Marcar reseñas o servicios que la página no muestra
Un bloque puede ser técnicamente correcto y describir contenido inexistente. No copies el aggregateRating de un ejemplo, ni uses opiniones de otra empresa. La correspondencia con el contenido y las políticas de cada función forman parte de la validación, aunque una herramienta automática no detecte el problema.
Si no puedes justificar el dato, retíralo. Para reseñas, revisa además las normas específicas de Google: mostrar una valoración en tu web no garantiza que sea elegible para estrellas en el buscador.
5. Elegir un tipo que describe otra cosa
Un hotel y una habitación no son la misma entidad. Un artículo que habla de dentistas tampoco es una clínica dental. Usa el tipo que describe el contenido o la entidad real de la página.
Empieza por un tipo general válido y concreta cuando proceda. Organization no es un error por sí mismo; LocalBusiness describe un negocio local y tiene subtipos. En la guía de LocalBusiness tienes un ejemplo de entidad, dirección e identificador.
6. Concluir que no hay schema porque no aparece en el código fuente
Puede haber JSON-LD añadido por JavaScript, Microdata o RDFa. Buscar ld+json en el HTML inicial solo detecta una parte de los casos.
Nuestro validador por URL lee el HTML recibido y extrae sus bloques JSON-LD: no ejecuta la página como un navegador. Si no encuentra nada, comprueba también el HTML renderizado y el test de Google. Google documenta que puede procesar datos estructurados generados con JavaScript. No extrapoles esa capacidad a todos los rastreadores.
7. Varios plugins describen la misma entidad con datos diferentes
Tener varios bloques no es necesariamente un fallo: una página puede describir una organización, un artículo y unas migas de pan. El problema aparece cuando dos fuentes mantienen versiones incompatibles del mismo negocio.
Anota qué bloque genera cada plugin o plantilla, comprueba sus identificadores @id y decide dónde mantener los datos comunes. Antes de desactivar un plugin, revisa si también genera títulos, sitemaps u otras funciones que necesitas. Después comprueba varias páginas, no solo la que tenía el error.
Cómo comprobar que la corrección está publicada
- Guarda el código anterior para poder deshacer el cambio.
- Corrige la fuente del dato: plugin, CMS o plantilla.
- Publica y limpia la caché de esa página si tu sistema la utiliza.
- Prueba la URL pública sin iniciar sesión.
- Compara el dato corregido con el contenido visible y guarda fecha y resultado.
Si el marcado es correcto pero buscas un resultado enriquecido, revisa también acceso e indexación con Search Console. La validación no equivale a que Google ya haya rastreado el cambio.
Qué esperar después de validar
El resultado inmediato es un marcado legible y coherente. No hay un porcentaje de mejora de menciones que puedas deducir de una pantalla sin errores. Para comprobar cambios comerciales, conserva las mismas preguntas y condiciones en tu medición de visibilidad.
Empieza por validar tu página. Si todavía no tiene marcado, sigue la guía general de schema para IA.
