Edge Schema Injectie

1) Configureer een routeregel op de CDN om een worker te triggeren op /*product*-URL’s. 2) Haal in de worker de origin HTML op met `cacheTtlByStatus`, zodat de HTML downstream nog steeds gecachet kan worden. 3) Parse de HTML met een streaming HTMLRewriter of een vergelijkbare API om volledige DOM-kosten te vermijden. 4) Extraheer SKU, prijs, beschikbaarheid en merk uit de HTML (gebruik selector­queries of regex-fallbacks). 5) Bouw een JSON-LD-object dat voldoet aan Schema.org/Product en aan Google’s prijs-/beschikbaarheidsrichtlijnen. 6) Injecteer het blok `<script type="application/ld+json">` vlak vóór `</head>` met dezelfde stream om de TTFB laag te houden. 7) Stel passende `cache-control`-headers in zodat de gemodificeerde respons aan de edge wordt gecachet, niet alleen op de origin. 8) Log een hash van het geïnjecteerde schema naar een KV-store of logging-service voor debugging. 9) Test live met `curl -H "User-Agent: Googlebot"` om te bevestigen dat het schema in gecachete responses aanwezig is. Resultaat: productpagina’s sturen nu geldige schema uit zonder de origin-templates aan te passen en met slechts microseconden extra latency.

Edge Schema Injection plaatst gestructureerde data in de ruwe HTML nog vóór deze de browser bereikt, zodat Googlebot (dat voornamelijk de initiële HTML parseert) het schema ziet zonder een tweede renderingsfase. Dit voorkomt vertragingen in de JavaScript-renderqueue en bespaart crawl- en renderbudget. Onderhoud wordt gecentraliseerd in de edge worker, zodat je de hele site niet hoeft te redeployen bij schema-wijzigingen. Client-side injectie vertrouwt op Google’s uitgestelde rendering; het schema blijft onzichtbaar tot de renderfase, wat de crawl-latentie verhoogt en het risico op gedeeltelijke indexering vergroot. JavaScript-injectie kan echter eenvoudiger zijn wanneer je al controle hebt over de front-end code en geen edge-scripting gebruikt. Kies voor edge-injectie wanneer: (a) origin-templates niet aangepast kunnen worden, (b) je onmiddellijke crawler-zichtbaarheid nodig hebt, of (c) je het schema op CDN-niveau A/B wilt testen. Kies voor client-side wanneer je een moderne SPA-infrastructuur hebt en geen controle over CDN-scripting, of wanneer het schema afhankelijk is van data die pas na client-hydratie beschikbaar komt.

Oorzaak 1: cold starts van workers. Oplossing: houd de worker lichtgewicht, gebruik globale variabelen voor hergebruikte objecten en activeer een keep-alive/ping om de edge-locaties warm te houden. Oorzaak 2: volledige HTML-buffering in het geheugen. Oplossing: schakel over op streaming rewrites die chunks on-the-fly muteren in plaats van het volledige document samen te stellen. Oorzaak 3: origin fetch levert geen cache-hit meer omdat caching is omzeild met `cache-control: private`. Oplossing: stel de `cacheTtl`-headers correct in en respecteer surrogate keys zodat de worker gecachete HTML kan serveren en alleen schema injecteert bij cache-hits.

Haal eerst de gerenderde HTML op via `curl -A 'Googlebot'` om te bevestigen dat er twee Organization-objecten aanwezig zijn—één uit de CMS-microdata en één die door de edge is geïnjecteerd. Vergelijk vervolgens hun ID’s (`"@id"`) en property-sets. Aangezien Google grafknooppunten met identieke `@id`-waarden samenvoegt, ontstaat de duplicatie wanneer de edge een tweede Organization injecteert zonder naar de eerste te verwijzen. Oplossing: detecteer in de worker of de microdata een `url`- of `@id`-waarde bevat; gebruik die waarde als `@id` in de geïnjecteerde JSON-LD en voeg alleen ontbrekende properties toe. Alternatief: onderdruk de Organization-injectie op pagina’s die er al een bevatten door vóór het schrijven te controleren op een microdata-selector `itemtype="http://schema.org/Organization"`. Draai de Rich Results Test opnieuw; de foutmelding over duplicaten zou nu verholpen moeten zijn omdat Google één samengevoegde node ziet.