Schema.org para IA: empieza por la página que tienes delante

La etiqueta de una página debe coincidir con lo que el visitante ve

El marcado de Schema.org proporciona al software una descripción estructurada de una página y su tema. Debe explicar lo que la página ya dice, no añadir afirmaciones que un visitante no pueda confirmar.

Empieza por anotar el propósito de la página y su entidad principal. Luego elige el tipo más simple que encaje. La página «Sobre nosotros» de un proyecto y una página de producto no son intercambiables, aunque estén en el mismo sitio web. Esto te da una primera comprobación útil para el schema.org para mejorar visibilidad en IA. ¿Puede una persona señalar el contenido visible detrás de cada dato marcado?

Preferimos un conjunto pequeño que tu equipo pueda mantener antes que un registro abarrotado de propiedades sin respaldo. Para una visión más amplia del trabajo técnico, consulta la guía técnica de AEO.

Empieza por los detalles del proyecto que la gente ya pregunta

Imagina a un fundador cuyo primer lanzamiento pasó desapercibido. La única persona que responde se va de vacaciones y los nuevos visitantes siguen necesitando información clara sobre el proyecto.

Nosotros empezaríamos por las páginas que esos visitantes necesitan, no por una plantilla de marcado grande. Comprobaríamos si el nombre del proyecto, la descripción del producto y los datos de contacto aparecen claramente en el sitio. Luego mapearíamos solo esos hechos visibles a las propiedades adecuadas de schema.org. La página sigue siendo la fuente de verdad; el marcado la sigue.

Imagina que el proyecto tiene una página de producto y un artículo explicativo breve. La página de producto puede admitir Product si realmente describe el producto. El artículo explicativo puede ser adecuado para Article cuando se muestran su autor y los detalles editoriales. Si la página no respalda un campo, déjalo fuera y pide primero al responsable del proyecto que aclare la fuente.

Esto también facilita la transferencia del trabajo. Un compañero puede seguir la conexión entre cada campo y la página en lugar de adivinar por qué se añadió. Para más información sobre cómo crear páginas fuente útiles, visita contenido citable para asistentes de IA.

¿Qué tipos de schema encajan en las distintas partes de un sitio de proyecto?

El tipo de schema adecuado depende de lo que representa una página concreta. Un sitio web de proyecto puede usar varios tipos en distintas URL, siempre que cada uno refleje el contenido visible.

Empieza por el sitio y sus páginas

Organization puede describir el proyecto o la empresa detrás del sitio. WebSite describe el sitio web en su conjunto, mientras que WebPage describe una URL individual. Estos tipos se pueden conectar cuando la relación es real y clara. Mantén los nombres y los datos públicos coherentes entre la página y su marcado.

Añade tipos específicos de contenido solo donde encajen

Article puede ser adecuado para un recurso editorial con autor o detalles de publicación visibles. Product puede encajar en una página que presenta genuinamente un producto. SoftwareApplication puede ser adecuado para una página que describe software, si los detalles representados en el marcado tienen respaldo allí.

Por ejemplo, una página que explica una funcionalidad de software podría revisarse para determinar si es adecuada para SoftwareApplication. Si solo habla del proyecto en general, añadir ese tipo podría describirlo incorrectamente. Una revisión página por página evita que una plantilla se copie en páginas diferentes.

Un objeto JSON-LD puede ser pequeño y legible. Aquí, el nombre y la dirección son ilustrativos, no datos reales sobre tu proyecto:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Proyecto Ejemplo",
  "url": "https://ejemplo.org/"
}

Usa los datos públicos reales de tu sitio y luego comprueba que la página renderizada los respalda. Para páginas de preguntas, la optimización de FAQ puede ayudarte a planificar las respuestas visibles antes de considerar el marcado.

Un pase tranquilo de cinco pasos: de la lista de páginas al JSON-LD verificado

Una lista de páginas y una comprobación breve de evidencias facilitan la revisión del trabajo con schema. Usamos esta secuencia para mantener cada registro conectado con la página que describe.

1. Elige las URL prioritarias. Enumera las páginas que importan primero. Anota el propósito de cada página, su entidad principal y su dirección canónica.
2. Selecciona un tipo adecuado. Decide si la página describe la organización, el sitio web, un artículo, un producto, un software u otro asunto apropiado.
3. Rastrea cada propiedad. Anota dónde puede ver el visitante ese dato, o qué fuente fiable del proyecto lo confirma. Elimina los campos sin respaldo claro.
4. Añade el JSON-LD a la página correspondiente. Verifica que sus URL apunten a la página prevista y que su sintaxis sea correcta. Compara el registro con el contenido renderizado.
5. Revisa después de las ediciones. Comprueba el marcado relacionado cuando cambie una página, un detalle del producto, el autor o un dato de la organización.

Recomendamos que un editor o responsable del producto confirme la identidad y las afirmaciones sobre el producto antes de publicar. Esa revisión detecta nombres incorrectos y descripciones desactualizadas cuando aún son fáciles de corregir. Guarda la lista de verificación con las notas de la página, para que un futuro editor pueda repetir las mismas comprobaciones sin tener que reconstruir el razonamiento desde cero. Si también estás considerando cómo implementar llms.txt, mantén esa tarea separada: el archivo y el marcado de la página hacen trabajos distintos.

El límite entre los datos estructurados y las plataformas de IA

Los datos estructurados pueden hacer que los detalles de una página sean más explícitos. Pero no pueden dirigir cómo ChatGPT, Perplexity, Google u otra plataforma selecciona o presenta la información. La documentación de Google describe los datos estructurados como una forma de ayudarle a entender el contenido y evaluar la elegibilidad para ciertas apariencias en los resultados. Que se muestre o no una apariencia sigue siendo decisión de Google. Ningún tipo de schema puede prometer una cita o una respuesta concreta.

Ese límite te da una prueba de calidad útil para tu equipo. Comprueba si la página responde a una necesidad real del lector, si sus afirmaciones están respaldadas y si el marcado refleja el texto visible. Si los datos se analizan correctamente pero la página es vaga, mejora la página antes de añadir más propiedades. Si la descripción de un proyecto cambia, actualiza la página y luego revisa el registro relacionado.

Guarda notas sobre qué cambiaste y por qué. Así, la siguiente persona podrá saber si un campo representa un detalle real de la página o una suposición antigua. Cuando compares lo que muestran ChatGPT y Perplexity, registra lo que cada plataforma muestra realmente. No trates el marcado como la causa de una mención u omisión. Nuestra guía sobre visibilidad en búsqueda con IA cubre el panorama editorial más amplio.

Mantén un registro pequeño que tu equipo pueda retomar

Un registro de revisión compacto ayuda al equipo a mantener separados los datos de la página, las comprobaciones del marcado y las observaciones de visibilidad. También hace que la próxima actualización de contenido tenga menos probabilidades de dejar atrás detalles antiguos.

Para cada URL prioritaria, anota su tipo previsto, dirección canónica, fecha de la última revisión y estado de validación. Añade una nota breve cuando la página cambie de forma que pueda afectar a sus datos estructurados. Luego guarda las observaciones de las plataformas en un lugar aparte: registra la pregunta comprobada, la plataforma, la fecha de la comprobación y lo que mostró. Estas notas describen lo que tu equipo vio; no establecen por qué una plataforma eligió una fuente concreta.

Usa un conjunto pequeño de preguntas que los visitantes reales podrían hacer sobre el proyecto. Repítelas cuando revises la página y compara la respuesta con lo que dice la página publicada. Si una respuesta omite un detalle importante, inspecciona la redacción y la información de la fuente antes de cambiar el schema. Esto mantiene el trabajo basado en contenido que la gente puede verificar.

Si deseas una revisión técnica más amplia, llms.txt y configuración del rastreador de IA explica una parte separada de ese trabajo. Para empezar tu propia revisión, reúne unas pocas URL prioritarias, las preguntas que hace tu audiencia y cualquier exportación de schema existente. Nosotros podemos ayudarte a comprobar la correspondencia entre página y marcado y devolver correcciones claras para tu equipo.

Cómo trabajamos

1. Enumera las páginas prioritariasRegistra el propósito, la entidad principal y la dirección canónica de cada URL.
2. Selecciona los tipos de páginaElige tipos que describan el propósito visible de cada página.
3. Rastrea los datosConecta cada propiedad con contenido visible o una fuente fiable del proyecto.
4. Añade y verifica el JSON-LDColócalo en la página que describe, prueba su sintaxis y compara sus datos con la página renderizada.
5. Revisa después de las edicionesVuelve a comprobar el marcado cuando cambien el contenido de la página relacionada o los detalles del proyecto.