Inyección de schema en el edge

1) Configura una regla de ruta en el CDN para activar un worker en URLs del tipo /*product*. 2) Dentro del worker, recupera el HTML de origen con `cacheTtlByStatus` para que el HTML siga pudiendo almacenarse en caché aguas abajo. 3) Analiza el HTML con un HTMLRewriter en streaming o una API similar para evitar el coste de procesar todo el DOM. 4) Extrae SKU, precio, disponibilidad y marca del HTML (usa consultas de selectores o expresiones regulares como método de respaldo). 5) Construye un objeto JSON-LD que cumpla con Schema.org/Product y con las directrices de precio/disponibilidad de Google. 6) Inyecta el bloque `<script type="application/ld+json">` justo antes de `</head>` usando el mismo stream para mantener bajo el TTFB. 7) Establece los encabezados `cache-control` apropiados para que la respuesta modificada se almacene en caché en el edge, no solo en el origen. 8) Registra un hash del esquema inyectado en un KV store o servicio de logging para depuración. 9) Prueba en vivo con `curl -H "User-Agent: Googlebot"` para confirmar que el esquema aparece en las respuestas cacheadas. Resultado: las páginas de producto ahora emiten un esquema válido sin tocar las plantillas de origen y con solo microsegundos adicionales de latencia.

La inyección de schema en el edge coloca los datos estructurados en el HTML sin procesar antes de que llegue al navegador, de modo que Googlebot (que principalmente analiza el HTML inicial) vea el schema sin necesitar una segunda pasada de renderizado. Esto evita las demoras de la cola de renderizado de JavaScript y conserva el presupuesto de rastreo/renderizado. Además, centraliza el mantenimiento en el worker del edge, por lo que no es necesario volver a desplegar todo el sitio para modificar el schema. La inyección del lado del cliente depende del renderizado diferido de Google; el schema es invisible hasta la fase de renderizado, lo que incrementa la latencia de rastreo y el riesgo de indexación parcial. Sin embargo, la inyección mediante JavaScript puede resultar más sencilla si ya controlas el código front-end y no dispones de scripting en el edge. Elige la inyección en el edge cuando: (a) las plantillas de origen son intocables, (b) necesitas visibilidad inmediata para el rastreador, o (c) quieres realizar pruebas A/B del schema a nivel de la CDN. Opta por la inyección del lado del cliente cuando dispongas de una infraestructura SPA moderna y no tengas control sobre el scripting de la CDN, o cuando el schema dependa de datos que solo están disponibles tras la hidratación del cliente.

Causa 1: cold starts del worker. Mitigación: mantén el worker ligero, usa variables globales para los objetos reutilizados y habilita un keep-alive/ping para calentar los edges. Causa 2: almacenamiento en búfer completo del HTML en memoria. Mitigación: cambia a reescrituras en streaming que modifiquen los chunks al vuelo en lugar de ensamblar todo el documento. Causa 3: la petición al origen ya no resulta en un cache-hit porque se omitió la caché con `cache-control: private`. Mitigación: configura correctamente las cabeceras `cacheTtl` y respeta las surrogate keys para que el worker pueda servir HTML cacheado e inyectar schema solo en los aciertos de caché.

Primero, recupera el HTML renderizado con `curl -A 'Googlebot'` para confirmar que existen dos objetos Organization: uno proveniente de los microdatos del CMS y otro inyectado por el edge. Luego, compara sus IDs (`"@id"`) y conjuntos de propiedades. Debido a que Google fusiona los nodos del grafo con el mismo valor de `@id`, la duplicación se produce cuando el edge inyecta un segundo Organization sin hacer referencia al primero. Solución: en el worker, detecta si los microdatos incluyen un valor de `url` o `@id`; utiliza ese valor como `@id` en el JSON-LD inyectado y añade solo las propiedades faltantes. Como alternativa, suprime la inyección de Organization en las páginas que ya lo exponen, detectando un selector microdata `itemtype="http://schema.org/Organization"` antes de escribir. Vuelve a ejecutar la Prueba de resultados enriquecidos; el error de duplicado debería resolverse porque Google ahora ve un único nodo unificado.