Comience por la página y una función compatible
No empiece añadiendo todos los tipos de schema.org que suenen relacionados con su negocio. Schema.org es un vocabulario amplio compartido, mientras que la Search Gallery de Google documenta las funciones de resultados enriquecidos que admite y las propiedades que necesitan. Una página de producto, evento o artículo debe ser útil sin marcado.
Para cada plantilla, nombre su sujeto principal y los hechos visibles que lo acompañan. Luego lea la guía actual de Google para la función correspondiente. Producto, Receta, Artículo, Breadcrumb (migas de pan), Evento, Organización, Negocio local y Vídeo son ejemplos. Un tipo de vocabulario por sí solo no crea una función de Google; las propiedades requeridas de esa función determinan la elegibilidad.
Haga que el elemento principal visible sea el marcado principal.
Use la guía de Google para el comportamiento de la función y schema.org para el vocabulario.
Haga de la página visible la fuente de la verdad
El marcado debe representar el contenido principal de la página, no material oculto, irrelevante o engañoso. Si dice que un intérprete aparece, la página debe describir a ese intérprete. Si marca una valoración agregada, los visitantes deben ver esa valoración. Esto evita que una plantilla derive hacia un resumen engañoso.
Construya el texto de la página y el marcado a partir de los mismos registros aprobados. Un feed de productos, un sistema de eventos o un CMS pueden suministrar ambos, pero los valores necesitan revisión antes de publicarse. No copie un precio, estado de stock, fecha o total de reseñas en un campo solo para marcado que pueda olvidarse. Actualice o elimine el marcado cuando la información visible cambie.
Mantenga nombres, fechas, precios, disponibilidad y valoraciones alineados con la página.
Nunca rellene propiedades con valores supuestos o desactualizados.
Use JSON-LD como una capa de datos mantenible
JSON-LD es un formato de datos vinculados basado en JSON que se coloca en un documento HTML. Google admite JSON-LD, Microdata y RDFa, y dice que JSON-LD suele ser el más fácil de implementar y mantener a escala. Su separación del marcado visible puede facilitar modelar información anidada.
Use un objeto de datos claro para cada elemento real, con un tipo apropiado de schema.org y propiedades admitidas y precisas. Para cada plantilla, documente la guía de la función, el campo de origen, el comportamiento de campos obligatorios y el propietario. Inspeccione la salida representada también: un complemento o componente puede añadir marcado duplicado o en conflicto.
Elija el formato que su equipo pueda mantener de forma coherente.
No invente un valor requerido cuando los datos de origen están ausentes.
Valide el código y la página accesible
La validación responde a dos preguntas. Primero, ¿el marcado es lo bastante completo para una función compatible? Rich Results Test acepta código pegado o una URL pública accesible e informa los resultados enriquecidos que pueden generarse a partir de los datos estructurados. Pruebe ejemplos representativos para cada plantilla, no una página inusualmente completa.
Segundo, ¿puede Google acceder a la página publicada y a sus recursos? No bloquee páginas con marcado mediante robots.txt, noindex o controles de acceso. Verifique las URLs relevantes de imágenes. La prueba no es una garantía de calidad: problemas de contenido visible o de política aún pueden impedir la visualización.
Pruebe el código primero y luego una URL pública accesible.
Compare la página renderizada, la fuente y el resultado de la prueba cuando las herramientas añaden marcado.
La posible visualización no es una promesa de visualización eventual.
Publíquelo como un cambio de plantilla orientado al usuario
Los datos estructurados a menudo dependen de plantillas, feeds y reglas de publicación. Un rediseño, un cambio de integración de inventario, una actualización de localización o un componente eliminado puede romper muchos elementos. Añada comprobaciones representativas de marcado a la revisión previa al lanzamiento que usa para etiquetas canónicas, títulos e imágenes. Registre la plantilla, ejemplos de páginas, campos de origen y fecha de lanzamiento.
Cuando una plantilla emite marcado incorrecto, corrija la fuente compartida o la plantilla, valide una muestra pequeña, despliegue el cambio más estrecho y seguro y vuelva a probar las URLs afectadas. Si la corrección se comporta de forma inesperada, use su proceso normal de reversión. El objetivo es una remediación basada en evidencia de una capacidad web degradada, no una alerta de caída.
Compruebe conjuntos representativos de páginas, no una única URL.
Registre el cambio y el componente de marcado antes de una corrección posterior.
Mantenga, mida y acepte el límite de visualización
Después del despliegue, use el informe relevante de resultados enriquecidos de Search Console para investigar problemas y confirmar correcciones. Los informes son muestreos más que un inventario completo, y las cuentas se refieren a elementos, no a páginas. Inspeccione una URL específica cuando sea necesario.
Mida con cautela. Google sugiere una comparación antes y después en páginas estables y con suficientes lecturas durante meses en Search Console. Registre la fecha de lanzamiento y otros cambios de página. Corregir el marcado solo habilita la elegibilidad; Google determina la presentación en la búsqueda.
Vuelva a comprobar después de cambios en el CMS, plantilla, feed, política o modelo de contenido.
Evite comparaciones donde otros cambios importantes de página difieran.