Języki

SEO Cloudflare Workers

Jak wprowadzać zmiany technicznego SEO w Cloudflare Workers — handler fetch, HTMLRewriter do wstrzykiwania canonical/hreflang/JSON-LD, przekierowania oparte na KV, Workers Cache API kontra cache brzegowy i Cache-Control, granica cloakingu oraz sposób, w jaki Bot Fight Mode może zablokować Googlebota.

Opublikowano po raz pierwszy: 3 lip 2026 · Ostatnia aktualizacja: 10 sie 2026 · Advanced
Języki
AIAutor:AI v2
1 sygnał dowodowy na tej stronie

SEO Cloudflare Workers to techniczne SEO wykonywane w bezserwerowym środowisku Cloudflare: Worker widzi tylko żądania pasujące do jego trasy, a każde z nich trafia do jednego handlera fetch, w którym przepisujesz żądanie, nagłówki odpowiedzi i treść odpowiedzi. Przepisywanie treści odbywa się przez HTMLRewriter — właściwy mechanizm wstrzykiwania canonical, poprawiania hreflang lub dodawania JSON-LD bez wdrożenia CMS-a — i musi być idempotentne dla brakujących, zduplikowanych oraz nie-HTML-owych przypadków. Przekierowania na dużą skalę należą do KV albo D1; Bulk Redirects/Rules są prostsze dla małych zestawów, ale wybierz jednego właściciela URL-a, aby systemy się nie kłóciły. Trzy różne rzeczy dzielą słowo cache — Workers Cache API, cache brzegowy Cloudflare i Cache-Control originu — a ich pomylenie sprawia, że wstrzyknięty tag wydaje się nie pojawiać; diagnozuj według klucza cache, warstwy, TTL i unieważnienia. Twarda zasada dotyczy cloakingu: stosuj identyczną logikę dla Googlebota i użytkowników. Najbardziej charakterystyczne ryzyko Workers to Bot Fight Mode blokujący Googlebota w potoku, do którego reguły allow WAF nawet nie docierają. Każdą zmianę wpływającą na SEO wdrażaj z zapisanymi metadanymi wersji i przetestowanym wycofaniem, a potem weryfikuj przez GSC URL Inspection i nagłówek CF-Cache-Status. Ogólną koncepcję znajdziesz w hubie Edge SEO.

TL;DR — Cloudflare Worker widzi tylko żądania dopasowane do skonfigurowanej trasy i przechwytuje każde z nich w jednym handlerze fetch, w którym kolejno: przepisujesz żądanie, przepisujesz nagłówki odpowiedzi i przepisujesz treść odpowiedzi przez HTMLRewriter. To prawdziwy mechanizm stojący za „wstrzyknięciem canonical” lub „poprawieniem tytułu” — musi być idempotentny i przetestowany dla brakujących, zduplikowanych oraz nie-HTML-owych odpowiedzi, a nie tylko dla szczęśliwej ścieżki. Przekierowania na dużą skalę należą do KV (szybkie wyszukiwanie klucza) albo D1 (dane relacyjne); Bulk Redirects/Rules prościej obsługują małe zestawy, a ja zwykle preferuję przekierowania na brzegu nad przekierowaniami serwerowymi — ale wybierz jednego właściciela każdego URL-a, bo przekierowanie Workera, Bulk Redirect i przekierowanie originu mogą zadziałać na tej samej ścieżce. Trzy różne rzeczy dzielą słowo „cache” — Workers Cache API (caches.default), cache brzegowy Cloudflare i Cache-Control originu — a pomylenie ich jest zwykle przyczyną, dla której „mój tag się nie pojawił”; diagnozuj nieaktualność według klucza cache, warstwy, TTL i unieważnienia, zamiast zgadywać. Własne zalecenia Google dotyczące ETag / If-None-Match / 304 można bezpośrednio zastosować do Workera, który kontroluje odpowiedź. Granica cloakingu: identyczna logika dla każdego odbiorcy. Najbardziej charakterystyczne dla Workers ryzyko samodzielnego problemu to Bot Fight Mode działający poza WAF Ruleset Engine, więc zwykłe reguły „allow” do niego nie docierają. Każdą zmianę wpływającą na SEO wdrażaj z zapisanymi metadanymi wersji, przetestowanym wycofaniem i warunkiem zatrzymania — następnie zweryfikuj ją przez GSC URL Inspection oraz CF-Cache-Status.

Czym ten artykuł jest — a czym nie jest

To praktyczny, kodowy dodatek do huba Edge SEO. Hub zawiera ogólną definicję, tabelę porównującą platformy (Workers, Akamai, Fastly, Lambda@Edge, Vercel, Netlify), decyzję Snippets kontra Workers oraz pełne omówienie zasady cloakingu. Nie odtwarzam tu tych treści. Ta strona schodzi o poziom głębiej w Cloudflare Workers — środowisko uruchomieniowe, na którym działa również własny worker tej witryny, podłączony przez run_worker_first w wrangler.toml — i pokazuje prawdziwe API zamiast ogólnikowego stwierdzenia, że „edge compute może wstrzykiwać tagi”.

Uwaga przed kodem: Google nie ma dokumentacji SEO dotyczącej konkretnie Cloudflare Workers. Oficjalne wytyczne, które mają tu zastosowanie (polityka cloakingu, cache HTTP, indeksowanie przez CDN), są ogólne i dotyczą każdej implementacji brzegowej. Wolę powiedzieć to wprost, niż sugerować istnienie dokumentu Google, którego nie ma.

Jak Worker znajduje się na ścieżce żądania i odpowiedzi

Worker to bezserwerowy skrypt działający w izolatach V8. Każde żądanie skierowane do niego przechodzi przez handler fetch. Evidence for this claim A Cloudflare Worker receives HTTP requests through a fetch handler. Scope: Cloudflare Workers handlers. Confidence: high · Verified: Cloudflare Workers: Fetch handler Sformułowanie „skierowane do” ma tu realne znaczenie: Worker widzi tylko żądania pasujące do skonfigurowanej trasy lub własnej domeny — wszystko inne w ogóle nie dociera do handlera fetch. Gdy dwa wzorce tras mogą pasować do tego samego URL-a, pierwszeństwo ma bardziej szczegółowy wzorzec. Zanim zaufasz zachowaniu Workera dla danego URL-a, potwierdź więc dopasowanie trasy i sprawdź, która wdrożona wersja jest aktywna na tej trasie (środowiska Wranglera i stopniowe wdrożenia sprawiają, że wersja obsługująca ruch nie zawsze jest tą z edytora). W handlerze możesz wykonać trzy odrębne czynności, w tej kolejności:

  1. Przepisać żądanie przed wysłaniem go do originu.
  2. Przepisać nagłówki odpowiedzi podczas drogi powrotnej.
  3. Przepisać treść odpowiedzi — przez HTMLRewriter.

Oto minimalny kształt:

export default {
  async fetch(request, env, ctx) {
    // 1. (optionally) inspect/modify the request
    const response = await fetch(request);   // hit the origin

    // 2. rewrite headers
    const headers = new Headers(response.headers);
    headers.set("X-Robots-Tag", "index, follow");

    // 3. rewrite the body with HTMLRewriter (see next section)
    return new Response(response.body, { ...response, headers });
  },
};

Zespół SALT.agency, który na podstawie badań Cloudflare Workers ukuł określenie „edge SEO”, zbudował swoje narzędzia jako łańcuch filtrów — filtr żądania, filtr odpowiedzi i filtr treści. To ten sam wzorzec trzech faz; zespół nadał mu tylko nazwę. Rozdzielenie tych trzech faz w głowie pomaga zachować czytelność Workera.

Przepisywanie HTML za pomocą HTMLRewriter

HTMLRewriter to strumieniowy parser HTML Cloudflare i właściwe API stojące za każdym trikiem typu „wstrzyknij tag”. Evidence for this claim Cloudflare HTMLRewriter provides selector-based handlers that can transform streamed HTML elements. Scope: Cloudflare Workers HTMLRewriter API. Confidence: high · Verified: Cloudflare Workers: HTMLRewriter Rejestrujesz handlery elementów .on(selector, handler), a handler otrzymuje getAttribute / setAttribute, prepend / append, setInnerContent oraz replace. Ponieważ parser działa strumieniowo, nie buforujesz całego dokumentu w pamięci.

Wstrzykiwanie lub poprawianie tagu canonical

class CanonicalHandler {
  constructor(url) { this.url = url; }
  element(el) { el.setAttribute("href", this.url); }
}

const rewriter = new HTMLRewriter()
  .on('link[rel="canonical"]', new CanonicalHandler("https://example.com/preferred/"));

return rewriter.transform(response);

Jeśli strona w ogóle nie ma canonical, podłącz handler do head i zamiast edytować istniejący tag dodaj nowy przez append. W obu przypadkach pamiętaj o lekcji z obszaru canonicalizacji: rel=canonical to wskazówka, a nie polecenie — Worker pozwala ustawić ją spójnie na całej platformie, ale ostatecznie decyduje Google.

Pokazany wyżej CanonicalHandler zakłada, że tag już istnieje, a odpowiedź jest HTML-em. W produkcji nie masz gwarancji żadnego z tych założeń, a pomyłka prowadzi do dwóch tagów canonical na jednej stronie zamiast jednego. Zanim wdrożysz taką modyfikację, uczyń ją idempotentną i przetestuj dla:

  • Brak istniejącego canonical — handler musi wykryć brak i przez append dodać tag do head, a nie po cichu nic nie zrobić, bo dopasowanie link[rel="canonical"] niczego nie znalazło.
  • Istniejący zduplikowany lub zniekształcony canonical — zdecyduj, czy usunąć błędny tag, czy pozwolić modyfikacji dodać drugi (to prawdziwy błąd, a nie przypadek brzegowy — duplikaty canonical są częstym problemem wywołanym przez nas samych).
  • Odpowiedź niebędąca HTML-em — trasą API, obrazem ani odpowiedzią przekierowania przechodzącą przez ten sam Worker nie należy w ogóle przepuszczać przez HTMLRewriter; ogranicz transformację do tras i typów treści, które rzeczywiście sprawdziłeś.
  • Dwukrotne uruchomienie transformacji dla tej samej odpowiedzi (ponowienie, zagnieżdżony fetch) — upewnij się, że nie dołączy drugiego tagu.

Dodawanie lub poprawianie alternatyw hreflang

Ten sam mechanizm, sterowany konfiguracją. Dołączasz jeden link[rel="alternate"] na lokalizację do head. Jeśli alternatywy są relacyjne i zależne od lokalizacji, konfiguracja należy do D1; jeśli jest płaską tabelą wyszukiwania, wystarczy KV. Chodzi o to, że HTMLRewriter wstrzykuje je identycznie dla każdego odbiorcy — nie rozgałęziasz logiki według user agenta.

Wstrzykiwanie danych strukturalnych JSON-LD

new HTMLRewriter().on("head", {
  element(head) {
    head.append(
      `<script type="application/ld+json">${JSON.stringify(schema)}</script>`,
      { html: true }
    );
  },
});

Limity CPU, które zaczynają boleć przy skali

Z jednym twierdzeniem konkurencji bym polemizował: „sub-millisecond, no constraints.” Prawdziwym ograniczeniem jest czas CPU: 10 ms w planie bezpłatnym, 30 ms w płatnym (czas zegarowy oczekiwania na fetch się nie liczy — liczy się czas CPU). Przy typowych przepisaniach nawet tego nie zauważysz. Przy ciężkich przebiegach HTMLRewriter po bardzo dużych stronach jest to realne ograniczenie, które trzeba uwzględnić w projekcie, a nie straszenie.

Przekierowania na brzegu: KV kontra D1 kontra Rules

Zwykle wolę umieszczać przekierowania na brzegu (na poziomie CDN) niż na serwerze — odciąża to origin i działa, zanim strona w ogóle zostanie wygenerowana. W Cloudflare w moim przewodniku Ahrefs dotyczącym przekierowań dla SEO opisałem kilka możliwości: pojedyncze lub zbiorcze przekierowania, redirect rules, page rules albo Workers z parami klucz-wartość — ewentualnie Worker modyfikujący nagłówki, aby dodać przekierowanie.

W tabeli obsługiwanej przez Workera naturalnym miejscem jest KV: szybkie, ostatecznie spójne wyszukiwanie klucza po URL-u.

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const target = await env.REDIRECTS.get(url.pathname);   // KV namespace
    if (target) return Response.redirect(target, 301);
    return fetch(request);
  },
};

Sięgnij po D1, gdy przekierowania są relacyjne (SQL per lokalizacja lub segment, który chcesz odpytywać). I pamiętaj, kiedy Worker byłby przesadą: dla małego, statycznego zestawu przekierowań prostsze są Bulk Redirects Cloudflare albo Redirect Rules — nie wymagają żadnego kodu. Nie pisz własnego Workera KV dla pięćdziesięciu przekierowań.

Wybierz jednego właściciela danego URL-a i nie pozwól, aby Worker, Bulk Redirect, Redirect Rule oraz przekierowanie originu działały na tej samej ścieżce — to osobne systemy, z których każdy może zadziałać dla tego samego żądania. Gdy pasuje więcej niż jeden, zamiast czystego przekierowania debugujesz pierwszeństwo. Przed dodaniem przekierowania sprawdź, czy nie istnieje już w innych systemach dla tej ścieżki, a warstwę wybierz według złożoności dopasowania (proste 1:1 kontra wzorcowe), skali i tego, kto ma je obserwować lub wycofywać — przekierowanie Workera mieszka w kodzie i logach, a Bulk Redirect lub Rule w panelu i łatwiej je audytować lub cofnąć osobie niebędącej programistą.

Cache: trzy różne rzeczy pod jedną mylącą nazwą

To sekcja pomijana przez strony konkurencji i właśnie ona wywołuje najwięcej pytań typu „dlaczego moja zmiana się nie pojawiła”. Trzy odrębne warstwy dzielą słowo cache:

  • Workers Cache API — caches.default i caches.open(). To programowalny cache zakresu Workera, który odczytujesz i zapisujesz w kodzie.
  • Cache brzegowy Cloudflare — cache CDN obsługujący zasoby. Jest odrębny od Cache API.
  • Originowe Cache-Control — nagłówki ustawiane przez origin (albo Workera), które wpływają na obie powyższe warstwy oraz na działanie Googlebota.

Pomylenie ich sprawi, że uznasz, iż zmiana nie została wdrożona, podczas gdy jest po prostu serwowana z warstwy, której nie wyczyściłeś.

Gdy zmiana rzeczywiście się nie pojawia, nie zgaduj — diagnozuj warstwa po warstwie:

  1. Klucz cache. Jakie atrybuty żądania decydują, czy dwa żądania trafią do tego samego wpisu cache (URL, a czasem nagłówki lub cookies, jeśli uwzględnia je klucz cache)? Przepisanie zależne od elementu nieuwzględnionego w kluczu może zwrócić niewłaściwy wariant.
  2. Warstwa, która zwróciła odpowiedź. Sprawdź CF-Cache-Status (HIT/MISS/EXPIRED/DYNAMIC), aby zobaczyć, czy odpowiedział cache brzegowy, czy żądanie dotarło do Workera.
  3. Lokalizacja i stan. Cache Cloudflare jest rozproszony między centrami danych — czyszczenie ani nowe wdrożenie nie musi natychmiast unieważnić każdej lokalizacji brzegowej.
  4. TTL i reguła, która go ustawiła. Potwierdź, czy TTL kontroluje reguła cache, nagłówek Cache-Control z originu czy nagłówek ustawiony przez samego Workera.
  5. Unieważnienie. Czy wyczyściłeś konkretny URL, wszystko, czy czekasz na wygaśnięcie TTL? Wpis Cache API należący do Workera (caches.default) wymaga własnego jawnego delete() — czyszczenie cache CDN go nie dotyka.

Co Googlebot robi z ETag / If-None-Match / 304

Jeśli Worker generuje lub przepisuje odpowiedź, on kontroluje nagłówki cache — dlatego wytyczne Google z grudnia 2024 dotyczące cache HTTP są dla ciebie bezpośrednio użyteczne. Google obsługuje heurystyczne cache HTTP przez ETag/If-None-Match oraz Last-Modified/If-Modified-Since, zdecydowanie zaleca ETag, ponieważ jest mniej podatny na błędy, i mówi, że gdy ETag crawlera pasuje, serwer powinien zwrócić 304 Not Modified bez treści. Worker generujący odpowiedź może zrobić dokładnie to: obliczyć ETag, porównać go z If-None-Match i samodzielnie zakończyć obsługę kodem 304 — oszczędzając obliczenia i dając Googlebotowi szybki, możliwy do cache’owania sygnał.

Kompromis ponownego crawlowania przy max-age

Google zaleca również rozważenie ustawienia Cache-Control: max-age, aby pomóc crawlerom zdecydować, kiedy ponownie craw­lować URL. Problem w przypadku Workera przepisującego HTML polega na tym, że agresywne max-age na stronie, której tagi wstrzykiwane przez Workera właśnie się zmieniły, może opóźnić zauważenie przez Googlebota dopiero co wdrożonej aktualizacji. Nie nakładaj długiego czasu cache na przepisywany HTML i nie zapominaj o nim.

Granica cloakingu zastosowana do Workers

  • Sprawdzanie User-Agent nie jest automatycznie cloakingiem. Polityka spamu Google definiuje cloaking jako prezentowanie użytkownikom i wyszukiwarkom różnej treści — “Cloaking refers to the practice of presenting different content to users and search engines” (tłumaczenie) „cloaking to praktyka prezentowania różnej treści użytkownikom i wyszukiwarkom” — w celu manipulowania rankingiem. Google wskazuje też wstawianie tekstu lub słów kluczowych tylko wtedy, gdy odbiorcą jest wyszukiwarka — “Inserting text or keywords into a page only when the user agent that is requesting the page is a search engine, not a human visitor” (tłumaczenie) „wstawianie tekstu lub słów kluczowych tylko wtedy, gdy stronę pobiera wyszukiwarka, a nie człowiek”.
  • Testy A/B oparte na stronach są bezpieczne w Workers. Kierowanie użytkowników według URL-a i stosowanie tej samej reguły wobec każdego odbiorcy jest dozwolone. Rozgałęzianie treści według tożsamości pytającego — bota lub człowieka — nie jest.

Kilka doprecyzowań, bo łatwo tu przesadzić z korektą:

  • Sprawdzanie User-Agent nie jest automatycznie cloakingiem. Logowanie ruchu botów albo szybsze serwowanie odpowiedzi z cache dowolnemu klientowi jest w porządku. Granicą jest różnica w treści zależna od tożsamości odbiorcy, wprowadzona w celu manipulowania rankingiem.
  • Testy A/B z podziałem stron w Workers są w porządku. Dzielenie użytkowników według URL-a i traktowanie każdego odbiorcy tak samo jest legalne. Dzielenie według tego, kto pyta — bot kontra człowiek — już nie.

Dobry przykład bezpiecznego wzorca: własna bramka podglądu tej witryny jest Workerem, który zwraca 404 dla każdej ścieżki /preview/, chyba że cookie pasuje do sekretu. Bez tego cookie zwraca 404 każdemu — także Googlebotowi. To dokładnie bezpieczny kształt: nie ukrywa jednej rzeczy przed botami, pokazując inną użytkownikom, tylko stosuje jedną regułę bez wyjątków.

Nie polegaj też na kroku pre-renderowania wyłącznie dla botów, nawet jeśli zbudujesz go poprawnie w Workers. Google określiło dynamiczne renderowanie jako “Dynamic rendering was a workaround and not a long-term solution” (tłumaczenie) „dynamiczne renderowanie było obejściem, a nie rozwiązaniem długoterminowym” — w swojej dokumentacji; Worker, który renderuje wstępnie tylko dla botów, dziedziczy tę deprecjację.

Jak Worker może przypadkowo zablokować lub spowolnić Googlebota

To najbardziej specyficzny dla Workers sposób podcięcia gałęzi, na której siedzisz, i zwykle nie wynika z kodu Workera.

Bot Fight Mode działa poza Ruleset Engine

Bot Fight Mode (oraz Super Bot Fight Mode) może generować fałszywe alarmy wobec legalnych crawlerów, w tym Googlebota. Pułapka polega na tym, że Bot Fight Mode jest oceniany w osobnym potoku niż WAF Ruleset Engine, więc zwykłe niestandardowe reguły WAF „allow” lub „skip” go nie omijają. Jeśli Bot Fight Mode rzuca wyzwanie Googlebotowi, nie naprawisz tego regułą allow — musisz zmienić lub wyłączyć sam tryb. (Zanim na tym polegniesz, potwierdź bieżące działanie w dokumentacji Cloudflare: Bot Fight Mode i Super Bot Fight Mode — produkty botowe się zmieniają.)

Wzorzec niestandardowej reguły zweryfikowanych botów

Cloudflare udostępnia pole cf.client.bot oraz wzorzec reguły zezwalającej dla zweryfikowanych botów, dzięki czemu możesz dopuścić znane, dobre crawlery w swoich regułach niestandardowych — przydatne po stronie WAF, choć (jak wyżej) nie dociera to do Bot Fight Mode.

Sam CDN jest neutralny lub korzystny

Wyjaśnijmy mit: Cloudflare jako CDN nie szkodzi SEO. Własna praca Google z 2024 roku, Crawling December, zauważa, że Google zwiększa częstotliwość crawlowania po wykryciu CDN-u — ale CDN może też przypadkowo zablokować Googlebota przez reguły WAF lub botów, a odpowiedź 503 jest lepsza niż interstitial z weryfikacją bota. Ryzykiem jest źle skonfigurowany Worker albo ustawienie botów, nie sama infrastruktura.

Sprawdzanie, co naprawdę otrzymał Googlebot

Po każdym wdrożeniu Workera potwierdź, co faktycznie dostał crawler — nie zakładaj tego:

  • GSC URL Inspection → Test Live URL. Pobiera stronę jako Google i pokazuje wyrenderowany HTML, więc możesz potwierdzić, że wstrzyknięte canonical/hreflang/JSON-LD rzeczywiście są obecne.
  • Sprawdź CF-Cache-Status obok HTML. HIT / MISS / EXPIRED pokazuje, czy oglądasz świeżą odpowiedź Workera, czy odpowiedź z cache — to najszybszy sposób wykrycia sytuacji, w której „zmiana się nie pojawiła”, a problemem jest warstwa cache.
  • Pobierz stronę bezpośrednio jako Googlebot. Wyślij żądanie z user agentem Googlebota i porównaj wyniki — pamiętaj jednak, że zgodny ciąg znaków niczego nie dowodzi; prawdziwego Googlebota weryfikuj przez odwrotne i zwykłe DNS względem opublikowanych zakresów Google (zobacz kartę Scripts).

Higiena wdrożeń właściwa dla Workers

Udane wrangler deploy mówi, że skrypt został wysłany — nie mówi, że Googlebot otrzymuje właściwy wyrenderowany wynik. Traktuj każdą zmianę Workera wpływającą na SEO jak wydanie z rejestrem, a nie tylko jak push:

  • Ogranicz zakres tras. Nie uruchamiaj Workera domyślnie na /*. Dopasuj go do potrzebnych ścieżek we wzorcach tras wrangler.toml, aby błąd nie mógł wyłączyć całej witryny.
  • Sprawdź bieżące limity, zanim obiecasz skalę. Limity czasu CPU, liczby podżądań i rozmiaru skryptu zależą od planu i zmieniają się z czasem — przed zaprojektowaniem przepisywania pod konkretny próg sprawdź aktualną stronę limitów Cloudflare, zamiast polegać na zapamiętanej liczbie.
  • Zapisz metadane wersji wydania. Model wersji i wdrożeń Cloudflare śledzi wersję źródłową, datę zgodności, bindingi i trasy każdego wdrożenia — zanotuj, która wersja działa na której trasie, aby twierdzenie „Worker robi X” można było sprawdzić względem wdrożenia, a nie edytora.
  • Wersjonuj i wycofuj przez środowiska Wranglera. Wdróż na środowisko stagingowe, stopniowo zwiększaj procent ruchu i zachowaj możliwość natychmiastowego powrotu do poprzedniej wersji.
  • Używaj logów zakresowych do obserwacji wdrożenia, pamiętając o ich ograniczeniach. Workers Logs i śledzenie logów mogą pomagać w debugowaniu stopniowego wdrożenia, ale logi są próbkowane i przechowywane przez ograniczony czas — traktuj je jako dowód ograniczony do przechwyconych żądań, a nie pełny zapis każdej wizyty crawlera.
  • Ustal warunek zatrzymania i przetestuj wycofanie, zanim będzie potrzebne. Z góry zdecyduj, jakie zaobserwowane zachowanie (wskaźnik błędów, zła odpowiedź w kontroli punktowej, spadek crawlowania) zatrzymuje wdrożenie i potwierdź, że ścieżka wycofania działa, zamiast to zakładać.
  • Czyść cache jako część wdrożenia. Ponieważ działają trzy warstwy cache, czyszczenie lub unieważnienie musi być jawnym krokiem wysyłki zmiany, a nie czynnością po fakcie.

Uwaga o Bing i jeden kierunek na przyszłość

Bing również nie ma wskazówek dotyczących konkretnie Cloudflare ani edge. Ponieważ jednak wdrożenie Workera jest natychmiastowe, a crawlowanie nie, naturalnym uzupełnieniem jest IndexNow — uruchom je natychmiast po wysłaniu tabeli przekierowań lub zmiany tagu sterowanej przez Workera, aby Bing (i inne uczestniczące wyszukiwarki) szybko ponownie wykonały crawl. Warto też zwrócić uwagę, że Cloudflare udostępnił kanonikalizację wymuszaną na brzegu jako funkcję produktu („Redirects for AI Training”) — zweryfikowane crawlery szkolące AI otrzymują 301 do canonical za pomocą jednego przełącznika. To użyteczne porównanie z ręcznym pisaniem logiki canonical we własnym Workerze oraz przypomnienie, że „serwowanie crawlerom czegoś innego niż użytkownikom” to wzorzec, wobec którego Microsoft publicznie wyrażał sceptycyzm przy innych funkcjach Cloudflare dla crawlerów AI — dobry test zdroworozsądkowy dla każdego Workera zależnego od bota.

Jeśli interesuje cię szerszy obraz — porównanie platform, Snippets kontra Workers oraz kwestie kolejki deweloperskiej i zarządzania — wróć do huba Edge SEO.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.