Edge Schema Injection

1) Configure a route rule at the CDN to trigger a worker on /*product* URLs. 2) Inside the worker, fetch the origin HTML with `cacheTtlByStatus` so the HTML can still be cached downstream. 3) Parse the HTML with a streaming HTMLRewriter or similar API to avoid full DOM cost. 4) Extract SKU, price, availability, and brand from the HTML (use selector queries or regex fail-safes). 5) Build a JSON-LD object that conforms to Schema.org/Product and Google’s price/availability guidelines. 6) Inject the `<script type="application/ld+json">` block just before `</head>` using the same stream to keep TTFB low. 7) Set appropriate `cache-control` headers so the modified response is cached at the edge, not just at the origin. 8) Log a hash of the injected schema to a KV store or logging service for debugging. 9) Test with live `curl -H "User-Agent: Googlebot"` to confirm the schema appears in cached responses. Result: product pages now emit valid schema without touching the origin templates and with only microseconds of additional latency.

Edge Schema Injection places structured data in the raw HTML before it reaches the browser, so Googlebot (which primarily parses the initial HTML) sees the schema without needing a second rendering pass. This avoids JavaScript render queue delays and conserves crawl/render budget. It also centralizes maintenance in the edge worker, so you don’t redeploy the whole site for schema edits. Client-side injection relies on Google’s deferred rendering; the schema is invisible until the rendering phase, increasing crawl latency and the risk of partial indexing. However, JavaScript injection may be simpler if you already control front-end code and don’t have edge scripting. Choose edge injection when: (a) origin templates are untouchable, (b) you need immediate crawler visibility, or (c) you want to A/B test schema at the CDN level. Choose client-side when you have modern SPA infrastructure and no control over CDN scripting or when the schema depends on data only available after client hydration.

Cause 1: Worker cold starts. Mitigation: keep the worker lightweight, use global variables for re-used objects, and enable a keep-alive/ping to warm edges. Cause 2: Full HTML buffering in memory. Mitigation: switch to streaming rewrites that mutate chunks on the fly rather than assembling the entire document. Cause 3: Origin fetch no longer cache-hit because you bypassed caching with `cache-control: private`. Mitigation: set `cacheTtl` headers correctly and respect surrogate keys so the worker can serve cached HTML and only inject schema on cache hits.

First, fetch the rendered HTML through `curl -A 'Googlebot'` to confirm that two Organization objects exist—one from the CMS microdata and one injected by the edge. Next, compare their IDs (`"@id"`) and property sets. Because Google merges graph nodes with identical `@id` values, the duplication arises when the edge injects a second Organization without referencing the first. Fix: in the worker, detect if microdata includes a `url` or `@id` value; use that value as the `@id` in the injected JSON-LD and only add missing properties. Alternatively, suppress Organization injection on pages that already expose it by matching a microdata `itemtype="http://schema.org/Organization"` selector before writing. Re-run the Rich Results Test; the duplicate error should be resolved because Google now sees a single unified node.