JSON-LD para diseñadores: guía sin miedo

JSON-LD es una forma de agregar datos estructurados a una página para explicar con precisión qué contiene: un artículo, una persona, una organización, una FAQ, un producto o un servicio. Como diseñador, no necesitas volverte programador para usarlo; necesitas entender qué contexto le estás dando a Google y a otros sistemas.

¿Qué es JSON-LD sin ponerme técnico?

JSON-LD es una etiqueta invisible para el usuario, pero útil para máquinas. Mientras tu diseño comunica visualmente, JSON-LD comunica semánticamente. Le dice a un buscador: “esta página no solo tiene texto; esta página es un artículo, escrito por esta persona, publicado en esta fecha, dentro de este sitio, con estas preguntas frecuentes”.

A mí me gusta pensarlo como diseño de información, no como programación. Un buen diseñador ya toma decisiones semánticas todo el tiempo: qué es título, qué es jerarquía, qué es navegación, qué es contenido principal, qué es apoyo. JSON-LD hace algo parecido, pero en un lenguaje que los buscadores pueden procesar de forma más directa.

Google explica que los datos estructurados ayudan a dar pistas explícitas sobre el significado de una página. También recomienda JSON-LD como el formato más fácil de implementar y mantener a escala cuando el sitio lo permite ¹. Eso importa mucho en Webflow, porque puedes integrar bloques de código a nivel de página o plantilla sin convertir todo el proyecto en un sistema difícil de mantener.

El error común es copiar un snippet de internet y pegarlo sin entenderlo. Eso puede generar datos incompletos, inconsistentes o directamente falsos. Y aquí aplica una regla simple: si el dato no existe en la página o no representa lo que el usuario ve, no lo metas en el schema. Los datos estructurados no son maquillaje; son una traducción técnica de la realidad editorial.

Para diseñadores, JSON-LD se vuelve especialmente útil en tres escenarios: artículos de blog, páginas de servicio y páginas personales. En los tres casos, la pregunta de fondo es la misma: ¿qué entidad estoy describiendo y qué necesita saber una máquina para interpretarla sin adivinar?

¿Por qué un diseñador debería entender datos estructurados?

Un diseñador debería entender datos estructurados porque la experiencia digital no termina en la pantalla. También incluye cómo buscadores, asistentes, redes y modelos interpretan el contenido antes de que una persona haga clic.

Durante años, muchos diseñadores dejamos “lo técnico” en manos de desarrollo o SEO. El problema es que cada decisión visual también afecta interpretación. Si una página de servicio no tiene jerarquía clara, si una bio no explica quién es la persona, si una FAQ está escondida sin estructura o si un blog no marca autoría y fecha, el sistema tiene menos señales para entender qué está viendo.

No estoy diciendo que todos los diseñadores deban escribir código. Estoy diciendo que un diseñador senior necesita saber pedirlo, revisarlo y diseñar contenido compatible con esa capa. En especial si trabaja en Webflow, donde muchas veces diseño, contenido y publicación viven muy cerca.

Schema.org nació como un vocabulario compartido para describir contenido de forma que buscadores y aplicaciones puedan entenderlo mejor ². Eso suena técnico, pero suena menos raro si lo piensas así: es una etiqueta de contexto. Igual que un componente en Figma necesita nombre correcto para que el equipo lo use bien, una página necesita datos correctos para que los sistemas la interpreten bien.

¿Qué tipos de schema usaría en un blog profesional?

En un blog profesional usaría principalmente Article, FAQPage, BreadcrumbList, Person y Organization. No todos van en todas las páginas; se elige según el contenido visible y el objetivo de la página.

La regla importante es no usar schema por usar schema. Si un artículo no tiene FAQ visible, no metas FAQPage. Si una página no es producto, no uses Product. Google advierte que los datos estructurados deben describir el contenido de la página donde aparecen y no información oculta o no visible para el usuario ¹.

Para un blog como este, Article y FAQPage son los primeros candidatos. Article ayuda a ordenar la pieza editorial. FAQPage puede reforzar preguntas concretas al final. BreadcrumbList ayuda a navegación. Person y Organization pueden vivir en templates o páginas base.

¿Cómo se ve un JSON-LD básico para un artículo?

Un JSON-LD básico para un artículo describe el tipo de contenido, título, descripción, autor, fecha, URL e imagen principal. Puede pegarse dentro de una etiqueta <script type="application/ld+json"> en la página.

Ejemplo ilustrativo, no código universal para copiar sin revisar:

``json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "JSON-LD para diseñadores: guía sin miedo", "description": "Una guía sencilla para entender JSON-LD, schema.org y datos estructurados sin volverte programador.", "author": { "@type": "Person", "name": "Israel Piña", "url": "https://israelpina.cool" }, "publisher": { "@type": "Organization", "name": "Israel Piña", "url": "https://israelpina.cool" }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://blog.israelpina.cool/articulos/json-ld-para-disenadores.html" }, "image": "https://blog.israelpina.cool/assets/og/json-ld-para-disenadores.png", "datePublished": "2026-01-15", "dateModified": "2026-01-15" } ``

Lo más importante no es memorizar la sintaxis. Lo importante es revisar que cada dato sea verdadero y coincida con la página. Si el título cambia, el headline también. Si la imagen cambia, el campo image también. Si el autor es una persona, no lo marques como organización por flojera.

Aquí la IA puede ayudar como copiloto: le puedes pedir que genere un primer borrador de JSON-LD a partir del contenido visible. Pero después hay que revisar. La IA puede inventar URLs, fechas o propiedades. Y en datos estructurados, inventar es una mala idea.

¿Cómo lo implementaría en Webflow sin sufrir?

En Webflow lo implementaría a nivel de template cuando el patrón se repite, usando campos dinámicos para título, descripción, autor, imagen y fechas. Si la página es única, puede agregarse como código personalizado de esa página.

La lógica correcta es separar lo repetible de lo manual. Para un blog, no quieres pegar a mano un JSON-LD distinto en cada post si puedes usar CMS fields. Quieres que el template tome el nombre del artículo, la descripción, la imagen OG, la fecha y el slug. Así reduces errores y haces el sistema más mantenible.

Un proceso práctico sería:

1. Definir qué schema necesita cada tipo de página.
2. Mapear qué campos ya existen en el CMS.
3. Crear campos faltantes como SEO title, meta description, OG image o reading time si son necesarios.
4. Insertar el script JSON-LD en el template.
5. Probar una URL con Rich Results Test.
6. Corregir errores antes de publicar masivamente.
7. Revisar Search Console después de indexación.

No recomiendo empezar con todos los schemas posibles. Empieza con Article y FAQPage para blog. Luego BreadcrumbList. Después Person, Organization y Service si aplica. La madurez técnica se construye por capas, no con una megaplantilla frágil.

¿Qué errores veo más seguido con JSON-LD?

Los errores más comunes son usar datos que no existen en la página, copiar snippets genéricos, mezclar tipos incorrectos y no validar antes de publicar. También pasa mucho que el schema queda viejo cuando cambia el contenido.

El error más peligroso es pensar que JSON-LD es una decoración SEO. No lo es. Si dices que una página tiene FAQs, las FAQs deben estar visibles. Si marcas una reseña, debe existir una reseña real. Si agregas una fecha de modificación, debería reflejar cambios reales. Google es claro: es mejor proporcionar menos propiedades, pero completas y precisas, que intentar llenar todo con información incompleta o mal formada ¹.

Otro error es no pensar en escalabilidad. Si cada artículo tiene código manual, tarde o temprano habrá inconsistencias. En Webflow, lo ideal es diseñar un sistema de publicación donde el contenido editorial y el schema salgan de la misma fuente.

Y hay un error de diseño: no revisar cómo la estructura visual corresponde a la estructura semántica. Si todo parece una tarjeta bonita, pero no hay H1 claro, autor, fecha, breadcrumbs o jerarquía de secciones, el contenido se ve bien pero se entiende peor.

Checklist de JSON-LD para diseñadores

Antes de publicar, revisaría esta lista:

1. El tipo de schema coincide con el contenido real.
2. La información marcada está visible o representada en la página.
3. El título, descripción y URL son correctos.
4. El autor está definido como Person cuando corresponde.
5. La imagen principal usa una URL absoluta.
6. Las fechas no son inventadas ni inconsistentes.
7. Las FAQs visibles coinciden con FAQPage si se usa.
8. El JSON no tiene comas rotas ni caracteres inválidos.
9. La página pasa una prueba en Rich Results Test.
10. El template está pensado para mantenimiento, no para parches.

Este checklist no te vuelve programador. Te vuelve mejor diseñador de sistemas digitales. Y hoy, eso importa más que saber mover píxeles.

Preguntas frecuentes

¿JSON-LD mejora mi ranking automáticamente?

No. JSON-LD no garantiza mejores posiciones. Ayuda a que los sistemas entiendan mejor la página y puede habilitar resultados enriquecidos si cumples requisitos.

¿Puedo usar JSON-LD aunque no sepa programar?

Sí, pero debes entender qué representa cada campo. Puedes apoyarte en herramientas o IA, siempre que revises que los datos sean correctos.

¿Qué schema usaría para un artículo de blog?

Usaría BlogPosting o Article, y si el artículo tiene preguntas frecuentes visibles, también evaluaría FAQPage.

¿Dónde pruebo si mi JSON-LD está bien?

Puedes usar Rich Results Test de Google para revisar elegibilidad de resultados enriquecidos y el validador de Schema.org para revisar estructura general.

¿Puedo poner schema que el usuario no ve?

No deberías. Los datos estructurados deben representar el contenido visible o real de la página. Meter información oculta puede causar problemas de calidad.

CTA suave

Si quieres que tu sitio en Webflow no solo se vea bien, sino que también sea más entendible para Google y motores de respuesta, escríbeme a hola@israelpinapol.com o visita israelpina.cool. El diseño también vive en la capa semántica.

---

1. Google Search Central, “Introduction to structured data markup in Google Search”, consultado para lineamientos, formatos y recomendación de JSON-LD: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data ↩
2. Schema.org, “Getting started with schema.org”, consultado para explicación de vocabularios compartidos y significado semántico del contenido: https://schema.org/docs/gs.html ↩