Datos Estructurados y Construcción de Entidades

Los datos estructurados y la construcción de entidades convierten los hechos aprobados del sitio en una capa legible por máquinas. Identifica las personas, organizaciones, productos, artículos, preguntas, pasos y rutas de navegación que realmente existen, asigna identificadores estables y expresa relaciones comprobables. Nunca inventa una segunda versión del contenido.

Fase: P13, Datos Estructurados y Construcción de Entidades. Etapa: C — Construir. Tiempo estimado: 3–5 días hábiles para un sitio con un conjunto pequeño de plantillas estables; 1–2 semanas para un marketplace, editorial o catálogo de comercio electrónico con múltiples sistemas de contenido. Responsable: el líder técnico de SEO es el responsable, con ingeniería implementando las plantillas, los dueños de contenido confirmando los hechos visibles y los responsables de marca o legal aprobando los registros canónicos de entidades.

Los buscadores generalmente tratan el schema como una señal más entre el contenido de la página, los enlaces, los feeds y otras evidencias. Los sistemas de recuperación de IA pueden tratar cada vez más la capa estructurada como una fuente directa de hechos y relaciones. Un precio, autor, nombre de organización o relación incorrectos pueden, por lo tanto, extraerse con confianza porque parecen explícitos. El marcado mejora la interpretación; no puede hacer que una afirmación no respaldada sea verdadera.

Por qué esta fase, y por qué aquí

P13 consume decisiones tomadas antes en el proceso. El mapa temático identifica qué página es dueña de cada intención y entidad. El inventario de contenido identifica duplicados y URLs heredadas. El sistema de producción estabiliza campos como autor, fecha de revisión, precio, disponibilidad y texto de FAQ. La optimización en página hace visibles esos hechos, mientras que el trabajo de enlazado interno corrige la jerarquía y los destinos canónicos. Solo entonces una plantilla de schema puede describir una página estable en lugar de codificar un objetivo cambiante.

Realizar esta fase demasiado temprano produce ficción técnicamente válida. Un desarrollador puede marcar cada página editorial como Article antes de que el negocio decida si la firma representa a una persona, un equipo o la organización. Una plantilla de producto puede exponer un precio de oferta que la página visible luego reemplaza con «contáctenos». El marcado de migas de pan puede preservar una jerarquía antigua después de cambios en la navegación. Cada objeto se analiza, pero cada uno le dice a las máquinas algo diferente de lo que las personas ven.

Saltarse la fase deja que los sistemas infieran más de lo necesario. Pueden entender la página igualmente, pero los nombres, relaciones, fechas, autoría y hechos del producto permanecen ambiguos. Esto debilita la desambiguación de entidades : el proceso de decidir a qué persona, empresa, producto o lugar real se refiere un nombre. También dificulta el mantenimiento futuro porque nadie es dueño de los identificadores y campos fuente detrás del marcado.

El resultado no es «schema agregado». Es un mapeo probado de plantillas de página a tipos de schema justificados, un registro canónico de entidades, evidencia de validación en vivo y una regla de monitoreo. P14, relaciones públicas digitales y citas fuera del sitio, necesita ese contrato para que los perfiles externos, la cobertura y las referencias refuercen los mismos nombres e identificadores en lugar de crear nuevas variantes.

Entradas y salidas

La matriz de cobertura establece el contrato con la implementación; el registro de entidades establece el contrato con la siguiente fase. La evidencia de validación y el monitoreo mantienen ambos actualizados.

La lista de verificación

Cada elemento a continuación incluye el trabajo, su razón, el método, la herramienta y una condición de finalización. Conserva esos cinco campos si la lista se traslada a un sistema de tiquetes.

1. Inventariar plantillas y seleccionar muestras de página elegibles

Qué: enumerar cada plantilla dentro del alcance y elegir URLs representativas en vivo, incluyendo variantes con campos opcionales faltantes. Por qué: un ejemplo ideal no puede exponer errores condicionales como un producto sin reseñas, un artículo sin un autor nombrado o una categoría sin padre de miga de pan. Cómo: agrupar URLs por plantilla de renderizado y fuente de contenido, luego seleccionar al menos una URL completa, una mínima y una de caso límite por plantilla. Herramienta: el inventario de páginas, exportación de rastreador, modelo de CMS y navegador. Terminado cuando: el 100% de las plantillas dentro del alcance tienen al menos tres muestras, o todas las URLs en vivo cuando una plantilla tiene menos de tres.

2. Elegir solo tipos de schema que se ganen su lugar

Qué: asignar tipos según la función visible de la página. Por qué: los tipos adicionales aumentan la superficie de contradicciones sin generar derecho a un resultado. Cómo: usar el tipo preciso más estrecho y documentar por qué existe cada objeto:

• Schema de artículo o BlogPosting pertenece a contenido editorial con un titular visible, autor o editor, y contexto de publicación. Usa el más amplio Article cuando un subtipo más estrecho sería engañoso.
• Schema FAQ pertenece solo donde los usuarios ven las preguntas y respuestas completas. El valor semántico y la elegibilidad especial para presentación en búsqueda son cosas separadas.
• HowTo pertenece a un procedimiento ordenado visible. Tres beneficios de marketing no son un how-to.
• Schema de producto pertenece a un producto o variante específica. Las ofertas, moneda, disponibilidad, calificaciones y reseñas deben coincidir con la página.
• Schema de organización pertenece a la representación canónica de la organización y puede ser referenciado mediante un @id estable en otros lugares.
• Person pertenece a un perfil canónico con suficiente información visible para identificar a la persona. Una firma simple no justifica credenciales.
• Schema BreadcrumbList debe reflejar una jerarquía que los usuarios puedan entender, no una ruta artificial de palabras clave.

Herramienta: la matriz de cobertura, páginas visibles, vocabulario de schema.org y la documentación actual de elegibilidad de la plataforma de búsqueda. Terminado cuando: cada tipo seleccionado tiene una justificación de una oración, una fuente visible y una regla de exclusión explícita para páginas donde no debe renderizarse.

3. Construir el registro canónico de entidades

Qué: crear un registro mantenido para cada organización, persona, familia de productos y ubicación importante. Por qué: los identificadores consistentes permiten que páginas separadas se refieran a lo mismo; los nombres inconsistentes hacen que las máquinas decidan si «AmICited», «Am I Cited» y un nombre legal de empresa son una entidad o varias. Cómo: registrar el nombre público preferido, el nombre legal cuando sea relevante, alias, página canónica, tipo de entidad, @id estable, responsable y referencias sameAs autoritativas. Un valor sameAs afirma identidad, no relevancia temática, por lo que debe apuntar solo a un registro o perfil oficial que represente la misma entidad.

Una página canónica es dueña de la definición completa de cada entidad; otras páginas referencian su @id en lugar de crear competidores. La URL canónica de una página identifica la página preferida para la indexación, mientras que @id identifica la cosa descrita. Por ejemplo, la entidad puede ser https://ejemplo.com/acerca-de/#organization mientras la página sigue siendo https://ejemplo.com/acerca-de/.

Herramienta: registro de entidades, registros del CMS, datos fuente de recursos humanos o legales, perfiles oficiales y registros públicos autoritativos. Terminado cuando: el 100% de las entidades materiales usadas en el marcado tienen un nombre preferido, una página canónica o excepción aprobada, un @id estable, un responsable y ningún conflicto de identidad sin resolver.

4. Mapear propiedades a campos fuente visibles

Qué: conectar cada propiedad del schema al campo que renderiza el hecho visible. Por qué: la duplicación manual crea desviación; el mismo precio o autor almacenado dos veces eventualmente discrepará. Cómo: mapear headline al título visible, author al registro de firma publicado, dateModified a una fecha de actualización visible significativa, los campos de oferta a la fuente de comercio orientada al cliente, los objetos de FAQ a las respuestas renderizadas y las posiciones de migas de pan a la jerarquía real. No poblar una propiedad porque está disponible en un complemento si su fuente está oculta, desactualizada o es semánticamente diferente.

Herramienta: schema del CMS, código de plantilla, feed de comercio, API de contenido y mapa de campos. Terminado cuando: cada propiedad material tiene una fuente nombrada, regla de transformación, comportamiento de respaldo y responsable; cero valores materiales se mantienen de forma independiente en el marcado y el contenido visible.

5. Implementar un grafo JSON-LD conectado

Qué: renderizar los objetos aprobados y conectarlos con identificadores estables. Por qué: los bloques desconectados pueden describir la misma organización o autor como cosas separadas, mientras que las referencias estables expresan relaciones claramente. Cómo: usar JSON-LD —Notación de Objetos JavaScript para Datos Enlazados— a menos que la plataforma existente requiera otro formato soportado. Usar referencias @id para el editor, autor, marca del producto y entidad principal en lugar de repetir definiciones parciales. Mantener la salida legible por servidor cuando sea posible y escapar de forma segura las cadenas controladas por el usuario.

El resultado es un pequeño grafo de conocimiento a nivel de página: entidades y sus relaciones. Incluir hechos que las identifiquen o califiquen en esta página, no cada propiedad disponible.

Herramienta: motor de plantillas, revisión de control de fuentes, fuente del navegador y un analizador JSON. Terminado cuando: todas las muestras seleccionadas generan objetos analizables, cada @id interno se resuelve a una definición o referencia prevista, los campos opcionales desaparecen limpiamente cuando están ausentes y ninguna plantilla emite valores vacíos o de marcador de posición.

6. Realizar revisión de paridad de contenido visible

Qué: comparar cada hecho material marcado con lo que un usuario puede ver en la misma URL. Por qué: los datos estructurados son una afirmación explícita, no un escondite para contenido. Los sistemas de búsqueda pueden ignorar el marcado engañoso, eliminar la elegibilidad o aplicar políticas de acción manual; los sistemas de IA pueden repetir el valor incorrecto como si fuera autoritativo. Cómo: comparar la página renderizada y el grafo extraído lado a lado. Verificar nombres, autoría, credenciales, fechas, precios, disponibilidad, moneda, calificaciones, conteo de reseñas, preguntas, respuestas, pasos y etiquetas de migas de pan.

Herramienta: página renderizada, JSON-LD extraído, vista previa del CMS y fuente de comercio. Terminado cuando: el 100% de las propiedades materiales coinciden con el contenido visible en significado, unidades, alcance y actualidad en las muestras completas, mínimas y de caso límite.

7. Validar sintaxis, elegibilidad, canónicos e interpretación en vivo

Qué: probar el grafo generado en cuatro capas. Por qué: un JSON válido puede usar la propiedad incorrecta; un schema válido puede no cumplir los requisitos de una función de búsqueda; una página correcta puede seguir sin estar indexada; y Google puede seleccionar otro canónico. Cómo: primero analizar el JSON. Segundo, validar el vocabulario y los requisitos específicos del tipo. Tercero, inspeccionar los veredictos de resultados enriquecidos y elementos detectados de la URL en vivo. Cuarto, confirmar el estado de indexación y el canónico seleccionado. Separar errores de advertencias, y separar elegibilidad de visualización real.

Herramienta: validador de schema, la herramienta de prueba de la plataforma de búsqueda relevante y la Inspección de URL de AmICited. Terminado cuando: no hay errores de sintaxis, cero propiedades requeridas inválidas o no soportadas, cero errores de resultados enriquecidos no resueltos en plantillas elegibles, cada advertencia tiene un responsable o una razón documentada de no aplicabilidad, y la URL inspeccionada en vivo está indexada bajo el canónico previsto.

8. Establecer monitoreo de regresión y responsabilidad de cambios

Qué: automatizar verificaciones y definir eventos que exijan revalidación. Por qué: el schema se degrada silenciosamente cuando un campo del CMS se renombra, un componente se oculta, una fuente de precio cambia o un despliegue de JavaScript deja de inyectar el grafo. Cómo: ejecutar fixtures de plantilla en pruebas de lanzamiento, rastrear URLs representativas en vivo, comparar los tipos detectados y los conteos de error con la línea base, y suscribirse a los informes de la plataforma de búsqueda. Disparar una revisión específica después de cambios en plantillas, navegación, autoría, identidad de organización, campos del catálogo, reglas canónicas o componentes visibles de FAQ y pasos.

Herramienta: pruebas automatizadas, rastreador programado, registro de despliegue, Inspección de URL y una cola de incidencias asignada. Terminado cuando: cada plantilla crítica se verifica antes del lanzamiento y al menos semanalmente en producción, las fallas crean una alerta asignada dentro de un día hábil y el registro de entidades tiene una fecha de revisión trimestral.

Herramientas en AmICited

AmICited soporta dos partes diferentes del flujo de trabajo. No deben fusionarse en una sola puntuación porque la accesibilidad y la interpretación de datos estructurados responden a preguntas distintas.

Abre Accesibilidad para IA en https://app.amicited.com/accessibility para verificar que los agentes de IA puedan alcanzar y extraer la estructura de la página que el marcado pretende describir. Un grafo perfecto es irrelevante si un rastreador recibe una página de desafío, un shell renderizado por el cliente o acceso bloqueado. Usa esta verificación en las mismas URLs representativas y condiciones de agente de usuario utilizadas para la muestra de schema.

Abre Inspección de URL en https://app.amicited.com/reports/google-search/url-inspection para el veredicto en vivo de Google. Inspecciona el canónico previsto, el estado de indexación, el veredicto de resultados enriquecidos y los nodos de schema.org detectados. Revisa los totales de objetos, errores y advertencias en lugar de tratar «marcado detectado» como un aprobado. Actualiza después de un despliegue cuando un resultado en caché no representaría la nueva plantilla.

Registra ambas URLs del informe, la página inspeccionada, la hora, el resultado y la captura de pantalla para que el siguiente revisor pueda reproducir la verificación.

Reglas de decisión

Los números convierten la «calidad del schema» en una decisión de lanzamiento. Estos umbrales miden la integridad de la implementación, no posiciones prometidas, resultados enriquecidos o citaciones.

Aprobar no garantiza un resultado enriquecido ni una citación de IA; estos umbrales rigen la precisión y el mantenimiento, no la selección.

Entregable

Entregar un paquete versionado con cuatro artefactos: la matriz de cobertura, el registro de entidades, el registro de validación y la especificación de monitoreo. Una hoja de cálculo, base de datos o archivo de repositorio es aceptable si los campos son exportables y los responsables pueden actualizarlos sin reconstruir el método.

MATRIZ DE COBERTURA DE SCHEMA
Plantilla | URLs de ejemplo | Tipos incluidos | Tipos excluidos y razón
Propiedad | Campo fuente visible | Respaldo | Responsable de implementación

REGISTRO DE ENTIDADES
Tipo de entidad | Nombre preferido | Nombre legal | Alias
Página canónica | @id estable | Referencias sameAs | Responsable del registro | Fecha de revisión

REGISTRO DE VALIDACIÓN
URL | Plantilla | Hora de prueba | Versión desplegada
Resultado de análisis | Tipos detectados | Errores | Advertencias | Paridad visible
Estado de indexación | Canónico de Google | Veredicto de resultados enriquecidos | Enlaces de evidencia

ESPECIFICACIÓN DE MONITOREO
Plantilla | URLs de prueba | Frecuencia de verificación | Condición de alerta
Responsable | Tiempo de respuesta | Última pasada | Próxima revisión de entidad

La transferencia se acepta cuando ingeniería puede identificar la regla de plantilla detrás de cualquier objeto en vivo, contenido puede identificar la fuente visible detrás de cualquier valor material y el responsable de la siguiente fase puede identificar el registro canónico de la entidad sin abrir el código.

Lo que sale mal

Un complemento marca todo. La página de inicio se convierte en un Article, las tarjetas de categoría en productos y cada acordeón en una FAQ. Corrige la matriz de cobertura; la configuración sigue el propósito de la página.

El marcado y el contenido visible usan bases de datos diferentes. La oferta dice «en stock» después de que la página dice no disponible. Genera ambas representaciones desde el mismo campo y prueba la latencia de actualización.

Cada página redefine la organización. Nombres, logotipos y perfiles se desvían. Defínelo una vez con un @id estable, luego referéncialo.

sameAs se convierte en un vertedero de enlaces. Menciones y empresas con nombres similares se afirman como idénticas. Conserva solo los registros autoritativos y perfiles controlados para la misma entidad.

El marcado FAQ o HowTo oculta la respuesta. Si los usuarios ven solo un adelanto o un paso bloqueado, renderiza el contenido completo marcado o elimina las propiedades.

La validación se detiene en un generador. La plantilla en vivo puede duplicar objetos, escapar JSON incorrectamente o fallar para los rastreadores. Valida la página desplegada y su interpretación en el índice.

Las advertencias se ignoran por completo o se tratan como fallos. Triar cada una por consecuencia, registrar la decisión y revisarla cuando cambien los requisitos o las plantillas.

El schema recibe crédito por resultados que no puede garantizar. Rastrea la validez por separado de la presentación en búsqueda, el tráfico, las citaciones de IA y las conversiones.

Siguiente fase

P14 son relaciones públicas digitales y citas fuera del sitio. Necesita el registro de entidades, no solo código. La cobertura, los perfiles, las asociaciones y los directorios deben usar el nombre aprobado, el destino canónico y el lenguaje de relación; de lo contrario, la evidencia externa puede fortalecer la identidad equivocada.

El responsable de P13 entrega:

• el nombre preferido aprobado, alias, página canónica e identificador estable para cada entidad dentro del alcance de la campaña;
• los registros autoritativos ya conectados con sameAs, incluyendo cualquier vacío que no deba llenarse sin verificación;
• los tipos de página y schema que describen cada entidad, para que las afirmaciones de divulgación coincidan con los hechos del sitio;
• los conflictos no resueltos, como un nombre legal que difiere de la marca pública o dos expertos con nombres similares;
• el responsable de monitoreo que debe revisar los cambios de identidad creados por nuevos perfiles, cambios de marca, adquisiciones o movimientos de autores.

La siguiente fase puede comenzar cuando un editor externo pueda identificar y enlazar la entidad correcta usando solo este paquete. Espera mientras la propiedad, el nombre o la identidad sigan siendo cuestionados.

FAQ

Preguntas frecuentes