SEO için Headless CMS

TL;DR — Bir headless CMS, içerik yazdığınız yer ile gösterildiği yer arasında bir ayrım yapar. Bu ayrım SEO için sorun değildir — ancak yalnızca web sitesi tarafı arama motorlarına tamamen oluşturulmuş HTML sunuyorsa. Ana kural: sayfalarınızı bir sunucuda veya derleme zamanında (SSR veya SSG) oluşturun, ziyaretçinin tarayıcısında tamamen değil (CSR). Ve tüm SEO işlerini bir WordPress eklentisinin sizin için yaptığı gibi — başlıklar, site haritaları, robots.txt — artık kendiniz kurmanız gerekiyor.

”Headless” gerçekte ne anlama geliyor

WordPress gibi geleneksel bir kurulumda, içerik yazdığınız yer ile onu bir web sayfasına dönüştüren yer aynı sistemdir. Bir headless CMS bu iki işi birbirinden ayırır. CMS yalnızca bir içerik deposu haline gelir (Contentful, Sanity, Strapi ve diğerleri) ve ayrı bir web sitesi — Next.js, Nuxt, Astro veya Gatsby gibi bir çerçeveyle oluşturulmuş — bu içeriği getirir ve gerçek sayfaları oluşturur. Evidence for this claim A headless CMS separates content management from the presentation frontend and exposes content through APIs. Scope: Contentful as a representative headless CMS architecture. Confidence: high · Verified: 2026-07-14 Contentful: What is a headless CMS?

İnsanlar bunun SEO için kötü olduğundan endişeleniyor. Kendi başına değil. Arkada oturan CMS’in sıralamalarınız üzerinde neredeyse hiçbir etkisi yoktur. Önemli olan, ön kısmın sayfayı nasıl oluşturduğudur.

Önemli olan tek karar: oluşturma

Birisi (veya Googlebot) bir sayfa istediğinde, bitmiş HTML nerede üretilir? Temel olarak iki güvenli cevap ve bir riskli olan vardır:

• Derleme zamanında (SSG) — sayfalar önceden düz HTML dosyaları halinde oluşturulur. Hızlı ve arama dostu.
• Sunucuda, istek başına (SSR) — sunucu tam sayfayı oluşturur ve gönderir. Ayrıca arama dostu ve her zaman güncel.
• Ziyaretçinin tarayıcısında (CSR) — sunucu neredeyse boş bir kabuk gönderir ve JavaScript daha sonra onu doldurur. Bu, SEO için riskli olanıdır.

Google JavaScript çalıştırabilir, ancak oluşturma ayrı bir işleme aşamasıdır ve JavaScript yine de başarısız olabilir veya engellenebilir. Diğer tarayıcıların farklı oluşturma yetenekleri vardır, bu nedenle sunucuda oluşturulmuş veya önceden oluşturulmuş HTML, kritik içeriği sunmanın en taşınabilir yoludur. Evidence for this claim Google processes JavaScript through a rendering stage, and blocked or failed resources can prevent expected content from rendering. Scope: Google Search; other crawlers have their own capabilities. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

”SEO ayarlarım nereye gitti?” sorunu

WordPress’te Yoast gibi bir eklenti başlıklarınızı, meta açıklamalarınızı, site haritanızı ve canonical etiketlerinizi sessizce hallediyordu. Headless bir sitenin eklenti katmanı yoktur. Bu, bir geliştiricinin bilinçli olarak şunları yapması gerektiği anlamına gelir:

• CMS’deki içerik modeline SEO alanları (başlık, açıklama vb.) ekleyin.
• Bu alanları sayfanın HTML’sine bağlayın.
• Bir site haritası ve bir robots.txt oluşturun.

Bunların hiçbiri zor değil — sadece kendiliğinden olmayacak. “Headless sitem SEO’sunu kaybetti” hikayelerinin çoğu aslında “kimse eklentinin yaptığı şeyleri yeniden oluşturmadı” hikayesidir.

Sessizce bozulan birkaç şey

• Önizleme/geçici sitelerin dizine eklenmesi. Headless kurulumlar genellikle herkese açık önizleme URL’leri oluşturur. Google bunları bulursa, sitenizin tamamen kopyalanmış bir sürümünü dizine ekleyebilir. Bunların dizine eklenmesi engellenmelidir.
• Gerçek bağlantı olmayan bağlantılar. Arama motorları yalnızca gerçek <a href> bağlantılarını takip eder. JavaScript ile gezinme yapan tıklanabilir bir <div> taranmayacaktır.

Tam sürümü mü istiyorsunuz — dört oluşturma modunun karşılaştırması, canonical etiketler, site haritaları, ISR bayat içerik tuzağı, Bing ve geçişler? Gelişmiş sekmesine geçin.

TL;DR — Headless SEO’da mimari üründür: CMS arka ucu neredeyse SEO açısından nötrdür ve ön ucun oluşturma modu her şeyi belirler. SSG ve SSR tamamen oluşturulmuş HTML sunar ve güvenli seçeneklerdir; CSR en riskli olanıdır; ISR, yeniden doğrulamadan sonraki ilk istekte bayat içerik tuzağı taşır. Yoast’ın otomatik olarak yaptığı her şey — meta veriler, canonicals, site haritaları, robots.txt — artık açıkça siz oluşturursunuz ve canonical mantığı CMS → çerçeve → bileşen arasında parçalanır, bu nedenle onu tek bir SITE_URL’den oluşturma katmanında ayarlayın. Aynı ayrım, yerel ayar yönlendirmesi/hreflang ve önizleme erişimi için de geçerlidir (önce kimlik doğrulayın; noindex ikincildir, erişim kontrolü değildir). Google dinamik oluşturmayı kullanımdan kaldırdı (SSR/SSG/hidrasyon kullanın), AI tarayıcı oluşturma sağlayıcıya göre değişir ve yayınlama/yayından kaldırma olaylarının bir zamanlayıcı değil, webhook tarafından tetiklenen bir önbellek temizlemesi gerektirir.

Mimari üründür

Headless bir CMS yalnızca bir arka uçtur: içerik depolama, içerik modeli, düzenleme arayüzü ve bir API. Ön uç — Next.js, Nuxt, Gatsby, Astro, SvelteKit, Remix — REST veya GraphQL üzerinden içerik getiren ve onu işleyen ayrı bir uygulamadır. Buradaki en kullanışlı zihinsel model şudur: seçtiğiniz CMS’in doğrudan SEO etkisi neredeyse yoktur; ön uçtaki işleme kararları her şeyi belirler. Her headless SEO konuşması şu soruyla başlamalıdır: ön uç bu içeriği nasıl işliyor? Evidence for this claim A headless CMS supplies content through APIs while a separate frontend controls how pages are rendered. Scope: Contentful as a representative headless CMS architecture. Confidence: high · Verified: 2026-07-14 Contentful: What is a headless CMS?

Bu yüzden “headless SEO için kötüdür” yanlış bir çerçevedir. Headless tarafsızdır. SSR veya SSG üzerinde iyi yapılandırılmış, disiplinli meta verilere sahip bir headless site, ihmal edilmiş bir WordPress kurulumundan daha iyi performans gösterir. Varsayılan olarak istemci tarafı işlemeye geçen ve meta veri katmanını asla yeniden oluşturmayan bir headless site sessizce dağılır. Bu, JavaScript SEO rehberimde yaptığım aynı noktadır: web düz HTML’den uzaklaştı ve bir SEO olarak bununla savaşmak yerine onu benimseyebilirsiniz.

Kim neye sahip: CMS, API ve ön uç

“CMS neredeyse SEO-nötrdür” doğru bir içgüdüdür, ancak gerçek bir sahiplik haritasını atlamak için bir lisans değildir. Bir içerik modeli yapılandırılmış türleri ve alanları depolar — hepsi bu. Başlıkların, kanoniklerin, şemaların veya bağlantıların gerçekten yayınlandığını kanıtlamaz; bu yalnızca ön uç işini yaptığında gerçekleşir. Evidence for this claim A headless CMS content model defines structured types and fields, but the consuming frontend owns URL routing and the rendered HTML that titles, canonicals, schema, and links depend on. Scope: Contentful content-model docs plus Next.js metadata docs as representative frontend evidence. Confidence: high · Verified: 2026-07-18 Contentful: Data model Next.js: Metadata and OG images Sorumluluğu açıkça bölmek, en çok gördüğüm iki başarısızlık modundan kaçınır: kimse bir parçaya sahip değildir (sessizce asla oluşturulmaz) veya üç katman da ona sahip olduğunu düşünür (parçalanır, aşağıdaki kanoniklerin yaptığı gibi).

Ayrıca farklı olan: hangi API’yi çağırdığınız. Teslimat, yönetim ve önizleme API’leri farklı yayınlama ve yetkilendirme anlamlarına sahiptir. Üretim işleme yalnızca yayınlanmış içerik API’sini kullanmalıdır — asla yönetim veya önizleme token’ı/bitiş noktasını kullanmamalıdır; bu, yayınlanmamış içeriği veya yazma erişimini genel bir yanıta sızdırabilir. Evidence for this claim Delivery, management, and preview APIs have different publication and authorization semantics; production rendering must use the published-content API and must not expose management or preview tokens. Scope: Contentful API basics and Preview API docs as representative headless-API evidence. Confidence: high · Verified: 2026-07-18 Contentful: API basics Contentful: Content Preview API overview

Google bir JavaScript sayfasını nasıl işler

Google, JavaScript sayfalarını tarama, işleme ve dizine ekleme yoluyla işler. İstemci işlemeye bağlı sayfalar, ilk HTML yanıtında son içeriklerini açığa çıkarmazken, SSR ve SSG bu içeriği tarayıcı yürütmesinden önce yanıta koyar. Evidence for this claim Google crawls, renders, and indexes JavaScript pages, while server-side or pre-rendered HTML exposes content in the initial response. Scope: Google Search JavaScript processing; indexing is not guaranteed. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Ölçekte iki ilgili gerçek önemlidir. Google, engellenen dosyalardan JavaScript işleyemez, bu nedenle gerekli .js ve .css kaynaklarının taranabilir kalması gerekir. JS işlemek gerçekten pahalıdır — Ahrefs’te günde milyarlarca sayfa tarıyoruz ve JavaScript sayfalarını işlemek altyapımızın ciddi bir kısmını tüketiyor — bu, “Googlebot bunu işleyebilir” ifadesinin “Googlebot’un bunu işlemesini sağlamalısınız” ile aynı olmadığını hatırlatır.

Yapay zekâ tarayıcı gerçeği

Bu, 2026’nın çoğu headless SEO tavsiyesinin hâlâ gözden kaçırdığı kırışıklığıdır. Çoğu yapay zekâ tarayıcısı — ChatGPT, Perplexity ve benzerlerinin arkasındaki getiriciler — JavaScript’i çalıştırmaz. Bir Vercel çalışması bunu açıkça ortaya koydu: hiçbiri istemci tarafı içeriği işlemez, yani kritik sayfalarınız JavaScript’e bağımlı SPA’lar olarak sunuluyorsa, bu sayfalar AI araması için etkili bir şekilde görünmezdir. Google’ın kendi işleme ekibi, temel olarak tüm HTML sayfalarını işlediklerini söyledi, ancak bu Google’dır. AI görünürlüğü için SSR/SSG lüks değil; giriş ücretidir.

Dört işleme modu

SSG — Statik Site Üretimi. HTML derleme zamanında üretilir ve bir CDN’den statik dosyalar olarak sunulur. En iyi SEO senaryosu: ilk istekte tamamen işlenmiş HTML, çok hızlı TTFB. Ödünleşim tazeliktir — yeni veya değişen içerik yeniden derleme gerektirir ve büyük siteler yavaş derlemeler alır (ISR bunu kısmen çözer). Gatsby ve Astro SSG-önceliklidir; Next.js bunu rota başına destekler; Hugo klasiktir.

SSR — Sunucu Tarafı İşleme. HTML, bir sunucuda veya edge işlevinde istek başına işlenir. Mükemmel SEO: her zaman taze, ilk istekte tamamen işlenmiş HTML. Ödünleşim altyapı maliyeti ve statik dosyalardan biraz daha yüksek TTFB’dir. Next.js, Nuxt, SvelteKit ve Remix bunu yapar.

ISR — Artımlı Statik Yeniden Üretim. Statik sayfalar, yeniden doğrulama aralığından sonra arka planda yeniden üretilir. Çoğu zaman iyi SEO, tek gerçek tuzakla (sonraki bölüm). Öncelikle bir Next.js özelliği; Nuxt’un analogları vardır.

CSR — İstemci Tarafı İşleme. Minimal bir HTML kabuğu gönderilir, ardından tarayıcıdaki JavaScript içeriği getirir ve DOM’u oluşturur. Bu en kötü SEO seçeneğidir: Googlebot sayfayı işleme dalgası için sıraya almalıdır, zamanlama öngörülemez ve AI tarayıcıları ve diğer birçok bot yalnızca boş kabuğu görür. CSR, son derece etkileşimli panolar veya oturum açma gerektiren ve zaten dizine eklenmemesi gereken yalnızca kimliği doğrulanmış sayfalar için kabul edilebilir — bulunmasını istediğiniz içerik için değil. Next.js/Nuxt olmadan ham React veya Vue SPA’ları varsayılan olarak buraya düşer.

ISR bayat içerik tuzağı

Bu, kendi bölümünü hak edecek kadar yeni. ISR ile yeniden doğrulama penceresi sona erdiğinde:

1. Sonraki gelen istek arka planda yeniden üretimi tetikler.
2. Bu istek — Googlebot olabilir — yine de bayat önbelleğe alınmış sayfayı alır.
3. Taze sürüm yalnızca sonraki istekte sunulur.

Sık tarama yapılan sayfalar için bu, Googlebot’un rutin olarak içeriği bir yeniden doğrulama döngüsü gerisinde görebileceği anlamına gelir. Gerçekten değişken veriler için (fiyatlar, stok seviyeleri), SSR daha güvenli bir seçimdir. ISR, saatler veya günler mertebesinde değişen içerik için harika bir orta yol — saniyeler değil.

Dinamik işleme kullanımdan kaldırıldı

Yıllar önce — 2019 civarında verdiğim konuşmalar dahil — dinamik işleme (Puppeteer veya Rendertron gibi bir şeyle botlara önceden işlenmiş bir sürüm sunmak) makul bir geçici çözümdü. Google o zamandan beri bu tutumunu tersine çevirdi. Resmi olarak, “dynamic rendering was a workaround and not a long-term solution,” (Türkçe çeviri) “Dinamik oluşturma geçici bir çözümdü; uzun vadeli bir çözüm değildi.” ve “creates additional complexities and resource requirements.” (Türkçe çeviri) “Ek karmaşıklıklar ve kaynak gereksinimleri yaratır.” Google artık bunun yerine sunucu tarafı işleme, statik işleme veya hidrasyon öneriyor. Nüansı not edin: dinamik işleme otomatik olarak gizleme değildir — Google yalnızca var olduğu için cezalandırmaz ve yalnızca kullanıcılara vs. tarayıcılara tamamen farklı içerik sunarsanız gizlemeye geçer. Ancak “gizleme değil” ve “resmi olarak kullanımdan kaldırıldı” aynı anda doğrudur. Yeni bir derlemede ona uzanmayın.

Meta veriler — eklentinin yaptığını yeniden oluşturma

WordPress’te Yoast veya Rank Math her sayfa için otomatik olarak bir başlık ve açıklama üretti. Headless’ın eklenti katmanı yoktur, bu nedenle iş açıktır:

1. CMS içerik modeline SEO alanları ekleyin — başlık, açıklama, robots geçersiz kılma, canonical geçersiz kılma, Open Graph alanları.
2. Bu alanları API yanıtından her sayfa şablonunun <head> bölümüne eşleyin.
3. Framework’e özgü head yönetimini kullanın — Next.js generateMetadata (App Router) veya metadata dışa aktarımı; Nuxt useSeoMeta; Gatsby’nin <Seo> bileşeni / react-helmet; Astro’nun düzen dosyalarındaki <head> bölümü.

Yaygın hatalar: istemci tarafında enjekte edilen meta veriler hemen değil, geç (oluşturma sonrası) görülür; her sayfada asla güncellenmeyen tek bir paylaşılan düzen canonical’i (böylece her şey ana sayfaya canonicalize edilir); ve Next.js App Router’da, bozuk göreli canonical URL’ler üreten eksik bir metadataBase. Güvenilirlik kuralı basittir — HTML düzeyindeki meta veriler, JS ile enjekte edilen meta verilerden daha iyidir, çünkü Google bunu ilk getirmede görür. Helmet ve Head gibi modüller bunun için uygundur, ancak kritik etiketleri sunucu tarafında oluşturulan HTML’e ekleyin.

İçerik modelinin kendisinin yalnızca alanlara değil, kurallara da ihtiyacı vardır, yoksa yukarıdaki eşleme adımı sessizce bozulur:

• Alan başına zorunlu vs. isteğe bağlı. Başlık ve canonical geçersiz kılma zorunlu (veya otomatik türetilmiş) olmalıdır, böylece bir sayfa asla boş bir <title> ile yayınlanamaz. Açıklama ve OG alanları, ön uçta bir yedek ile isteğe bağlı kalabilir.
• Tanımlı bir yedek zinciri. Bir SEO alanı boşsa, ön ucun neyi ikame edeceğine önceden karar verin — açıklama için gövde alıntısı, başlık için H1 — ve bunu şablon başına gelişigüzel değil, eşleme katmanında uygulayın.
• Yerel ayar yedeği, alan yedeğinden ayrı bir kuraldır. İçerik API’si, bir çeviri eksik olduğunda varsayılan yerel ayar değerini ikame edebilir; bu gövde için yararlıdır, ancak bir SEO alanının sessizce başka bir yerel ayarın başlığına/açıklamasına geri dönmesi genellikle yanlıştır ve ayrıca işaretlenmeye değerdir.
• Eşleme adımında kaçış. CMS metin alanları genellikle HTML veya zengin metne izin verir; bunu bir <title>, <meta> veya JSON-LD dizesine yerleştirmeden önce temizleyin veya kaçışlayın, aksi takdirde bozuk işaretleme veya daha kötüsü, enjekte edilmiş komut dosyası gönderirsiniz.
• Rota türü başına kabul testi. Yayından önce, normal bir girdi, boş isteğe bağlı alana sahip bir girdi ve çevirisi olmayan bir yerel ayarda sorgulanan bir girdi için oluşturulan <head> bölümünün nasıl göründüğünü doğrulayın — tek bir mutlu yol testinin yakalayamayacağı üç farklı kod yolu.

Canonical parçalanması — headless’e özgü bir risk

WordPress’te canonical tek bir yerde yaşar. Headless’te üç katmana bölünmüştür: CMS bir slug saklar, framework tam URL’yi bu slug artı ortam ayarlarından birleştirir ve bir bileşen <link rel="canonical"> etiketini owuşturur. Herhangi bir katman saparsa — bir slug değişir, bir rota deseni değişir, bir bileşen yeniden düzenlenir — canonical artık var olmayan bir URL’yi işaret edebilir. Tarihsel olarak Google, JavaScript ile eklenen canonical’leri bile dikkate almıyordu; bu bazı durumlarda gevşetildi, ancak HTML düzeyindeki canonical’ler çok daha güvenilir olmaya devam ediyor ve birden fazla çakışan etiket, Google’ı seçim yapmaya zorlar.

Çözüm: canonical mantığını CMS’nin içinde değil, oluşturma katmanında (framework) sahiplenin ve mutlak URL’leri tek bir SITE_URL ortam değişkeninden oluşturun. Tek bir doğruluk kaynağı, her zaman mutlak URL’ler, asla göreli değil.

Yerel ayar sahipliği: API yedeği vs. ön uç yönlendirmesi

Çok yerel ayarlı headless siteler, canonical’lerle aynı sahiplik karışıklığının bir versiyonuna sahiptir. İçerik API’sinin yerel ayar seçimi ve yedeği, alan değerlerini ikame edebilir — bir yerel ayar isteyin, o yerel ayarın içeriğini veya yapılandırılmış bir yedeği alın — ancak bu bir veri ikame özelliğidir, bir SEO özelliği değildir. Evidence for this claim Content API locale selection and fallback can substitute field values, but the frontend still owns locale URLs, canonicals, hreflang, x-default, and language negotiation. Scope: Contentful localization docs plus Google rendering/canonical guidance. Confidence: high · Verified: 2026-07-18 Contentful: Localization Google: JavaScript SEO basics Ön uç yine de arama odaklı her parçanın sahibidir:

• Yerel URL’ler. Yerelin bir yolda (/es/page), bir alt alan adında veya ayrı bir alan adında olması, ön ucun verdiği bir yönlendirme kararıdır — API URL üretmez.
• Yerel başına canonical. Her yerel sürüm, varsayılan yereli işaret etmek yerine kendisini işaret eden kendi canonical’ını alır.
• hreflang ve x-default. Ön ucun bilinen yerel yollarından tüm alternatif dil bağlantıları kümesini oluşturun; eşleşmeyen diller için bir x-default dahil — API’nin hreflang kavramı yoktur.
• İçerik anlaşması ve durum davranışı. Belirli bir girdi için mevcut olmayan bir yerel istendiğinde ne olacağına bilinçli olarak karar verin: varsayılan yerele yönlendirin, o yerelin URL’sinde yedek içeriği sunun veya gerçek bir 404 döndürün — ve hangisi olduğu konusunda tutarlı kalın, çünkü Google “API’nin sessizce İngilizce metin ikame etmesi” ile “bu yerel varyantın mevcut olmaması” durumlarını farklı HTTP durum kodları gerektiren farklı durumlar olarak ele alır.

Pratik tuzak: API düzeyindeki yedekleme, eksik bir çevirinin CMS önizlemesinde iyi görünmesini sağlayabilir (her zaman içerik görürsünüz, asla boş bir alan görmezsiniz), bu da yerel boşlukların genellikle ilk olarak SEO sorunları olarak ortaya çıkması anlamına gelir — yanlış hreflang altında indekslenen yanlış dil başlıkları veya hiçbir editoryal uyarı tetiklemeyen yereller arasında yinelenen içerik.

Site haritaları ve robots.txt

Yoast yoksa otomatik site haritası da yoktur. Programatik olarak oluşturun: Next.js App Router, /sitemap.xml dosyasını bir sitemap.ts dosyasından üretir (CMS’yi derleme veya istek zamanında sorgular); Nuxt’un site haritası modülleri vardır; Gatsby’nin gatsby-plugin-sitemap’i vardır; Astro’nun @astrojs/sitemap’i vardır. Yüksek yayın hacimli sitelerdeki tuzak, bayatlayan derleme zamanı statik site haritalarıdır — içerik türüne göre bölümlenmiş ISR ile yeniden oluşturulan site haritaları kullanın.

Robots.txt de açık olmalıdır — /public içinde statik bir dosya veya oluşturulmuş bir yol (Next.js’te robots.ts). Yanlış yapamayacağınız tek kural: .js veya .css dosyalarını asla engellemeyin. Bunları engellemek oluşturmayı tamamen engeller.

Yayınlamayla senkronize tutma

Önbellek ve yeniden doğrulama, yalnızca bir performans sorunu değil, aynı zamanda bir editoryal doğruluk sorunudur — zaman, etiket veya yol tabanlı geçersiz kılma, bayat içeriği tasarım gereği sunabilir, bu nedenle bir yayınlama eyleminin bir kopyayı önbelleğe alan her katmana ulaşması gerekir, yalnızca CMS’ye değil. Evidence for this claim Time-, tag-, and path-based cache invalidation can serve stale content by design, so publish, unpublish, rename, and locale changes need webhook-triggered purge and rollback handling, not a fixed timer. Scope: Next.js current cache/revalidation model. Confidence: high · Verified: 2026-07-18 Next.js: Revalidating Yayına geçmeden önce, dört olayda — yayınlama, yayından kaldırma, yeniden adlandırma/slug değişikliği ve yerel güncelleme — bunların her birine ne olduğunu yazın ve test edin:

• API/CDN önbelleği bu girdi için.
• Framework sayfa önbelleği (ISR/isteğe bağlı yeniden doğrulama, etiket veya yol tabanlı).
• CDN uç önbelleği ön ucun önünde.
• Site haritası — girdi eklendi, kaldırıldı veya yeni bir URL altında yeniden listelendi.
• Meta veriler — eski canonical/URL tamamen kullanımdan kaldırıldı, yenisiyle birlikte çözümlenmeye bırakılmadı.
• Geri alma — bir yayın geri alınırsa, temizlemenin yalnızca ileri değil, ters yönde de çalıştığını doğrulayın.

Tetikleyici, CMS’nin yayınlama/yayından kaldırma olayından framework’ünüzün etiket veya yol tabanlı yeniden doğrulamasını (revalidateTag, revalidatePath veya eşdeğeri) çağıran bir web kancası olmalıdır, sabit bir zamanlayıcı değil — bir zamanlayıcı, bu dört olayın tamamının anında güncellemek yerine bir sonraki döngüyü beklemesi anlamına gelir.

İç bağlantılar ve yapılandırılmış veriler

İç bağlantılar gerçek <a href> etiketleri olmalıdır. JavaScript ile gezinme yapan bir <div onClick> veya <span> taranamaz — Googlebot yalnızca gerçek çapaları takip eder. Ve JS ile oluşturulan bağlantılar, oluşturma dalgasına kadar keşfedilmez, bu da gecikme ekler. API odaklı içerik kendi başına bağlantı yapıları üretmez, bu nedenle ilgili yazılar, içerik haritası ve içerik içi bağlantı yüzeylerinin tümü bileşen düzeyinde bağlanmalıdır.

Yapılandırılmış veri, headless’in WordPress’ten daha kolay olduğu nadir bir yerdir: JSON-LD, sıfır istemci paketi maliyetiyle doğrudan sunucu tarafından oluşturulan bir <head> içine girer, kodda sürüm kontrolü yapılır ve eklenti çakışmaları olmaz. İçerik siteleri için olağan türler — Article/BlogPosting, BreadcrumbList, FAQPage, Organization — hepsi geçerlidir. Herhangi bir işleme değişikliğinden sonra Zengin Sonuçlar Testi ile test edin, çünkü JS enjeksiyon zamanlaması testin gördüklerini etkileyebilir.

Önizleme ve hazırlık ortamları

Headless yığınlar, sıklıkla herkese açık olarak erişilebilen önizleme ve dal dağıtım URL’leri (Vercel/Netlify önizleme dağıtımları, CMS taslak uç noktaları) üretir. Google bunları dizine eklerse, sitenizin başka bir ana bilgisayarda tam bir kopyasını görür. Çözümler: ana bilgisayar düzeyinde (ortam yapılandırmasında — yalnızca bir CSR sayfasının geç enjekte edebileceği bir meta etiket değil) bir noindex HTTP başlığı uygulayın, önizlemeleri imzalı belirteçlerin arkasına alın, hazırlık ortamının kendisini asla kurallı hale getirmemesi için ortam duyarlı kurallı URL’ler ayarlayın ve kısa ömürlü önizleme ana bilgisayarları kullanın. Beklenmeyen alan adlarının görünüp görünmediğini görmek için Search Console’u izleyin — bu sizin erken uyarınızdır.

Savunma sırasını doğru kurun, çünkü önce noindex’e uzanıp orada durmak kolaydır. noindex yalnızca Google’ın sayfayı taramasına ve etiketi görmesine izin verilirse çalışır — dizine eklemeyle ilgili bir istektir, erişim kontrolü değildir, bu nedenle sayfanın kendisi herkese açık olarak erişilebilirse kararlı bir tarayıcıya veya sızdırılmış bir bağlantıya karşı hiçbir şey yapmaz. Evidence for this claim A noindex rule is not access control and requires Google to crawl the page to see it; private headless previews should be authenticated first, with noindex as a secondary indexing safeguard. Scope: Google noindex documentation plus Contentful/Sanity preview-token separation as representative platform evidence. Confidence: high · Verified: 2026-07-18 Google: Block Search indexing with noindex Sanity: Presenting and previewing content Gerçek sınır daha yukarı akışta olmalıdır:

1. Önce kimlik doğrulama. Önizleme ortamları, herhangi bir şey sunmadan önce imzalı bir belirteç veya oturum açma gerektirmelidir — noindex, erişilebilir kalması gereken nadir sayfa için ikincil bir güvence, birincil kontrol değildir.
2. Ortam başına ayrı belirteçler ve ana bilgisayarlar. Önizleme ve üretim asla aynı API belirtecini veya ana bilgisayar adını paylaşmamalıdır; önizlemenin belirteci, yayınlanmamış içeriği görmesine izin verilen belirteçtir ve asla bir üretim derlemesinde yer almamalıdır.
3. Doğru içerik perspektifini sorgulayın. Üretim kodu yalnızca yayınlanmış içeriği sorgular; yalnızca önizleme ortamı taslak/önizleme perspektifini sorgular. Bunu tersine çevirirseniz, üretim kimlik doğrulama ve noindex yerinde olsa bile yayınlanmamış girdileri sızdırabilir.

Bing ve IndexNow

Bingbot artık JavaScript’i Microsoft Edge (Chromium) kullanarak işliyor — Googlebot ile aynı web platformu teknolojisi — ancak bunu Google’dan daha az tutarlı bir şekilde yapıyor. Screaming Frog’un testleri, Bing’in JS dizine eklemesinin “uzaktan güvenilir” olmadığını buldu ve kesin sonuçları şuydu: “SEO’yu ve geceleri uyumayı önemsiyorsanız, istemci tarafı işlemeye güvenmeyin.” Bu nedenle, Bing trafiği önemliyse SSR/SSG daha da önemlidir.

Bing ayrıca bir push modeline çok yaslanır. Headless içerik güncellemeleri bir API üzerinden aktığından ve Bing’i bir WordPress eklentisinin yapacağı gibi uyarmadığından, IndexNow burada özellikle değerlidir — değişen URL’lerin anında bildirilmesi için CMS yayın web kancanıza bir IndexNow tetikleyicisi bağlayın. Fabrice Canel’in tarama ekonomisi çerçevesini akılda tutmakta fayda var: daha az, daha temiz URL daha iyidir, bu nedenle API odaklı fasetli gezinmenin binlerce kurallı hale getirilmemiş parametre URL’si oluşturmasına izin vermeyin.

Trafiği düşürmeden headless’e geçiş

Headless SEO’nun gerçekten bozulduğu yer geçişlerdir. Sektör analizlerine göre, WordPress’ten headless mimariye geçişlerde sıklıkla büyük trafik kayıpları ve uzun toparlanma süreleri görülür. Yaklaşık %50 düşüş ve yaklaşık 523 günlük toparlanma gibi rakamları kesin ölçüler olarak değil, kötü yürütülen bir geçişin ne kadar zarar verebileceğine dair yön gösteren uyarılar olarak değerlendirin. Temel nedenler öngörülebilirdir: bozuk 301’ler (özellikle herkesin eşlemeyi unuttuğu kategori, etiket ve sayfalandırılmış arşiv sayfalarında), eski CMS’den taşınmayan meta veriler ve sessizce CSR’ye dönen bir oluşturma modu. Yalnızca yazıları değil tüm URL’leri envantere alın, yayına geçmeden önce eksiksiz bir 301 eşlemesi hazırlayın, yeni ön uçtaki meta verileri ve canonical’ları doğrulayın, geçiş öncesi ve sonrasında Screaming Frog taramalarını karşılaştırın, sitemap’leri hem GSC’ye hem Bing Webmaster Tools’a yeniden gönderin ve IndexNow’u devreye alın. Tam liste için geçiş kontrol listesi sekmesine bakın.

İlgili okumalar JavaScript SEO ve işleme konularında yer alır — headless SEO aslında her ikisinin de özel bir uygulamasıdır.

AI özeti

Gelişmiş sürümün yoğunlaştırılmış bir değerlendirmesi:

• Mimari ürünün kendisidir. CMS arka ucu SEO açısından neredeyse nötrdür; her şeyi ön ucun oluşturma modu belirler. “Headless SEO için kötüdür” sözü bir efsanedir.
• Sahiplik haritası: CMS içerik modeli = ham yapılandırılmış alanlar. Teslimat API’si = üretimde yalnızca yayımlanmış içerik. Önizleme/yönetim API’si = kendi belirteci ve ana bilgisayarındaki taslak içerik. Ön uç/derleme = gerçekten oluşturulan <head>, canonical, sitemap, robots.txt, şema ve yerel ayar yönlendirmesi. Üretim hiçbir zaman önizleme/yönetim API’sini veya belirtecini çağırmamalıdır.
• Oluşturma modları: SSG ve SSR tamamen oluşturulmuş HTML gönderir ve güvenli seçeneklerdir. CSR en riskli seçenektir; içerik ancak sonraki bir oluşturma dalgasından sonra ortaya çıkar. ISR iyi bir orta yoldur, ancak bir tuzağı vardır.
• ISR tuzağı: yeniden doğrulama penceresinden sonraki ilk istek — bu Googlebot da olabilir — yine bayat sayfayı alır; güncel sürüm ancak bir sonraki istekte sunulur. Değişken veriler için SSR kullanın.
• Dinamik oluşturma kullanımdan kaldırıldı — Google artık SSR, statik oluşturma veya hidrasyon öneriyor. Bu yöntem otomatik olarak cloaking sayılmaz, ancak yeni yapılarda kullanmayın.
• AI tarayıcılarının oluşturma davranışı sağlayıcıya özgüdür — CSR sayfaları, ortak tek bir sözleşmenin kapsamadığı istemci yürütmesine bağımlıdır. SSR/SSG en geniş kapsamı sağlar.
• Eklentinin yaptıklarını yeniden kurun: içerik modelindeki SEO alanları → <head> içine eşleme → sitemap ve robots.txt dosyalarını açıkça üretme. .js/.css dosyalarını asla engellemeyin. HTML düzeyindeki meta veriler, JS ile enjekte edilenlerden daha güvenilirdir. Bir yedek zinciri tanımlayın ve zengin metin alanlarını <title> veya JSON-LD dizesine girmeden önce kaçışlayın.
• Canonical’lar parçalanabilir: CMS slug’ı → çerçeve URL’si → bileşen etiketi. Bunları, tek bir SITE_URL değerinden üretilen mutlak URL’lerle oluşturma katmanında ayarlayın.
• Yerel ayar sahipliği de aynı şekilde bölünür: API’nin yerel ayar yedeği içeriği ikame eder; ancak yerel ayar URL’leri, yerel ayar başına canonical’lar, hreflang, x-default ve çeviri eksikken ne olacağı ön ucun sorumluluğundadır.
• Bağlantılar gerçek <a href> olmalıdır — <div onClick> taranabilir değildir.
• Önizleme savunmasında sıra önemlidir: önce kimlik doğrulama yapın, önizleme ve üretim belirteçleri ile ana bilgisayarlarını ayırın, üretimde yalnızca yayımlanmış içeriği sorgulayın. noindex, erişim kontrolü değil ikincil bir güvencedir; çünkü Google’ın etiketi görebilmesi için sayfayı taraması gerekir.
• Yayınlama, yayından kaldırma, yeniden adlandırma ve yerel ayar değişiklikleri sabit bir zamanlayıcı yerine webhook tarafından tetiklenen bir temizlemeyi API önbelleğinde, çerçeve önbelleğinde, CDN’de, sitemap’te ve meta verilerde birlikte yürütmeli; ayrıca bir geri alma yolu bulunmalıdır.
• Bing, JS’yi Edge üzerinden oluşturur ancak bunu Google’dan daha az güvenilir yapar; CMS yayın webhook’unda IndexNow kullanın. Google yaklaşık 2 MB kaynak sınırı uygular.
• Geçişler bozuk kalıcı yönlendirmeler, kayıp meta veriler ve yanlışlıkla CSR’ye dönme nedeniyle başarısız olur; yayına geçmeden önce tam URL envanteri ve yönlendirme eşlemesi hazırlayın.

Resmi dokümantasyon

Arama motorlarından birincil kaynak dokümantasyonu.

Google

• JavaScript SEO’nun Temellerini Anlama — tarama → oluşturma → dizine ekleme hattı, JS ile canonical’lar, SPA’larda yanlış biçimde bulunamadı sayılan sayfalar ve History API rehberliği.
• Dinamik Oluşturma (kullanımdan kaldırılmış geçici çözüm) — Google’ın bunu neden kullanımdan kaldırdığı ve yerine ne kullanılması gerektiği (SSR, statik oluşturma, hidrasyon).
• Aramayla İlgili JavaScript Sorunlarını Düzeltme — oluşturulmuş DOM sorunlarını, durumsuz oluşturmayı ve aşırı önbelleğe almaya karşı fingerprinting’i teşhis etme.
• İçerik Odaklı Web Uygulamaları için Oluşturma — içerik sitelerinde SSR, SSG ve CSR arasındaki ödünleşimler.
• Web’de Oluşturma (web.dev — Addy Osmani ve Jason Miller) — SSR, CSR ve hidrasyonun temel tanımları ile tam yeniden hidrasyon yerine SSR veya statik oluşturmayı tercih etme önerisi.

Bing / Microsoft

• Yeni kalıcı Bingbot (Microsoft Edge) — Bingbot’un JavaScript’i Googlebot ile aynı web platformu teknolojisiyle işlemesi.
• IndexNow / indexnow.org — CMS yayın webhook’unuza bağlayacağınız push protokolü.

Kaynaktan alıntılar

Google ve Bing’den kayıtlara geçmiş açıklamalar. Her bağlantı, kaynak sayfadaki alıntılanan pasaja atlayan bir derin bağlantıdır.

Google — JavaScript sayfalarının nasıl işlendiği

• “All pages returning a 200 HTTP status code are queued for rendering, no matter whether JavaScript is present on the page.” (çeviri) “Sayfada JavaScript bulunup bulunmadığına bakılmaksızın, 200 HTTP durum kodu döndüren tüm sayfalar oluşturma kuyruğuna alınır.” — Google Arama Merkezi belgeleri. Alıntıya git
• “Google Search won’t render JavaScript from blocked files or on blocked pages.” (çeviri) “Google Arama, engellenmiş dosyalardaki veya engellenmiş sayfalardaki JavaScript’i oluşturmaz.” — Google Arama Merkezi belgeleri. Alıntıya git
• “Don’t use fragments to load different page content.” (Türkçe çeviri) “Farklı sayfa içeriklerini yüklemek için parçaları kullanmayın; bunun yerine History API’yi kullanın.” — Google Arama Merkezi belgeleri. Alıntıya git

Google — dinamik işleme 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.” (Türkçe çeviri) «Dinamik işleme, arama motorlarında JavaScript ile oluşturulan içerik sorunları için geçici bir çözümdü ve uzun vadeli bir çözüm değildi.» — Google Arama Merkezi belgeleri. Alıntıya git
• Bunun yerine önerilen: “server-side rendering, static rendering, or hydration.” (Türkçe çeviri) «sunucu tarafı işleme, statik işleme veya hidrasyon.» — Google Arama Merkezi belgeleri. Alıntıya git
• “…creates additional complexities and resource requirements.” (Türkçe çeviri) «…ek karmaşıklıklar ve kaynak gereksinimleri yaratır.» — Google Arama Merkezi belgeleri. Alıntıya git

Google — SSR / statik işlemeyi tercih edin (web.dev)

• “We encourage developers to consider server-side rendering or static rendering over a full rehydration approach.” (çeviri) «Geliştiricileri, tam yeniden hidrasyon yaklaşımı yerine sunucu tarafı işleme veya statik işlemeyi değerlendirmeye teşvik ediyoruz.» — Addy Osmani & Jason Miller, web.dev. Alıntıya git

İki kontrol listesi: headless SEO sağlığı + geçiş

Headless SEO sağlık kontrolü

• Sayfalar içeriklerini ilk istekte HTML olarak (SSR veya SSG) oluşturur, yalnızca istemci tarafı JavaScript çalıştıktan sonra değil.
• Hiçbir kritik sayfa ana içeriği için CSR’ye bağlı değildir (unutmayın: AI tarayıcıları JS çalıştırmaz).
• SEO alanları (başlık, açıklama, robots, canonical, OG) CMS içerik modelinde mevcuttur ve <head> içine eşlenir.
• Canonical’lar, oluşturma katmanında ayarlanan tek bir SITE_URL’den oluşturulan mutlak URL’lerdir — ve sayfa başınadır, paylaşılan bir ana sayfa canonical’ı değildir.
• robots.txt mevcuttur ve .js veya .css’i engellemez.
• Bir site haritası programatik olarak oluşturulur ve güncel kalır (yüksek hacimli sitelerde ISR ile yeniden oluşturulur / bölümlenir).
• İç bağlantılar gerçek <a href> etiketleridir — <div onClick> gezinme yok.
• Yapılandırılmış veri (JSON-LD) sunucu tarafı oluşturulan <head> içindedir ve Zengin Sonuçlar Testi’ni geçer.
• Önizleme/geçici ana bilgisayarlar ana bilgisayar düzeyinde noindex başlığı döndürür.
• IndexNow, CMS yayınlama olayında tetiklenir (Bing ve diğerleri için).

Geçiş kontrol listesi (geleneksel CMS → headless)

• Tam URL envanteri — yalnızca gönderiler değil: yazar sayfaları, etiket sayfaları, sayfalanmış arşivler, parametre URL’leri.
• Değişen her URL için 301 yönlendirme haritası, canlıya geçmeden önce oluşturulur.
• Meta veriler (başlık, açıklama) taşınır ve URL başına doğrulanır.
• Canonical etiketleri yeni ön uçta doğrulanır.
• Oluşturma modunun SSR/SSG olduğu doğrulanır (kazara CSR varsayılanı değil).
• Site haritaları Google Search Console ve Bing Webmaster Tools’a yeniden gönderilir.
• Tarama karşılaştırması (Screaming Frog) lansman öncesi ve sonrası çalıştırılır.
• Yeni alan adı/protokol için Search Console özelliği ayarlanır.
• IndexNow uygulanır.

Zihinsel modeller

1. Mimari üründür. CMS arka ucu neredeyse SEO açısından nötrdür. Ön ucun oluşturma modu üründür. Headless bir sitede herhangi bir şeyi hata ayıklamadan önce şu soruyu yanıtlayın: ön uç bu içeriği nasıl oluşturuyor? Neredeyse her headless SEO sorunu buna indirgenir.

2. Oluşturma modu karar kuralı. İçeriğin ne sıklıkla değiştiğine ve ne kadar etkileşimli olduğuna göre seçin:

• Çoğunlukla statik içerik (bloglar, belgeler, pazarlama) → SSG (yeniden oluşturma veya zamanlayıcıda ISR).
• Her zaman taze olması gereken sık değişen içerik (fiyatlar, stok) → SSR.
• Saatler/günler düzeyinde değişiklikler, statik hız istiyorsanız → ISR (ilk istekte bayat kalma tuzağına dikkat edin).
• Son derece etkileşimli, oturum açma arkasında, dizine eklenmesi amaçlanmayan → CSR kabul edilebilir.
• AI tarafından sıralanmasını veya alıntılanmasını istediğiniz herkese açık içerik → asla CSR.

3. “Eklentinin yaptığını yeniden oluşturun.” Yoast/Rank Math’ın her otomatik davranışı artık bilinçli bir derleme adımıdır: içerik modelindeki meta veri alanları → <head>’e eşlenir → site haritası → robots.txt → canonical’lar → yapılandırılmış veri. Bir şey “eksikse”, genellikle bir eklenti davranışının asla yeniden uygulanmadığı anlamına gelir.

4. URL’ler için tek doğruluk kaynağı. Canonical’lar, site haritası girdileri ve iç bağlantılar tek bir SITE_URL ve çerçevenin yönlendirmesinden türetilmelidir — üç farklı katmanda elle birleştirilmiş slug’lardan değil. Tek doğruluk kaynağı canonical parçalanmasını ortadan kaldırır.

5. Önce HTML, sonra JS. Tarama ve dizine ekleme için önemli olan her şey — içerik, meta veriler, canonical’lar, iç bağlantılar, yapılandırılmış veri — sunucu tarafı oluşturulan HTML’de bulunur. JS ile enjekte edilen SEO sinyallerini bir yedek olarak ele alın, plan olarak değil, çünkü bunlar Google tarafından geç görülür ve çoğu AI tarayıcısı tarafından hiç görülmez.

Headless SEO — kopya kağıdı

İşleme modlarına bir bakış

Çerçeveye göre meta veri yönetimi

Hızlı kurallar

• robots.txt içinde .js / .css dosyalarını asla engellemeyin.
• Canonical’lar: tek bir SITE_URL’den üretilen mutlak URL’ler, oluşturma katmanında ayarlanır.
• Next.js App Router’da metadataBase ayarlayın, aksi takdirde göreli kanonikler bozulur.
• İç bağlantılar = gerçek <a href>. <div onClick> tarayıcılar tarafından görünmez.
• Önizleme/staging: geç bir JS meta etiketi değil, host düzeyinde noindex başlığı.
• Google kaynak sınırı: ~2 MB, ötesinde kesilir.
• Dinamik işleme: kullanımdan kaldırıldı — SSR / statik işleme / hidrasyon kullanın.
• Çoğu AI tarayıcısı: JavaScript yok → CSR içeriği onlar için görünmez.
• Bing: JS’i (Edge) işler ancak daha az güvenilir; yayın olaylarını bağlamak için IndexNow kullanın.

Sunucu tarafından gönderilen yanıtı denetleyin

Temsili ön uç rotalarını urls.txt dosyasına dışa aktarın. Bu, kasıtlı olarak ham yanıtı bir tarayıcı yerine kullanır, böylece eksik sunucu tarafından işlenmiş meta veriler hidrasyonun arkasına saklanamaz:

while IFS= read -r url; do
  html=$(mktemp)
  status=$(curl -sS -o "$html" -w '%{http_code}' "$url")
  title_count=$(grep -Eio '<title>[^<]*</title>' "$html" | wc -l | tr -d ' ')
  canonical_count=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$html" | wc -l | tr -d ' ')
  jsonld_count=$(grep -Eio '<script[^>]+type=["'"']application/ld\+json["'"']' "$html" | wc -l | tr -d ' ')
  printf '%s\t%s\ttitles=%s\tcanonicals=%s\tjsonld=%s\n' "$status" "$url" "$title_count" "$canonical_count" "$jsonld_count"
  rm -f "$html"
done < urls.txt

Akış veya içeriği daha sonra yükleyen rotalar için ayrıca işlenmiş bir karşılaştırma çalıştırın. CMS önizleme belirteçlerini URL listesine asla koymayın.

Headless SEO’yu teşhis etmek için araçlar

• URL Inspection (Google Search Console) — tek bir URL’nin nasıl tarandığını ve işlendiğini görün. İşlenmiş HTML / ekran görüntüsü, içeriğinizin gerçekten dahil edilip edilmediğini söyler — CSR boşluklarını yakalamak için gereklidir.
• Rich Results Test — herhangi bir işleme değişikliğinden sonra işlenmiş çıktıda JSON-LD’nin mevcut olduğunu doğrulayın (JS enjeksiyon zamanlaması neyin algılandığını değiştirebilir).
• Screaming Frog SEO Spider — ham HTML ile işlenmiş HTML arasındaki farkı karşılaştırmak için JavaScript işlemeyi açık/kapalı olarak tarayın; geçişler için öncesi/sonrası tarama karşılaştırması oluşturun.
• Ahrefs Site Audit — tüm ön uçta yönlendirme zincirlerini, bozuk kanonikleri, eksik meta verileri ve dizinlenebilirlik sorunlarını ortaya çıkarır.
• Bing Webmaster Tools — Bing’in işleme/dizinleme görünümü ve IndexNow gönderimlerinin göründüğü yer.

Headless yapılarda sürekli gördüğüm hatalar

Pazarlama sitesini istemci tarafından işlenen bir SPA olarak yayınlamak. SSR/SSG katmanı olmayan ham bir React veya Vue ön ucu, en yaygın headless SEO hatasıdır. Neden yanlış: Googlebot, içeriğiniz onun için var olmadan önce sayfayı ikinci bir işleme dalgası için sıraya almak zorundadır; AI sağlayıcıları farklı veya eksik işleme sözleşmeleri yayınlar. HTML-only getiriciler boş kabuğu görür. Bunun yerine yapın: varsayılan olarak tamamen işlenmiş HTML sunan bir çerçeve seçin (Next.js, Nuxt, Astro, Gatsby) ve bulunmasını istediğiniz her sayfa için SSR veya SSG kullanın.

CMS’nin slug alanını kanonik URL olarak ele almak. Geliştiriciler genellikle <link rel="canonical"> öğesini doğrudan CMS’nin döndürdüğü şeyden oluşturur. Neden yanlış: kanonik daha sonra CMS slug, çerçeve yönlendirmesi ve bileşen mantığı arasında parçalanır — yeniden adlandırılmış bir slug veya yeniden düzenlenmiş bir rota onu sessizce bozar. Bunun yerine yapın: kanonikleri işleme katmanında tek bir SITE_URL ortam değişkeninden oluşturun, asla doğrudan CMS çıktısından değil.

Önizleme/staging dağıtımlarının herkese açık şekilde taranabilir kalması. Vercel/Netlify önizleme URL’leri ve CMS taslak uç noktaları varsayılan olarak erişilebilirdir. Neden yanlış: Google bunlardan birini bulursa, sitenizin tam bir kopyasını başka bir sunucuda dizine ekleyebilir — ve JavaScript tarafından geç enjekte edilen bir noindex meta etiketi genellikle bunu durdurmak için yeterli olmaz. Bunun yerine yapın: noindex’i ana bilgisayar düzeyinde bir HTTP başlığı olarak uygulayın ve önizlemeleri imzalı belirteçlerin arkasına alın.

ISR kurmak ve her zaman taze olduğunu varsaymak. Ekipler ISR’yi “yeterince iyi” tazelik için seçer ve bunu düşünmeyi bırakır. Neden yanlış: yeniden doğrulama penceresinden sonra yeniden oluşturmayı tetikleyen istek — muhtemelen Googlebot — hâlâ eski önbelleğe alınmış sayfayı alır; yalnızca sonraki istek güncellemeyi görür. Bunun yerine yapın: ISR’yi saatler veya günler düzeyinde değişen içerik için kullanın ve gerçekten değişken verileri (fiyatlar, stok seviyeleri) bunun yerine SSR’a geçirin.

Navigasyonu ve ilgili içerik bağlantılarını tıklanabilir <div>ler olarak oluşturmak. Bileşen kitaplıkları, herhangi bir öğeye bir onClick navigasyon işleyicisi bağlamayı kolaylaştırır. Neden yanlış: arama motorları yalnızca gerçek <a href> çapalarını takip eder — bir <div onClick> ziyaretçiye nasıl görünürse görünsün tarayıcılar için görünmezdir. Bunun yerine yapın: API’den çekilen ilgili yazılar ve breadcrumb bağlantıları dahil her iç bağlantıyı gerçek bir çapa tetikleyicisi olarak işleyin.

“Tarama bütçesi kazanmak için” robots.txt’de .js veya .css dosyalarını engellemek. Bu, eski bir robots.txt’yi miras alan headless yapılarda beklediğinizden daha sık görülür. Neden yanlış: Google, JavaScript’i veya CSS’si engellenmiş bir sayfayı işleyemez, bu yüzden bu tarama bütçesi kazandırmaz — işlemeyi tamamen bozar. Bunun yerine yapın: .js ve .css dosyalarını taranabilir bırakın; bunları engellemek için meşru bir neden yoktur.

Belirti → neden → çözüm

URL İnceleme sayfanın sorunsuz getirildiğini gösteriyor, ancak işlenmiş HTML’de içerik eksik

Neden: sayfa istemci tarafında işleniyor ve içerik yalnızca JavaScript tarayıcıda çalıştıktan sonra var oluyor — Google’ın URL İnceleme aracı size işleme sonrası DOM’u gösterir ve ana içeriğiniz hâlâ orada eksikse, işleme dalgası onu üretmiyordur (veya henüz çalışmamıştır). Çözüm: işleme modunu Patrick’in Render Gap aracı ile doğrulayın; bu araç bir URL için ham HTML’i işlenmiş HTML ile karşılaştırır. Fark gerçekse, istemci tarafı getirmelerine güvenmek yerine bu rotayı SSR veya SSG’ye taşıyın.

Search Console’da Google’ın bildirdiği canonical, kodunuzdakiyle aynı değil

Neden: canonical parçalanması — CMS slug’ı, çerçevenin URL birleştirmesi ve etiketi işleyen bileşen senkronizasyondan çıkmıştır veya paylaşılan bir düzen her sayfada aynı canonical’ı yayıyor. Çözüm: canlı etiketi Patrick’in Canonical Checker ile kontrol edin, sonra canonical oluşturmayı işleme katmanına taşıyın ve üç ayrı parça yerine tek bir SITE_URL değişkeninden oluşturun.

Headless geçişten hemen sonra trafik keskin bir şekilde düştü

Neden: neredeyse her zaman bozuk 301’ler — özellikle kimsenin eşlemeyi hatırlamadığı kategori, etiket ve sayfalandırılmış arşiv sayfalarında — veya eski CMS’den taşınmayan meta verilerdir. Çözüm: her eski URL’yi Patrick’in Redirect Checker aracından geçirerek zincire ya da 404’e değil, tek bir 301 ile doğru hedefe ulaştığını doğrulayın; ardından başlık ve açıklamaların URL bazında taşındığını kontrol edin.

Önizleme veya staging URL’leri Search Console’da veya site: aramasında görünüyor

Neden: önizleme/staging ana bilgisayarı ana bilgisayar düzeyinde dizine eklenmekten hiç engellenmemiş — istemci tarafında enjekte edilen bir meta etiket noindex, Google’ın görmesi için çok geç ulaşabilir. Çözüm: noindex HTTP başlığını ortam ayarının kendisine uygulayın (yalnızca sayfa işaretlemesine değil) ve önizleme ana bilgisayarını imzalı bir belirtecin arkasına alın, böylece hiçbir şekilde herkese açık şekilde taranamaz.

Zengin Sonuçlar Testi, kaynak kodunuzda açıkça bulunan yapılandırılmış veriyi algılamıyor

Neden: JSON-LD, ilk HTML yanıtından sonra istemci tarafında enjekte ediliyor ve zamanlama, testin — veya Googlebot’un ilk geçişinin — gerçekte gördüğüyle uyuşmuyor. Çözüm: JSON-LD’yi sunucu tarafında oluşturulan <head> bölümüne taşıyın ve ardından Patrick’in Schema Validator veya Rich Result Eligibility Checker aracıyla ham yanıtı kontrol edin — yalnızca tarayıcıda oluşturulan DOM’u değil.

Sitemap hâlâ aylar önce sildiğiniz veya yeniden adlandırdığınız URL’leri listeliyor

Neden: yalnızca tüm site yeniden oluşturulduğunda yenilenen, derleme zamanı statik bir sitemap — yüksek yayın hacimli bir sitede bu günlerce veya haftalarca güncel olmayabilir. Çözüm: içeriğinizle aynı sıklıkta yenilenen bir sitemap’e geçin (ISR ile yenilenen veya içerik türüne göre bölümlenmiş) ve Patrick’in Sitemap Validator aracıyla mevcut çıktıyı doğrulayın.

Bu sayfa hangi oluşturma modunu kullanmalı?

Oluşturma modu seçimi, headless bir sayfanın SEO’su hakkında neredeyse her şeyi belirleyen tek karardır. Bunu tüm site için bir kez değil, rota bazında ele alın — bir pazarlama sitesi ve kimliği doğrulanmış kontrol paneli rotaları farklı yerlerde olabilir (ve olmalıdır).

Headless geçişinden sonra trafik düştü — sonraki adımlar

Bu, en sık gördüğüm senaryo ve öngörülebilir bir dizi kök nedeni var. Listeyi sırayla çalışın — her adım ya sorunu çözer ya da onu eler ve sizi bir sonrakine yönlendirir.

1. Önce Search Console’daki tarama istatistiklerini ve kapsam raporunu alın. Yayından hemen sonra 404’lerde sıçrama veya dizine eklenen sayfalarda düşüş görürseniz 2. adıma geçin. Dizine ekleme kararlı görünmesine rağmen sıralamalar ya da trafik düştüyse 5. adıma atlayın.
2. Bozuk yönlendirmeleri kontrol edin. Yalnızca yazıları değil; yazar sayfalarını, etiket sayfalarını ve sayfalandırılmış arşivleri de içeren tam geçiş öncesi URL listenizi Patrick’in Redirect Checker aracından geçirin. Herhangi biri 404’e, bir yönlendirme zincirine veya yanlış hedefe ulaşıyorsa başka bir şey yapmadan önce 301 eşlemesini oluşturun ya da düzeltin.
3. Yönlendirmeler temizse meta veri geçişini kontrol edin. Geçiş öncesinde en çok trafik alan URL’lerinizdeki başlık ve açıklamaları, şu anda yayında olanlarla örneklem üzerinden karşılaştırın. Eski CMS’den taşınmayan meta veriler, geçiş sonrası düşüşlerin en yaygın ikinci nedenidir.
4. Meta veriler doğruysa oluşturma modunu kontrol edin. Yeni ön ucun sessizce CSR’ye dönmediğini doğrulayın. Ham HTML ile oluşturulmuş HTML’yi karşılaştırmak için bir sayfa örneklemini Patrick’in Render Gap aracında çalıştırın. SSR/SSG’yi CSR’ye düşüren bir çerçeve yanlış yapılandırması, kimse fark etmeden yayına çıkabilecek türden bir hatadır.
5. Yukarıdaki kontroller temizse canonical’ların parçalanmadığını doğrulayın. Canonical Checker ile örnek kontrol yapın. Paylaşılan bir düzen canonical’ı veya geçiş sırasında değişen bir slug, sıralamaları sessizce yanlış URL’de birleştirebilir.
6. Sitemap’leri hem Google Search Console’a hem Bing Webmaster Tools’a yeniden gönderin ve IndexNow’un CMS yayın webhook’una bağlandığını doğrulayın. Böylece yeni ve değişen URL’ler yeniden taranmayı beklemek yerine hemen bildirilir.
7. 2–6. adımları tamamlamanıza rağmen trafik hâlâ toparlanmadıysa, bunu peşine düşülecek bir hata değil, daha uzun süren bir toparlanma olarak değerlendirin. Tüm teknik sorunları düzelten headless geçişlerin bile tamamen toparlanması zaman alabilir; çünkü Google’ın yeni site yapısını yeniden taraması ve değerlendirmesi gerekir.

Headless SEO görevleri için istemler

Bunlar, köşeli parantez içindeki girdi değiştirilerek kullandığınız herhangi bir yapay zekâ asistanına yapıştırılmak üzere tasarlanmıştır. Bu makalenin kapsadığı belirli görevlere yöneliktirler — genel “SEO’mu denetle” istemleri değil.

1. Bir sayfa bileşeninde yalnızca CSR içeriğini tespit edin

Sayfa/şablon bileşeninizi (ör. bir Next.js page.tsx veya bir Nuxt .vue dosyası) yapıştırın ve sorun:

Here is a page component from my headless CMS frontend. Identify any content
that is fetched or rendered only on the client (inside useEffect, onMounted,
or similar client-only hooks) rather than during server rendering or build.
For each one, tell me whether it would be present in the initial HTML
response or only appear after JavaScript runs in the browser.

[paste component code]

Karşılığında, sunucu tarafında işlenen ve yalnızca istemci tarafında olan belirli içerik bloklarının bir listesini bekleyin; bu, AI tarayıcılarına veya Google’ın ilk geçiş isteğine neyin görünmeyeceğini tam olarak söyler.

2. Parçalanma riski için bir canonical-URL uygulamasını inceleyin

Canonical etiketinizi oluşturan kodu (CMS alanı, URL derleme mantığı ve <link rel="canonical"> öğesini işleyen bileşen) yapıştırın ve sorun:

This is how my headless site builds its canonical URL across three layers:
the CMS content model, the framework's URL assembly, and the rendering
component. Identify any point where these could drift out of sync (a slug
change, a route change, a hardcoded fallback) and suggest how to consolidate
this into a single source of truth built from one SITE_URL variable.

[paste canonical-related code from CMS field, framework logic, and component]

Karşılığında, genel canonical tavsiyeleri değil, gerçek kodunuza bağlı belirli sapma risklerini bekleyin.

3. Bir CMS içerik modeline eklenecek SEO alanlarını taslak haline getirin

İçerik türlerinizi açıklayın ve sorun:

I'm setting up SEO fields in a headless CMS content model for [content type,
e.g. "blog post" / "product page"]. List the fields I should add (title,
description, robots override, canonical override, Open Graph fields, etc.),
a sensible field type for each, and which ones should have sensible
auto-generated defaults vs. requiring manual entry.

[describe your content type and any existing fields]

Karşılığında, genel bir kontrol listesi yerine tanımladığınız içerik türüne göre uyarlanmış, CMS’yi yapılandıran kişiye verebileceğiniz her alanı kapsayan bir liste bekleyin.

4. Bir geçiş taraması için ham ve işlenmiş HTML’i karşılaştırın

İki tarama dışa aktarımını yapıştırın (ham HTML taraması ve JS işlemeli tarama, örn. Screaming Frog’u her iki şekilde de çalıştırarak) ve sorun:

Here are two crawl exports of the same URL set from my headless site — one
crawled with JavaScript rendering off (raw HTML) and one with it on
(rendered HTML). Compare them and flag any URLs where the title, meta
description, canonical, or main content differs meaningfully between the two,
since that gap indicates content is only appearing after client-side
rendering.

[paste or summarize the two exports]

Karşılığında, ham ve işlenmiş HTML’in farklılaştığı URL’lerin bir listesini bekleyin — bunlar, önce düzeltmeye değer CSR’ye bağımlı sayfalarınızdır.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• JavaScript SEO Sorunları ve En İyi Uygulamalar — tüm bunların işleme tarafındaki birincil referansım; headless ile doğrudan ilgili. İşleme modlarını, meta veri modüllerini (Meta etiketler, Helmet, Head), JS canonicals, sitemaps ve robots.txt Allow: .js / Allow: .css kuralını kapsar.
• Teknik SEO Başlangıç Rehberi — işleme ve taramanın daha büyük resme nerede uyduğu.

Konuşmalarım

• JavaScript SEO — Ungagged 2019 (SlideShare) — headless/ayrık CMS’lerin ön ucu arka uçtan nasıl ayırdığına ve Googlebot’un durum bilgisi olmayan işleme davranışına dair anlatımım. (Kalıcı feragatname: Bu sunumdaki dinamik işleme önerisi artık güncel değil — Google bunu kullanımdan kaldırdı.)

Başkalarından

• Web’de İşleme (web.dev) — Addy Osmani ve Jason Miller’ın işleme modları hakkındaki kesin makalesi.
• Bing JavaScript işleme çalışması (Screaming Frog) — Bing’in JS’i gerçekte ne kadar tutarlı dizine eklediğine dair gerçeklik kontrolü.
• İstemci Tarafı ve Sunucu Tarafı İşleme (Search Engine Journal) — Martin Splitt’ten Google’ın tüm HTML’i neden işlediği hakkında.
• 2026’da JavaScript’siz Geri Dönüşler: Daha Az Kritik, Hâlâ Gerekli (Search Engine Land, James Allen) — AI tarayıcılarının JS çalıştırmamasını ve 2MB Google kaynak sınırını kapsar; büyük AI tarayıcılarının hiçbirinin istemci tarafı içeriği işlemediğine dair Vercel’in bulgusunu kaynak gösterir.
• Sıralamaları Etkileyen Mimari Kararlar (Focus Reactive) — belirli headless mimari seçimlerinin SEO sonuçlarına nasıl yansıdığına dair daha titiz bağımsız makalelerden biri.
• Headless CMS Başlangıç Rehberi (Oncrawl, Dan Taylor) — ayrık mimari ve tarama etkileri hakkında teknik SEO öncelikli bir anlatım.
• Headless Ticaret için SEO Temelleri (Women in Tech SEO, Safia Marmon) — headless e-ticaret SEO için pratik uygulama rehberi; meta verileri, canonicals ve sitemap desenlerini kapsar.
• Next.js Meta Verileri ve OG Görselleri (Next.js dokümanları) — Gelişmiş sekmesinde kapsanan generateMetadata, metadataBase ve App Router baş yönetimi desenleri için resmi referans.
• r/TechSEO — işleme/dizinleme hata ayıklama topluluğu.

Değişiklik günlüğü