Cómo implementar schema markup: dónde va, qué se declara y qué falla en silencio

La parte fácil de los datos estructurados es escribirlos; la difícil es que digan la verdad sobre la página y sigan diciéndola dentro de seis meses. El fallo más caro de esta tecnología no produce ningún error en ninguna herramienta: el JSON sigue siendo válido, el validador lo aprueba, y Google simplemente ignora la relación que se quería declarar. Este artículo es el recorrido operativo, con las tres comprobaciones que hay que automatizar porque a mano no se sostienen.

Respuesta rápida

• JSON-LD es el formato recomendado por la propia documentación.
• No se marca lo que no está visible en la página. Es una regla explícita.
• Todo lo que se declare debe existir en el HTML. Si no, no sale como resultado enriquecido.
• La comprobación que más vale es la de referencias colgantes, y no la hace ningún validador.

¿Cómo se implementa schema markup en una web?

Añadiendo un bloque JSON-LD generado por la plantilla, con los tipos que correspondan al contenido real de cada página y ningún dato que no esté visible en ella. Después se comprueba con la prueba de resultados enriquecidos de Google y, sobre todo, se automatiza la verificación para que el marcado no se desincronice del contenido con el tiempo.

Qué tipo de trabajo es este

El encuadre que produce marcado inútil es tratarlo como una tarea de instalación: se pega un bloque, se valida una vez y se da por hecho.

Lo que es en realidad es una segunda copia de la información de la página, escrita en un formato que lee una máquina. Y como toda copia, su problema no es crearla sino mantenerla sincronizada: el día que alguien cambia el título, el autor o la fecha en el HTML y no en el JSON, el marcado empieza a mentir sin que nada avise.

De ahí la consecuencia que ordena todo el trabajo: el marcado se genera desde la misma fuente que la página, nunca se escribe a mano por página. Si los dos salen del mismo dato, no pueden desincronizarse.

Qué son y qué efecto tienen, que es la pregunta anterior a esta, está en datos estructurados.

Las decisiones de implementación, en orden

1. El formato: JSON-LD

La documentación lo recomienda expresamente frente a microdatos y RDFa, y la razón práctica pesa más que la preferencia: va en un bloque separado del HTML, así que se puede generar, revisar y modificar sin tocar la maquetación.

Con microdatos, cambiar el marcado obliga a cambiar las etiquetas del contenido, y eso significa que cualquier rediseño puede romperlo sin que nadie se dé cuenta.

2. Qué tipos declarar

Los que correspondan a lo que la página es de verdad, y ninguno más. Un artículo es un artículo; una página de servicio no es un artículo por mucho que tenga texto.

La tentación de declarar de más viene de suponer que más tipos es más superficie. No funciona así, y sí tiene un coste: un marcado que no representa el contenido principal de la página no se muestra como resultado enriquecido, y esa página deja de obtener el que sí le correspondía.

3. La regla que más se incumple

No se marca contenido que no esté visible para quien lee la página. Es una regla explícita de la documentación y se incumple casi siempre sin mala intención: se declaran valoraciones que no aparecen, autores que no se firman, preguntas frecuentes que no existen en el texto.

La prueba es de una frase: si un lector no puede ver ese dato en la página, no debe estar en el marcado.

4. Un solo grafo, no tres bloques sueltos

Es la decisión que más cambia el resultado y la que menos se toma.

Tres bloques JSON-LD independientes describen tres hechos inconexos. Un @graph donde los nodos se referencian por @id describe una entidad: este artículo lo escribió esta persona, que es la misma persona de todo el sitio, y vive en esta página, que pertenece a este sitio web.

Las tres comprobaciones que hay que automatizar

Validar a mano una vez sirve para el día del lanzamiento y para nada más. Estas tres se ponen en el proceso de construcción y fallan el despliegue.

Que el bloque existe en cada página que debe tenerlo. Es la más tonta y la que más veces salta, porque una plantilla nueva se olvida.

Que lo declarado coincide con lo publicado. Título, fecha, autor e imagen leídos del HTML y comparados contra el JSON. Aquí conviene una precisión que cuesta descubrir: las dimensiones de una imagen se leen del archivo, no se escriben a mano, porque un ancho declarado que no coincide es peor que no declararlo.

Y que ninguna referencia @id cuelgue. Es la más importante y la que ninguna herramienta pública comprueba: un @id que apunta a un nodo que no está en el grafo deja el JSON perfectamente válido y la relación perfectamente ignorada.

En este sitio esa tercera comprobación se probó rompiendo a propósito la referencia del autor, que es la manera de saber si un chequeo sirve. La cazó. Un control que nunca ha fallado merece que se rompa una vez, por el mismo motivo que se prueba una alarma de incendios.

Cuándo no merece la pena

Cuando la página no opta a ningún resultado enriquecido. El marcado no es un factor de posición.

Cuando el dato no está en la página. Entonces no es un problema de marcado, es de contenido.

Cuando se va a escribir a mano artículo por artículo. Se desincroniza en el primer cambio.

Cuando lo que falta es que la página se indexe. El marcado no ayuda a entrar en el índice, y ese problema tiene su propio recorrido en por qué Google no indexa mi página.

Y cuando el sitio es pequeño y el tiempo es escaso. Es la situación más común de todas y la que peor se aconseja, porque el marcado es visible, se puede enseñar en una captura y da sensación de trabajo hecho, mientras que las cosas que de verdad decidían en ese sitio no se ven en ninguna pantalla. El orden de prioridades técnicas, que casi nunca pone esto arriba, está en SEO técnico.

La guía termina en el validador, y ahí empieza la confusión

Comprobado el 13 de agosto de 2026, las guías que ocupan esta consulta terminan todas en el mismo paso: validar con la prueba de resultados enriquecidos de Google. Es buen consejo y está incompleto de una forma que produce el mismo susto una y otra vez.

Esa herramienta no valida el marcado: comprueba si tu página es elegible para algún resultado enriquecido. Son cosas distintas. Un marcado impecable de un tipo que no tiene resultado enriquecido asociado, o que no lo tiene en tu idioma o tu país, devuelve un mensaje de que no se han detectado elementos, y ese mensaje se lee como un error cuando no lo es.

De ahí sale una tarde entera reescribiendo JSON que estaba bien. El caso más reciente y más caro lo pone Google mismo: los resultados enriquecidos de preguntas frecuentes se retiraron para casi todos los sitios el 7 de mayo de 2026. Un marcado FAQPage correcto pasa hoy por esa herramienta sin producir nada visible, porque no queda nada que producir. Qué formatos siguen dando resultado enriquecido y cuáles se quedaron por el camino está en qué tipos de resultado enriquecido existen, y conviene mirarlo antes de elegir el tipo y no después de escribirlo.

Hay además un caso que ninguna de esas guías menciona y que se lleva bastantes horas: el marcado inyectado por JavaScript. Google lo ve, pero lo ve en la fase de renderizado, que va por detrás y no siempre llega; si el bloque lo escribe un script que depende de una interacción o de un consentimiento, no existe para el rastreador. Cuándo se ve y cuándo no está en JavaScript y SEO.

Y la consecuencia de fondo que ninguna dice: el marcado es requisito de un formato de resultado, no un factor de posición. Implementarlo no sube nada por sí solo, sino que habilita una presentación distinta cuando ya estás arriba. El sitio donde eso se nota, y donde se gana o se pierde el espacio grande de la página, es otro: el fragmento destacado, que no necesita marcado ninguno.

Errores que se repiten

• Escribirlo a mano por página. Se desincroniza con el primer cambio.
• Declarar datos que no están visibles. Es una regla explícita, y se incumple mucho.
• Poner tres bloques sueltos. Tres hechos inconexos en lugar de una entidad.
• Escribir a mano las dimensiones de imagen. Un ancho que no coincide hace daño.
• Validar una vez y olvidarse. El marcado envejece con el contenido.
• Declarar tipos de más. Un marcado no representativo no se muestra.

Datos y transparencia

Que las guías mejor posicionadas en español para esta consulta cierran en la prueba de resultados enriquecidos sin advertir de que esa herramienta comprueba elegibilidad y no validez del marcado es una observación propia del 13 de agosto de 2026 y se recoge como hueco, no como fuente. Que los resultados enriquecidos de preguntas frecuentes se retiraron para casi todos los sitios el 7 de mayo de 2026 procede del anuncio de Google, comprobado el mismo día.

Que JSON-LD es el formato recomendado por Google frente a microdatos y RDFa, que no debe marcarse contenido que no sea visible para quien lee la página, y que un marcado que no representa el contenido principal de la página o que puede resultar engañoso no se muestra como resultado enriquecido, proceden de las directrices generales de datos estructurados de Google, comprobadas el 12 de agosto de 2026. Esa documentación no presenta los datos estructurados como un factor de posicionamiento, sino como el requisito para optar a resultados enriquecidos. No aparece aquí ninguna cifra sobre cuánto mejora el CTR un resultado enriquecido: depende del tipo y de la consulta, y las que circulan proceden de muestras no comparables. Las tres comprobaciones automatizadas, incluida la de referencias @id colgantes, están implementadas en la auditoría de este mismo sitio y se probaron rompiéndolas a propósito; el código vive en el repositorio del proyecto. Verificado en agosto de 2026.

Lo que esto cambia

Los datos estructurados son el ejemplo más claro de una categoría de trabajo que se hace una vez y se degrada sola.

No hay señal de deterioro: la página se sigue viendo bien, el validador sigue aprobando, y el marcado va describiendo cada vez peor lo que hay debajo. Por eso la decisión que más rinde en este tema no es qué tipos declarar sino dónde vive la verificación. En un proceso de construcción que puede fallar el despliegue, el marcado no puede envejecer más de un día. En un documento de buenas prácticas, envejece hasta que alguien se acuerda.

Preguntas frecuentes