Cloudflare Workers SEO: tarama ve performans rehberi

TL;DR — Cloudflare Workers, Cloudflare’ın ağında, gerçek web sitenizin önünde çalışan küçük programlardır. Bir Worker, sayfa geçerken bir yönlendirme ekleyebilir, bir meta etiketi düzeltebilir veya bir canonical etiketi enjekte edebilir — CMS’nize dokunmadan veya geliştiricileri beklemeden. Bu sayfa, daha geniş Edge SEO fikrinin uygulamalı, kod düzeyindeki versiyonudur: bunu özellikle Workers üzerinde nasıl yaparsınız. Kıramayacağınız tek kural: Bir Worker ne değiştirirse değiştirsin, bunu Google ve gerçek ziyaretçiler için aynı şekilde yapmak zorundadır. Google’a farklı bir şey göstermek cloaking’dir.

Cloudflare Worker nedir, sade bir dille

Siteniz Cloudflare’deyse, bir ziyaretçiden (veya Googlebot’tan) gelen her istek, gerçek sunucunuza ulaşmadan önce Cloudflare’ın ağından geçer. Bir Worker, yolun bu noktasında çalıştırabileceğiniz küçük bir betiktir. Gelen isteği ve giden yanıtı görür ve ikisini de değiştirebilir. Evidence for this claim Cloudflare Workers run code on Cloudflare's network and can inspect or modify requests and responses. Scope: Cloudflare Workers request handling. Confidence: high · Verified: 2026-07-14 Cloudflare Workers: How Workers works

SEO açısından asıl avantajı budur: başka türlü düzenleyemediğiniz sayfalardaki sorunları giderebilirsiniz. Değişikliklere kapalı bir platformda mı kaldınız? Bir geliştiricinin canonical etiketi eklemesi için haftalarca mı bekliyorsunuz? Bir Worker, sitenin kendisini dağıtmaya gerek kalmadan bunu canlı ortamda dakikalar içinde yapabilir.

İnsanlar SEO’da Workers’ı ne için kullanır

• Yönlendirmeler — binlerce olsalar bile eski URL’leri uçta yenilerine yönlendirin.
• Etiketleri düzeltme veya ekleme — sayfanın kaynağını düzenlemeden canonical etiketi ekleyin, başlığı düzeltin, hreflang veya yapılandırılmış veri ekleyin.
• Üstbilgileri yeniden yazma — X-Robots-Tag gibi üstbilgileri ekleyin veya düzeltin.

Kıramayacağınız kural

Worker’ınız ne yaparsa yapsın, bunu herkes için yapmalıdır. Sıralamaları manipüle etmek amacıyla Googlebot’a gerçek bir kişinin gördüğünden farklı bir sayfa gösterirseniz bu cloaking’dir ve Google’ın kurallarına aykırıdır. Evidence for this claim Google defines serving materially different content to search engines and users to manipulate rankings as cloaking and a spam-policy violation. Scope: Google Search spam policy; legitimate personalization is context-dependent. Confidence: high · Verified: 2026-07-14 Google: Spam policies — cloaking Güvenli yaklaşım basittir: isteği kim gönderirse göndersin, her isteğe aynı mantığı uygulayın. (Edge SEO merkezi bu kuralı ayrıntılı biçimde ele alır; bu sayfa, kavramı zaten bildiğinizi ve Cloudflare’e özgü uygulama adımlarını öğrenmek istediğinizi varsayar.)

Kendinize zarar vermenin iki yolu

Çoğu “Cloudflare SEO’ma zarar verdi” hikayesi aslında Worker kodundan kaynaklanmaz:

1. Bot engelleme ayarı. Cloudflare’in Bot Fight Mode özelliği yanlışlıkla Googlebot’u engelleyebilir veya doğrulama adımına yönlendirebilir. Google sayfalarınızı getiremiyorsa başka hiçbir şeyin önemi kalmaz.
2. Önbellek karmaşası. Cloudflare’de birden fazla önbellek türü vardır. Hangisini etkilediğinizi bilmiyorsanız yayınladığınız bir değişiklik “görünmüyor” sanılabilir.

Gerçek kodu istiyor musunuz — bir fetch işleyicisi, bir HTMLRewriter örneği, bir KV yönlendirme tablosu — ayrıca önbelleğe alma ve bot engelleme ayrıntıları? Gelişmiş sekmesine geçin.

TL;DR — Bir Cloudflare Worker yalnızca yapılandırılmış rotasıyla eşleşen istekleri görür ve her isteği tek bir fetch işleyicisinde yakalar. Burada sırayla üç işlem yaparsınız: isteği, yanıt üstbilgilerini ve HTMLRewriter aracılığıyla yanıt gövdesini yeniden yazarsınız. “Canonical eklemek” veya “başlığı düzeltmek” ifadelerinin arkasındaki gerçek mekanizma budur. Yeniden yazma işlemi idempotent olmalı ve yalnızca sorunsuz senaryoda değil; eksik, yinelenen ve HTML olmayan yanıtlarla da test edilmelidir. Büyük ölçekli yönlendirmeler KV’de (hızlı anahtar araması) veya D1’de (ilişkisel) tutulur; Bulk Redirects/Rules küçük kümeler için daha basittir. Genellikle sunucu düzeyindeki yönlendirmeler yerine uç düzeyindeki yönlendirmeleri tercih ederim. Ancak her URL için tek bir sahip seçin; aynı yolda bir Worker yönlendirmesi, Bulk Redirect ve kaynak yönlendirmesi birlikte tetiklenebilir. Üç farklı şey “cache” adıyla anılır: Workers Cache API (caches.default), Cloudflare uç önbelleği ve kaynak Cache-Control. Bunları karıştırmak, “etiketim görünmedi” sorununun en yaygın nedenidir. Bayat içeriği tahmin yürüterek değil; önbellek anahtarı, katman, TTL ve geçersiz kılma üzerinden teşhis edin. Google’ın ETag / If-None-Match / 304 rehberi, yanıtın sahibi olan bir Worker için doğrudan uygulanabilir. Cloaking sınırı şudur: her isteği gönderen için aynı mantık uygulanmalıdır. Workers’a özgü en yaygın kullanıcı kaynaklı sorun, WAF Ruleset Engine dışında çalışan Bot Fight Mode’dur; bu nedenle sıradan “allow” kuralları ona erişemez. SEO’yu etkileyen her değişikliği kaydedilmiş sürüm meta verileri, test edilmiş bir geri alma yöntemi ve bir durdurma koşuluyla yayınlayın; ardından GSC URL Inspection ve CF-Cache-Status ile doğrulayın.

Bu makale neyi kapsar (ve neyi kapsamaz)

Bu makale, Edge SEO merkezinin uygulayıcılara yönelik, kod düzeyindeki eşlikçisidir. Genel tanım, platform karşılaştırma tablosu (Workers, Akamai, Fastly, Lambda@Edge, Vercel, Netlify), Snippets ile Workers arasındaki seçim ve cloaking kuralının ayrıntılı açıklaması merkezde yer alır. Bunları burada yeniden ele almıyorum. Bu sayfa, özellikle Cloudflare Workers konusuna bir seviye daha derinden yaklaşır: bu sitenin kendi Worker’ının da çalıştığı ve wrangler.toml dosyasındaki run_worker_first üzerinden bağlandığı çalışma zamanını, “edge compute etiket ekleyebilir” gibi soyut ifadeler yerine gerçek API’lerle açıklar.

Koddan önce bir not: Google’ın Cloudflare-Workers’a özel bir dokümantasyonu yoktur. Bunu yöneten resmi yönergeler (gizleme politikası, HTTP önbellekleme, CDN taraması) geneldir ve herhangi bir uç uygulaması için geçerlidir. Bunu açıkça söylemeyi, var olmayan bir Google dokümanı varmış gibi ima etmeye tercih ederim.

Bir Worker istek/yanıt yolunda nasıl konumlanır

Bir Worker, V8 izolatlarında çalışan sunucusuz bir betiktir. Yönlendirildiği her istek bir fetch işleyicisinden girer. Evidence for this claim A Cloudflare Worker receives HTTP requests through a fetch handler. Scope: Cloudflare Workers handlers. Confidence: high · Verified: 2026-07-14 Cloudflare Workers: Fetch handler “Yönlendirildiği” bu cümlede gerçek bir iş yapıyor: bir Worker yalnızca yapılandırılmış rotası veya özel alan adıyla eşleşen istekleri görür — diğer her şey fetch işleyicisine hiç ulaşmaz. İki rotanın aynı URL ile eşleşebildiği durumlarda, daha spesifik desen öncelik kazanır; bu nedenle bir Worker’ın belirli bir URL için davranışına güvenmeden önce rotanın gerçekten eşleştiğini doğrulayın ve o rotada hangi dağıtılmış sürümün canlı olduğunu kontrol edin (Wrangler ortamları ve kademeli yayınlar, trafiği sunan sürümün her zaman editörünüzdeki sürüm olmadığı anlamına gelir). İşleyicinin içinde sırayla üç farklı şey yapabilirsiniz:

1. İsteği kaynağınıza gitmeden önce yeniden yazın.
2. Yanıt başlıklarını geri dönerken yeniden yazın.
3. Yanıt gövdesini — HTMLRewriter aracılığıyla — yeniden yazın.

En temel yapı şöyledir:

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 });
  },
};

Cloudflare Workers araştırmalarından yola çıkarak “edge SEO” terimini ortaya atan SALT.agency ekibi, araçlarını bir filtre zinciri biçiminde oluşturdu: istek filtresi, yanıt filtresi ve gövde filtresi. Bu, aynı üç aşamalı modelin adlandırılmış hâlidir. Bu üç aşamayı zihninizde ayrı tutmak, Worker kodunun anlaşılır kalmasını sağlar.

HTMLRewriter ile HTML yeniden yazma

HTMLRewriter, Cloudflare’in akış tabanlı HTML ayrıştırıcısıdır ve her “etiket ekleme” işleminin arkasındaki gerçek API’dir. Evidence for this claim Cloudflare HTMLRewriter provides selector-based handlers that can transform streamed HTML elements. Scope: Cloudflare Workers HTMLRewriter API. Confidence: high · Verified: 2026-07-14 Cloudflare Workers: HTMLRewriter .on(selector, handler) ile öğe işleyicileri kaydedersiniz; işleyici de getAttribute / setAttribute, prepend / append, setInnerContent ve replace yöntemlerine erişir. Akış tabanlı çalıştığı için belgenin tamamını belleğe yüklemezsiniz.

Canonical etiketi ekleme veya düzeltme

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);

Sayfada hiç canonical etiketi yoksa mevcut bir etiketi düzenlemek yerine head öğesine bir işleyici bağlar ve append ile yeni bir etiket eklersiniz. Her iki durumda da canonicalization konusundaki dersi unutmayın: rel=canonical bir komut değil, ipucudur. Worker bunu platformun tamamında tutarlı biçimde ayarlamanızı sağlar, ancak son kararı yine Google verir.

Yukarıdaki CanonicalHandler, etiketin zaten bulunduğunu ve yanıtın HTML olduğunu varsayar. Üretim ortamında bu iki koşul da garanti değildir. Yanlış uygulama, sayfada tek canonical etiketi yerine iki tane bulunmasına yol açabilir. Böyle bir yeniden yazma işlemini yayınlamadan önce idempotent hâle getirin ve şu durumlarla test edin:

• Mevcut canonical etiketi yok — işleyiciniz bu durumu algılamalı ve hiçbir öğeyle eşleşmeyen link[rel="canonical"] seçicisinde sessizce hiçbir şey yapmamak yerine head içine append ile bir etiket eklemelidir.
• Zaten yinelenen veya hatalı biçimlendirilmiş bir canonical etiketi var — fazladan etiketi kaldıracağınıza mı, yoksa yeniden yazma işleminizin ikinci bir etiket eklemesine izin mi vereceğinize karar verin. İkincisi bir uç durum değil, gerçek bir hatadır; yinelenen canonical etiketleri sık rastlanan kullanıcı kaynaklı sorunlardandır.
• Yanıt HTML değil — aynı Worker’dan geçen bir API rotası, görsel veya yönlendirme yanıtı kesinlikle HTMLRewriter ile işlenmemelidir. Dönüşümü yalnızca gerçekten denetlediğiniz rotalar ve içerik türleriyle sınırlandırın.
• Dönüşüm aynı yanıtta iki kez çalışıyor (yeniden deneme veya iç içe bir fetch) — ikinci bir etiket eklemediğini doğrulayın.

hreflang alternatiflerini ekleme veya düzeltme

Yapılandırmanın yönettiği aynı mekanizma kullanılır. Her locale için head içine bir link[rel="alternate"] eklersiniz. Alternatifleriniz locale bazında ve ilişkisel yapıdaysa bu yapılandırmanın yeri D1’dir; düz bir arama tablosuysa KV yeterlidir. Önemli nokta, HTMLRewriter’ın bunları her isteği gönderen için aynı biçimde eklemesidir; kullanıcı aracısına göre dallanmazsınız.

JSON-LD yapılandırılmış veri ekleme

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

Ölçekte sorun yaratan CPU limitleri

Karşı çıktığım rakip iddialarından biri “milisaniyenin altında, hiçbir kısıtlama yok” söylemidir. Gerçek sınır CPU süresidir: ücretsiz planda 10 ms, ücretli planda 30 ms (fetch beklenirken geçen duvar saati süresi sayılmaz; CPU süresi sayılır). Tipik yeniden yazma işlemlerinde bunu hiç fark etmezsiniz. Ancak çok büyük sayfalarda yoğun HTMLRewriter geçişleri yaparken bu, korkutma amacıyla söylenen bir şey değil, tasarımda hesaba katılması gereken gerçek bir kısıtlamadır.

Uçta yönlendirmeler: KV vs D1 vs Kurallar

Genellikle yönlendirmelerin sunucuda olması yerine uçta (CDN seviyesinde) olmasını tercih ederim — bu, iş yükünü kaynağınızdan alır ve sayfa hiç oluşturulmadan önce uygulanır. Özellikle Cloudflare’da, Ahrefs’teki SEO için yönlendirmeler rehberimde birkaç seçeneğiniz olduğunu belirttim: tek veya toplu yönlendirmeler, yönlendirme kuralları, sayfa kuralları veya anahtar-değer çiftleri olan Worker’lar — veya bir yönlendirme eklemek için başlıkları değiştiren bir Worker.

Worker tabanlı bir tablo için KV doğal evdir: URL’ye göre anahtarlanan hızlı, nihai olarak tutarlı bir anahtar araması.

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);
  },
};

Yönlendirmeler ilişkisel olduğunda (örneğin sorgulamak istediğiniz locale veya segment bazlı SQL verileri varsa) D1 kullanın. Bir Worker’ın ne zaman gereğinden fazla karmaşık olduğunu da bilin: küçük ve statik bir yönlendirme kümesi için Cloudflare’in Bulk Redirects veya Redirect Rules özellikleri daha basittir ve hiç kod gerektirmez. Elli yönlendirme için kendi KV Worker’ınızı yazmayın.

Belirli bir URL için tek bir sahip seçin ve bir Worker yönlendirmesinin, bir Toplu Yönlendirmenin, bir Yönlendirme Kuralının ve bir kaynak yönlendirmesinin aynı yola uygulanmasına izin vermeyin — bunlar aynı istekte tetiklenebilen ayrı sistemlerdir ve birden fazlası eşleştiğinde, temiz bir yönlendirme yerine öncelik sırasını hata ayıklıyorsunuz demektir. Herhangi bir yere bir yönlendirme eklemeden önce, diğer sistemlerde o yol için zaten bir tane olup olmadığını kontrol edin ve katmanı eşleşme karmaşıklığına (basit 1:1 ve desen tabanlı), ölçeğe ve kimin gözlemlemesi veya geri alması gerektiğine göre seçin — bir Worker yönlendirmesi kodunuzda ve günlüklerinizde yaşar; bir Toplu Yönlendirme veya Kural panelde yaşar ve teknik olmayan birinin denetlemesi veya geri alması daha kolaydır.

Önbelleğe alma: aynı kafa karıştırıcı adla üç farklı şey

Bu, rakip sayfaların atladığı bölümdür ve en çok “değişikliğim neden görünmedi” kafa karışıklığını yaratan bölümdür. Önbellek kelimesini paylaşan üç ayrı katman vardır:

• Workers Cache API — caches.default ve caches.open(). Bu, kodda okuyup yazdığınız, Worker kapsamında programlanabilir bir önbellektir.
• Cloudflare uç önbelleği — varlıklarınızı sunan CDN önbelleği. Cache API’den farklıdır.
• Kaynak Cache-Control — kaynağınızın (veya Worker’ınızın) ayarladığı ve yukarıdakilerin her ikisini ve Googlebot’un ne yaptığını etkileyen başlıklar.

Bunları birbirine karıştırırsanız, bir değişikliğin dağıtılmadığına yemin edersiniz, oysa sadece temizlemediğiniz bir katmandan sunuluyordur.

Bir değişiklik gerçekten görünmediğinde, tahmin etmeyin — katman katman teşhis edin:

1. Önbellek anahtarı. İki isteğin aynı önbellek girdisiyle eşleşip eşleşmediğini hangi istek nitelikleri belirliyor? Bunlar URL; önbellek anahtarınıza dahil edilmişse üstbilgiler veya çerezler olabilir. Önbellek anahtarında bulunmayan bir niteliğe göre değişen yeniden yazma işlemi yanlış varyantı sunabilir.
2. Yanıtı sunan katman. Uç önbelleğin yanıt verip vermediğini veya isteğin Worker’ınıza ulaşıp ulaşmadığını görmek için CF-Cache-Status (HIT/MISS/EXPIRED/DYNAMIC) değerini kontrol edin.
3. Konum/durum. Cloudflare önbelleği veri merkezlerine dağıtılmıştır; bir temizleme işlemi veya yeni dağıtım, tüm uç konumlarını mutlaka anında geçersiz kılmaz.
4. TTL ve onu belirleyen kural. TTL’yi bir önbellek kuralının mı, kaynağınızdan gelen bir Cache-Control üstbilgisinin mi, yoksa Worker’ınızın ayarladığı bir üstbilginin mi denetlediğini doğrulayın.
5. Geçersiz kılma. Belirli URL’yi mi, tüm önbelleği mi temizlediniz, yoksa TTL’nin dolmasını mı beklediniz? Worker’a ait bir Cache API girdisinin (caches.default) ayrıca açıkça delete() ile silinmesi gerekir; CDN önbelleğini temizlemek bu girdiyi etkilemez.

Googlebot’un ETag / If-None-Match / 304 ile yaptıkları

Worker’ınız yanıtı üretiyor veya yeniden yazıyorsa önbellek üstbilgilerinin sahibidir. Dolayısıyla Google’ın Aralık 2024 tarihli HTTP önbellekleme rehberi sizin için doğrudan uygulanabilir niteliktedir. Google, ETag/If-None-Match ve Last-Modified/If-Modified-Since aracılığıyla sezgisel HTTP önbelleklemeyi destekler; hataya daha az açık olduğu için ETag kullanımını önemle tavsiye eder ve tarayıcının gönderdiği ETag eşleştiğinde sunucunuzun gövdesiz bir 304 Not Modified yanıtı döndürmesi gerektiğini belirtir. Yanıt üreten bir Worker tam olarak bunu uygulayabilir: bir ETag hesaplayabilir, bunu If-None-Match ile karşılaştırabilir ve doğrudan 304 döndürebilir. Böylece işlem gücünden tasarruf eder ve Googlebot’a hızlı, önbelleğe alınabilir bir sinyal verir.

max-age yeniden tarama takası

Google ayrıca tarayıcıların belirli bir URL’yi ne zaman yeniden tarayacaklarına karar vermelerine yardımcı olmak için Cache-Control: max-age ayarlamayı düşünmenizi önerir. HTML’i yeniden yazan bir Worker açısından sorun şudur: Worker tarafından eklenen etiketleri yeni değişmiş bir sayfada agresif bir max-age kullanmak, Googlebot’un az önce yayınladığınız güncellemeyi görmesini geciktirebilir. Yeniden yazılmış HTML’e uzun bir önbellek ömrü verip konuyu unutmayın.

Gizleme sınırı, Workers’a uygulandı

Workers açısından kesin kural şudur: her isteği gönderen için aynı mantığı çalıştırın. Google’ın spam politikası, sıralamaları manipüle etmek amacıyla kullanıcılara ve arama motorlarına farklı içerik sunmayı cloaking olarak tanımlar ve özellikle yalnızca isteği gönderen bir arama motoru olduğunda metin veya anahtar kelime eklemeyi örnek gösterir.

Birkaç açıklama, çünkü insanlar burada aşırıya kaçıyor:

• User-Agent’ı incelemek kendiliğinden cloaking değildir. Bot trafiğini günlüğe kaydetmek veya önbelleğe alınmış bir yanıtı herhangi bir istemciye daha hızlı sunmak sorun değildir. Sınır, sıralamaları manipüle etmek amacıyla isteği gönderenin kimliğine göre içeriğin farklılaştırılmasıdır.
• Workers üzerinde sayfa bazlı A/B testi yapılabilir. Kullanıcıları URL’ye göre ayırmak ve her isteği göndereni aynı şekilde ele almak meşrudur. İsteği kimin gönderdiğine göre, yani bot ile insan arasında ayrım yapmak ise meşru değildir.

Güvenli yaklaşımın uygulamalı bir örneği bu sitenin kendi önizleme geçididir: bir çerez gizli değerle eşleşmediği sürece tüm /preview/ yollarına 404 döndüren bir Worker kullanılır. Doğru çereze sahip olmayan herkese, Googlebot dahil, aynı 404 yanıtını verir. Güvenli yapı tam olarak budur: botlardan bir şeyi gizleyip kullanıcılara başka bir şey göstermez; tek bir kuralı herkese eşit biçimde uygular.

Workers üzerinde düzgün biçimde oluştursanız bile yalnızca botlara yönelik bir ön işleme adımına güvenmeyin. Google, dinamik oluşturmayı geçici bir çözüm olarak nitelemiş ve uzun vadeli bir çözüm olmadığını belirtmiştir; yalnızca botlar için ön işleme yapan bir Worker da kullanımdan kaldırılan bu yaklaşımı devralır.

Bir Worker Googlebot’u nasıl yanlışlıkla engelleyebilir veya yavaşlatabilir

Bu, Workers’a özgü biçimde kendi ayağınıza sıkmanın en yaygın yoludur ve genellikle sorun Worker kodunuzda değildir.

Bot Fight Mode, Ruleset Engine dışında çalışır

Bot Fight Mode (ve Super Bot Fight Mode), Googlebot dahil meşru tarayıcıları yanlışlıkla tehdit olarak algılayabilir. Buradaki tuzak şudur: Bot Fight Mode, WAF Ruleset Engine’den ayrı bir işlem hattında değerlendirilir. Bu nedenle sıradan WAF “allow” veya “skip” özel kurallarınız onu geçersiz kılamaz. Bot Fight Mode Googlebot’a doğrulama adımı uyguluyorsa bunu bir izin kuralıyla düzeltemezsiniz; modun kendisini değiştirmeniz veya devre dışı bırakmanız gerekir. (Bu özelliğe güvenmeden önce güncel işleyişi Cloudflare’in Bot Fight Mode ve Super Bot Fight Mode belgelerinden doğrulayın; bot ürünleri değişebilir.)

Doğrulanmış botlar özel kural deseni

Cloudflare, cf.client.bot alanını ve bir doğrulanmış botlara izin deseni sunar; böylece özel kurallarınızda bilinen iyi tarayıcılara izin verebilirsiniz — WAF tarafı için yararlıdır, ancak (yukarıdaki gibi) Bot Fight Mode’a ulaşmaz.

CDN’nin kendisi nötrden olumluya

Yaygın yanılgıyı açıklığa kavuşturalım: CDN olarak Cloudflare SEO’ya zarar vermez. Google’ın 2024 tarihli Crawling December çalışması, bir CDN algıladığında Google’ın tarama hızını artırdığını; ancak CDN’nin WAF veya bot kuralları aracılığıyla Googlebot’u yanlışlıkla engelleyebileceğini ve bot doğrulama ara sayfası yerine 503 yanıtı vermenin daha iyi olduğunu belirtir. Risk altyapının kendisi değil, yanlış yapılandırılmış bir Worker veya bot ayarıdır.

Googlebot’un gerçekte ne aldığını doğrulama

Herhangi bir Worker dağıtımından sonra, bir tarayıcının gerçekte ne aldığını doğrulayın — varsaymayın:

• GSC URL Inspection → Test Live URL. Sayfayı Google gibi getirir ve oluşturulmuş HTML’i gösterir; böylece eklediğiniz canonical/hreflang/JSON-LD verilerinin gerçekten mevcut olduğunu doğrulayabilirsiniz.
• HTML ile birlikte CF-Cache-Status değerini kontrol edin. HIT / MISS / EXPIRED, yeni bir Worker yanıtına mı yoksa önbelleğe alınmış bir yanıta mı baktığınızı gösterir. Bu, aslında önbellek katmanından kaynaklanan bir “değişiklik görünmedi” sorununu yakalamanın en hızlı yoludur.
• Doğrudan Googlebot olarak getirin. Googlebot’un kullanıcı aracısıyla istek gönderip yanıtları karşılaştırın. Ancak yalnızca dizenin eşleşmesi kimliği kanıtlamaz; gerçek Googlebot’u, Google’ın yayımladığı aralıkları kullanarak ters ve ileri DNS sorgularıyla doğrulayın (Scripts sekmesine bakın).

Workers’a özel dağıtım hijyeni

Başarılı bir wrangler deploy komutu, betiğin gönderildiğini söyler — Googlebot’un doğru işlenmiş çıktıyı aldığını söylemez. SEO’yu etkileyen her Worker değişikliğini yalnızca bir gönderim değil, kaydı tutulan bir sürüm olarak ele alın:

• Rotalarınızın kapsamını daraltın. Bir Worker’ı varsayılan olarak /* üzerinde çalıştırmayın. wrangler.toml içindeki rota desenlerini yalnızca gereken yollarla eşleştirin; böylece bir hata tüm sitenizi devre dışı bırakamaz.
• Ölçek sözü vermeden önce güncel sınırları kontrol edin. CPU süresi, alt istek sayısı ve betik boyutu sınırları plana göre değişir ve zamanla güncellenir. Belirli bir sınıra göre yeniden yazma tasarlamadan önce, hatırladığınız bir sayıya güvenmek yerine Cloudflare’in güncel sınırlar sayfasını doğrulayın.
• Her yayın için sürüm meta verilerini kaydedin. Cloudflare’in versions and deployments modeli her dağıtımın kaynak sürümünü, uyumluluk tarihini, binding’lerini ve rotalarını izler. Hangi rotada hangi sürümün canlı olduğunu kaydedin; böylece “Worker X yapıyor” iddiası, editörünüzdeki kodla değil gerçekten dağıtılmış sürümle karşılaştırılabilir.
• Wrangler ortamlarıyla sürümleyin ve geri alın. Önce hazırlık ortamına dağıtın, yüzde bazında kademeli yayın yapın ve önceki sürüme anında dönebilme olanağını koruyun.
• Yayını izlemek için kapsamı belirlenmiş günlükler kullanın; sınırlarını unutmayın. Cloudflare’in Workers Logs özelliği ve canlı günlük izleme, kademeli bir yayında hata ayıklamaya yardımcı olabilir. Ancak günlükler örneklenir ve sınırlı süre saklanır; bunları tüm tarayıcı ziyaretlerinin eksiksiz kaydı olarak değil, yakaladıkları isteklere ilişkin kapsamlı kanıt olarak değerlendirin.
• Bir durdurma koşulu belirleyin ve gerekmeden önce geri alma işlemini test edin. Hangi gözlemlenen davranışın (hata oranı, noktasal kontrolde yanlış yanıt veya tarama hızında düşüş) yayını durduracağını önceden belirleyin ve geri alma yolunun çalıştığını varsaymak yerine doğrulayın.
• Önbelleği temizlemeyi dağıtımın bir parçası yapın. Üç önbellek katmanı devrede olduğundan temizleme/geçersiz kılma işlemini sonradan düşünülecek bir konu değil, yeniden yazma işlemini yayınlamanın açık bir adımı hâline getirin.

Bir Bing notu ve ileriye dönük bir şey

Bing’in de Cloudflare/edge’e özgü bir rehberi yoktur. Ancak Worker dağıtımı anında gerçekleşirken tarama aynı hızda gerçekleşmediği için IndexNow doğal bir tamamlayıcıdır. Worker tarafından yönetilen bir yönlendirme tablosu veya etiket değişikliği yayınlanır yayınlanmaz IndexNow’ı tetikleyerek Bing’in ve katılımcı diğer arama motorlarının içeriği kısa sürede yeniden taramasını sağlayın. Ayrıca Cloudflare’in uçta zorunlu canonicalization’ı bir ürün özelliği olarak sunduğu “Redirects for AI Training” özelliğine de göz atmaya değer: doğrulanmış AI eğitim tarayıcıları tek bir ayarla canonical URL’nize 301 ile yönlendirilir. Bu, kendi Worker’ınızda canonical mantığını elle yazmakla yararlı bir karşılaştırma sunar. Ayrıca “tarayıcılara kullanıcılardan farklı içerik sunma” yaklaşımına Microsoft’un Cloudflare’in diğer AI tarayıcı özellikleri bağlamında kamuoyu önünde kuşkuyla yaklaştığını hatırlatır; bot koşuluna bağlı her Worker için iyi bir sağduyu kontrolüdür.

Daha geniş resim için — platform karşılaştırması, Snippets vs. Workers, geliştirici kuyruğu ve yönetişim açıları — Edge SEO merkezine geri dönün.

AI özeti

Gelişmiş sürümün özeti:

• Cloudflare Workers SEO = Cloudflare’in V8 isolate çalışma zamanında teknik SEO uygulamak. Bu, genel Edge SEO kavramının kod düzeyindeki, Workers’a özgü uygulamasıdır. Tanım, platform karşılaştırması ve cloaking konusunun ayrıntıları için ilgili merkeze bakın.
• Bir Worker yalnızca rotasıyla eşleşen istekleri görür. Rota/alan adı yapılandırması ve öncelik sırası, hangi isteklerin fetch işleyicisine ulaşacağını belirler. Belirli bir URL’deki Worker davranışına güvenmeden önce rotayı ve dağıtılmış sürümü doğrulayın.
• Tek bir fetch işleyicisi, üç aşama: isteği, yanıt üstbilgilerini ve yanıt gövdesini yeniden yazın. Gövdeyi yeniden yazma işlemi HTMLRewriter üzerinden yürür; canonical eklemenin, hreflang düzeltmenin veya JSON-LD eklemenin gerçek mekanizması budur. Yeniden yazma işlemini idempotent hâle getirin ve yalnızca sorunsuz senaryoyla değil; eksik, yinelenen, hatalı biçimlendirilmiş ve HTML olmayan yanıtlarla da test edin.
• Yönlendirmeler: hızlı anahtar aramaları için KV, ilişkisel yapılandırma için D1, küçük statik kümeler için Bulk Redirects/Rules kullanın. Patrick sunucu düzeyindeki yönlendirmeler yerine uç düzeyindeki yönlendirmeleri tercih eder; ancak her URL için tek bir sahip seçin. Aynı yolda Worker redirect, Bulk Redirect, Redirect Rule ve kaynak yönlendirmesi birlikte tetiklenebilir.
• Üç önbellek aynı sözcükle anılır: Workers Cache API (caches.default), Cloudflare uç önbelleği ve kaynak Cache-Control. Bunları karıştırmak “değişikliğim görünmedi” sorununa yol açar. Tahmin yürütmek yerine önbellek anahtarı, katman, TTL ve geçersiz kılma üzerinden teşhis koyun.
• Google’ın ETag/If-None-Match/304 önbellekleme rehberi (Aralık 2024) doğrudan uygulanabilir: yanıtın sahibi olan bir Worker doğrudan 304 döndürebilir; ancak agresif bir max-age, yeni değiştirilmiş bir sayfanın yeniden taranmasını geciktirebilir.
• Cloaking kuralı: her isteği gönderen için aynı mantığı uygulayın. UA’yı incelemek tek başına cloaking değildir; sıralamaları manipüle etmek amacıyla isteği gönderenin kimliğine göre içerik farklılaştırmak cloaking’dir.
• En büyük kullanıcı kaynaklı risk: Bot Fight Mode, WAF Ruleset Engine dışında çalışır; bu nedenle normal izin kuralları ona erişemez. Modun kendisini değiştirmeniz gerekir.
• Planlı biçimde yayınlayın: ölçek sözü vermeden önce güncel plan sınırlarını kontrol edin, her yayın için sürüm meta verilerini (uyumluluk tarihi, binding’ler ve rotalar) kaydedin, yayını izlemek için kapsamı belirlenmiş günlükler kullanın (bunlar örneklenir ve eksiksiz kayıt değildir) ve gerekmeden önce test edilmiş bir geri alma yöntemiyle durdurma koşulu belirleyin.
• Doğrulamayı GSC URL Inspection (Test Live URL) ve CF-Cache-Status üstbilgisiyle yapın; yoğun yeniden yazma işlemlerinde CPU sınırlarını (ücretsiz planda 10 ms / ücretli planda 30 ms) izleyin.

Resmi dokümantasyon

Google veya Bing’in Cloudflare Workers’a özgü bir SEO belgesi yoktur; geçerli rehberler geneldir. En yararlı birincil kaynaklar arama motorlarının politika/önbellekleme belgeleri ile Cloudflare’in çalışma zamanı API’leri arasında dağılmıştır.

Google (herhangi bir uç uygulaması için geçerlidir)

• Spam politikaları — cloaking — herhangi bir Worker mantığının saygı göstermesi gereken katı sınır.
• Aralık taraması: HTTP önbellekleme (2024) — ETag / If-None-Match / 304 / max-age, yanıta sahip bir Worker için doğrudan uygulanabilir.
• Aralık taraması: CDN’ler ve tarama (2024) — bir CDN’nin tarama hızını nasıl etkilediği ve bot kurallarının Googlebot’u nasıl engelleyebileceği.
• Dinamik oluşturma (kullanımdan kaldırıldı) — yalnızca botlara özel bir ön oluşturma Worker’ının neden kullanımdan kaldırılmış bir deseni miras aldığı.
• Google tarayıcılarına ve getiricilerine genel bakış — doğrulama için kullanıcı aracıları ve yayınlanan IP aralıkları.

Cloudflare (çalışma zamanı)

• HTMLRewriter — akış tabanlı HTML ayrıştırıcı API’si.
• Cache API — caches.default / caches.open().
• Önbellek nasıl çalışır — Cache API ile uç önbellek arasındaki fark.
• Yollar ve alan adları — yol eşleştirme, öncelik ve hangi isteklerin gerçekten bir Worker’ı çağırdığı.
• Toplu Yönlendirmeler — bir Worker yönlendirmesinin çakışabileceği veya örtüşebileceği kod gerektirmeyen yönlendirme sistemi.
• Workers sınırları — güncel CPU, alt istek ve betik boyutu tavanları; plan ve tarihe duyarlıdır, bu yüzden hatırlanan bir sayıya güvenmek yerine doğrudan kontrol edin.
• Sürümler ve dağıtımlar — sürümlü/kademeli dağıtımlar ve geri alma.
• Workers Günlükleri — çağrı günlükleri, izleme ve bunların örnekleme/saklama sınırları.
• Bot Fight Mode / Super Bot Fight Mode — Googlebot’u engelleyebilecek bot ayarları.
• Doğrulanmış botlardan gelen trafiğe izin ver — cf.client.bot özel kural deseni.

Bing — uç/Workers sayfası yoktur; IndexNow dağıtım sonrası anında yeniden tarama için ilgili eşleştirmedir.

Kaynaktan alıntılar

Kayıt altına alınmış ifadeler. Her Google bağlantısı, alıntılanan pasaja atlayan derin bir bağlantıdır.

Google — gizleme sınırı

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” — Google Search Central, Spam policies for Google web search. Alıntıya git
• “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” — cloaking örneği olarak listelenmiştir. Alıntıya git

Google — HTTP önbellekleme (Aralık 2024 Taraması)

• “Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” Alıntıya git
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” Alıntıya git
• “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” Alıntıya git
• “While not required, consider also setting the max-age field of the Cache-Control header to help crawlers determine when to recrawl the specific URL.” Alıntıya git

Google — dinamik oluşturma (kullanımdan kaldırıldı)

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” Alıntıya git

Ben — uç düzey yönlendirmeler hakkında

• “I typically prefer to have redirects on the edge (CDN-level) over having them on the server.” — Ahrefs rehberim 11 Types of Redirects & Their SEO Impact’ten. Kendi yayımlanmış makalemden aktarılmıştır; ifade bana aittir ancak kesin alıntı olarak değerlendirmeden önce canlı sayfadaki tam ifadeyi doğrulayın.

Cloudflare / SALT.agency — yönlendirmeler için neden Workers

• “we needed to implement simple redirects, which should be easy to create on the majority of platforms but wasn’t supported” — Igor Krestov ve Dan Taylor, Diving into Technical SEO using Cloudflare Workers (Cloudflare blogu). Cloudflare blog yazısının özetinden aktarılmıştır ve metinde birebir geçen bir ifade olduğu doğrulanmamıştır; kesin blok alıntı olarak kullanmadan önce canlı sayfadan yeniden doğrulayın.

İş için hangi araç?

“Yönlendirme eklemem gerekiyor.”

• Küçük, statik bir küme (birkaç düzine, mantık gerektirmiyor) mi? → Cloudflare Bulk Redirects veya Redirect Rules. Worker ve kod gerekmez.
• URL’ye göre anahtarlanmış binlerce yönlendirme mi? → Worker + KV araması.
• İlişkisel (locale veya segment bazında sorgulanan) yönlendirmeler mi? → Worker + D1.
• Aynı geçişte hem yönlendirme yapmak hem de üstbilgileri yeniden yazmak mı gerekiyor? → Worker (Rules ikisini birlikte yapamaz).

“Bir etiket (canonical, hreflang, title, JSON-LD) eklemem veya düzeltmem gerekiyor.”

• → HTMLRewriter içeren bir Worker. Rastgele gövde yeniden yazma için kod gerektirmeyen bir Cloudflare ürünü yoktur; bu Workers’ın işidir.

“Cloudflare’i ekledikten sonra Googlebot’un tarama hacmi düştü.”

• İlk olarak Worker’ınızdan değil, Bot Fight Mode / Super Bot Fight Mode özelliğinden şüphelenin. Googlebot’a doğrulama adımı uygulayıp uygulamadığını kontrol edin. Bir WAF izin kuralının bunu düzeltemeyeceğini unutmayın; modun kendisini değiştirmeniz gerekir.
• Ardından WAF özel kurallarını ve botlara 503 ya da doğrulama ara sayfası sunulup sunulmadığını kontrol edin.
• Ancak bunlardan sonra Worker kodunu ve rota kapsamını denetleyin.

“Eklediğim etiket görünmüyor.”

• CF-Cache-Status değerini kontrol edin. HIT/EXPIRED mi? Önbelleğe alınmış bir yanıt görüyorsunuz. Doğru katmanı (Workers Cache API veya uç önbelleği) temizleyip yeniden test edin.
• MISS olmasına rağmen sonuç hâlâ yanlış mı? Bu durumda sorun Worker mantığında veya rota kapsamındadır. GSC URL Inspection ile doğrulayın.

“Bir Worker’da yalnızca botlar için ön işleme yapmalı mıyım?”

• → Hayır. Bu, Google’ın kullanımdan kaldırdığı dinamik oluşturma yaklaşımıdır. Herkese uygulanan SSR veya statik oluşturmayı tercih edin.

Cloudflare Workers SEO kontrol listesi

Bir yeniden yazma Worker’ını yayınlamadan önce

• Rota, wrangler.toml içinde yalnızca gereken yollarla sınırlandırıldı; refleks olarak /* kullanılmadı ve o rotada gerçekten hangi dağıtılmış sürümün canlı olduğu doğrulandı.
• Worker, her isteği gönderene aynı mantığı uyguluyor (bot ve insan için ayrı içerik dalı yok).
• HTMLRewriter işleyicileri idempotent ve yalnızca sorunsuz senaryoyla değil; eksik etiket, yinelenen/hatalı mevcut etiket ve HTML olmayan yanıtlarla da test edildi.
• Yönlendirmeler için doğru araç seçildi: Bulk Redirects/Rules (küçük/statik), KV (büyük ölçekte URL anahtarlı) veya D1 (ilişkisel). Ayrıca başka bir yönlendirme sisteminin ilgili URL’nin sahibi olmadığı doğrulandı.
• Güncel plan sınırları (CPU, alt istekler ve betik boyutu) bellekten değil, doğrudan kaynaktan kontrol edildi.
• Yeniden yazılmış HTML’deki Cache-Control, değiştirilen sayfaların yeniden taranmasını geciktirecek kadar agresif değil.
• Yayına ait sürüm meta verileri (uyumluluk tarihi, binding’ler ve rotalar), test edilmiş geri alma yolu ve tanımlı durdurma koşuluyla birlikte kaydedildi.

Önbellek sağlaması

• Üç katmandan hangisine (Workers Cache API / uç önbellek / kaynak Cache-Control) dokunduğunuzu biliyorsunuz.
• Worker yanıtın sahibiyse, doğru bir ETag ayarlar ve 304’e kısa devre yapabilir.
• Önbellek temizleme/geçersiz kılma, dağıtımda açık bir adımdır.

Bot erişimi

• Bot Fight Mode / Super Bot Fight Mode, Googlebot’a doğrulama adımı uygulamıyor (doğrudan kontrol edildi; bir WAF izin kuralı bunu geçersiz kılamaz).
• WAF tarafında erişim kısıtlanıyorsa doğrulanmış botlara yönelik özel kural (cf.client.bot) etkin.
• Botları yavaşlatmanız gerektiğinde doğrulama ara sayfası yerine 503 yanıtı alıyorlar.

Dağıtımdan sonra doğrulayın

• GSC URL Inspection → Test Live URL, enjekte edilen etiketin işlenmiş HTML’de olduğunu doğrular.
• CF-Cache-Status kontrol edildi (HIT/MISS/EXPIRED), böylece önbelleğe alınmış bir kopya görüp görmediğinizi bilirsiniz.
• Bir yönlendirme tablosu veya etiket değişikliği yeni yayınlandıysa IndexNow tetiklendi (Bing/diğerleri).
• Test edilmiş bir geri alma yolu ile Wrangler ortamları aracılığıyla sürümlendi.

Zihinsel modeller

1. Tek işleyici, üç aşama. Her Worker bir fetch işleyicisidir ve yaptığınız her şey sırayla üç aşamadan birinde yaşar: isteği yeniden yaz → yanıt başlıklarını yeniden yaz → yanıt gövdesini yeniden yaz (HTMLRewriter). Bir satır yazmadan önce neyi değiştirdiğinizi bu sıraya yerleştirin.

2. “Önbellek” tek şey değil, üç şeydir. Workers Cache API (caches.default) ≠ Cloudflare uç önbelleği ≠ kaynak Cache-Control. Bir değişiklik “görünmüyorsa”, koda dokunmadan önce hangi katmana gerçekten baktığınızı sorun.

3. Cloaking testi: kimlik ve mantık. İsteği kimin gönderdiğine göre dallanarak içeriği değiştirmek = cloaking. Günlükleme veya hız amacıyla UA’yı incelese bile aynı mantığı herkese uygulamak sorun değildir. Şunu sorun: “Gerçek bir kullanıcı, Googlebot’un aldığı içeriğin aynısını alır mı?”

4. Tarama düşüşünde inceleme sırası. Bot Fight Mode → WAF kuralları → Worker kodu → rota kapsamı. Bot ayarları, izin kurallarınızın erişemediği ayrı bir işlem hattında çalışır; bu nedenle önce onları inceleyin.

5. Worker yanıtın sahibidir — bu yüzden önbelleğe alma semantiğinin de sahibidir. Worker’ınız gövdeyi üretiyor veya yeniden yazıyorsa, ETag, 304 ve max-age’den sorumludur. Bu hem bir yetenektir (304’ü kendiniz kısa devre yapabilirsiniz) hem de bir yükümlülüktür (aşırı önbelleğe alıp yeniden taramayı geciktirebilirsiniz).

Cloudflare Workers SEO — hızlı başvuru

Yönlendirme aracını seçin

Üç önbellek

HTMLRewriter işleyici API’si

• getAttribute / setAttribute — bir etiket özniteliğini okur/ayarlar (ör. canonical href)
• prepend / append — bir öğenin içine işaretleme ekler (ör. head içine bir etiket)
• setInnerContent — bir öğenin içeriğini değiştirir
• replace — öğeyi tamamen değiştirir

Hızlı bilgiler

• CPU sınırı: ücretsiz planda 10 ms / ücretli planda 30 ms (duvar saatiyle ölçülen fetch bekleme süresi sayılmaz).
• Cloaking = sıralamaları manipüle etmek amacıyla isteği gönderenin kimliğine göre içerik farklılaştırmak; “Worker UA’yı okudu” demek değildir.
• Bot Fight Mode, WAF Ruleset Engine dışında çalışır; izin kuralları ona erişemez, modu değiştirmeniz gerekir.
• Worker değişikliğini GSC Test Live URL ve CF-Cache-Status üstbilgisiyle doğrulayın.
• Google ETag kullanımını tavsiye eder; ETag eşleşiyorsa gövdesiz 304 döndürün.

Googlebot’un gerçekte ne aldığını doğrulayın — bir Worker dağıtımından sonra

Googlebot olarak getirip farkları karşılaştırın (kabuk)

# Fetch as a normal browser
curl -sS -A "Mozilla/5.0" https://example.com/page/ -o user.html -D user.headers

# Fetch as Googlebot's UA
curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o bot.html -D bot.headers

# The bodies should be identical — a diff is a cloaking red flag
diff user.html bot.html && echo "identical (good)"

# Check what cache layer served it
grep -i "cf-cache-status" bot.headers   # HIT / MISS / EXPIRED

Gerçek Googlebot’u doğrulayın (UA dizeleri kolayca taklit edilebilir) — ters + ileri DNS

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# 2) Forward DNS that hostname back — must resolve to the same IP
host crawl-66-249-66-1.googlebot.com

Denetimlerden biri başarısız olursa söz konusu istek Googlebot’tan değildir. Google’ın yayımladığı googlebot.json aralıklarıyla da eşleştirme yapabilirsiniz.

Oluşturulmuş HTML’den eklenen etiketleri okuyun (DevTools konsolu)

// Paste into the browser console on the live page to confirm your Worker's injection
[...document.querySelectorAll('link[rel="canonical"]')].map(l => l.href);
[...document.querySelectorAll('link[rel="alternate"][hreflang]')]
  .map(l => `${l.hreflang} -> ${l.href}`);
[...document.querySelectorAll('script[type="application/ld+json"]')].map(s => s.textContent);

Bir Worker içinde minimal bir ETag / 304 kısa devresi

export default {
  async fetch(request, env, ctx) {
    const res = await fetch(request);
    const body = await res.text();
    const etag = `"${await sha1(body)}"`;               // your hash of choice
    if (request.headers.get("If-None-Match") === etag) {
      return new Response(null, { status: 304 });        // no body, per Google's guidance
    }
    const headers = new Headers(res.headers);
    headers.set("ETag", etag);
    return new Response(body, { ...res, headers });
  },
};

Workers SEO oluşturmak ve doğrulamak için araçlar

• Wrangler — Workers geliştirmek, sürümlemek ve dağıtmak için Cloudflare’in CLI’ı (rota kapsamı, ortamlar, geri alma ve secret’lar). Dağıtım disiplininin uygulandığı yer burasıdır.
• HTMLRewriter — yerleşik, akış tabanlı HTML ayrıştırıcısı; tüm gövde yeniden yazma işlemlerinin API’sidir.
• Workers KV / D1 — yönlendirme tabloları ve yapılandırma için depolama seçenekleri (anahtar aramaları için KV, SQL için D1).
• GSC URL Inspection → Test Live URL — sayfayı Google gibi getirip oluşturur; böylece eklenen canonical/hreflang/JSON-LD verilerinin gerçekten yerleştiğini doğrulayabilirsiniz.
• CF-Cache-Status üstbilgisi (curl -I veya DevTools Network aracılığıyla) — HIT/MISS/EXPIRED değerini göstererek önbelleğe alınmış bir kopyaya mı, yoksa yeni bir Worker yanıtına mı baktığınızı anlamanızı sağlar.
• IndexNow — Worker kaynaklı değişiklik yayınlanır yayınlanmaz Bing’e ve katılımcı diğer arama motorlarına bildirim gönderir.
• Sunucu günlüklerinin analizi — gerçek ve doğrulanmış Googlebot’un Worker rotalarınıza ulaşıp ulaşmadığını belirleyen temel kanıt kaynağıdır.

SEO tutarlılığı ve önbellek davranışı için bir Worker’ı denetleyin

Review this Cloudflare Worker fetch handler as an SEO edge change. Trace the request,
response-header, body-rewrite, redirect, and caching paths. Return:
1. Every branch based on user agent, bot status, cookie, geography, or request header
2. Whether Googlebot/no-cookie traffic can receive different indexable content or SEO tags
3. HTMLRewriter selectors that fail when a tag is missing or create duplicates
4. Redirect lookups that can chain, loop, or fall through unexpectedly
5. Each use of the Cache API, Cloudflare edge cache behavior, and origin Cache-Control—kept as separate layers
6. Cache keys that could mix variants or preserve a stale canonical/robots/header change
7. A minimal test matrix for users, verified bots, cache hit/miss, and representative URLs

Apply the same content and SEO logic to bots and users. Flag intentional personalization
for human review rather than calling it cloaking automatically. Do not invent Cloudflare
settings, bindings, routes, cache rules, or origin behavior that are not in my input.

Worker code, bindings, routes, and relevant cache/security configuration:
[PASTE INPUT]

Dağıtımdan önce bir HTMLRewriter değişikliğini gözden geçirin

Audit this HTMLRewriter implementation for one SEO task: [CANONICAL / HREFLANG / JSON-LD].
Check whether it handles existing, missing, and duplicate elements; produces valid absolute
URLs or JSON; applies to the intended route cohort; and behaves identically for every
requester. Then return corrected code plus raw-response and rendered-response tests.

Do not add product, organization, locale, URL, or schema facts that are not supplied.

Code and expected per-route output:
[PASTE INPUT]

Kendinizi test edin: Cloudflare Workers SEO

Cloudflare Workers ile teknik SEO yapma hakkında beş hızlı soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Zamanınıza değer kaynaklar

İlgili yazılarım

• 11 Tür Yönlendirme ve SEO Etkileri (Ahrefs) — Cloudflare’deki yönlendirme seçenekleri ve sunucu düzeyi yönlendirmeler yerine neden uç düzeyi yönlendirmeleri tercih ettiğim.
• Teknik SEO Başlangıç Rehberi (Ahrefs) — uç değişikliklerin daha geniş resme nereye oturduğu.
• JavaScript SEO Sorunları ve En İyi Uygulamalar (Ahrefs) — işleme tarafı, uçta önceden işleme cazibesiyle ilgili.

Konuşmalarım

• Fine-Tune your Technical SEO, Page Speed, and Security (Marketing Speak röportajı) — kullanıcı sayfayı görmeden önce Cloudflare Workers ile yeniden yazma yapmayı ve yönlendirmeleri CDN’ye devretmeyi anlattığım bölüm. Sözlü röportaj dökümüdür; belirli ifadeleri birebir alıntı değil, açıklama olarak değerlendirin.

Sektörden kaynaklar

• Diving into Technical SEO using Cloudflare Workers — Cloudflare blogunda Igor Krestov (SALT.agency) ve Dan Taylor; filtre zinciri (istek/yanıt/gövde) modelinin çıkış noktası.
• What is edge SEO? (Search Engine Land) — bu makalenin bağlı olduğu merkezin ele aldığı kavramın üçüncü taraf anlatımı.
• Edge SEO (Dan Taylor) — terimi Cloudflare Workers araştırmalarından yola çıkarak ortaya atan kişinin yazısı.
• HTMLRewriter (Cloudflare belgeleri) — gövde yeniden yazma API’sinin temel referansı.
• How the cache works (Cloudflare belgeleri) — Cache API ile uç önbelleği arasındaki ayrımı açıklar.
• Redirects for AI Training (Cloudflare blogu) — ürün özelliği olarak uçta zorunlu canonicalization; bunu bir Worker’da elle uygulamakla yararlı bir karşılaştırma sunar.

Daha derine veya bağlantılı konulara geçin

• Edge SEO — ana merkez: genel kavram, platform karşılaştırması, Snippets ile Workers arasındaki seçim ve cloaking kuralının ayrıntılı açıklaması.

Değişiklik günlüğü