SEO’da Mimari Kontrollü Büyüme: Site Mimarisi Bozulmadan Nasıl Ölçeklenir?

SEO projeleri çoğu zaman tek bir büyük mimari hata yüzünden dağılmaz.

Daha sık görülen problem, aylar boyunca verilen yüzlerce küçük kararın aynı mimariyi farklı yönlere çekmesidir.

Keyword research yeni bir fırsat bulur ve yeni URL açılır.

İçerik ekibi benzer konu için ikinci sayfayı üretir.

Bir hizmet başka parent altına taşınır.

Eski URL redirect edilir fakat internal linkler güncellenmez.

Canonical başka bir adresi gösterir.

Sitemap üçüncü URL’yi içerir.

Bir süre sonra aynı kullanıcı ihtiyacını birden fazla sayfa karşılamaya çalışır.

Sonra ekip şu soruyu sorar:

Google neden yanlış sayfayı gösteriyor?

Asıl problem çoğu zaman Google’ın yanlış URL’yi seçmesinden daha önce başlamıştır.

Site aynı ihtiyacı hangi URL’nin sahiplenmesi gerektiği konusunda kendi içinde tutarlı davranmamıştır.

Bu yazıda SEO’da Mimari Kontrollü Büyüme adını verdiğim çalışma modelini ele alıyorum.

Bu yerleşik bir SEO standardı veya Google tarafından kullanılan bir terim değildir. Berkedalar.com’da site büyümesini yönetmek için kullandığım bir governance framework’üdür.

Temel fikir şudur:

ÖLÇ
↓
TEŞHİS ET
↓
OWNERSHIP BELİRLE
↓
MİMARİYİ KİLİTLE
↓
ÜRET
↓
KALİTE KAPISINDAN GEÇİR
↓
ÖLÇ
↓
KONTROLLÜ DEĞİŞTİR

Büyümeyi yavaşlatmak için değil, büyümenin mimari borç üretmesini engellemek için gate kullanılır.

SEO büyüdükçe site mimarisi neden bozulur?

Bir site ilk kurulduğunda mimari çoğu zaman oldukça temiz görünür.

Ana Sayfa
↓
Hizmetler
↓
Alt HizmetlerBlog
↓
Rehberler

Problem üretim başladığında ortaya çıkar.

Yeni sorgular bulunur.

Yeni ürün veya hizmetler eklenir.

Yeni landing page talepleri gelir.

Content cluster genişler.

Local sayfalar açılır.

Eski sayfalar birleştirilir.

URL’ler değiştirilir.

Bütün bu kararlar tek tek mantıklı olabilir.

Fakat birbirinden bağımsız verildiklerinde toplam sistem mantıksız hale gelebilir.

Keyword bulundu
↓
Yeni sayfa açBaşka keyword bulundu
↓
Bir sayfa daha aç
Yeni hizmet geldi
↓
Yeni parent oluştur
Eski hizmet güncellendi
↓
Yeni URL aç
SONUÇ
Same intent
→ 3 URL
Same page
→ 2 parent
Internal links
→ farklı owner'lar
Canonical
→ başka URL

Bu nedenle SEO mimarisi yalnız ilk site haritasını çizme işi değildir.

Mimari aynı zamanda değişikliklerin nasıl yapılacağını belirleyen bir yönetim sistemidir.

Site mimarisi yazısında URL, hiyerarşi ve internal linking arasındaki farkı ayrıntılı biçimde ele alıyorum. Buradaki problem ise bu yapının üretim devam ederken nasıl korunacağıdır.

SEO’da Mimari Kontrollü Büyüme nedir?

SEO’da Mimari Kontrollü Büyüme, yeni URL, page role, parent, taxonomy veya diğer kritik mimari değişikliklerin önceden tanımlanmış karar kapılarından geçmeden üretime alınmaması prensibidir.

Klasik üretim modeli çoğu zaman şöyledir:

KEYWORD
↓
CONTENT
↓
PUBLISH

Mimari kontrollü model ise:

BUSINESS CONTEXT
↓
TECHNICAL VIABILITY
↓
SEARCH OPPORTUNITY
↓
PAGE OWNERSHIP
↓
ARCHITECTURE LOCK
↓
PRODUCTION
↓
QUALITY GATE
↓
MEASUREMENT
↓
CONTROLLED CHANGE

Buradaki kritik kavram gate, yani karar kapısıdır.

Gate şunu söyler:

Bu karar çözülmeden sonraki aşamaya geçme.

Örneğin hangi URL’nin sorgu ailesinin owner’ı olduğu belli değilse yeni içerik üretimine geçilmez.

Yeni commercial page mevcut bir sayfanın görevini tekrar ediyorsa yalnız keyword bulundu diye yayınlanmaz.

Pre-Gate: Önce business baseline oluştur

İlk aşamada herhangi bir mimari karar kilitlenmez.

Önce mevcut durum anlaşılır.

Temel sorular:

• Business model nasıl çalışıyor?
• Hangi hizmet veya ürünler ticari olarak önemli?
• Hedef müşteri kim?
• Kullanıcı yolculuğu nasıl ilerliyor?
• GA4 ve Search Console ölçümü çalışıyor mu?
• Mevcut organik trafik hangi sayfalardan geliyor?
• Hangi sayfalar lead veya satış üretiyor?
• Mevcut sıralamalar ve backlink değerleri nerede yoğunlaşıyor?

Buradaki çıktı yeni URL listesi değildir.

Çıktı:

CURRENT STATE
+
BUSINESS PRIORITY
+
MEASUREMENT BASELINE

olmalıdır.

Çünkü search demand ile business value aynı şey değildir.

Gate 1: Teknik olarak büyümeye hazır mıyız?

Yeni sayfa üretmeden önce sitenin mevcut teknik yapısının büyümeyi taşıyıp taşımadığı kontrol edilir.

Özellikle:

• crawlability,
• indexability,
• robots kuralları,
• canonical davranışı,
• HTTP status kodları,
• rendering,
• sitemap,
• internal linking,
• kritik template sorunları

incelenir.

Örneğin ana kategori sayfalarına crawlable linklerle ulaşılamıyorsa yüzlerce yeni kategori üretmek büyüme değildir.

Mevcut sorunu ölçeklemektir.

KRİTİK BLOCKER?
    / \
 EVET  HAYIR
  |      |
FIX    DEVAM

Google da önemli sayfaların navigasyon ve crawlable bağlantılar üzerinden erişilebilir olmasının site yapısını anlamaya yardımcı olduğunu belirtir.

Gate 2: Search Opportunity Map oluştur

Bu aşamada klasik keyword listesi yerine opportunity map oluşturulur.

QUERY
↓
INFORMATION NEED
↓
INTENT
↓
EXPECTED PAGE TYPE
↓
BUSINESS VALUE
↓
PRIORITY

Buradaki en önemli ayrım query ile kullanıcı ihtiyacının aynı şey olmamasıdır.

Information Retrieval yazısında information need ile query arasındaki farkı daha teknik biçimde ele alıyorum.

Bir kullanıcı:

M8 civata

yazarak ürün satın almak isteyebilir.

Başka biri aynı sorguyla ölçü öğrenmek isteyebilir.

Dolayısıyla:

Keyword
≠
Automatic page requirement

Opportunity map’in görevi yalnız ne kadar arama hacmi olduğunu değil, bu talebin hangi kullanıcı göreviyle ilişkili olduğunu anlamaktır.

Gate 3: Keyword ve Topic Ownership belirle

Framework’ün en kritik aşamalarından biri budur.

Soru:

Bu kullanıcı ihtiyacının ana sahibi hangi URL?

Her yeni fırsat için şu aksiyonlardan biri seçilebilir:

KEEP
EXPAND
REWRITE
MERGE
REDIRECT
REMOVE
NEW

Yeni URL varsayılan cevap değildir.

Örneğin yeni bir query bulunduğunda önce şu sorular sorulur:

• Bu ihtiyacı karşılayan mevcut bir URL var mı?
• Mevcut sayfa genişletilerek ihtiyacı karşılayabilir mi?
• Yeni query gerçekten ayrı intent veya page role taşıyor mu?
• SERP yapısı farklı bir sayfa türü gerektiriyor mu?
• Yeni URL mevcut owner ile çakışacak mı?
• Yeni sayfanın mimaride doğal parent’ı ve supporting ilişkileri var mı?

Bu yaklaşım SEO stratejisinde kullanıcı ihtiyacı → sayfa rolü → ownership kararının devamıdır.

Gate 4: Mimari Kilit nedir?

Mimari Kilit, kritik site mimarisi kararlarının belirli bir versiyonda onaylanmasıdır.

Örneğin:

MİMARİ KİLİT v1.0Primary owners
Parent / child ilişkileri
URL politikası
Taxonomy
Navigation
Internal linking yönleri
Canonical ownership
Sitemap eligibility

Bu noktadan sonra üretim ekibi kafasına göre yeni:

/yeni-hizmet//blog/yeni-hizmet/
/istanbul/yeni-hizmet/
/hizmetler/yeni-hizmet/

adreslerinden birini seçmez.

Önce mevcut mimaride bu ihtiyacın owner’ı olup olmadığı kontrol edilir.

Yeni mimari karar gerekiyorsa değişiklik talebi oluşturulur.

Mimari Kilit:

Artık site değişmeyecek.

demek değildir.

Şunu demektir:

Mimariyi değiştiren kararlar görünür ve gerekçeli olacak.

Mimari Kilit hangi kararları kapsar?

Özellikle şu kararlar birbirine bağlıdır:

PAGE ROLE
↕
OWNER
↕
URL
↕
PARENT
↕
INTERNAL LINKING
↕
CANONICAL
↕
SITEMAP

Örneğin:

/yazilar/implant-seo/

sayfasını:

/hizmetler/implant-seo/

adresine taşımak yalnız slug değişikliği değildir.

Aynı anda:

• page role,
• parent ilişkisi,
• internal links,
• redirect,
• canonical,
• sitemap,
• conversion expectation

değişebilir.

Google’ın site migration rehberi de URL değişikliklerinde mapping, redirect, canonical, internal links ve sitemap güncellemelerinin birlikte ele alınmasını önerir.

Bu yüzden:

URL değişikliği CMS’deki bir alanı değiştirmek değildir. Küçük bir mimari migration’dır.

Gate 5: Production paralel çalışabilir

Mimari kilitlendikten sonra teknik ve içerik üretimi paralel ilerleyebilir.

TECHNICAL LANERedirect
Canonical
Schema
Internal Linking
Sitemap
Rendering
Performance
    +CONTENT LANE
Commercial pages
Supporting content
Category content
FAQ
EEAT evidence
Local pages

Ancak burada:

Parallel work ≠ Independent decisions

İki lane de aynı architecture contract altında çalışır.

İçerik ekibi yeni sayfa üretirken teknik ekip başka bir URL’yi canonical owner yapmamalıdır.

Developer yeni taxonomy üretirken content owner bundan habersiz olmamalıdır.

Bu özellikle e-ticaret SEO’da page role → site architecture → internal linking → crawling zincirinin birlikte yönetilmesi gereken büyük kataloglarda daha önemlidir.

Gate 6: Quality Gate olmadan release yok

Bir sayfanın CMS’e girilmiş olması işlemin tamamlandığı anlamına gelmez.

Release öncesi minimum quality gate:

INTENT doğru mu?
↓
OWNER doğru mu?
↓
PARENT doğru mu?
↓
URL doğru mu?
↓
CANONICAL doğru mu?
↓
INDEXABILITY doğru mu?
↓
INTERNAL LINKS doğru mu?
↓
TRACKING çalışıyor mu?

Her proje için aynı kontrollerin tamamı gerekli olmayabilir.

Ancak mimariyi etkileyen değişikliklerde owner, parent, canonical ve internal linking kontrol edilmeden release yapılması gereksiz risk üretir.

Gate 7: Mimari sabit değil, kontrollü değişkendir

Mimari Kilit’in amacı değişimi engellemek değildir.

Veri geldikçe kararlar değişebilir.

MİMARİ v1.0
↓
GSC + GA4 + Crawl verisi
↓
Yeni bulgu
↓
Değişiklik talebi
↓
Etki analizi
↓
Onay
↓
MİMARİ v1.1

Bunu tek cümlede şöyle özetleyebiliriz:

Mimari stabil olmalı ama statik olmamalıdır.

Örneğin Search Console zaman içinde belirli query ailesinde farklı bir URL’nin sürekli daha güçlü performans ürettiğini gösterebilir.

Bu veri:

Google böyle istiyor, owner’ı değiştirelim.

şeklinde otomatik karar üretmez.

Ama ownership kararını yeniden incelemek için evidence oluşturabilir.

Bütün SEO değişiklikleri aynı riskte değildir

SEO governance’ın amacı her title değişikliğini üç kişinin onayına göndermek değildir.

Bürokrasi üretmek ile kontrol sistemi kurmak arasında insanlığın şaşırtıcı biçimde sürekli karıştırdığı bir fark vardır.

Değişiklikleri risk seviyelerine ayırmak daha kullanışlıdır.

Değişiklik	Risk	Mimari kontrol
Title / meta güncelleme	Düşük	Gerekmez
Mevcut içeriği genişletme	Düşük	Gerekmez
Görsel / FAQ ekleme	Düşük	Gerekmez
Internal link ekleme	Orta	Ownership kontrolü
Yeni supporting content	Orta	Intent / owner kontrolü
Yeni informational page	Orta	Page role kontrolü
Yeni commercial page	Yüksek	Mimari onay
Parent değiştirme	Yüksek	Mimari onay
URL değiştirme	Çok yüksek	Etki analizi + migration planı
Merge	Çok yüksek	Ownership + redirect planı
Taxonomy değiştirme	Çok yüksek	Mimari versiyon değişikliği

Neden her yeni içerik Architecture Lock gerektirmez?

Çünkü governance’ın amacı üretimi felç etmek değildir.

Örneğin mevcut owner’ı destekleyen yeni bir rehber:

Existing topic
↓
Distinct supporting intent
↓
Clear parent
↓
Clear internal link role
↓
NEW SUPPORTING CONTENT

şeklinde ilerleyebilir.

Ama yeni bir commercial page:

New commercial intent
↓
Existing owner?
↓
New owner needed?
↓
Parent?
↓
URL?
↓
Internal links?
↓
Conversion role?

sorularını cevaplamadan açılmamalıdır.

Keyword ownership tablosu nasıl kullanılabilir?

Mimari kontrollü büyümenin operasyonel araçlarından biri ownership tablosudur.

Topic / Query	Intent	Owner URL	Aksiyon	Parent	Supporting
diş hekimi seo	Commercial	/hizmetler/dis-hekimi-seo/	EXPAND	Sağlık	5
implant seo nedir	Informational	/yazilar/implant-seo-nedir/	NEW	Diş SEO	–
klinik seo	Commercial	/hizmetler/klinik-seo/	KEEP	Sağlık	4

Bu tablo keyword tracking tablosu değildir.

Asıl işi:

Hangi ihtiyacın hangi URL tarafından karşılanacağı konusunda organizasyonel hafıza oluşturmaktır.

Böylece altı ay sonra aynı query yeniden keyword research’te çıktığında ekip yeniden sıfırdan sayfa açma tartışmasına girmez.

Mimari değişiklik talebi ne içermeli?

Architecture Lock sonrası yüksek riskli değişiklikler kısa bir değişiklik talebiyle yönetilebilir.

CHANGE REQUESTNe değişecek?
↓
Neden?
↓
Hangi URL'ler etkileniyor?
↓
Ownership değişiyor mu?
↓
Parent değişiyor mu?
↓
Redirect gerekiyor mu?
↓
Canonical değişiyor mu?
↓
Internal links değişiyor mu?
↓
Sitemap etkileniyor mu?
↓
Measurement planı ne?

Bu dokümanın roman olması gerekmez.

Önemli olan değişikliğin sistem etkisinin görünür olmasıdır.

Architecture debt nedir?

Teknik borç kavramına benzer biçimde bir site de zamanla mimari borç biriktirebilir.

Örneğin:

• aynı ihtiyacı karşılayan birden fazla URL,
• redirect zincirleri,
• eski internal linkler,
• yanlış parent altında yaşayan sayfalar,
• canonical çatışmaları,
• sitemap’te artık owner olmayan URL’ler,
• orphan veya zayıf bağlı önemli sayfalar

mimari borcun parçaları olabilir.

Büyüme modeli yalnız:

Daha fazla trafik
Daha fazla keyword
Daha fazla URL

üretirken bu borcu ölçmüyorsa kısa vadede büyürken uzun vadede sistemi karmaşıklaştırabilir.

SEO mimarisinin sağlık metrikleri neler olabilir?

Organik trafik yine önemlidir.

Ama mimari kontrollü büyümede ek sağlık göstergeleri de takip edilebilir.

Organic Visibility
↓
Target Query Ownership
↓
Qualified Traffic
↓
Conversion
↓
Revenue

Bunun yanında architecture health:

• wrong-owner query sayısı,
• orphan önemli sayfalar,
• canonical conflict sayısı,
• redirect chain / redirect debt,
• internal linklerin eski URL’lere gitme oranı,
• index bloat,
• duplicate page-role vakaları

üzerinden takip edilebilir.

Buradaki amaç gizli bir “SEO mimari skoru” üretmek değildir.

Ama büyürken mimarinin bozulup bozulmadığını ayrıca gözlemlemektir.

SEO Stratejisi, Site Mimarisi ve Mimari Kontrollü Büyüme arasındaki fark

İçerik	Ana soru
SEO Stratejisi	Ne yapacağız, neden ve hangi öncelikle?
Site Mimarisi	Sayfalar hangi görev, hiyerarşi ve bağlantı yapısıyla organize edilecek?
Mimari Kontrollü Büyüme	Bu yapı üretim ve değişiklikler devam ederken nasıl korunacak?

Bu nedenle bu üç içerik birbirinin yerine geçmez.

SEO stratejisi kararların nedenini ve önceliğini belirler.

Site mimarisi bu kararların sayfa ve bağlantı yapısına nasıl yansıdığını açıklar.

Mimari Kontrollü Büyüme ise bu kararların üretim sırasında nasıl korunacağını ve nasıl değiştirilebileceğini tanımlar.

SEO’da Mimari Kontrollü Büyüme framework’ü

0. BUSINESS BASELINE
Mevcut durumu ve ticari önceliği anla↓

TECHNICAL VIABILITY
Kritik teknik blocker'ları çöz

↓

SEARCH OPPORTUNITY MAP
Query'yi kullanıcı ihtiyacına bağla

↓

OWNERSHIP
Her ihtiyacın owner URL'sini belirle

↓

ARCHITECTURE LOCK
Owner, parent, URL ve link kurallarını kilitle

↓

PRODUCTION
Technical + Content paralel üret

↓

QUALITY GATE
Release öncesi mimari ve teknik QA

↓
LEARN & CHANGE
Veriden öğren, değişikliği kontrollü uygula

Sonuç: SEO büyümesi URL üretim hızı değildir

Bir SEO programının üretken olması önemlidir.

Yeni içerik, kategori, landing page ve teknik geliştirmeler olmadan büyüme gerçekleşmez.

Fakat üretim kapasitesi arttıkça mimari kararların koordinasyonu daha önemli hale gelir.

Çünkü:

MORE PRODUCTION
+
NO GOVERNANCE
=
MORE ARCHITECTURE DEBT

Bu nedenle Mimari Kontrollü Büyüme’nin amacı yeni sayfa üretimini zorlaştırmak değildir.

Amaç:

Yeni sayfaların mevcut sisteme hangi görevle girdiğinin ve mimariyi hangi noktada değiştirdiğinin görünür olmasını sağlamaktır.

Sağlıklı model:

ÖLÇ
↓
TEŞHİS ET
↓
OWNERSHIP BELİRLE
↓
MİMARİYİ KİLİTLE
↓
ÜRET
↓
QA
↓
ÖLÇ
↓
ÖĞREN
↓
KONTROLLÜ DEĞİŞTİR

Mimari değişebilir.

Ama rastgele değişmemelidir.

İyi SEO mimarisi yalnız bugünkü siteyi düzenlemez; yarın site büyüdüğünde hangi değişikliklerin nasıl yapılacağını da tanımlar.

Sık Sorulan Sorular

SEO’da Mimari Kontrollü Büyüme nedir?

Mimari Kontrollü Büyüme, yeni URL, page role, taxonomy ve diğer kritik SEO değişikliklerinin önceden tanımlanmış ownership ve mimari karar kapılarından geçerek uygulanmasını amaçlayan bir çalışma framework’üdür.

Mimari Kilit ne demektir?

Mimari Kilit, primary owner URL’ler, parent-child ilişkileri, URL politikası, internal linking yönleri ve benzeri kritik kararların belirli bir versiyonda onaylanmasıdır. Bu, mimarinin bir daha değişmeyeceği anlamına gelmez; değişikliklerin kontrollü yapılacağı anlamına gelir.

Her yeni içerik mimari onay gerektirir mi?

Hayır. Mevcut owner’ı destekleyen ve açık bir supporting role taşıyan düşük veya orta riskli içerikler daha hafif kontrollerle üretilebilir. Yeni commercial page, URL değişikliği, merge ve taxonomy değişikliği gibi yüksek riskli işlemler daha güçlü mimari kontrol gerektirir.

Keyword ownership nedir?

Keyword ownership, bir sorgu veya kullanıcı ihtiyacı ailesinin sitede hangi URL tarafından öncelikli olarak karşılanacağını belirleyen içerik ve mimari planlama kararıdır. Google’a gönderilen teknik bir etiket değildir.

SEO mimarisi neden sürekli değişmemeli?

Sık ve koordinasyonsuz URL, parent, canonical veya internal linking değişiklikleri aynı ihtiyacın farklı sayfalar tarafından sahiplenilmesine ve mimari borç oluşmasına neden olabilir. Ancak veri yeni bir karar gerektiriyorsa mimari kontrollü biçimde güncellenmelidir.

Mimari değişikliklerde hangi alanlar kontrol edilmelidir?

Değişikliğe göre owner URL, page role, parent, internal links, redirect, canonical, sitemap, indexability ve measurement etkileri birlikte değerlendirilmelidir.

Kaynaklar ve teknik referanslar

1. Google Search Central — Help Google understand your ecommerce site structure
2. Google Search Central — Site Moves and Migrations