Blog details
Sayfa tarayıcıda kusursuz görünebilir, ama arama motoru bazen yalnızca boş bir kabuk görür. Headless CMS tarafındaki teknik SEO sorunu çoğu zaman platformdan değil, dağınık süreçlerden çıkar.
İçerik başka yerde, render mantığı başka yerde, sitemap ise ayrı bir iş akışında yönetilince küçük hatalar büyür. Oysa doğru kurulan bir yapı, klasik CMS’lere göre daha hızlı, daha kontrollü ve daha esnek çalışır.
Asıl farkı, her sayfa tipinin nasıl üretileceğini ve hangi SEO sinyalinin nerede yönetileceğini baştan tanımlamak yaratır.
Headless mimaride SEO neden süreç işi?
Klasik CMS’lerde başlık, canonical, şablon ve içerik çoğu zaman aynı sistemde yaşar. Headless yapıda ise içerik deposu, frontend framework’ü, CDN, build süreci ve bazen edge katmanı ayrı çalışır. Bu yüzden tek bir sayfanın SEO çıktısı, birkaç farklı parçanın doğru konuşmasına bağlıdır.
Sorun tam da burada başlar. Editör slug değiştirir, ama eski URL için 301 kuralı oluşmaz. Yeni içerik yayına çıkar, fakat sitemap bir sonraki deploy’a kadar güncellenmez. Sayfa ekranda açılır, ancak ilk HTML içinde başlık ya da ana gövde metni yoktur. Arama motoru için kritik olan sinyaller, kullanıcıya görünen sayfayla aynı anda ulaşmaz.
Contentful, Strapi, Sanity ve Storyblok gibi sistemler içerik modelleme, alan doğrulama ve webhook tarafında iyi imkanlar sunar. Yine de bu araçların hiçbiri tek başına render stratejisini, canonical mantığını ya da crawl kontrolünü çözmez. Bunlar ekip kararıdır.
Bu yüzden ilk iş, sayfa tipi bazlı bir sahiplik matrisi kurmaktır. Her route için şu sorular net olmalı: Bu sayfa index alacak mı, hangi render yaklaşımı kullanılacak, canonical nasıl üretilecek, hangi schema tipi çıkacak, sitemap’e ne zaman girecek, slug değişirse ne olacak?
MACH mimarisi ve headless SEO eğilimlerine dair güncel değerlendirmeler de aynı noktaya dikkat çekiyor. Teknoloji seçimi kadar, süreç tasarımı da sonucu belirliyor.
Headless CMS teknik SEO sürecinde sağlam temel, tek bir eklenti değil, route bazlı kurallar kümesidir. Bu kurallar yazılı değilse, ekipler aynı sayfayı farklı varsayımlarla üretir. Sonuç da kopya URL’ler, noindex sızıntıları, yetim sayfalar ve tutarsız metadata olur.
SEO değeri taşıyan her route, kullanıcıya gelen ilk HTML içinde ana sinyalleri taşımalıdır.
Sayfa tipine göre doğru render yaklaşımını seçin
2026 itibarıyla en güvenli yaklaşım hibrit modeldir. Organik trafik hedefleyen sayfalarda SSR, SSG veya gerektiğinde ISR kullanılır. Saf CSR ise uygulama ekranları için uygundur, SEO odaklı sayfalar için değil.
Bunun nedeni basit. Google JavaScript işleyebiliyor, ama gecikmeli render, eksik head etiketleri ve ağır istemci paketi hâlâ sorun çıkarıyor. İlk HTML ne kadar doluysa, crawl ve index tarafı o kadar temiz ilerliyor.
Aşağıdaki tablo pratik bir başlangıç verir:
| Sayfa tipi | Önerilen yaklaşım | Kısa gerekçe |
|---|---|---|
| Blog yazıları | SSG veya ISR | Hızlı açılır, cache dostudur |
| Landing page’ler | SSG | En iyi LCP ve öngörülebilir metadata |
| Kategori ve listeleme sayfaları | SSR veya ISR | Sıklıkla güncellenir, filtre mantığı ister |
| Ürün detay sayfaları | SSR veya ISR | Fiyat, stok, schema ve tazelik önemlidir |
| Yardım merkezi, dokümantasyon | SSG | Derin tarama için temiz HTML üretir |
| Yerel veya çok dilli SEO sayfaları | SSG veya SSR | hreflang ve canonical daha kontrollü çıkar |
| Dashboard, hesap alanı, uygulama ekranları | CSR, çoğu durumda noindex | Organik index için hedef değildir |
SSR, içerik sık değişiyorsa iyi seçimdir. Fiyat, stok, teslimat, canlı veri ya da sık güncellenen kategori blokları varsa SSR mantıklıdır. SSG ise daha sabit sayfalarda en iyi hız ve cache dengesini verir.
ISR aradaki boşluğu kapatır, ama tek şartla. Revalidation mantığı güvenilir olmalıdır. İçerik güncellendiğinde sayfa dakikalarca eski kalıyorsa, teori güzel olsa da pratikte index gecikmesi yaşarsınız.
Next.js, Nuxt, Astro ya da benzeri modern framework’lerde metadata’yı istemci tarafında sonradan eklemek risklidir. Başlık, description, canonical, hreflang ve ana içerik mümkünse sunucu tarafında üretilmelidir. Özellikle landing page, kategori ve makale şablonlarında bunu standart kabul edin.
Saf CSR kullanan ekipler çoğu zaman “sayfa zaten açılıyor” diye düşünür. Oysa kaynak HTML ile rendered DOM aynı şeyi göstermeyebilir. Bu farkı yakalamak için render hatalarını bulmak için JavaScript SEO rehberi iyi bir referans noktasıdır.
Filtreli URL’lerde de render tercihi kadar URL politikası önemlidir. Her filtre kombinasyonunu index’e açmak crawl bütçesini bozar. Çoğu projede ana kategori sayfası index alır, ince filtre kombinasyonları canonical ile ana kümeye döner ya da noindex kalır.
Preview ve staging ortamlarını da bu karar ağacının dışında bırakmayın. Önizleme sayfaları arama sonuçlarına düşüyorsa, sorun CMS’de değil süreçtedir.
CMS katmanında hangi teknik SEO öğeleri yer almalı?
Headless yapılarda CMS, yalnızca metin girilen yer olmamalı. Aynı zamanda SEO için gerekli verinin üretildiği güvenilir kaynak olmalı. Ancak burada sınır önemli, CMS veriyi toplar; final HTML çıktısını her zaman kendi başına yönetmez.
İyi bir modelde her sayfa tipinin zorunlu alanları bellidir. Slug, sayfa başlığı, SEO title, meta description, index durumu, locale bilgisi, sosyal paylaşım görseli ve varsa canonical override alanı standart olmalıdır. Editörün bunları rastgele alan adlarıyla değil, tutarlı bir şema içinde görmesi gerekir.
Ayrıca ilişki alanları da önemlidir. Breadcrumb zinciri, ilgili içerikler, ebeveyn sayfa, yerel dil karşılığı ve kategori ilişkileri CMS’te tanımlanırsa, frontend bu veriyi sağlam iç link yapısına çevirebilir. Böylece yeni içerikler yetim kalmaz.
Schema verisinin ham girdileri de mümkün olduğunca CMS’te yaşamalıdır. Makale için yazar, yayın tarihi ve güncellenme tarihi; ürün için fiyat, stok ve SKU; FAQ için soru ve cevap çiftleri; organizasyon için sabit kurum bilgileri CMS’te tutulmalıdır. JSON-LD üretimi ise frontend tarafında yapılmalıdır. Bu ayrım temizdir ve hata oranını düşürür.
Slug değişimlerinde yönlendirme geçmişi de CMS modelinin parçası olmalıdır. Editör URL’yi değiştirdiğinde eski slug kaybolmamalı. İdeal akışta sistem bu değişikliği webhook ile redirect servisine iletir ve eski adres otomatik 301 verir.
Strapi’nin implementasyon rehberi gibi kaynaklarda da benzer bir yaklaşım öne çıkıyor. İçerik modeli ne kadar disiplinliyse, frontend tarafında o kadar az özel durum birikir.
Bir başka önemli nokta da doğrulama kurallarıdır. Aynı slug’ın tekrar oluşmasını engelleyin. Zorunlu locale eşleşmelerini kontrol edin. Eksik meta alanlarında uyarı üretin. Başlık uzunluğu için katı karakter limitleri koymak yerine, editöre görünür uyarılar verin. Çünkü iyi SEO, yalnızca form doldurmakla değil, doğru bağlamı üretmekle oluşur.
Frontend ve build pipeline hangi işi üstlenmeli?
CMS veriyi toplar, ama teknik SEO’nun son milini frontend ve build pipeline taşır. Sayfayı indexlenebilir HTML olarak üretmek, doğru status code vermek ve arama motoruna tutarlı sinyaller sunmak bu katmanın işidir.
Aşağıdaki sahiplik ayrımı ekip içi karmaşayı azaltır:
| Öğe | CMS tarafı | Frontend / build pipeline |
|---|---|---|
| Title ve meta description | Ham değerler ve varsayımlar | Route bazlı son HTML çıktısı |
| Canonical | Gerekirse manuel override | Mutlak URL üretimi ve kural mantığı |
| hreflang | Dil eşleşme verisi | Karşılıklı etiketlerin çıktısı |
| Structured data | Ham alanlar | JSON-LD üretimi ve doğrulama |
| Sitemap | Dahil etme durumu, lastmod verisi | Dinamik üretim ve hızlı güncelleme |
| Redirects | Slug geçmişi, manuel kural girişi | 301 sunumu, zincir kontrolü |
| Robots kuralları | Sayfa bazlı index tercihleri | meta robots, X-Robots-Tag, ortam ayrımı |
| İç link ve breadcrumb | İçerik ilişkileri | HTML link çıktısı ve crawl derinliği |
| Görseller | Alt text, odak noktası | Responsive teslimat, format ve önceliklendirme |
Burada en sık yapılan hata, sitemap’i yalnızca build anında üretmektir. Eğer site günde birkaç kez içerik alıyorsa, deploy bekleyen sitemap index gecikmesi yaratır. Daha iyi yöntem, publish webhook ile sitemap’i yenilemek ya da sitemap’i istek anında üretmektir.
Canonical mantığı da basit görünür ama çok hata üretir. Sayfa adresini olduğu gibi yazmak yetmez. Parametreli URL’ler, filtre kombinasyonları, takip etiketleri ve slash politikası route resolver içinde normalize edilmelidir. Canonical her zaman mutlak olmalı ve 200 dönen, indexlenebilir hedefe işaret etmelidir.
hreflang tarafında da aynı disiplin geçerlidir. Yalnızca etiket basmak yetmez. Karşılıklı eşleşme, doğru dil-bölge kodu ve tutarlı canonical gerekir. Bir sayfa “tr-TR” veriyorsa, eşleniği de onu geri göstermelidir.
Yapısal veri için kural nettir. Sayfada görünmeyen bir bilgiyi JSON-LD ile göndermeyin. Ayrıca schema tipini şablona göre otomatik seçin. Makale şablonu Article, ürün şablonu Product, kurumsal sayfalar uygun durumlarda Organization veya BreadcrumbList üretebilir.
Performans tarafı da bu katmanın sorumluluğundadır. 2026’da Core Web Vitals konuşurken odak noktası hâlâ LCP, INP ve CLS. Bunun için gereksiz hydration azaltılmalı, büyük client bundle’lar bölünmeli, LCP görseli önceliklendirilmeli, font yükleme kontrol altında tutulmalıdır. 2026 için SEO odaklı CMS beklentileri incelendiğinde de ortak payda aynı, hızlı ve tutarlı çıktı.
404 ve 410 kararları da unutulmamalı. Silinen içeriği sessizce ana sayfaya atmak kötü pratiktir. İçerik kalıcı olarak kaldırıldıysa uygun durum kodu verin. Eğer karşılığı olan yeni bir URL varsa 301 kullanın.
QA ve yayın akışında atlanmaması gereken kontroller
Headless CMS teknik SEO süreci, QA kapısı zayıfsa bozulur. Çünkü hata çoğu zaman tek noktada değil, entegrasyon çizgisinde oluşur. Bu yüzden yayın öncesi kontrol, yalnızca içerik onayı değildir.
Aşağıdaki akış, ekipler için işe yarayan temel çerçevedir:
- Yeni şablon ya da route açıldığında önce kaynak HTML kontrol edilir. Title, H1, ana metin, canonical, robots etiketi ve schema ilk yanıt içinde görünmelidir.
- Sayfa yayına çıkmadan status code doğrulanır. 200, 301, 404 ve 410 kuralları nettir; geçici 302’ler ya da zincir yönlendirmeler bırakılmaz.
- Indexability testi yapılır. Canonical ile noindex birbirini bozmamalı, robots.txt ilgili route’u yanlışlıkla engellememeli, staging ve preview adresleri kapalı kalmalıdır.
- Sitemap ve iç link kontrolü tamamlanır. Yeni URL sitemap’e kısa sürede girmeli, en az bir iç bağlantıyla bulunabilir olmalı ve yetim sayfa oluşmamalıdır.
- Yapısal veri ve dil etiketleri doğrulanır. JSON-LD görünür içerikle aynı olmalı, hreflang eşleşmeleri karşılıklı çalışmalı ve locale bazlı canonical tutarlı kalmalıdır.
- Performans testi şablon düzeyinde yapılır. Tek bir sayfa değil, o şablona ait örnek sayfalar ölçülür; ağır üçüncü taraf script’ler ve geç yüklenen temel içerik tespit edilir.
Bu akışı elle yürütmek mümkündür, ama bir noktadan sonra yavaşlar. Daha iyi yöntem, QA kapılarını otomatik hale getirmektir. Örneğin PR aşamasında rendered HTML snapshot testi, schema doğrulaması, kırık link taraması ve status code kontrolü çalışabilir. Yayın sonrası da GSC URL inceleme, log takibi ve sitemap diff raporu rutin hale gelir.
Kural basittir, kullanıcıya görünenle botun gördüğü şey farklıysa yayın tamamlanmış sayılmaz.
Ekipler birlikte nasıl çalışmalı ve neyi otomatikleştirmeli?
En sağlıklı modelde her sayfa tipinin tek bir sahibi vardır, ama karar tek kişiye bırakılmaz. SEO ekibi kuralı tanımlar, geliştirici şablonu kurar, içerik ekibi gerekli alanları doldurur. Platform ya da DevOps tarafı da cache, redirect ve deploy tetiklerini yönetir.
Bu iş birliği için kısa ama net bir belge gerekir. Sayfa tipi, render modu, index kuralı, canonical mantığı, schema tipi, sitemap davranışı ve redirect politikası aynı tabloda yer almalıdır. Wiki’de duran uzun metinler yerine yaşayan bir sahiplik dökümü daha iyi çalışır.
Otomasyon tarafında en çok fayda veren işler bellidir. Slug değişince 301 üretmek, sitemap’i yenilemek, schema testini çalıştırmak, eksik meta alanlarını işaretlemek ve yetim sayfaları raporlamak ilk sıradadır. Daha ileri ekipler, rendered HTML ile CMS verisini karşılaştırıp tutarsızlıkları da işaretler.
Burada yapay zeka da işe yarar. Özellikle büyük içerik depolarında başlık tekrarlarını, zayıf description’ları, eksik iç linkleri ve anormal şablon farklarını saptamak için teknik SEO süreçlerinde yapay zeka kullanımı pratik fayda sağlar. Ancak son karar yine kural bazlı sistemlerde olmalıdır.
Headless yapı karmaşık olmak zorunda değil. Sorumlulukları net böldüğünüzde, yayın hızı artar ve teknik borç azalır.
Sonuç
Headless mimaride iyi SEO, tek bir ayarla çıkmaz. Render seçimi, veri sahipliği ve yayın öncesi kontrol aynı hatta birleştiğinde sonuç verir.
İşe en değerli 5 ila 10 sayfa tipiyle başlayın. Her biri için render kararını, CMS alanlarını, frontend kurallarını ve zorunlu QA testlerini yazın.
Arama motorunun gördüğü HTML ile kullanıcının gördüğü sayfa aynıysa, headless yapı risk olmaktan çıkar ve güçlü bir avantaja dönüşür.
This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.