Qué es schema markup y cómo añadirlo

Schema markup es una de esas cosas que mucha gente escucha, poca gente entiende y casi todo el mundo implementa a medias.

La idea, en realidad, es sencilla: añadir datos estructurados para ayudar a los buscadores a entender mejor qué tipo de contenido hay en una página. No hace milagros por sí solo, pero bien usado puede mejorar comprensión, consistencia y opciones de rich results.

Qué es schema markup

Schema markup es una forma estandarizada de describir contenido web con datos estructurados. Se basa en vocabularios como schema.org y se suele implementar en formatos como JSON-LD.

En vez de dejar que Google “interprete” por contexto que una página habla de:

• una empresa,
• un artículo,
• un producto,
• una FAQ,
• o unas migas de pan,

se lo dices de forma más explícita.

Para qué sirve de verdad

Sirve para tres cosas principales:

1. ayudar a los buscadores a entender el contenido,
2. dar más contexto estructurado a la página,
3. y, en algunos casos, habilitar rich results o fragmentos enriquecidos.

Lo importante aquí es no sobreprometer. Schema markup no te sube posiciones por meter un bloque JSON-LD y ya. Pero sí puede ayudarte a estructurar mejor la información y a mejorar cómo se presenta o interpreta el contenido.

Tipos de schema más útiles para la mayoría de webs

Organization

Útil para describir la empresa detrás del sitio.

Article

Muy recomendable en contenidos editoriales y blog.

Product

Para fichas de producto, siempre que la información sea real y consistente.

FAQPage

Útil cuando tienes preguntas frecuentes reales y bien resueltas.

BreadcrumbList

Muy interesante para reflejar estructura y navegación.

Cuál elegiría primero en una PyME

Yo empezaría por:

1. Organization,
2. Article si tienes contenidos,
3. BreadcrumbList,
4. y FAQPage solo cuando las preguntas frecuentes sean reales y visibles.

JSON-LD vs microdata vs RDFa

Hoy, si quieres evitarte dolores de cabeza, lo habitual es trabajar con JSON-LD.

JSON-LD

Va en un bloque de script separado y es más limpio de mantener.

Microdata

Va embebido en el HTML y puede ser más incómodo de mantener o escalar.

RDFa

Existe, pero para la mayoría de equipos no es la opción más práctica.

En un proyecto moderno, especialmente con CMS o frameworks, casi siempre elegiría JSON-LD.

Ejemplo simple de Organization

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Weaking",
  "url": "https://weaking.com",
  "logo": "https://weaking.com/logo.png"
}

Ejemplo de Article

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Qué es schema markup y cómo añadirlo",
  "author": {
    "@type": "Person",
    "name": "Jan Gualda"
  },
  "datePublished": "2026-04-24"
}

Ejemplo de FAQPage

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "¿Schema markup mejora el SEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Ayuda a estructurar el contenido y puede habilitar rich results, pero no garantiza subidas directas en rankings."
      }
    }
  ]
}

Cuándo merece la pena implementarlo

No hace falta poner schema en todo por sistema.

Yo lo priorizaría cuando:

• tienes artículos o blog,
• vendes productos,
• tienes FAQs útiles,
• o necesitas reforzar entidad y estructura.

Si una página es mínima, temporal o irrelevante, no hace falta meterle tres capas de marcado para sentir que “está más optimizada”.

Cómo añadir schema markup según tu entorno

WordPress

Lo habitual es usar un plugin SEO o una capa específica si necesitas control más fino.

Next.js

Suele resolverse bien generando el bloque JSON-LD desde el propio componente o layout.

HTML plano

Puedes añadir el script directamente dentro del documento, siempre manteniendo consistencia con el contenido visible.

Ejemplo mínimo en HTML

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Tu Marca",
  "url": "https://tudominio.com"
}
</script>

Ejemplo de enfoque en Next.js

Lo normal es construir el objeto de datos y renderizarlo dentro del layout o de la página, para que no se quede duplicado ni desalineado.

Error crítico: decir en schema algo que no está en la página

Este es uno de los fallos más feos.

Si el marcado dice que hay:

• valoraciones,
• preguntas frecuentes,
• datos de producto,
• o información corporativa,

eso debe estar alineado con lo que ve el usuario. Si no, entras en terreno de marcado engañoso o poco fiable.

Cómo validarlo

Tienes varias opciones, pero la idea es siempre la misma:

• comprobar que el JSON-LD es válido,
• revisar que el tipo elegido tiene sentido,
• y confirmar que no contradice el contenido visible.

Una auditoría técnica completa como la que puedes plantear desde el website audit te ayuda a detectar otras incoherencias de on-page y estructura que suelen aparecer junto a estos errores.

Qué revisaría yo al validar

• que el bloque parsea bien,
• que el tipo tiene sentido,
• que los campos importantes están completos,
• y que no promete nada que la página no muestra.

Errores típicos con schema markup

Usar tipos que no tocan

Poner Product en una página que en realidad es una landing genérica no ayuda.

Copiar ejemplos sin adaptarlos

Esto es muy común. El bloque valida, pero describe otra cosa.

No actualizarlo

Si cambias contenido, precios, preguntas o estructura y el schema se queda atrás, deja de ser útil.

Meterlo por obsesión

No toda página necesita datos estructurados complejos.

Qué impacto real puedes esperar

Lo honesto es esto:

• mejor comprensión estructural,
• posibilidad de rich results en ciertos casos,
• y una capa adicional de calidad técnica.

No esperaría milagros aislados. Esperaría una web mejor ordenada y más coherente para buscadores.

Cuándo no me obsesionaría con schema

Si una web tiene:

• problemas graves de indexación,
• tiempos de carga muy malos,
• contenido flojo,
• o arquitectura pobre,

schema no sería la primera palanca. Lo arreglaría, sí, pero sin tratarlo como si fuera la prioridad absoluta.

Cómo lo integraría en una auditoría SEO

Yo lo revisaría como parte del bloque on-page/técnico:

1. ¿Existe marcado útil?
2. ¿Está alineado con el contenido visible?
3. ¿Usa tipos adecuados?
4. ¿Se mantiene actualizado?

Si falla todo lo anterior, schema no es el primer problema. Pero sí conviene dejarlo bien.

Qué errores de implementación veo más a menudo

Duplicar bloques para el mismo contenido

Suele pasar con plugins o plantillas mezcladas.

Marcar FAQs que en la página no existen de verdad

Muy típico cuando alguien quiere “forzar” rich snippets.

Usar datos desactualizados

Un Product con precios antiguos o un Organization con datos viejos deja de ayudar rápido.

Añadir schema sin revisar la base técnica

Si la página ya falla en on-page, indexación o rastreo, schema no compensa ese desorden.

Un orden sensato para implementarlo

Si tuviera que hacerlo en una web real, iría así:

1. revisar qué tipos de página existen,
2. decidir qué tipos de schema aportan más valor,
3. implementar primero Organization y el tipo principal por plantilla,
4. validar,
5. y luego mantenerlo junto al contenido para que no se quede obsoleto.

Ese orden evita el caos típico de añadir bloques sueltos sin sistema.

Cómo pensar schema sin volverte técnico

Una forma útil de verlo es esta:

• el HTML visible le habla al usuario,
• el schema le habla al buscador,
• y ambos deberían contar la misma historia.

Cuando no la cuentan, el problema no es “de código”. Es de coherencia.

Resumen

• Schema markup es una forma de estructurar mejor la información de una página.
• JSON-LD suele ser la opción más cómoda y mantenible.
• No mejora rankings por arte de magia, pero sí ayuda a comprensión y rich results.
• Hay que mantener coherencia entre el marcado y el contenido visible.
• Úsalo donde aporta claridad, no por rellenar checklist.

Preguntas frecuentes

¿Schema markup mejora el SEO?

Puede ayudar indirectamente por mejor estructuración y rich results, pero no es una palanca milagrosa por sí sola.

¿Qué formato usaría hoy?

JSON-LD, salvo que tengas una razón muy clara para otra cosa.

¿Hace falta en todas las páginas?

No. Tiene más sentido en tipos de página donde el marcado aporta contexto claro y útil.

¿Puedo copiar un ejemplo y ya?

Solo si lo adaptas por completo al contenido real de la página.

¿Dónde lo reviso si no me fío de la implementación?

Empieza por validar el bloque y luego revisa la página dentro de una auditoría más amplia con el analizador gratuito o el website audit.