Edge-Schema-Injektion

1) Konfiguriere im CDN eine Routenregel, die bei /*product*-URLs einen Worker auslöst. 2) Hole im Worker die Origin-HTML mit `cacheTtlByStatus`, damit das HTML weiterhin downstream gecacht werden kann. 3) Parse die HTML per Streaming-HTMLRewriter oder ähnlicher API, um die vollständigen DOM-Kosten zu vermeiden. 4) Extrahiere SKU, Preis, Verfügbarkeit und Marke aus dem HTML (nutze Selektor-Abfragen oder Regex-Fallbacks). 5) Erstelle ein JSON-LD-Objekt, das der Schema.org/Product-Spezifikation und den Google-Richtlinien für Preis & Verfügbarkeit entspricht. 6) Füge den `<script type="application/ld+json">`-Block unmittelbar vor `</head>` im selben Stream ein, um die TTFB niedrig zu halten. 7) Setze geeignete `cache-control`-Header, sodass die modifizierte Antwort am Edge gecacht wird und nicht nur am Origin. 8) Schreibe einen Hash des injizierten Schemas zur Fehlersuche in einen KV-Store oder Logging-Service. 9) Teste live mit `curl -H "User-Agent: Googlebot"`, um zu bestätigen, dass das Schema in gecachten Antworten erscheint. Ergebnis: Produktseiten liefern nun gültiges Schema aus, ohne die Origin-Templates anzutasten und mit nur wenigen Mikrosekunden zusätzlicher Latenz.

Edge-Schema-Injection fügt strukturierte Daten bereits im rohen HTML ein, bevor dieses den Browser erreicht, sodass der Googlebot (der primär das initiale HTML parst) das Schema ohne einen zweiten Rendering-Durchgang erkennt. Dadurch werden Verzögerungen in der JavaScript-Render-Queue vermieden und Crawl-/Render-Budget eingespart. Außerdem wird die Wartung im Edge-Worker zentralisiert, sodass die gesamte Website nicht neu deployt werden muss, um Schema-Anpassungen vorzunehmen. Client-seitige Injection setzt auf Googles „Deferred Rendering“; das Schema ist bis zur Rendering-Phase unsichtbar, was die Crawl-Latenz erhöht und das Risiko einer teilweisen Indexierung steigert. JavaScript-Injection kann jedoch einfacher sein, wenn du bereits die Kontrolle über den Frontend-Code hast und keine Edge-Skripting-Möglichkeit besteht. Wähle Edge-Injection, wenn (a) die Origin-Templates unantastbar sind, (b) du sofortige Sichtbarkeit für Crawler benötigst oder (c) du Schema auf CDN-Ebene A/B-testen möchtest. Wähle Client-seitige Injection, wenn du eine moderne SPA-Infrastruktur nutzt, keinen Zugriff auf CDN-Scripting hast oder wenn das Schema von Daten abhängt, die erst nach der Client-Hydration verfügbar sind.

Ursache 1: Kaltstart des Workers. Maßnahme: Den Worker schlank halten, globale Variablen für wiederverwendete Objekte nutzen und per Keep-Alive/Ping die Edge-Knoten vorwärmen.
Ursache 2: Vollständiges HTML-Buffering im Arbeitsspeicher. Maßnahme: Auf Streaming-Rewrites umstellen, die Daten-Chunks on the fly verändern, anstatt das gesamte Dokument zusammenzusetzen.
Ursache 3: Origin-Fetch erzielt keinen Cache-Hit mehr, weil das Caching mit cache-control: private</code> umgangen wurde. Maßnahme: <code>cacheTtl-Header korrekt setzen und Surrogate Keys beachten, damit der Worker zwischengespeichertes HTML ausliefern und Schema nur bei Cache-Hits einfügen kann.

Zuerst das gerenderte HTML mit `curl -A 'Googlebot'` abrufen, um zu bestätigen, dass zwei Organization-Objekte vorhanden sind – eines aus den CMS-Mikrodaten und eines, das vom Edge injiziert wurde. Anschließend ihre IDs (`"@id"`) und Property-Sets vergleichen. Da Google Graph-Knoten mit identischem `@id` zusammenführt, entsteht die Duplizierung, wenn der Edge eine zweite Organization einbindet, ohne die erste zu referenzieren. Lösung: Im Worker prüfen, ob die Mikrodaten einen `url`- oder `@id`-Wert enthalten; diesen Wert als `@id` im injizierten JSON-LD verwenden und nur fehlende Properties ergänzen. Alternativ die Organization-Injektion auf Seiten unterdrücken, die bereits eine ausgeben, indem vor dem Schreiben ein Mikrodaten-Selektor `itemtype="http://schema.org/Organization"` gematcht wird. Danach den Rich-Results-Test erneut ausführen; der Duplicate-Fehler sollte behoben sein, weil Google jetzt nur einen konsolidierten Knoten erkennt.