¿Cómo saber si un proveedor de creación de sitios web admite datos estructurados?

Al evaluar a un proveedor de creadores de sitios web con datos estructurados, no basta con que responda que «admite datos estructurados». Lo que realmente hay que confirmar es qué páginas se pueden marcar, de dónde proceden los datos, si se sincronizan al modificarlos y quién se encarga de validarlos y mantenerlos tras la publicación. Especialmente para las empresas de comercio exterior con catálogos de productos multilingües, insertar un fragmento de código en una página concreta y gestionar las marcas de todo el sitio a largo plazo son capacidades muy distintas.

Primero, distinga entre admitir la inserción de código y permitir el mapeo de datos empresariales

Los datos estructurados son información que describe el contenido de una página en un formato acordado. Una práctica habitual es utilizar el vocabulario de Schema.org y el formato JSON-LD para indicar a los motores de búsqueda que la página trata de una empresa, un producto u otra entidad. No son etiquetas de palabras clave ni sustituyen el contenido de la página. Aunque un motor de búsqueda detecte las marcas, eso no garantiza la indexación, una mejora del posicionamiento ni la aparición de resultados enriquecidos.

Al evaluar una solución, puede pedir al proveedor que demuestre una acción concreta: modificar en el panel de administración el nombre o la imagen de un producto, publicar la página y comprobar si los datos estructurados se actualizan en consecuencia. Si solo es posible escribir el código manualmente en cada página, quizá sea suficiente para unas pocas páginas fijas; cuando hay muchos productos y se actualizan con frecuencia, el mantenimiento repetitivo puede provocar fácilmente discrepancias entre el contenido de las páginas y las marcas.

Aclare también en qué nivel se añade el código: en una configuración común para todo el sitio, en una plantilla de página o como código personalizado en una página concreta. El código para todo el sitio es adecuado para información corporativa común, pero no para copiar los mismos datos de un producto en todas las páginas de productos. La cuestión no es «si se puede pegar código», sino si se pueden mostrar los datos correspondientes en las páginas adecuadas.

Revise las marcas según el tipo de página, en lugar de intentar usar cuantos más tipos mejor

Un sitio web corporativo suele incluir tipos como Organization, BreadcrumbList y Product; las páginas de artículos pueden incluir Article. La elección debe depender del contenido real de la página y de los requisitos del motor de búsqueda al que se dirija. Schema.org define los vocabularios disponibles, pero la existencia de un tipo no significa que Google u otros motores de búsqueda ofrezcan necesariamente una presentación correspondiente.

En las páginas de productos B2B, es especialmente importante que los campos sean verídicos. El sitio web de un fabricante puede mostrar únicamente especificaciones, aplicaciones y una opción para solicitar información, sin publicar precios ni existencias. En ese caso, no se deben inventar precios, monedas o estados de disponibilidad para completar los campos. Si la página muestra realmente una oferta comercial, compruebe que el precio, la moneda y las condiciones aplicables de las marcas coincidan con lo que aparece en la página.

Si el proveedor presenta una «lista de funciones compatibles», pregunte también por los detalles de cada campo: ¿se puede asignar el modelo del producto a un campo del sistema de administración? ¿La ruta de navegación cambia según la jerarquía de secciones? Cuando se actualizan el nombre, el sitio web o el logotipo de la empresa, ¿se eliminan los datos antiguos? Admitir un tipo no significa que se puedan configurar todos los campos que este requiere.

Compruebe la capacidad de configuración y publicación con una demostración completa

Una forma más fiable que limitarse a revisar una descripción de funciones es pedir al proveedor que complete en un entorno de pruebas todo el proceso de «configuración, publicación, modificación y nueva verificación». Elija una página de detalles de producto y una página de listado o de sección, y observe si se pueden configurar las marcas por separado, si los cambios en las plantillas afectan a otras páginas y qué se muestra en la URL real tras la publicación.

Durante la aceptación, puede centrarse en los siguientes puntos:

• Consulte el código fuente de la página o la página renderizada para confirmar que JSON-LD está presente y que campos como la URL, el nombre y la imagen corresponden al contenido actual.
• Utilice la herramienta de validación de marcado de Schema.org para comprobar la sintaxis y el vocabulario. Para los tipos de resultados enriquecidos que admite Google, use además su herramienta de prueba de resultados enriquecidos para comprobar los aspectos pertinentes.
• Revise tanto las marcas generadas automáticamente por el sistema como las añadidas manualmente para evitar que una misma entidad tenga nombres, URL o precios contradictorios.
• Modifique un campo real y vuelva a publicar para confirmar que el valor anterior ya no aparece. Si es necesario, borre la caché antes de repetir la prueba.

Que una herramienta de validación no muestre errores solo significa que no ha detectado problemas dentro de su ámbito de comprobación; no significa que los datos empresariales sean correctos. Las herramientas tampoco sustituyen la comprobación manual del contenido de la página ni garantizan que aparezca una presentación especial en los resultados de búsqueda. En los sitios web que generan marcas mediante scripts, también hay que confirmar que los motores de búsqueda puedan acceder a los recursos de la página y procesarlos.

En los sitios multilingües, el reto está en las relaciones entre los datos y las responsabilidades de mantenimiento

El nombre, la descripción y la URL de un producto suelen variar entre las páginas en distintos idiomas, mientras que su modelo puede ser el mismo. Durante la evaluación, revise una muestra de cada versión lingüística: ¿las marcas utilizan el idioma y la URL de la página actual? ¿Se puede acceder a las imágenes? ¿La moneda o la oferta son aplicables a esa página? No dé por hecho que todo el sitio multilingüe está configurado correctamente por haber validado solo el idioma predeterminado.

Averigüe también qué información genera automáticamente el sistema y cuál introducen los editores. Por ejemplo, si cambian los datos de contacto de la empresa, pero la información del pie de página y los datos estructurados siguen mostrando los datos antiguos aunque el contenido de la página se haya actualizado, resolver el problema más adelante puede resultar muy laborioso. Es más fiable definir claramente el origen de los campos clave y acordar un proceso de revisión tras las actualizaciones de contenido.

Los equipos que ofrecen servicios integrales de creación de sitios web y marketing suelen participar también en la gestión de contenidos, la optimización para buscadores y las páginas de campañas. La actividad de 易营宝 abarca la creación inteligente de sitios web, los sitios multilingües y el SEO, entre otros ámbitos. Al evaluar este tipo de soluciones, puede incluir en la lista de preguntas la coordinación entre equipos: quién configura los campos, quién revisa las traducciones y la información empresarial, y quién vuelve a validar la configuración tras una actualización de las plantillas. Las capacidades concretas en materia de datos estructurados deben confirmarse mediante una demostración del proyecto y las condiciones de entrega acordadas.

Incluya las condiciones de aceptación en el alcance de la entrega

Antes de contratar, se recomienda pedir al proveedor que detalle las páginas aplicables, los tipos de marcado, el origen de los campos, los permisos de configuración y los métodos de validación, e indique si añadir idiomas o modificar las plantillas de productos requiere desarrollo adicional. En el caso del código personalizado, confirme también si la empresa puede consultarlo, modificarlo o eliminarlo, y cómo se migrará el código al cambiar de plantilla.

La aceptación no tiene que abarcar todas las páginas, pero sí debería incluir muestras de diferentes plantillas y versiones lingüísticas, y conservar las URL de prueba junto con los resultados. Un criterio fiable es comprobar si, después de que el personal de negocio actualice el contenido, el sistema puede mostrar información coherente, el personal técnico puede verificarla de forma independiente y, si surge un problema, se puede identificar claramente a la persona responsable. Solo cuando se cumplen estas condiciones, los datos estructurados pasan a formar parte real del mantenimiento habitual del sitio web.