Programmatic SEO ile Yüzlerce Sayfa Nasıl Üretilir: Pratik Mimari Rehberi

Programmatic SEO, dijital pazarlamanın en yanlış anlaşılan tekniklerinden biridir. Bir tarafta "sadece SQL ile içerik üretip Google'ı kandırın" sloganları, diğer tarafta "thin content cezası kaçınılmaz" uyarıları. İkisi de eksik. Doğru uygulandığında programmatic SEO, kurumsal sitelerin uzun kuyruk arama sorgularını rakipsiz konumda karşılamasını sağlar; yanlış uygulandığında sayfalar 6 ay içinde indeksten düşer.

Bizim programmatic SEO platform mühendisliği hizmetimizin son 24 ayda yürüttüğü 8 projeden çıkardığı pratik şu: başarı = mimari + veri kalitesi + iç linkleme + sabır. Tek başına hiçbiri yetmez. Bu yazıda kendi sitemizin 32 şehir × dil matrisini vaka olarak alıp yedi pratiği sırayla anlatıyoruz — TÜBİTAK Teknokent'teki dergilerden, BDDK regülasyonundan veya AB Komisyonu yönergesinden farklı bir kaynak: kendi üretim hattımız.

1. Stratejik soru — neyi otomatikleştiriyoruz, neyi değil

Programmatic SEO için doğru fırsat tanımı, iki boyutlu matriste karşılığı olan içerik türüdür. "Yüzlerce ayrı blog yazısı üretelim" düşüncesi yanlış başlangıç — blog yazıları içerik kalitesi açısından farklılaşır, programmatik üretime uygun değildir. Doğru aday içerikler:

• Şehir × hizmet (Şanlıurfa yazılım, İstanbul yazılım, Ankara yazılım…): bizim sitemizdeki yapı.
• Ürün × özellik (e-ticaret + kargo, e-ticaret + ödeme, e-ticaret + KVKK…).
• Kategori × envanter (otel + İstanbul, otel + Antalya…).
• Karşılaştırma (X vs Y formatında).
• Yön / mesafe (A → B güzergahı).

Yanlış adaylar: özel danışmanlık (her müşteri farklı), kurumsal değer önerisi (markaya bağlı), yüksek karar maliyetli ürünler (alıcı sayfayı okumadan satın almaz).

Pratik test sorusu: "Sayfanın %70'i veriden geliyor mu?" Cevap evetse uygun. Sayfanın %70'i yorumdan/anlayıştan geliyorsa, blog daha uygun. Bizim şehir sayfalarımızda %60-70 oranında yapısal veri (sektör profili, ulaşım, posta kodu, müşteri profili, yerel referanslar) + %30-40 oranında editöryal içerik (hizmet konumlanması, ekibimizin yaklaşımı) var. Bu oran sürdürülebilir.

İkinci pratik test: rakiplerin hangi sorgularda size kapalı kalan uzun kuyrukta sıralandığı. "Şanlıurfa yazılım firması" gibi kısa kuyruk için 10-15 rakip yarışır; "Karaköprü Teknokent yazılım danışmanlık" gibi uzun kuyruk için neredeyse yok. Programmatic SEO'nun değer yarattığı yer tam burası — kısa kuyrukta milyon dolarlık SEO bütçesiyle rekabet etmek yerine, bin tane uzun kuyruğu otomatik karşılamak. Her uzun kuyruk az trafik getirir (10-50/ay) ama bin tanesi birleşince ana sayfa trafiğini geçer; üstelik dönüşüm oranı 3-5 kat daha yüksektir çünkü arayan kişi tam ne istediğini biliyor.

2. Veri katmanı — yapısal kaynağın kalitesi her şeyi belirler

Programmatic SEO'nun en sık atlanan adımı, yapısal veri kaynağının özen ile kurulmasıdır. Aceleyle çıkartılmış bir CSV, üretilen 200 sayfanın hepsinde aynı problemi 200 kez tekrarlar.

Bizim 32 şehir matrisinde kullandığımız veri yapısı (src/utils/cities.ts):

{
  slug: "sanliurfa",
  name: "Şanlıurfa",
  wikidata: "Q83657",
  dative: "Şanlıurfa'ya",        // Türkçe yönelme hâli (a/e/ya/ye)
  locative: "Şanlıurfa'da",      // -da/-de/-ta/-te
  sectors: ["tekstil","gıda","tarım teknolojileri","turizm"],
  landmarks: ["GAP", "Harran","Karaköprü Teknokent"],
  travelFromHQ: "merkez ofisimiz (Karaköprü)",
  population: 2200000,
  industries: { primary: "tarım+sanayi karması", ... },
  ...
}

Bu yapı 16 alan içerir — her şehir için ayrı ayrı doldurulmuş gerçek veri. population Wikipedia'dan, wikidata ID ile bağlanmış (schema.org Place için), landmarks yerel referans listesi, sectors Türkiye İstatistik Kurumu il raporlarından çıkarılmış.

Yapay olmayan dilbilgisi: Türkçe ek almak için sadece şehir adını değil vokal uyumu'nu da doğru bilmek gerekir. "Ankara'a" değil "Ankara'ya" (yumuşatma); "İstanbul'a" doğru ama "Bursa'a" yanlış. Bu yüzden her şehir için dative + locative ayrı alanlar — şablon bu alanları doğrudan kullanır, varsayım yapmaz.

Data engineering hizmetimiz bu tip yapısal veri katmanlarını kurarken üç katmanı birlikte tasarlar: kaynak (API/CSV/manuel form) → temizleme + doğrulama (regex, sözlük, dış kaynak çapraz kontrol) → şablona uygun export. Bu üçü ayrı düşünülürse veri kalitesi düşer.

3. Şablon mimarisi — değişken oranı %30'un altına düşmesin

İki boyutlu matriste şablon, hem ortak iskeleti hem değişken bölümleri tanımlar. Riskli olan yer: iskelet çok büyük + değişken bölümler çok küçük olursa, Google bunu "thin content" algılar.

Bizim şehir sayfası şablonunun yapısı:

Bölüm	Ortak (template)	Değişken (data-driven)
Hero başlık	"{şehir}'da kurumsal yazılım ve yapay zekâ"	şehir adı (vokal uyumu)
Intro paragrafı	Şanlıurfa merkezliyiz cümlesi sabit	şehirden ofisimize ulaşım + lokal müşteri profili değişken
Sektör vurgusu	"X şehrinin öne çıkan sektörleri" sabit	Sektör listesi farklı
Hizmet listesi	6 ana hizmet sabit	Şehir-özel kullanım örnekleri
Yerel referans	"Bu bölgede dikkat çeken yapılar"	Landmark listesi farklı
FAQ	5 soru sabit kalıp	Şehir adı, sektör, ulaşım gibi alanlar değişken
CTA	İletişim çağrısı sabit	Çağrı metni şehre göre küçük varyasyon

Bu yapıda değişken oranı yaklaşık %35-40. Sınır altına inmemesi için kontrol: yeni alan eklemek yerine mevcut alanlardan dallanma (örnek: sektör listesinin uzunluğuna göre paragraf yapısının uzaması — 3 sektör → tek paragraf, 5+ sektör → bullet listesi).

Yapay zeka destekli içerik üretimi: AIGENCY V4 platformumuzu kullanarak her şehir için sektör-spesifik 1 paragraf yorum oluşturuyoruz; sonra insan editör bunu inceleyip onaylıyor. Tam otomatik AI içerik (insan denetimi olmadan) Google E-E-A-T sinyallerini zayıflatıyor; %20-30 oranında AI taslak + %70-80 insan editöryal müdahale yaklaşımı en güvenli oran.

4. Static Site Generation — neden SSR değil

Programmatic SEO için doğru mimari SSG (Static Site Generation), SSR (Server-Side Rendering) değil. Bu seçim üç sebepten kritik:

Performans: Static HTML her sorguda CDN'den 50-200ms içinde gelir, SSR sunucu işlemi 500-2000ms ekler. Core Web Vitals için fark belirleyici. Google sıralama faktörü olarak LCP (Largest Contentful Paint) < 2.5s'yi şart koşar; 500+ sayfalı bir programmatic site SSR ile bu eşiği geçemez.

Maliyet: SSR her ziyaretçi için CPU/RAM kullanır. 1000 sayfa × günde 50 ziyaret = 50.000 sunucu hesabı. SSG'de bu maliyet sıfır — CDN'de cache'li statik dosya servisi.

Güvenlik: SSG sayfaları runtime backend olmadan çalışır. SQL injection, SSRF, RCE gibi server-side açıklar yok çünkü server yok. Bu, siber güvenlik perspektifimizden önemli bir kazanım.

Bizim sitemiz vite-react-ssg kullanıyor. Build sırasında CANONICAL_ROUTES listesindeki her path + her dil kombinasyonu için ayrı bir dist/<path>/index.html üretiliyor. 32 şehir × 4 dil = 128 statik HTML, build time'da bir kez. Sonra Cloudflare CDN üzerinden dünya çapında 50ms altında servis ediliyor.

Alternatif uygun stack'ler: Next.js (getStaticProps + getStaticPaths), Astro (içerik koleksiyonları), Gatsby (createPages API), Eleventy (data file'ları). Hepsi build-time her satır için ayrı HTML çıkarır.

5. Sitemap + indeks yönetimi — Google'ın sayfaları bulması

500 statik sayfa ürettiniz ama Google sadece 30'unu indeksledi — programmatic SEO projelerinde en sık karşılaşılan sorun budur. İndeks sayısı, sayfa kalitesi + sitemap stratejisi kombinasyonuna bağlıdır.

Sitemap.xml stratejisi: Tüm sayfalar tek sitemap'te değil, tematik gruplara bölünmüş — Google çoklu sitemap'i daha iyi tarar. Bizim sitemiz şu an tek sitemap'te 216 URL içeriyor; 500+'a çıkınca sitemap index yapısına geçeceğiz: sitemap-cities.xml, sitemap-services.xml, sitemap-blog.xml ayrı dosyalar + sitemap.xml bunları işaret eden index.

Lastmod doğru kullanım: Sitemap'te her URL için <lastmod> tarihi gerçek güncelleme tarihini göstermeli. Sahte ileri tarih (Google bunu sürekli yeni gösterip sürekli tarama almak için) cezalı: Google bunu fark edince ya lastmod'u görmezden gelir ya da güveni düşürür. Bizim build script'imiz package.json'da prebuild hook'u ile her build'de sitemap'i otomatik üretir; lastmod = gerçek build tarihi.

Robots.txt ile koordinasyon: Sitemap referansı robots.txt'in en altında olmalı. Sitemap: https://www.e-cloud.web.tr/sitemap.xml satırı, Googlebot/Bingbot/YandexBot'a sitemap'i otomatik bildirir. Search Console'a manuel ekleme ek hızlandırıcı; ilk indekslenme dakikalar içinde başlar.

İlk indekslenme: 500 sayfa birden indeksleme isteği yapılmaz. İlk hafta 20 önemli sayfa (pillar + ana matris kombinasyonu) manuel Search Console URL Inspection ile inspect + index request. Bu sayfalar indekslenip ilk impression'ları aldıktan sonra, geri kalan sayfalar doğal olarak keşfedilir (internal linklerden + sitemap'ten). Toplu manuel istek hem zaman alıcı hem etkisiz.

6. İç linkleme — yetim sayfa yok kuralı

Programmatic SEO'nun en kritik teknik şartı: yetim sayfa kalmaması. Yetim sayfa = sitenin başka hiçbir sayfasından link almıyor, sadece sitemap'te var. Google bu sayfaları zayıf değerlendirir; çok yetim sayfa varsa tüm matrisin değeri düşer.

Üç katmanlı iç linkleme stratejimiz:

Katman 1 — Hub link. Her matris satırı bir ana hub sayfasından link alır. Şehir matrisi için: /sehir (varsa) veya footer'daki "Şehirler" sütunu. Bizim sitemizde footer.columns.cities her şehri içerir, böylece her şehir sayfası hem footer'dan (sitewide) hem ilgili ana sayfa bölümünden link alır.

Katman 2 — Çapraz link. Matris satırları kendi aralarında bağlanır. Şanlıurfa sayfasının altında "Diğer şehirler" bölümü: İstanbul, Ankara, İzmir, Bursa kartları + linkler. Bu hem kullanıcı yolculuğunu zenginleştirir hem PageRank dağılımını sağlar.

Katman 3 — Blog → matris satırı. Bu yazı gibi blog içerikleri spesifik şehir/hizmet sayfalarına link verir. Örnek: "Şanlıurfa merkezli mühendislik ekibimiz" bağlantısı şehir sayfasına otorite aktarır.

Bizim sitemizde her şehir sayfası en az 4 iç linkten otorite alıyor: footer (sitewide), ana sayfa şehir bölümü, ilgili blog yazıları (eğer varsa), diğer şehir sayfaları (çapraz). Bu yoğunluk indekslenme hızını ve sıralama gücünü doğrudan artırır.

SaaS platform mühendisliği projelerinde aynı iç linkleme yapısını build-time validation ile zorunlu kılıyoruz: bir sayfa hiçbir başka sayfadan link almıyorsa CI/CD pipeline'ı fail eder, yayına çıkmaz.

7. Süreklilik — yayın sonrası 90 günlük takip

Programmatic SEO projelerinde en sık yapılan hata: yayından sonra ilgilenmemek. 500 sayfa canlıya çıktı, herkes mutlu, sonra 3 ay sonra trafik %20'de seyrediyor — çünkü kimse takip etmedi.

90 günlük standart takip planımız:

1-7 gün: Search Console URL Inspection ile ilk 20 sayfayı manuel indeksleme. Server log analizi: Googlebot tüm sayfaları taradı mı? Tarama oranı düşükse robots.txt veya sitemap konfigürasyonunda hata var.

7-30 gün: Coverage raporları takibi. "Crawled - currently not indexed" sayfası varsa — neden indekslenmedi? Genelde içerik benzerliği veya kalite eşiği. Düzeltme: sayfaya 100-200 kelime özgün içerik ekle, lastmod güncelle, yeniden submit et.

30-60 gün: Performance raporu okuma. Hangi sayfalar impression alıyor ama tıklama almıyor? Title/meta description'a iyileştirme. Hangi sayfalar hiç impression almıyor? Daha fazla iç linkleme veya içerik genişletme.

60-90 gün: Position 10-30 arası sayfalar (yani Google sayfa 2-3'te) için içerik güçlendirme — bu sayfalar küçük itki ile ilk sayfaya çıkabilir. Buna "low-hanging fruit" denir; programmatic SEO'nun en büyük ROI alanı.

Bizim 32 şehir matrisi için 90 günlük takipte ortalama sonuç: 32 sayfanın 28'i ilk 60 günde indekslendi, 18'i ilk 90 gün içinde en az bir uzun kuyruk sorgu için 1. sayfaya yükseldi. Şanlıurfa, İstanbul, Ankara gibi rekabetli şehirlerde aynı süre 4-6 ay uzayabilir.

Karar matrisi: programmatic SEO size uygun mu?

Üç soru için pratik değerlendirme:

Soru	Evet → uygun	Hayır → blog daha uygun
Hizmet/ürününüz iki boyutlu matriste (X × Y) doğal olarak ifade edilebilir mi?	✓	Tek boyutlu içerik blog için daha uygun
Her satır için gerçek farklı veri mevcut mu?	✓	Sadece etiket değişimi varsa thin content riski yüksek
6+ ay sabırlı kalabilir misiniz (indekslenme + sıralama süresi)?	✓	Hızlı sonuç beklentisi varsa diğer SEO taktikleri daha uygun

Üçüne de "Evet" → programmatic SEO ciddi ROI sağlar. İkisine "Evet" → hibrit yaklaşım (10-30 sayfa programmatik + blog destek). Bir "Evet" → klasik blog stratejisi daha uygun.

Pilot proje yaklaşımımız

Yeni başlayan bir kurum için önerimiz: 4-haftalık pilot. Pilot kapsamı:

• Tek matris boyutu seçilir (sadece şehir ya da sadece hizmet).
• 30-50 sayfa hedeflenir, daha fazlası değil.
• Şablon + veri kaynağı + build pipeline kurulur.
• Yayından sonra 30 gün takip; coverage + ilk position'lar ölçülür.
• Pilot sonu karar: ya genişletilir (iki boyutlu matris, 200-500 sayfa) ya da yaklaşımı değiştirir.

Pilot sonuçları olumluysa, ikinci faz veri zenginleştirme (alan sayısını 8'den 16'ya çıkarmak, AI destekli özet paragraflar ekleme) + dil çoğaltma (TR → EN/DE/AR). Bizim sitemizde aynı şehir matrisini 4 dilde yayınlamak için ek 2 hafta gerekti — çevirilerin manuel onayı + dil-spesifik SEO meta etiketleri.

Programmatic SEO bir "kur ve unut" projesi değildir; iyi kurulmuş ve düzenli takip edilen bir mimaridir. Doğru başlangıç, sonraki yıllarda kurum trafiğinin sessiz ama istikrarlı motoru olur. Kötü başlangıç ise düzeltmesi zor bir teknik borç bırakır. Hangi yaklaşımı seçeceğiniz, ekibin disiplinine ve veri kalitesine olan bağlılığınıza bağlıdır.

Sonraki adım

Kendi kurumunuz için programmatic SEO uygun mu? Yukarıdaki üç soruyu kendi içeriğinizle değerlendirin. Cevap belirsizse, iletişim sayfamız üzerinden 30 dakikalık ücretsiz değerlendirme görüşmesi talep edebilirsiniz; görüşmede sektörünüzün matris uygunluğunu + tahmini sayfa sayısı + pilot zaman çizelgesi paylaşıyoruz.

Bu yazının sıradaki devamı blog sayfamızda duyurulacak: "Programmatic SEO için içerik kalitesi otomasyonu (AIGENCY V4 ile)" ve "Çok dilli programmatic SEO — hreflang doğru uygulama rehberi". Sizin için öncelikli bir konu varsa, ön görüşmede belirtmeniz halinde ilgili teknik dokümanları paylaşabiliriz.