Qué tipos de datos estructurados usar en una web corporativa, cómo conectarlos con JSON-LD y qué errores evitar al implementar Schema.org de forma segura.
Schema describe; no inventa relevancia
Los datos estructurados entregan pistas explícitas sobre el significado de una página. No corrigen una propuesta ambigua, una biografía vacía ni un producto sin explicación. Antes de escribir JSON-LD, hay que comprobar que la información existe en pantalla y coincide con el título, la descripción y los enlaces. Si una página presenta Wiwo.Lab como producto de creative intelligence, el marcado debe describir esa misma oferta, no una lista de capacidades que el usuario no puede encontrar. La regla editorial es simple: toda propiedad importante debe tener un equivalente visible y verificable.
Schema.org funciona cuando describe con precisión el contenido visible y conecta entidades mediante identificadores estables. Para una marca como Wiwo, la prioridad no es agregar todos los tipos posibles, sino construir un grafo coherente entre Organization, WebSite, Service o Product, Article, Person y BreadcrumbList.
Empieza con un grafo base para toda la organización
El home puede declarar Organization y WebSite con identificadores estables mediante @id. La organización reúne nombre, URL, logo, descripción, ubicaciones y perfiles oficiales cuando estén confirmados. WebSite identifica el dominio y su editor. Las páginas interiores pueden referirse a esos mismos @id en author, publisher, provider o isPartOf, evitando recrear entidades ligeramente distintas. Esta continuidad ayuda a que productos, artículos, personas y estudios pertenezcan a una misma arquitectura semántica.
Usa el tipo más específico que la página realmente sostiene
Las páginas de Wiwo.Lab, Wiwo.Ops y Wiwo.Talk pueden evaluarse como Product o Service según el modelo comercial y la información disponible; la decisión debe ser consistente. Los artículos usan Article o BlogPosting con headline, description, image, author, publisher, datePublished y dateModified. Liderazgo puede usar Person cuando la biografía es sustantiva. BreadcrumbList explica jerarquía y ItemList puede ordenar archivos editoriales, aunque no todo tipo produce una apariencia especial en resultados. La especificidad sirve para describir, no para prometer un rich result.
Las preguntas frecuentes deben existir para las personas
Un bloque de FAQ puede modelarse como FAQPage cuando las preguntas y respuestas están visibles y representan el contenido real de esa URL. No conviene generar preguntas ocultas solo para completar Schema. Tampoco se debe confundir FAQPage, donde el editor entrega respuestas, con QAPage, pensado para páginas donde usuarios pueden aportar respuestas. Incluso con marcado válido, un buscador puede decidir no mostrar una apariencia enriquecida. La ganancia principal sigue siendo una página más clara y una descripción semántica fiel.
Valida el grafo como parte de cada publicación
La revisión debe comprobar sintaxis, URLs absolutas, fechas ISO, imágenes rastreables, identificadores estables y paridad con el contenido. También debe detectar nodos duplicados, propiedades vacías y entidades que cambian de nombre entre plantillas. El Rich Results Test ayuda a revisar funciones compatibles con Google; el validador de Schema.org permite inspeccionar vocabulario general. Ninguna validación automática reemplaza una lectura editorial: un JSON-LD puede ser sintácticamente correcto y seguir describiendo mal la página.
