Aprende qué tipos de schema encajan con entradas de blog, términos de glosario y noticias, además de pasos sencillos para probar el marcado schema en blogs y lograr resultados enriquecidos.
El marcado schema es un pequeño bloque de datos estructurados que añades a una página para que los motores de búsqueda lean hechos clave en un formato claro y consistente. Piénsalo como una etiqueta en una caja: el contenido sigue siendo el mismo, pero la etiqueta facilita ordenar y mostrarlo.
Cuando los motores de búsqueda entienden mejor tu página, pueden mostrarla como un resultado enriquecido en lugar de un enlace azul estándar. Un resultado enriquecido puede incluir detalles extra como un titular, fecha de publicación, autor, migas de pan o una vista previa corta. Esto no ocurre en todas las páginas y siempre depende del motor de búsqueda.
Conviene tener claro qué puede y qué no puede hacer el schema. Los datos estructurados mejoran la claridad y la elegibilidad para ciertas funciones de búsqueda, pero no aumentan el ranking por sí solos. Si una página es pobre, está desactualizada o es difícil de rastrear, el schema no lo arreglará. Y no puede forzar la aparición de un resultado enriquecido.
En la mayoría de sitios, hay algunos patrones que importan más que cualquier otra cosa:
Un ejemplo sencillo: publicas una definición de glosario y una entrada de blog que la referencia. Con el marcado correcto, un motor de búsqueda puede tratar con más confianza una página como la definición y la otra como una guía, en lugar de dos “artículos” que compiten.
Si publicas muchas páginas (especialmente desde plantillas o una API), el schema es aún más valioso porque mantiene tu salida consistente a medida que añades blogs, noticias y entradas de glosario con el tiempo.
Para la mayoría de blogs, el punto de partida es BlogPosting, que es una versión más específica de Article.
Las mayores ganancias suelen venir de acertar con lo básico en cada publicación. A los motores de búsqueda les importan más señales precisas y estables que una larga lista de propiedades opcionales.
Asegura que estos campos sean precisos en cada publicación:
Si actualizas una guía antigua, conserva datePublished como la fecha original y establece dateModified con la fecha de actualización. No cambies datePublished solo para parecer más reciente, y no actualices dateModified salvo que algo cambie realmente.
Los campos opcionales pueden ayudar, pero solo si son precisos y fáciles de mantener. keywords puede funcionar si ya muestras etiquetas o categorías. wordCount está bien para páginas largas y mayormente estáticas, pero evítalo si el contenido cambia mucho tras la publicación. speakable solo tiene sentido cuando mantienes un resumen corto y limpio diseñado para ser leído en voz alta.
Si tu pipeline genera JSON-LD automáticamente (por ejemplo, a través de una plantilla del CMS o un renderizador impulsado por API), prioriza la consistencia y la corrección antes de añadir campos extra.
Las páginas de noticias se juzgan mucho por la frescura y la claridad. Los motores de búsqueda quieren saber qué ocurrió, cuándo se publicó y quién lo publicó. Por eso el marcado de noticias suele ser menos permisivo.
Usa NewsArticle cuando la página informe sobre un evento o desarrollo puntual que quedará desactualizado (incluso si se mantiene en tu archivo). Usa Article para reportajes evergreen, columnas de opinión y largos análisis que no están ligados a un momento específico.
Una regla práctica:
Las fechas importan más en noticias que en casi cualquier otro tipo de contenido. Incluye tanto datePublished como dateModified y asegúrate de que coincidan con lo que el lector ve en la página. Si actualizas una historia, actualiza dateModified. Si “republicas” una pieza antigua como nueva, asegúrate de que las fechas visibles y los datos estructurados cuenten la misma historia.
Para muchas páginas de noticias, un conjunto pequeño de campos aporta la mayor parte del valor: titular, descripción, imagen (una imagen real y rastreable), autor, publisher (como Organization), mainEntityOfPage, datePublished y dateModified.
Si tienes un muro de pago o suscripción, márcalo claramente con isAccessibleForFree y los detalles de contenido con pago. No digas que un contenido es gratuito si no lo es.
Para historias republicadas o sindicadas, evita parecer una fuente duplicada. Mantén una URL canónica por historia, conserva los datos estructurados consistentes en esa versión canónica y evita cambiar titulares entre copias. Si la misma historia existe en varios lugares, deja claro cuál página es la principal.
Las páginas de glosario pueden lograr fragmentos más claros cuando los motores de búsqueda entienden que estás definiendo términos, no publicando artículos normales. Incluso si tu foco principal es el marcado schema para blogs, el marcado de definiciones ayuda a clasificar el contenido de glosario más rápido.
Usa DefinedTerm cuando una página explique un término. Usa DefinedTermSet cuando la página sea una colección de términos, como un glosario A–Z o una página de categoría con muchas entradas. Usa FAQPage solo cuando la página sea realmente una lista de preguntas con respuestas, no una definición única.
Una regla simple: si el objetivo de la página es “definir esto”, elige DefinedTerm. Si el objetivo es “explorar muchas definiciones”, elige DefinedTermSet.
Para una página de un único término, mantén el marcado centrado en un término y su definición, además de dónde pertenece.
{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"name": "Canonical tag",
"alternateName": ["rel=canonical", "canonical URL"],
"description": "A canonical tag tells search engines which URL is the preferred version of a page.",
"inDefinedTermSet": {
"@type": "DefinedTermSet",
"name": "SEO Glossary"
}
}
Para una página de categoría, usa DefinedTermSet. Añade un ItemList de las páginas de términos solo si esa lista es visible para los usuarios en la página.
Cuando tengas sinónimos, usa alternateName para variaciones reales, acrónimos y diferencias ortográficas. Manténlo corto y honesto; no rellenes con palabras clave.
Alinea el texto de la definición con lo que los usuarios pueden leer. Si la descripción en el JSON-LD dice una cosa y la definición en la página otra, las posibilidades de obtener un resultado enriquecido disminuyen.
Algunos tipos de schema ayudan a casi cualquier página, ya sea una entrada de blog, una entrada de glosario o una noticia.
BreadcrumbList es una de las mejoras más sencillas. Muestra dónde está una página dentro de tu sitio usando la misma ruta que ven los usuarios (Home > Blog > Tema > Publicación). Esto puede limpiar la apariencia del resultado y reduce la confusión cuando hay páginas similares en distintas secciones.
Organization y WebSite dan señales claras de marca. Organization cubre tu nombre, logo y datos de contacto básicos. WebSite puede describir el sitio y, opcionalmente, una acción de búsqueda interna. Incluye el marcado de búsqueda solo si los usuarios realmente pueden buscar en tu sitio.
Las imágenes merecen atención. Si las páginas dependen de imágenes destacadas, añadir ImageObject (o describir completamente la imagen en tu esquema principal) ayuda a los motores de búsqueda a entender qué es la imagen, dónde vive y sus propiedades clave.
El marcado de autor suele causar inconsistencias evitables. Elige un enfoque y mantenlo: usa Person cuando un individuo real escriba y sea acreditado en la página, y usa Organization cuando el contenido se publique bajo un pie de autor de marca. Evita alternar entre Person y Organization para el mismo nombre de autor.
Usa sameAs solo para perfiles oficiales que controles. Si dudas, omítelo. Perfiles desactualizados o incorrectos pueden debilitar la confianza.
JSON-LD suele ser la forma más segura de añadir datos estructurados porque vive en un único bloque \u003cscript type="application/ld+json"\u003e y no cambia lo que ven los usuarios. Ponlo en el HTML de la página (comúnmente en el \u003chead\u003e o cerca del final del \u003cbody\u003e) y asegúrate de que se renderice en la página final, no solo en una vista previa.
Parte del contenido visible y máppalo a los campos de schema. Si la página muestra un titular, nombre del autor, fecha de publicación, imagen destacada y una breve descripción, tu JSON-LD debería coincidir exactamente con esos valores. Las discrepancias son una razón común por la que el marcado schema para blogs no logra resultados enriquecidos.
Crea una plantilla repetible por tipo de contenido (entrada de blog, noticia, término de glosario). La configuración más segura es cuando la plantilla extrae de la misma fuente que el contenido de la página, así las actualizaciones permanecen sincronizadas.
Un flujo de despliegue que minimiza riesgos:
@id.Aquí hay un patrón pequeño para IDs estables (fíjate en el @id basado en URL):
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://example.com/blog/my-post#blogposting",
"headline": "My Post Title",
"datePublished": "2026-01-16",
"mainEntityOfPage": "https://example.com/blog/my-post"
}
Si tu sitio está construido con un framework como Next.js, genera este bloque en tiempo de renderizado desde tu CMS o API de contenido.
La validación tiene dos partes. Primero, asegúrate de que tu JSON-LD sea válido y cumpla las reglas del schema. Luego, comprueba si Google lo considera elegible para resultados enriquecidos. Pasar las comprobaciones de sintaxis no garantiza que obtendrás un resultado enriquecido.
Empieza copiando el JSON-LD renderizado exacto desde la página en vivo (no un archivo de plantilla) y valídalo por problemas generales de schema. El Schema Markup Validator es útil para detectar nombres de propiedades erróneos, campos obligatorios faltantes y desajustes de tipo.
Después, prueba la elegibilidad para resultados enriquecidos con la Rich Results Test de Google. Esta prueba se centra en las funciones que Google realmente muestra y destaca los campos faltantes que bloquean la elegibilidad incluso cuando el marcado es técnicamente válido. Para contenido de blog, brechas pequeñas como una imagen faltante o el autor son causas comunes por las que los resultados no se enriquecen.
Trata los hallazgos de forma diferente:
Si actualizas una plantilla compartida y la Rich Results Test empieza a marcar la ausencia de datePublished en algunas páginas, suele señalar un problema de datos (un campo vacío en tu CMS), no un fallo del schema.
Vuelve a probar después de cada cambio de plantilla, aunque parezca menor. Si generas contenido a través de una API, valida una página recién publicada de cada tipo antes de desplegar cambios en todas partes.
Los resultados enriquecidos a menudo fallan por razones sencillas: los motores pueden leer tus datos estructurados, pero no confían en ellos.
La regla más grande es que el marcado coincida con lo que los usuarios ven. Si tu JSON-LD afirma un nombre de autor, un titular o una fecha de publicación, esos detalles deben ser visibles en la página. No ocultes detalles clave solo en el marcado y no uses redacción diferente.
La ausencia de campos obligatorios es otro bloqueo frecuente. Para páginas tipo Article, el titular, la imagen y las fechas de publicación o actualización son requisitos comunes. Si tu imagen es demasiado pequeña, falta o no es accesible, la página puede quedarse fuera de los resultados enriquecidos aun cuando todo lo demás esté correcto.
Usar el tipo de schema equivocado también puede perjudicar. Añadir FAQPage a una página que no es realmente una sección de preguntas y respuestas puede hacer que el marcado se ignore o se marque. Elige tipos que reflejen la página real: BlogPosting para una entrada de blog, NewsArticle para una noticia, DefinedTerm para una definición.
Algunos problemas recurrentes:
Ejemplo: un equipo publica una noticia y la página muestra “Actualizado el 16 de ene.”, pero el marcado aún contiene la fecha de la semana pasada de una plantilla reutilizada. Incluso con schema de NewsArticle correcto, los motores pueden considerarlo poco fiable hasta que el contenido visible y los datos estructurados coincidan.
Antes de publicar, haz una comprobación rápida de consistencia. La mayoría de problemas con resultados enriquecidos no son problemas complejos. Son pequeñas discrepancias entre lo que la página muestra y lo que el marcado afirma.
Si vas a añadir marcado schema para blogs, empieza por decidir qué es la página (BlogPosting, NewsArticle o una página de definición). Todo lo demás debe apoyar esa elección.
Si publicas una actualización de noticias y más tarde reutilizas la misma plantilla para una entrada de glosario, no dejes campos de NewsArticle atrás. Una página de definición que aún afirma ser NewsArticle suele fallar las comprobaciones de elegibilidad.
Imagina un sitio pequeño que publica tres cosas: entradas de blog semanales, un glosario de términos clave y un hub de noticias sencillo para actualizaciones de la empresa. El objetivo es obtener fragmentos de búsqueda más claros y elegibilidad para resultados enriquecidos sin cambiar el diseño de la página.
Las elecciones de schema difieren según la intención. Las entradas de blog suelen encajar con BlogPosting (o Article). Las noticias encajan con NewsArticle solo cuando son realmente oportunas. Las entradas de glosario deben centrarse en DefinedTerm y DefinedTermSet (a menudo emparejadas con WebPage) para que los motores entiendan “esta página define un término”, no “esto es una noticia”.
Aquí tienes un despliegue práctico de 2 semanas que mantiene el riesgo bajo:
BreadcrumbList y un perfil de Organization (editor).Tras el despliegue, confirma dos cosas: que el marcado sigue presente en la página en vivo (y no es eliminado por tu renderer o herramientas de consentimiento) y que los motores de búsqueda rastrean las páginas actualizadas e informan datos estructurados en sus informes de mejoras y resultados enriquecidos.
El éxito suele verse como más impresiones para páginas que ya posicionan, nuevos elementos de mejora para tipos elegibles y un modesto aumento del CTR gracias a títulos, fechas y migas de pan más claros.
El schema no es una tarea única. Se rompe con mayor frecuencia cuando una plantilla cambia, un campo se renombra o se añade un nuevo bloque de contenido y el JSON-LD no se actualiza para coincidir.
Haz de los datos estructurados parte del proceso de publicación. Si gestionas un blog, un hub de noticias y un glosario, decide qué campos son obligatorios para cada tipo de contenido y trata esos campos como tratas el título y la URL: que se publiquen siempre.
La forma más sencilla de mantener el marcado schema para blogs consistente es vincularlo a la misma fuente de verdad que usas para generar la página: título, autor, fecha de publicación, imágenes, categoría y el cuerpo principal. Cuando el contenido se crea con herramientas distintas por diferentes personas, aparecen campos faltantes (sin autor, formato de fecha incorrecto, array de imágenes vacío) y las posibilidades de resultados enriquecidos disminuyen.
Una rutina ligera que funciona para la mayoría de equipos:
Si publicas a escala, la automatización ayuda. Por ejemplo, GENERATED (generated.app) puede generar contenido de blog, noticias y glosario vía API y mantener campos de datos estructurados consistentes entre plantillas, incluso cuando traduces o actualizas contenido.
Ejemplo: si introduces una nueva insignia de “última actualización”, actualiza también tu JSON-LD para incluir dateModified y luego valida una entrada de blog de muestra, una página de NewsArticle y una entrada de glosario antes de que el cambio salga en producción.
El marcado schema es datos estructurados que ayudan a los motores de búsqueda a leer hechos clave de tu página de forma consistente. Puede hacer que tu página sea elegible para resultados enriquecidos (por ejemplo, mostrar fechas, migas de pan o detalles adicionales), pero no aumentará el posicionamiento por sí solo.
Usa BlogPosting cuando la página sea claramente una entrada de blog como una guía, resumen, opinión o actualización. Usa Article cuando tu contenido sea editorial más amplio o cuando quieras un tipo consistente en distintas secciones y tu sistema ya genere Article.
Empieza por los campos que deben ser precisos y estables: headline, author, datePublished, image y mainEntityOfPage. Si esos coinciden con lo que ven los usuarios en la página, ya has hecho la mayor parte del trabajo que importa para la elegibilidad y la confianza.
Mantén datePublished como la fecha de publicación original y solo actualiza dateModified cuando hagas un cambio real en el contenido. Cambiar datePublished para que parezca más reciente puede salir mal si no coincide con lo que muestra la página y lo que esperan los usuarios.
Usa NewsArticle solo para historias oportunas con un momento de publicación claro, como anuncios o novedades que pueden quedar obsoletas. Usa Article para explicaciones atemporales, editoriales y largos análisis que no están ligados a un evento específico.
Usa DefinedTerm cuando una página defina un único término, y usa DefinedTermSet cuando una página sea una colección de términos (por ejemplo, un glosario A–Z). Alinea la definición estructurada con la definición visible para que no parezca inconsistente.
BreadcrumbList ayuda a los motores de búsqueda a mostrar una pista de migas más limpia en lugar de una URL larga, lo que reduce la confusión cuando existen páginas similares en secciones distintas. También es uno de los tipos de schema más fáciles de mantener porque refleja la navegación visible.
Añade un único bloque JSON-LD dentro de una etiqueta script (type="application/ld+json") en el HTML final renderizado, normalmente en el head o cerca del final del body. Lo más seguro es generar el JSON-LD desde la misma fuente de datos que pinta el título, las fechas, el autor y la imagen visibles, así se mantienen sincronizados.
Valida en dos pasos: primero, comprueba que el JSON-LD sea válido y use propiedades y tipos correctos; después, verifica la elegibilidad para resultados enriquecidos por separado. Una página puede tener schema válido y aun así no ser elegible para un resultado enriquecido, así que trata las pruebas de elegibilidad como un filtro adicional.
Los bloqueadores más comunes son desajustes entre el marcado y lo que los usuarios ven, campos clave ausentes como una imagen accesible o la fecha de publicación, y bloques de schema conflictivos que discrepan sobre URL, titulares o autores. Mantén un único tipo primario por página, IDs y URL canónicas consistentes, y evita añadir tipos que no reflejen el contenido real de la página.