Explicación de JSON-LD para sitios web personales

 (hawksley.dev)
2 puntos por GN⁺ 8 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Incluso un sitio web personal puede beneficiarse de incluir datos estructurados, ya que los rastreadores pueden entender mejor la relación entre la página, la persona y los artículos, y así mejorar la calidad de las vistas previas de enlaces y la visibilidad en búsquedas.
  • La implementación consiste en colocar dentro de <head> un <script type="application/ld+json">, establecer Schema.org como @context y ubicar nodos como WebSite, Person y BlogPosting dentro de @graph.
  • Si se usa el mismo @id, los rastreadores web pueden fusionar propiedades de nodos entre varias páginas, pero los scrapers o LLM que solo leen una página no lo hacen.
  • En la página raíz, lo básico es incluir WebSite, ProfilePage y Person; en páginas de blog, proyectos o listados, se agregan según corresponda Blog, BlogPosting, SoftwareApplication, CollectionPage y BreadcrumbList.
  • Los campos sameAs de Person, breadcrumb de la página, e image, license y fechas del artículo se usan directamente para identificar a la persona, mostrar rutas en resultados de búsqueda, generar vistas previas, indicar condiciones de uso y evaluar vigencia.

El papel de JSON-LD y su estructura básica

  • JSON-LD significa JSON Linked Data y es un formato para agregar datos estructurados a una página web.
  • Ayuda a los rastreadores a entender la estructura semántica del sitio y puede contribuir a vistas previas de enlaces más ricas y a posibles mejoras en el posicionamiento de búsqueda.
  • Para agregarlo a una página, se inserta en la sección <head> un script con esta forma:
    • <script type="application/ld+json"> declara el tipo MIME como application/ld+json.
    • Cuando se especifica este tipo, el motor de JavaScript del navegador no lo ejecuta.
    • Rastreadores especiales como Googlebot encuentran ese elemento y analizan su contenido.

@context, @graph e ID de nodos

  • @context especifica el contexto que sigue la información JSON-LD, y los rastreadores web usan Schema.org como estándar.
  • Schema.org define los pares clave-valor válidos que pueden usarse en JSON.
  • Un documento JSON-LD puede verse como un grafo dirigido con etiquetas, y los datos se almacenan bajo @graph.
  • El grafo puede contener varios nodos, conectados entre sí mediante enlaces dirigidos.
  • Cada nodo se compone de los siguientes elementos:
    • @type: indica qué es el nodo. Ej.: WebSite, SoftwareApplication
    • @id: normalmente, un identificador del nodo formado al añadir un hash único al final de una URL
    • Propiedades: pares clave-valor que representan las características del nodo
  • Los rastreadores web pueden fusionar propiedades de nodos que comparten el mismo @id a través de varias páginas.
  • Pero los scrapers o LLM que solo leen una sola página no fusionan propiedades, así que conviene tener en cuenta esta diferencia al reutilizar JSON-LD en varias páginas.
  • Se recomienda que @id use un hash agregado a la URL para identificar de forma única al nodo, como #website.

Nodos para describir el sitio y las páginas

  • WebSite

    • WebSite contiene los metadatos del sitio y da pistas a los rastreadores sobre cómo deben mostrarlo.
    • En la página raíz puede incluirse una versión detallada con propiedades como url, name, alternateName, description, inLanguage, publisher e image.
    • No es necesario insertar el nodo completo de WebSite en todas las páginas.
    • Conviene hacer la página raíz del dominio en detalle, y en las demás páginas basta con una versión abreviada que incluya @type, @id, url y name.
    • La versión abreviada aporta el contexto necesario para que los rastreadores que leen una sola página identifiquen correctamente el nombre del sitio.

  • WebPage

    • WebPage representa la página actual en sí, es decir, la página física HTML.
    • Debe distinguirse de tipos de contenido como BlogPosting; WebPage se refiere a la página que contiene ese contenido.
    • Entre sus propiedades de ejemplo están url, isPartOf, name, inLanguage y breadcrumb.
    • ProfilePage y CollectionPage son subtipos más específicos de WebPage.
    • Otros subtipos menos comunes pueden consultarse en la definición de WebPage de Schema.org.

Identidad personal y páginas de perfil

  • Person

    • Se recomienda incluir un nodo Person en todas las páginas de un sitio web personal.
    • Person indica quién es el dueño del sitio y se usa como parte de algunos indicadores de calidad de contenido de Google.
    • Los rastreadores de LLM también usan cada vez más la información de Person para decidir a quién citar en sus respuestas.
    • A diferencia de WebSite, Person es un contexto lo bastante importante como para incluirlo en todas las páginas.
    • Estas son propiedades importantes:
      • url: apunta a la página raíz para anclar el nodo
      • name, givenName, familyName: expresan claramente el nombre
      • image: idealmente usa una foto propia o un logo relacionado para enlazar una imagen oficial
      • sameAs: informa a los rastreadores sobre otros perfiles y ayuda a identificar a la persona
    • sameAs es especialmente útil para distinguir homónimos cuando se tiene un nombre común, y se usa para construir una representación del grafo de conocimiento a través de varias páginas.
    • Otras propiedades de Person sirven para agregar detalle, pero no son obligatorias y reducirlas tiene poco impacto.

  • ProfilePage

    • ProfilePage representa una página sobre una persona específica dentro del sitio.
    • Si te presentas en la página principal, puede usarse allí; si tienes una página aparte de about, puede ser más adecuado ponerlo ahí.
    • Es importante conectarlo con el nodo más amplio de WebSite mediante isPartOf.
    • mainEntity le indica al rastreador de quién trata la página.
    • dateCreated y dateModified son útiles como señales de vigencia para los rastreadores, pero si el sitio no puede proporcionarlos fácilmente, no hace falta preocuparse demasiado.

Proyectos y rutas de navegación

  • SoftwareApplication

    • Si una página presenta software, conviene usar un nodo SoftwareApplication para incluir los metadatos de ese software.
    • Como tipos más específicos pueden usarse MobileApplication, WebApplication y VideoGame.
    • La propiedad url debe apuntar al lugar donde se distribuye el proyecto.
    • Un ejemplo sería una página de distribución como crates.io.
    • sameAs se usa para otras páginas vinculadas al proyecto, como el repositorio del código fuente.
    • Los valores válidos de applicationCategory pueden consultarse en la definición de SoftwareApplication de Google.
    • Incluso en proyectos FOSS, debe incluirse offers y establecer el precio en 0.

  • BreadcrumbList

    • BreadcrumbList es ampliamente útil en todas las páginas excepto la raíz.
    • Representa la ruta de clasificación de la página y no tiene por qué coincidir exactamente con la ruta real de la URL.
    • Puede usarse para controlar cómo los motores de búsqueda muestran la ruta de una página concreta.
    • Si la ruta del sitio ya es corta, la utilidad de este nodo es menor y puede omitirse.
    • En sitios con rutas largas, BreadcrumbList ayuda a acortar la ruta mostrada en los resultados de búsqueda.

Páginas de listados, blog y artículos

  • CollectionPage

    • CollectionPage es un subtipo de WebPage que se usa sobre todo en páginas que contienen listados.
    • Ejemplos son una página /elsewhere/ que reúne otros perfiles o una página /blog/ con la lista de artículos del blog.
    • Puede conectarse un nodo Person relacionado mediante about.
    • breadcrumb debe vincularse correctamente con el BreadcrumbList de la página actual.

  • Blog

    • El nodo Blog se agrega al índice o página principal del blog.
    • Cumple el papel de nodo intermedio entre WebSite y cada BlogPosting.
    • dateModified es útil como señal de vigencia, pero si no puede ofrecerse fácilmente, se puede omitir.
    • license permite que los rastreadores sepan en qué condiciones pueden usar los artículos.
    • En un sitio personal, publisher puede establecerse como Person en lugar de Organization.
    • La documentación de Google, a diferencia de antes, también permite válidamente Person, y puede ser más preciso para sitios personales.

  • BlogPosting

    • BlogPosting debe incluirse en todos los artículos de blog publicados.
    • Aporta información adicional para que los rastreadores representen el artículo con mayor precisión.
    • Puede usarse para lograr una ubicación más precisa en resultados de búsqueda y mostrar detalles más ricos.
    • En un sitio personal, no hay problema en que author y publisher apunten al mismo nodo Person.
    • Conviene que la propiedad image coincida con la imagen OG que ya se usa en la vista previa del enlace del artículo.
    • license puede usarse para indicar las condiciones de uso del artículo.

Implementación mínima y criterios de aplicación

  • El JSON-LD necesario para un sitio personal puede organizarse de forma selectiva según el tipo de página.
  • Incluso en un sitio estático sin etapa de build, puede obtenerse beneficio agregando al menos los siguientes nodos en la página raíz:
    • WebSite
    • ProfilePage
    • Person
  • Si hay un blog, pueden añadirse Blog y BlogPosting, y en páginas de listados de artículos o de perfiles externos puede usarse CollectionPage.
  • En páginas de presentación de proyectos puede considerarse SoftwareApplication, y en páginas que no sean la raíz puede evaluarse BreadcrumbList.

Lecturas relacionadas

1 comentarios

 
GN⁺ 8 시간 전
Comentarios de Hacker News

  • Para usar una analogía, se siente como volver a pelear la guerra pasada
    Desde la perspectiva de mi sitio WWW, ahora Google muestra arriba un resumen largo generado por LLM con errores, en vez de enviar a la gente a mis textos reales
    Conseguir un nombre para mostrar bonito en lugar de un “breadcrumb” o del dominio no resuelve la realidad de que Google le da baja prioridad a si pule esos elementos o no
    Es dedicar demasiado esfuerzo a algo que quienes llegan directamente al sitio real nunca verán, y que quienes usan Google tienen difícil de encontrar porque queda enterrado debajo de la propia versión llena de LLM de Google

    • Si queremos un mundo en el que este tipo de datos tenga sentido, primero hay que sembrar
      Aunque Google no lo use, si todo Internet adopta este tipo de metadatos, se crea un terreno fértil para que competidores que no dependan del scraping de LLM puedan ofrecer alternativas
      Rendirse ante Google solo refuerza su dominio, eleva la barrera de entrada para los competidores y los empuja a usar la misma tecnología
    • Totalmente cierto. Nuestra empresa ahora aparece así en la búsqueda de Google:
      $STATE-based IT company specializing in practical AI workflows and information management solutions for Midwest businesses. Operates on an agile fixed-price contract model, focusing on delivering specific outcomes while avoiding enterprise-style bloat
      Yo no sabía que ahora ofrecíamos flujos de trabajo prácticos de IA
      Y luego mezcla el nombre de un competidor con un nombre parecido pero claramente distinto, y me pone como ejecutivo. Lo único rescatable es que el competidor esconde su contacto detrás de un formulario de “reservar consulta”, así que solo muestra nuestro contacto
    • Yo ya no permito que Google rastree e indexe mi sitio
    • Ahora Google también está incluido entre quienes, “si un bot entra al sitio, recibe un zipbomb de 10GB”
      En este momento no agrega ningún valor y solo causa más problemas
    • Exacto. Durante años llené mi sitio web de etiquetas y atributos de microdata esperando que trajeran tráfico
      Al final, lo único que hice fue entrenar la IA de Google para que la gente no salga de Google

  • Si tienes una inclinación práctica, recomiendo leer la documentación de Google para sitios web sobre JSON-LD
    https://developers.google.com/search/docs/appearance/structu...
    También verás que mucha de la información solo aplica a algunos sitios. Rotten Tomatoes puede publicar calificaciones de críticos de cine con JSON-LD, pero aunque yo escriba reseñas de películas, eso no me resulta muy relevante
    JSON-LD es fácil y está bien porque los motores de búsqueda sí lo usan. Puede duplicar información dentro de la página web, pero creo que el sueño de anotarlo todo perfectamente para que la información aparezca exactamente una sola vez en el documento se parece más a una idealización tipo vaca esférica y cuerda sin masa
    Crear una página web requiere esfuerzo humano, y está bien que el resultado final tenga un poco de duplicación

    • Puedes usar JSON-LD para reseñas de películas aunque no seas un sitio grande
      En mi sitio lo uso para reseñas de libros, juegos y películas, y parece que la mayoría de los motores de búsqueda muestran información como las estrellas
    • 403. That’s an error.
      Dice que el cliente no tiene permiso para obtener la URL /search/docs/appearance/structured-data/intro-structured-data de este servidor
    • Pero si duplicas los datos, va a aumentar el consumo de agua. /s

  • Para vistas previas enriquecidas de enlaces, OpenGraph tiene mucho más soporte que JSON-LD
    Si el objetivo es optimización para motores de búsqueda, los tipos de JSON-LD que soportan los motores de búsqueda son muy específicos y limitados. Es mucho mejor revisar la documentación del motor de búsqueda en cuestión, es decir, Google[1] o Bing[2], y seguirla tal cual; todo lo demás está cerca de ser una pérdida de tiempo
    Fuera de los motores de búsqueda, salvo que tengas un propósito específico, JSON-LD por lo general no sirve de mucho. Si tienes un requisito concreto que necesite JSON-LD, entonces mete datos que sean útiles, pero incluir otros datos se parece a gritarle al vacío
    IndieWeb[3] usa datos estructurados, pero considera que JSON-LD viola DRY y en su lugar usa Microformats[4]
    0: https://ogp.me
    1: https://developers.google.com/search/docs/appearance/structu...
    2: https://www.bing.com/webmasters/help/marking-up-your-site-wi...
    3: https://indieweb.org/
    4: https://microformats.org/

  • Lo que realmente conviene implementar en cualquier sitio web son datos estructurados usando el vocabulario de Schema.org
    JSON-LD es una de las formas de hacerlo, y también existen RDFa y Microdata
    Cuando empecé a aprenderlo, tomé este artículo como referencia y vale la pena recomendarlo: https://neilpatel.com/blog/get-started-using-schema/
    Puedes revisar qué datos agregar con esta herramienta: https://technicalseo.com/tools/schema-markup-generator/
    La lista completa se puede ver en el sitio de schema.org: https://schema.org/docs/schemas.html

  • Hace unos años me enteré de que las funciones vistosas en correos electrónicos, como boletos de avión insertados o información de seguimiento de envíos, se implementan totalmente con JSON-LD dentro del correo
    Aunque, hasta donde sé, solo Gmail lo soporta
    Más información: https://www.emailonacid.com/blog/article/email-development/s...

    • Outlook e iCloud también soportan algunas funciones, como boletos o reservaciones

  • Me pregunto si estos atributos realmente ayudan con la visibilidad en búsquedas, o si solo hacen más fácil que los motores de búsqueda mantengan a los usuarios dentro de la página de resultados

    • Después de agregar JSON-LD, Google empezó a mostrar enlaces secundarios hacia secciones dentro de mi sitio. Eso estuvo bien
    • Si es un sitio de negocio, JSON-LD puede usarse para suministrar datos a plataformas de mapas
      Cosas como dirección, horario, teléfono y menú

  • Ya existe el HTML semántico, pero de alguna manera también hay que volver a expresar el significado del sitio web con un JSON raro y personalizado dentro de una etiqueta script que el navegador no procesa

    • He usado JSON-LD en mi sitio web, y creo que cubre una necesidad distinta del HTML semántico
      El HTML semántico define cosas que procesa el navegador, como el título y los encabezados. Los datos de JSON-LD son metadatos como fecha de creación, fecha de modificación, etiquetas y autor
      Eso también puede expresarse dentro del HTML con microdata, pero dejé de usar microdata porque JSON-LD es más fácil
      JSON-LD se llena a partir de los mismos datos con los que se genera el sitio, y con esos metadatos también hago páginas índice, como la lista de posts del blog de 2024 o todos los artículos sobre el tema X. El principal consumidor de JSON-LD son los motores de búsqueda
      Si quieres enojarte más, piensa que también estás metiendo metadatos OpenGraph en la misma página. O sea, hay dos formatos distintos de metadatos en una sola página
    • También existe Microdata y, si no me equivoco, soporta el mismo vocabulario que JSON-LD. schema.org es un buen recurso
      Pero JSON-LD ha sido la opción por defecto desde hace tiempo, un poco como cuando en la práctica dejamos atrás REST y nos fuimos a RPC. No sé si los parsers importantes todavía soportan completamente microdata, y en particular cuando hacía sitios para clientes, como tiendas en línea que querían visibilidad en Google, por defecto usábamos LD
      También hay algo importante al compararlo con HTML semántico. El HTML semántico ayuda a definir la estructura del marcado, pero no llega a expresar contexto del mundo real como “este es un producto en venta” o “este es un horario de trenes”
    • Creo que no entendiste bien el artículo
      Incluso sin JSON-LD ni la etiqueta script, puedes usar ontologías como Schema.org/FOAF/WikiData dentro del HTML
    • En un mundo ideal, el servidor y el navegador podrían hacer negociación de contenido, y el navegador primero pediría solo el JSON-LD del sitio web antes de usar su propio formato interno de renderizado
    • El HTML semántico no cubre el mismo alcance que JSON-LD y otros microformatos
      Con solo ver lo que aparece en el artículo, uno termina preguntándose cuáles son los elementos semánticos para representar personas, listas de breadcrumbs, aplicaciones de software, blogs o publicaciones de blog
      El HTML semántico existe para ayudar a quienes usan lectores de pantalla a navegar por elementos generales como “navegación” o “artículo”

  • ¿Esto no es simplemente OpenGraph escrito en JSON? ¿Cuál es la ventaja?

  • Desde 2024, el tráfico de nuestras páginas de marketing basadas en contenido cayó alrededor de 85%
    Lo que no entiendo es si, con el aumento de las páginas de resultados de búsqueda sin clic, Google no recibió también un golpe fuerte
    Los ingresos por anuncios en páginas de resultados, que dependen de los clics, también deberían haber caído de forma igual de grave, pero no he podido encontrar cifras públicas para refutar o confirmar esa hipótesis

  • Hay un equilibrio delicado donde, a partir de cierto punto, la simbiosis se convierte en explotación
    La relación en la que los sitios web obtenían visibilidad gracias a los motores de búsqueda era, en gran medida, mutuamente beneficiosa
    Pero ahora parece estar yéndose por completo hacia una dirección en la que los dueños de los sitios no obtienen nada del trabajo que hicieron con tanto esfuerzo