Wstrzykiwanie schematu na poziomie Edge

1) Skonfiguruj regułę routingu w CDN, aby uruchamiać workera dla adresów /*product*. 2) W workerze pobierz HTML źródłowy z użyciem `cacheTtlByStatus`, dzięki czemu HTML nadal będzie cachowany w dalszych warstwach. 3) Parsuj HTML za pomocą strumieniowego HTMLRewriter lub podobnego API, aby uniknąć kosztu pełnego DOM-u. 4) Wyodrębnij SKU, cenę, dostępność i markę z HTML-a (użyj zapytań selektorów lub awaryjnie wyrażeń regularnych). 5) Zbuduj obiekt JSON-LD zgodny ze Schema.org/Product oraz wytycznymi Google dla ceny i dostępności. 6) Wstrzyknij blok `<script type="application/ld+json">` tuż przed `</head>` przy użyciu tego samego strumienia, aby utrzymać niski TTFB. 7) Ustaw odpowiednie nagłówki `cache-control`, żeby zmodyfikowana odpowiedź była cachowana na edge, a nie tylko w originie. 8) Zaloguj hash wstrzykniętego schematu do magazynu KV lub usługi logującej w celach debugowania. 9) Przetestuj na żywo poleceniem `curl -H "User-Agent: Googlebot"`, aby potwierdzić, że schemat pojawia się w odpowiedziach z cache. Rezultat: strony produktowe emitują prawidłowy schemat bez modyfikacji szablonów originu i zaledwie z mikrosekundowym dodatkowym opóźnieniem.

Edge Schema Injection umieszcza dane strukturalne w surowym HTML-u, zanim dokument dotrze do przeglądarki, dzięki czemu Googlebot (który przede wszystkim analizuje początkowy HTML) widzi schemat bez konieczności drugiego etapu renderowania. Zapobiega to opóźnieniom w kolejce renderowania JavaScriptu i oszczędza budżet crawl/render. Centralizuje również utrzymanie w edge workerze, więc nie musisz ponownie wdrażać całej witryny przy każdej edycji schematu. Iniekcja po stronie klienta bazuje na odroczonym renderowaniu Google; schemat jest niewidoczny aż do fazy renderowania, co zwiększa latencję crawla i ryzyko częściowej indeksacji. Jednak iniekcja JavaScript może być prostsza, jeśli masz kontrolę nad kodem front-endu i brak skryptów krawędziowych (edge scripting). Zastosuj iniekcję na krawędzi, gdy: (a) szablony origin są nietykalne, (b) potrzebujesz natychmiastowej widoczności dla crawlera albo (c) chcesz testować schemat w A/B na poziomie CDN. Wybierz iniekcję po stronie klienta, gdy korzystasz z nowoczesnej infrastruktury SPA, nie masz kontroli nad skryptami CDN lub gdy schemat zależy od danych dostępnych dopiero po hydratacji po stronie klienta.

Przyczyna 1: cold start workera. Mitigacja: utrzymuj workera lekko, używaj zmiennych globalnych dla ponownie wykorzystywanych obiektów oraz włącz keep-alive/ping, aby podtrzymać „ciepłe” węzły edge. Przyczyna 2: pełne buforowanie HTML w pamięci. Mitigacja: przejdź na strumieniowe przepisywanie (streaming rewrites), które modyfikuje fragmenty w locie zamiast składać cały dokument. Przyczyna 3: pobranie z originu nie trafia już w cache, ponieważ ominąłeś cache nagłówkiem `cache-control: private`. Mitigacja: prawidłowo ustaw nagłówki `cacheTtl` i respektuj klucze zastępcze (surrogate keys), aby worker mógł serwować zcache'owany HTML i wstrzykiwać schemat tylko przy trafieniach w cache.

Najpierw pobierz wyrenderowany HTML za pomocą `curl -A 'Googlebot'`, aby potwierdzić, że istnieją dwa obiekty Organization—jeden pochodzący z mikrodanych CMS, a drugi wstrzyknięty na warstwie edge. Następnie porównaj ich identyfikatory (`"@id"`) oraz zestawy właściwości. Ponieważ Google scala węzły grafu o identycznych wartościach `@id`, duplikacja pojawia się, gdy edge wstrzykuje drugi obiekt Organization bez odwołania do pierwszego. Naprawa: w workerze wykryj, czy mikrodane zawierają wartość `url` lub `@id`; użyj tej wartości jako `@id` w wstrzykiwanym JSON-LD i dodaj tylko brakujące właściwości. Alternatywnie wyłącz wstrzykiwanie Organization na stronach, które już ją zawierają, wyszukując selektor mikrodanych `itemtype="http://schema.org/Organization"` przed zapisem. Uruchom ponownie test Rich Results; błąd duplikatu powinien zniknąć, ponieważ Google widzi teraz jeden, zunifikowany węzeł.