15 Tem 2025·8 dk
Programatik Sayfalarla Teknik Bir Blog Sitesi Nasıl Kurulur
Programatik sayfalarla teknik bir blog oluşturma: içerik modeli, yönlendirme, SEO, şablonlar, araçlar ve sürdürülebilir iş akışı adım adım rehber.
Programatik sayfalarla teknik bir blog oluşturma: içerik modeli, yönlendirme, SEO, şablonlar, araçlar ve sürdürülebilir iş akışı adım adım rehber.
Programatik sayfalara sahip bir teknik blog, tek tek yazılmış gönderilerin bir akışından daha fazlasıdır. İçeriğinizin tutarlı bir içerik modelinden otomatik olarak düzenlenip yeniden yayınlandığı ve yardımcı indeks sayfaları oluşturduğu bir sitedir.
Programatik sayfalar, tek tek yazılmak yerine yapılandırılmış verilerden oluşturulan sayfalardır. Yaygın örnekler şunlardır:
/tags/react/) ilgili gönderileri listeler ve ana alt konuları ortaya çıkarır./authors/sam-lee/) biyografi, sosyal bağlantılar ve o yazarın tüm makalelerini gösterir./series/building-an-api/) küratörlü öğrenme yolları sunar./guides/, “Buradan başlayın” merkezleri veya niyet bazlı konulara göre içerik toplayan dizinler.İyi yapıldığında programatik sayfalar tutarlılık ve ölçek sağlar:
“Programatik” otomatik, değersiz içerik demek değildir. Bu sayfaların hâlâ bir işi olmalı: net bir giriş, mantıklı sıralama ve okuyucunun bir sonraki ne okuyacağına karar vermesine yardımcı olacak yeterli bağlam. Aksi halde güven kazanmayan (veya aramada görünürlüğü düşük) zayıf listelere dönüşürler.
Bu rehberin sonunda pratik bir planınız olacak: programatik rotalara sahip bir site yapısı, onları besleyen bir içerik modeli, yeniden kullanılabilir şablonlar ve içerik ağırlıklı bir teknik blogu yayınlamak ve sürdürmek için bir editoryal iş akışı.
Bir içerik modeli tasarlamadan veya binlerce sayfa üretmeden önce blogun ne için olduğunu ve kimin için olduğunu belirleyin. Programatik sayfalar seçtiğiniz stratejiyi—iyi ya da kötü—büyütür; bu yüzden bu adımda özel olun.
Çoğu teknik blog birden fazla gruba hizmet eder. Bu sorun değil, ancak şunu unutmayın: farklı arama yaparlar ve farklı açıklama seviyelerine ihtiyaç duyarlar:
Yararlı bir egzersiz: her grup için 5–10 temsilci sorgu seçin ve “iyi” bir cevabın ne görünmesi gerektiğini (uzunluk, örnekler, önkoşullar, kod snippet’i gerekip gerekmediği) yazın.
Programatik sayfalar her sayfanın net bir işi olduğu durumlarda en iyi çalışır. Yaygın yapı taşları:
Sürdürebileceğiniz bir frekans seçin, sonra her içerik türü için minimum inceleme adımlarını tanımlayın: hızlı bir editoryal geçiş, eğiticiler için kod incelemesi ve güvenlik/uyumluluk/performance iddiaları için uzman (SME) incelemesi.
Blogu ölçülebilir sonuçlara bağlayın, mucizeler vaat etmeyin:
Bu seçimler, daha sonra hangi sayfaları oluşturacağınızı ve güncellemeleri nasıl önceliklendireceğinizi doğrudan şekillendirir.
Programatik bir blog, okuyucuların (ve tarayıcıların) her şeyin nerede olduğunu tahmin edebildiği zaman başarılı olur. Şablonları oluşturmadan önce üst düzey gezinmeyi ve URL kurallarını beraber çizin—bunu sonradan değiştirmek yönlendirmelere, çoğaltılan sayfalara ve kafa karıştırıcı dahili bağlantılara yol açar.
Birincil yapıyı basit ve dayanıklı tutun:
Bu yapı, net isimlendirilmiş bölümlerin altında programatik sayfalar eklemeyi kolaylaştırır (örn. bir konu hub’ı tüm gönderileri, ilişkili serileri ve SSS’leri listeler).
Okunabilir bir dizi desen seçin ve onlara sadık kalın:
/blog/{slug}/topics/{topic}/series/{series}Birkaç pratik kural:
internal-linking, InternalLinking değil) kullanın.Her sınıflandırmanın ne anlama geldiğini belirleyin:
seo, SEO ve search-engine-optimization gibi near-duplicate’ler ortaya çıkarUzun vadeli tutarlılık istiyorsanız konulara öncelik verin ve etiketleri seyrek kullanın (veya hiç kullanmayın).
Örtüşmeler olur: bir gönderi hem bir konuya ait olabilir hem de bir etikete uyan olabilir; bir seri bir konu hub’ına benzeyebilir. “Gerçek kaynak”ı belirleyin:
noindex veya ilgili konu sayfasına canonical uygulamayı düşünün.Bu kararları erken belgeleyin ki her oluşturulan sayfa aynı canonical modelini izlesin.
Programatik bir blog, içerik modeline bağlı olarak ya başarılı olur ya başarısız. Verileriniz tutarlıysa konu hub’ları, seri sayfaları, yazar arşivleri, “ilişkili gönderiler” ve araç sayfalarını otomatik olarak oluşturabilirsiniz—her rotayı elle küratörlemeden.
Okuyucuların gezinme biçimine uyan küçük bir model seti tanımlayın:
Post için şablonların tahmin etmemesi adına zorunlu alanları belirleyin:
title, description, slugpublishDate, updatedDatereadingTime (saklanmış veya hesaplanmış)codeLanguage (tek veya liste, filtreler ve snippet’ler için)Programatik sayfaları açan alanlar ekleyin:
topics[] ve tools[] ilişkileri (çoktan-çoğa)seriesId ve seriesOrder (veya seriesPosition) için doğru sırarelatedPosts[] (isteğe bağlı manuel geçersiz kılma) ve autoRelatedRules (etiket/araç örtüşmesine dayalı)Programatik sayfalar stabil isimlendirmeye bağlıdır. Net kurallar koyun:
slug olsun (eşanlamlılardan kaçının).Somut bir spesifikasyon isterseniz bunu repo wiki’sine veya dahili bir sayfaya (/content-model) yazın ki herkes aynı şekilde yayınlasın.
Yığın tercihiniz iki şeyi belirler: sayfaların nasıl render edildiği (hız, hosting, karmaşıklık) ve içeriğin nerede saklandığı (yazar deneyimi, önizleme, yönetim).
Statik Site Üreteçleri (SSG) — Next.js (statik çıkış) veya Astro gibi — HTML’i önceden üretir. Çok kullanılan ve kalıcı içerik için genellikle en basit, en hızlı yaklaşımdır: barındırması ucuzdur ve önbelleklemesi kolaydır.
Sunucu tarafı render sayfaları istekte üretir. İçerik sürekli değişiyorsa, kullanıcıya özel içerik gerekiyorsa veya uzun build zamanlarına katlanamıyorsanız faydalıdır. Maliyet ve çalışma zamanı karmaşıklığı artar.
Hibrit (statik + sunucu karışımı) genellikle en iyi dengeyi sunar: gönderiler ve çoğu programatik sayfayı statik tutup birkaç dinamik rota (arama, dashboard, gated içerik) için sunucu render kullanın. Next.js ve benzeri çerçeveler bu modeli destekler.
Markdown/MDX + Git geliştirici odaklı takımlar için mükemmeldir: temiz versiyonlama, kod incelemesi kolaylığı ve yerel düzenleme. Önizleme genellikle “siteyi yerelde çalıştır” veya önizleme deploy’ları ile sağlanır.
Headless CMS (Contentful, Sanity, Strapi vb.) yazar deneyimini, izinleri ve editorial iş akışlarını (taslaklar, zamanlı yayın) geliştirir. Maliyet abonelik ve daha karmaşık önizleme kurulumu getirir.
Veritabanı tabanlı içerik tamamen dinamik sistemler veya ürün verilerinden oluşturulan içerikler için uygundur. Mühendislik maliyeti artar ve genellikle bir blog için gereksizdir.
Emin değilseniz önce SSG + Git ile başlayın; içerik modelinizi ve şablonlarınızı temiz tutarak (bkz. /blog/content-model) daha sonra CMS ekleyebilecek esnekliği bırakın.
Eğer tam bir boru hattı kurmak istemiyorsanız, taslaklarınızı hızla denemek için Koder.ai gibi bir ortamda prototip yapmayı düşünün. Bilgi mimarinizi ve şablonlarınızı sohbet yoluyla çizebilir, bir React ön yüzü ve gerektiğinde Go + PostgreSQL arka uç oluşturabilir ve model (postlar, konular, yazarlar, seriler) stabil kaldığında kaynak kodu dışa aktarabilirsiniz.
Programatik sayfalar basit bir fikre dayanır: bir şablon + çok kayıt. Her sayfayı tek tek yazmak yerine başlık, giriş, kartlar, kenar çubuğu, metadata gibi bir düzen tanımlarsınız; sonra gönderiler, konular, yazarlar veya seriler gibi kayıt listelerini beslersiniz ve site her kayıt için bir sayfa üretir.
Çoğu teknik blog, otomatik çoğalan küçük bir sayfa “ailesi” ile sonuçlanır:
Bu deseni etiketlere, araçlara, “rehber”lere veya API referanslarına kadar genişletebilirsiniz—arkasında yapılandırılmış veri olduğu sürece.
Build sırasında (veya hibrit bir düzende talep üzerine) site iki iş yapar:
slug) eşleyerek rotalar oluşturur ve o kaydın verisiyle şablonu render eder.Birçok yığın bunu “build hook” veya “içerik koleksiyonu” adımı olarak adlandırır: içerik değiştiğinde üretici eşlemeyi yeniden çalıştırır ve etkilenen sayfaları yeniden render eder.
Programatik listelerin rastgele hissettirmemesi için net varsayılanlar gerekir:
/topics/python/page/2 gibi kararlı URL’lerBu kurallar sayfaların gezinmesini, önbelleğe alınmasını ve arama motorlarının anlamasını kolaylaştırır.
Programatik sayfalar, yüzlerce (veya binlerce) URL’ye hizmet edebilecek küçük bir şablon setiyle en iyi çalışır. Amaç okuyucular için tutarlılık, ekip için hızdır.
Esnek ama öngörülebilir bir post şablonu ile başlayın. İyi bir temel şunları içerir: net bir başlık alanı, uzun gönderiler için opsiyonel bir içindekiler ve hem metin hem kod için okunaklı tipografi.
Şablonunuzun desteklediğinden emin olun:
Çoğu programatik değer indeks benzeri sayfalardan gelir. Şablonlar oluşturun:
/topics/static-site-generator)/authors/jordan-lee)/series/building-a-blog)Her liste kısa açıklama, sıralama seçenekleri ve tutarlı snippet’ler (başlık, tarih, okunma süresi, etiketler) göstermeli.
Bileşenler sayfaları elle düzenlemeden faydalı kılar:
UI bileşenlerinize erişilebilirlik ekleyin: yeterli kontrast, klavye navigasyonu için görünür odak durumları ve mobilde okunabilir kod blokları. TOC tıklanabilir ise fare olmadan erişilebilir olduğundan emin olun.
Programatik sayfalar çok iyi sıralanabilir—eğer her URL’in net bir amacı ve yeterli benzersiz değeri varsa. Amaç, Google’ın her oluşturulan sayfanın faydalı olduğuna ikna olmasını sağlamaktır, sadece veri olduğu için çok sayıda near-duplicate sayfa üretmemek.
Her sayfa türüne öngörülebilir bir SEO anlaşması verin:
tag + author + year) yalnızca talep kanıtı varsa indexleyin.Basit bir kural: ana sayfadan gururla bağlamayacağınız bir sayfayı muhtemelen indexlememelisiniz.
Yapısal veriyi yalnızca içeriğe uyduğunda ekleyin:
Bunları tüm programatik rotalarda paylaşılan şablonlara dahil etmek en kolay yoldur.
Programatik siteler birbirini güçlendirdiğinde kazanır:
/blog/topics).Oluşturulan indeksler için asgari içerik kuralları belirleyin:
noindex yapın.Sayfalar üretmeye başladığınızda (etiket hub’ları, kategori listeleri, yazar sayfaları, karşılaştırma tabloları), arama motorlarına neyin önemli olduğunu ve neyin olmadığını açıkça göstermelisiniz. İyi crawl hijyeni botları gerçekten önemli sayfalara odaklar.
Hem editoryal gönderiler hem de programatik sayfalar için sitemap’ler oluşturun. Çok sayıda URL’niz varsa tip bazında ayırın ki yönetilebilir ve hata ayıklaması kolay olsun:
Gerçek içerik güncellemelerine dayanan lastmod tarihleri ekleyin ve engellemeyi planladığınız URL’leri listelemeyin.
Tarayıcıların zamanını boşa harcamasını önlemek için robots.txt kullanın:
Engelleyin:
/search?q=)?sort=, ?page=) eğer bu sayfalar benzersiz değer katmıyorsaBu sayfalar kullanıcılar için gerekli ise erişimi açık bırakın ama noindex eklemeyi ve dahili bağlantıları canonical versiyona yönlendirmeyi düşünün.
Ana blog için /feed.xml gibi bir RSS veya Atom feed yayınlayın. Konular kilit navigasyon öğeleri ise konu bazlı feed’ler de düşünün. Feed’ler e-posta özetleri, Slack botları ve okuyucu uygulamaları için içerik yayınlamanın basit bir yoludur.
URL stratejinize uygun breadcrumb’lar ekleyin (Ana sayfa → Konu → Gönderi). Site genelinde gezinme etiketlerini tutarlı tutun ki tarayıcılar ve kullanıcılar hiyerarşinizi anlasın. Ek SEO faydası için breadcrumb şema işaretlemesini UI ile birlikte ekleyin.
Programatik sayfalarla bir teknik blog 50’ten 50.000 URL’ye hızla büyüyebilir—bu yüzden performans bir ürün gereksinimi olmalı, sonradan yapılacak bir iş değil. İyi haber: çoğu kazanım birkaç net bütçe ve bir build hattı kuralıyla gelir.
Her sürümde ölçebileceğiniz hedeflerle başlayın:
Bütçeler tartışmaları kontrole çevirir: “Bu değişiklik 60 KB JS ekliyor—karşılığını veriyor mu?”
Sözdizimi vurgulama sık yapılan bir performans tuzağıdır. Tercih edin:
Tema karmaşıklığını azaltmayı da düşünün: daha az token stili genellikle daha küçük CSS demektir.
Görselleri içerik sisteminizin bir parçası olarak ele alın:
Bir CDN sayfalarınızı okuyucuya yakın cache’leyerek çoğu isteği hızlı karşılar. Mantıklı cache başlıkları ve purge kuralları ile güncellemelerin hızlı yayılmasını sağlayın.
Sık yayın yapıyorsanız veya çok sayıda programatik sayfanız varsa artımlı build önem kazanır: sadece değişen sayfaları (ve onlara bağlı olanları) yeniden oluşturun, tüm siteyi her seferinde render etmeyin. Bu deploy sürelerini kısaltır ve “build çok uzun sürdüğü için site eskidi” sorununu önler.
Programatik sayfalar sitenizi ölçeklendirir; kaliteyi ölçeklendiren şey iş akışınızdır. Hafif, tekrarlanabilir bir süreç “neredeyse doğru” içeriğin canlıya kaçmasını engeller.
Küçük bir durum seti tanımlayın ve ona sadık kalın: Draft, In Review, Ready, Scheduled, Published. Tek kişilik ekip olsanız bile bu yapı işe odaklanmayı ve toplu çalışmayı kolaylaştırır.
Özellikle şablon veya içerik modeli değişikliklerinde, her değişiklik için önizleme build’leri kullanın ki editörler formatı, dahili bağlantıları ve üretilen listeleri canlıya almadan doğrulayabilsin. Platform destekliyorsa yayın zamanlama özelliği ekleyin ki gönderiler önceden incelenip planlanabilsin.
Şablonlarda hızlı iterasyon yapıyorsanız Koder.ai gibi platformların sunduğu snapshot ve rollback özellikleri “bir şablon değişikliği 2.000 sayfayı bozdu” korkusunu azaltır; çünkü değişikliği önizleyip geri alabilirsiniz.
Kod blokları okuyucuların güvenini kazandırır veya kaybettirir. Ev kuralları koyun:
Örnekleri bir repo içinde tutuyorsanız, ona göre görece bir yol verin (örn. /blog/example-repo) ve örneklerin bozulmaması için commit/etiket ile sabitleyin.
Görünür bir “Son güncelleme” alanı ekleyin ve bunu içerik modelinde yapılandırılmış veri olarak saklayın. Evergreen gönderiler için kısa bir değişiklik günlüğü tutun (“Node 22 için adımlar güncellendi”, “Kaldırılan API yenisiyle değiştirildi”) ki geri gelen okuyucular neyin değiştiğini görsün.
Yayınlamadan önce hızlı bir kontrol listesi çalıştırın: kırık linkler, başlıkların sıralaması, metadata (başlık/açıklama), kod bloklarının formatı ve oluşturulan sayfa alanlarının doldurulmuş olması (etiketler, ürün adları vb.). Bu birkaç dakika sürer ama sonrasında gelecek destek maillerini azaltır.
Programatik bir blog lansmanda “bitmiş” olmaz. Ana risk sessiz sürtünme: şablonlar değişir, veri değişir ve farkında olmadan dönüşüm sağlamayan, sıralama kaybeden veya olmaması gereken sayfalar ortaya çıkar.
Duyurmadan önce üretimde hızlı bir tarama yapın: ana şablonlar doğru render ediyor mu, canonical URL’ler tutarlı mı ve her programatik sayfanın net bir amacı var mı (cevap, karşılaştırma, sözlük, entegrasyon vb.). Ardından sitemap’inizi Search Console’a gönderin ve analiz etiketlerinin tetiklendiğini doğrulayın.
İçerik kararlarını yönlendiren sinyallere odaklanın:
Mümkünse şablon türü bazında segmentleyin (örn. /glossary/ vs /comparisons/) ki bir sayfa sınıfını topluca iyileştirebilesiniz.
Site içi arama ve filtreler ekleyin ama filtre kaynaklı URL’lerle dikkatli olun. Sıralanmaya değmeyen filtrelenmiş görünüm varsa, insan kullanımına açık tutup tarayıcı israfını önlemek için noindex uygulayın (örn. parametre ağır kombinasyonlar).
Programatik siteler evrilir. Planlayın:
Okuyucuların çıkmaz sokaklara girmemesi için belirgin gezinme yolları oluşturun: küratörlü bir /blog hub’ı, “buradan başlayın” koleksiyonu ve—varsa—yüksek niyetli sayfalarla bağlı ticari yollar (/pricing).
Uygulamayı hızlandırmak istiyorsanız önce programatik rotaların ve şablonların ilk versiyonunu oluşturun, sonra içerik modelini sahada geliştirin. Koder.ai gibi araçlar ilk prototipi hızla oluşturup, daha sonra Go + PostgreSQL gibi bir arka uç eklemeye veya düz dosyalardan çıkmaya uygun bir yol sunabilir.
Programatik sayfalar, yapılandırılmış veriler ve şablonlardan üretilen sayfalardır; teker teker yazılmazlar. Teknik bir blogda yaygın örnekler konu merkezleri (ör. /topics/{topic}), yazar arşivleri (ör. /authors/{author}) ve seri açılış sayfaları (ör. /series/{series})dır.
Bunlar size tutarlılık ve ölçek kazandırır:
Tekrar eden konular, araçlar veya seriler üzerinde çok fazla içerik yayımlıyorsanız programatik sayfalar özellikle değerlidir.
Niyet bazlı segmentlerle başlayın ve içeriği insanların nasıl aradıklarına göre eşleyin:
Her segment için birkaç örnek sorgu yazıp “iyi bir cevap”ın ne içermesi gerektiğini (örnekler, gereksinimler, kod snippet'i) tanımlayın.
Bir dizi kararlı, okunabilir deseni seçin ve URL’leri kalıcıymış gibi ele alın:
/blog/{slug}/topics/{topic}/series/{series}Küçük harf, kısa çizgi (-) kullanın; tarihler yalnızca haber ağırlıklı içerik için uygundur; küçük başlık değişiklikleri için slug değiştirmeyin.
Kontrollü birincil taksonominiz olarak konular/kategoriler kullanın (sınırlı sayıda ve kasıtlı). Etiketler yalnızca kuralları uygulayabilecekseniz ekleyin; aksi halde seo vs SEO gibi çoğaltmalar oluşur.
Pratik yaklaşım: “önce konular, etiketler ihtiyatlı” ve yeni konu oluşturma üzerinde net sahiplik.
En azından şu varlıkları modelleyin ki şablonlar güvenilir şekilde sayfa üretebilsin:
İlişkiler ekleyin: topics[], , gibi alanlar hub’ları ve “seride sonraki” yönlendirmesini otomatikleştirir.
Çoğu blog için en iyi yol hibrit yaklaşımdır:
Depolama için: geliştirici liderliğindeki ekipler Markdown/MDX + Git tercih eder; editorial onay, taslak ve zamanlama gerekiyorsa headless CMS daha uygundur.
Listelerin rastgele görünmemesi için kararlı varsayımlar tanımlayın:
URL’leri öngörülebilir tutun (örn. /topics/python/page/2) ve hangi filtrelenmiş görünümlerin indexlenebilir olduğuna erken karar verin.
Her üretilen sayfaya benzersiz bir değer verin ve nelerin indexleneceğini kontrol edin:
noindex uygulayınBir kural: Ana hub’dan sayfaya gururla bağlanmazsanız, muhtemelen indexlenmemeli.
Sağlıklı bir programatik blog için bakım rutinleri ve tarama kontrolleri uygulayın:
lastmod kullanınrobots.txt ile engelleyin (iç arama, filtre/sıralama kombinasyonları)Ayrıca şablon türüne göre performansı izleyin (gönderi vs konu hub vs karşılaştırma) ki iyileştirmeler tüm sayfa ailesine yansısın.
tools[]seriesOrder