Si alguna vez te has preguntado cómo Google muestra estrellas de valoración, precios o preguntas frecuentes directamente en los resultados de búsqueda, la respuesta casi siempre es la misma: JSON-LD. En este artículo te explicaré qué es, por qué importa para el SEO de tu proyecto y cómo implementarlo en una aplicación Next.js.
¿Qué es JSON-LD?
Imagina que tienes una tienda online, el usuario que accede ve el escaparate: imágenes, textos, precios… todo en HTML. Pero por detrás, tienes una ficha interna con información perfectamente organizada: nombre del producto, precio, disponibilidad, marca, etc..
JSON-LD es esa ficha interna que no ve el usuario, pero que entienden perfectamente los buscadores. Es decir, es un formato que permite añadir información estructurada a tu web para que los buscadores la entiendan mejor. Esto no mejora directamente el ranking, pero sí como se muestra tu resultado, y en consecuencia, su CTR.
Schema.org: el vocabulario común
JSON-LD define el formato, pero no el contenido. Es por ello que existe Schema.org, el diccionario que utilizan los buscadores para entender qué significa cada dato. Por ejemplo, no es lo mismo decir “precio” que definirlo como una propiedad oficial dentro de un tipo de “Product”.
Los cuatro elementos clave
Un bloque típico de JSON-LD contiene:
- @context: indica que estamos utilizando Schema.org
- @type: indica el tipo de entidad (Product, Article, FAQ, etc)
- Propiedades básicas (name, description)
- Propiedades complejas (offers, author, etc.)
Técnicamente, JSON-LD se incluye como un bloque <script> con el tipo application/ld+json dentro del HTML de tu página (habitualmente en el <head>, aunque en frameworks como Next.js puede inyectarse directamente en el render):
- @context: le dice al parser “el vocabulario que voy a utilizar está en schema.org. Sin esto, palabras como Article o author no significan nada para Google.
- @type: “Article”: declara que esta página es un artículo, esto activa las propiedades válidas para este tipo, por ejemplo: headline, author, datePublished, image, etc..
- headline: es el título del artículo, Google lo utiliza para mostrarlo en Rich Results (más adelante hablaremos sobre este concepto).
- author: el valor no es una string simple, sino otro objeto con su propio @type, esto se llama entidad anidada. Le dices a Google que el autor no es solo el texto “Roger”, sino una entidad de tipo “Person” a la cual se le podrían añadir más datos. Esto le permite a Google construir un knowledge graph: no solo sabe que el artículo tiene un autor llamado Roger, sabe que Roger es una persona con una identidad propia en la web.
¿Por qué importa para el SEO? Rich Results y CTR
Implementar datos estructurados no es simplemente “hacer SEO técnico”, es mejorar como aparece tu resultado en Google. Cuando JSON-LD se implementa de forma correcta, se puede optar a los llamados Rich Results. Los Rich Results transforman un enlace “normal” en algo mucho más visible.
Aunque Google ha mencionado en varias ocasiones que los datos estructurados no son un factor directo en ranking, si influyen en el comportamiento del usuario. Y esto, tiene consecuencias directas: aumenta la probabilidad de clic, reduce fricción y mejora la relevancia percibida.
Por ejemplo, un producto con un precio visible atrae más clics que uno que no lo muestra, un artículo con FAQs responde dudas antes de entrar, un resultado con estrellas transmite confianza inmediata.
En la mayoría de los casos, esto puede suponer mejoras de CTR significativas sin haber cambiado la posición.
Los Rich Results funcionan porque activan varios sesgos del usuario:
- Prueba social: un producto con estrellas y reviews tiende a ser un producto consolidado y validado.
- Transparencia: precio visible.
- Autoridad: la información que percibe el usuario está estructurada y es clara.
- Escaneabilidad: más fácil de entender con un único vistazo.
Implementación en Next.js
Hasta aquí todo suena bien, sabes que es JSON-LD, sabes que es Schema.org… pero llega el momento real: hay que implementarlo en una aplicación de verdad.
Y aquí es donde entra la posibilidad de fallo, porque no estás trabajando en una página web estática, estás trabajando con Next.js, datos dinámicos, APIs, SSR… y el SEO deja de ser “añadir un script” y pasa a formar parte de la arquitectura.
El enfoque más común suele ser: “Pego un JSON-LD en el <head> y ya está”. Esto puede funcionar, pero en casos muy simples. En cuanto tu aplicación escala aparecen los primeros problemas:
- Contenido dinámico que no se refleja en el schema
- Páginas que comparten el mismo JSON-LD
- Datos desactualizados
- Duplicidad en la información
Lo que provoca que, aunque se haya implementado, no está aportando ningún valor real.
El punto fuerte es entender que JSON-LD debe generarse con la misma fuente de datos que la UI, y para ello, hay dos formas posibles de implementarlo.
App Router
Con App Router puedes generar el schema directamente en el render del componente, como parte de la propia página, eso cambia el enfoque por completo, ya no estás “añadiendo SEO”, estás haciendo que el SEO forme parte del render.
Al generarse en el servidor, el JSON-LD forma parte del HTML inicial, lo que evita depender de la ejecución de JavaScript para que Google lo procese.
Esto implica varias cosas importantes:
- Se genera en el servidor (SSR o RSC)
- Se envía y llega ya renderizado al HTML inicial
- Google puede leerlo sin tener que ejecutar JavaScript
Con App Router te aseguras de que el schema esté disponible desde el primer momento. Por otro lado, evita generar JSON-LD en componentes cliente, ya que en este caso dependeremos de la ejecución del navegador.
Pages Router
Si trabajas con el sistema tradicional de Next.js, el enfoque es ligeramente distinto. Aquí no tienes Server Components, pero se puede inyectar en el <head> utilizando next/head.
Aún así, Pages Router sigue siendo totalmente válido por una razón: funciona. Next.js lo mantiene activamente y no hay ninguna señal de que vaya a desaparecer. En algunos casos podríamos plantearnos migrar a App Router, pero no merece la pena si el proyecto es estable y está en producción. Si bien es cierto que, si iniciamos un proyecto nuevo entonces es buen momento para utilizar App Router.
App Router VS Pages Router
App Router permite integrar el SEO directamente en el flujo de render. Pages Router también lo permite, pero requiere más control manual sobre cómo y cuándo se generan los datos.
Independientemente del Router que se utilice, el valor está en generar el JSON-LD con los mismos datos que construyen la interfaz.
Tipos más útiles según el caso de uso
¿Cómo validar que funciona correctamente?
Antes de publicar es recomendable validar que la implementación de JSON-LD es correcta, para ello existen dos herramientas oficiales de Google:
- Rich Results Test: te muestra que Rich Results puede generar tu página y si hay errores en el esquema.
- Schema Markup Validator: valida la corrección del JSON-LD contra la especificación de Schema.org
Conclusión
JSON-LD es una de esas mejoras que cuesta poco implementar y tiene un impacto visible en cómo apareces en Google. No cambia tu posición, pero sí cómo compites por el clic.
En Next.js, integrarlo correctamente es tan simple como generar el schema con los mismos datos que ya usas para construir la UI. Sin librerías, sin complejidad añadida.
Si estás construyendo un producto o una web con Next.js, añadir JSON-LD a tus páginas principales es una de las primeras optimizaciones SEO técnicas que deberías aplicar.
Pero, antes de implementar JSON-LD, ¿has definido una estructura clara y escalable dentro de tu proyecto Next.js?
