Site Mimarisi Nedir? URL, Hiyerarşi ve Internal Linking Nasıl Birlikte Çalışır?

Site mimarisi, bir web sitesindeki sayfaların hangi görevleri üstlendiğini, nasıl gruplandığını ve aralarında hangi yollarla geçiş yapılabildiğini belirleyen yapıdır. URL’ler, kategori hiyerarşisi, navigasyon ve iç bağlantılar bu yapının farklı parçalarıdır.

Bir sayfanın adresi düzenli olabilir; ancak kullanıcı o sayfayı ilgili kategoriden bulamıyorsa mimari eksiktir. Menüde yüzlerce bağlantı bulunabilir; fakat hangi bölümün ne sunduğu anlaşılmıyorsa bağlantı sayısı sorunu çözmez.

Ben site mimarisini üç soruyla değerlendiriyorum: Bu sayfa ne işe yarıyor, hangi sayfalarla ilişkili ve ona gerçekten nasıl ulaşılıyor?

Burada web mimarisinin sunucu, uygulama veya veritabanı tasarımını değil; içerik, sayfa ve gezinme ilişkilerini ele alıyorum. SEO stratejisi hangi işin neden öncelikli olduğunu belirlerken, site mimarisi bu kararın sitenin sayfalarına ve bağlantılarına nasıl yansıyacağını açıklar.

URL yapısı, hiyerarşi ve internal linking arasındaki fark

Bu kavramlar aynı yapının üç farklı görünümüdür. Birbirleriyle tutarlı olmaları gerekir; ancak birbirlerinin yerine geçmezler.

Bileşen	Cevapladığı soru	Tek başına açıklamadığı şey
URL yapısı	Sayfa hangi adreste bulunuyor?	Sayfaya hangi diğer sayfalardan ulaşılabildiği.
Hiyerarşi	Sayfa veya içerik grubu hangi üst kapsamın altında yer alıyor?	Bu ilişkinin arayüzde ve bağlantılarda gerçekten uygulanıp uygulanmadığı.
Internal linking	Hangi sayfa, hangi bağlamda hangi sayfaya bağlantı veriyor?	Hedef sayfanın doğru görev ve yeterli içerikle tasarlanıp tasarlanmadığı.

Google, e-ticaret sitelerinin yapısını anlamak için sayfalar arasındaki bağlantı ilişkilerini analiz ettiğini; site hiyerarşisini genel olarak URL yapısından çıkarmadığını açıklar.^[1]

Örneğin /urun/model-a/ adresindeki bir ürün, anlamlı biçimde “Elektrikli El Aletleri” ve “Akülü Matkaplar” kategorilerine bağlanabilir. Bütün kategori adlarının ürün URL’sine yazılmaması, bu ilişkilerin kurulamayacağı anlamına gelmez.

Tersine, /elektrikli-el-aletleri/akulu-matkaplar/model-a/ adresinin uzunluğu da ürünün kategori sayfasından bağlantı aldığını kanıtlamaz. Adres örüntüsü ile gerçek gezinme yolunu ayrı kontrol etmek gerekir.

Mimari neden sayfa rolüyle başlar?

Bir sayfayı nereye yerleştireceğimize karar vermeden önce neyi karşılayacağını belirlemeliyiz. Ürün seçmek, belirli bir ürünü satın almak ve bir teknik terimi öğrenmek farklı görevlerdir.

Bir e-ticaret sitesinde kategori seçenekleri düzenleyebilir; ürün sayfası tek ürünün özelliklerini sunabilir; rehber seçim kriterlerini açıklayabilir. Hizmet sitesinde ise ana hizmet, alt hizmet, uygulama rehberi ve teklif sayfası benzer biçimde farklı roller üstlenebilir.

Buradaki owner, bir kullanıcı ihtiyacının ana karşılığı olarak seçilen sayfayı anlatır. Bu, Google’a gönderilen özel bir etiket veya canonical talimatı değildir; içerik ve mimari planlama kararıdır.

Yeni bir sayfa için şu dört soruya cevap veremiyorsak, klasör seçmeye henüz hazır değiliz:

• Mevcut sayfalardan farklı hangi görevi tamamlayacak?
• Hangi bölümün parçası olacak?
• Kullanıcı hangi sayfalardan buraya gelmek isteyecek?
• Buradan sonra hangi bilgiye veya işleme ihtiyaç duyabilecek?

Her anahtar kelime için yeni URL açmak yerine, birbirine yakın ihtiyaçların aynı sayfada karşılanıp karşılanamayacağı değerlendirilmelidir. Yeni URL kararı, yalnızca farklı bir ifade bulunduğu için verilmemelidir.

Taksonomi, hiyerarşi ve menü aynı şey mi?

Taksonomi, içerik veya ürünlerin hangi sınıflara ayrıldığını anlatır. Hiyerarşi, bu sınıflar arasındaki üst-alt ilişkilerini kurar. Menü ise bu yapının kullanıcıya sunulan gezinme araçlarından biridir.

Hırdavat kataloğunda ürün tipi, marka ve kullanım alanı farklı sınıflandırma boyutlarıdır. Bunların tamamını aynı hiyerarşiye zorlamak, gereksiz kategori dalları oluşturabilir. Örneğin “Akülü Matkaplar” bir ürün grubu, “Marka A” marka boyutu, “Ahşap İşleme” ise kullanım bağlamı olabilir.

Bir ürün birden fazla mantıklı listede bulunabilir. Bu durum ürün için her listede ayrı bir içerik kopyası oluşturmayı zorunlu kılmaz. Ürünün kimliğiyle katalogdaki yerleşimleri ayrı yönetilebilir.

Ağaç yapısı neden tek başına yetmez?

Üst kategori ve alt kategoriler bir ağaç olarak çizilebilir. Fakat bir rehberin kategoriye, ürünün uyumlu aksesuara ve kategorinin seçim rehberine bağlanması bu ağacı aşar.

Bu nedenle gerçek site yapısı, hiyerarşinin yanında yatay ilişkiler de içerir. Sayfaları düğüm, bağlantıları yönlü ilişki olarak düşündüğümüzde bir bağlantı ağı ortaya çıkar.

Benim yaklaşımım, konu kümelerini birbirinden koparmak değil; her bağlantının gerekçesini tanımlamaktır. “Aynı konuya ait”, “birlikte kullanılır”, “karşılaştırmaya yardımcı olur” ve “üst kategoriye döndürür” farklı ilişkilerdir. Hepsini tek bir “ilgili içerikler” kutusuna bırakmak bu ayrımı gizler.

İyi bir URL yapısı nasıl seçilir?

Google; anlaşılır sözcükler, mantıklı adresler, kelimeleri ayıran tireler ve gereksiz parametrelerin azaltılması gibi uygulamaları önerir. Büyük-küçük harf farklılıkları da aynı içeriğin ayrı URL’lerle temsil edilmesine yol açabileceğinden tutarlılık önemlidir.^[2]

Ancak “en kısa URL her zaman en iyi mimaridir” sonucu buradan çıkmaz. Daha önemli karar, adreslerin içerik yönetimi ve gelecekteki değişikliklerle nasıl çalışacağıdır.

Örneğin ürünün kategori üyeliği sık değişiyorsa, her değişiklikte ürün URL’sini de değiştiren bir tasarım ek bakım yükü oluşturur. Sabit ürün adresi kullanmak bu bağımlılığı azaltabilir. Bu bir tasarım tercihidir; bütün e-ticaret siteleri için zorunlu URL şablonu değildir.

Adres standardında en azından şunlar net olmalıdır:

• Sayfa türlerinin adresleri nasıl üretilecek?
• Aynı sayfaya giden alternatif adresler nasıl ele alınacak?
• Kategori adı değişirse hangi URL’ler etkilenecek?
• Filtre ve sıralama durumları hangi parametrelerle temsil edilecek?
• İç bağlantılarda hangi tercih edilen adres kullanılacak?

URL derinliği ile tıklama derinliği neden farklıdır?

URL derinliği adresin yol segmentleriyle ilgilidir. Tıklama veya bağlantı derinliği ise belirlenen başlangıç sayfasından hedefe ulaşmak için izlenen bağlantı sayısıyla ilgilidir.

Doğrudan ana sayfadan bağlantı alan uzun bir URL, bağlantı açısından yakın olabilir. Kısa bir ürün adresi ise yalnızca çok ilerideki bir liste sayfasından erişilebiliyorsa derinde kalabilir.

Google, bir sayfaya ulaşmak için izlenmesi gereken bağlantılar ve o sayfaya verilen bağlantılar gibi bilgileri göreli önem değerlendirmesinde kullanabildiğini belirtir.^[1] Bu açıklama, bütün siteler için aynı üç tıklama sınırını tanımlamaz.

Ben derinliği tek başına bir geçer-kalır puanı olarak kullanmam. Öncelikli kategorilerin gereksiz yere uzak kalıp kalmadığına ve aynı rolü taşıyan sayfalar arasındaki farklara bakarım. Başlangıç URL’si, tarama kapsamı ve bağlantıların nasıl çıkarıldığı bilinmeden iki crawl raporundaki derinlikleri karşılaştırmak yanıltıcı olabilir.

Internal linking mimariyi nasıl uygulanabilir hale getirir?

Bir mimari dosyasında iki sayfayı ilişkili göstermek, sitede aralarında geçiş olduğu anlamına gelmez. Bu ilişkiyi çalışan bağlantılarla uygulamak gerekir.

Google, bağlantıların güvenilir biçimde çıkarılabilmesi için gerçek bir adres taşıyan <a href> yapısını önerir. JavaScript ile eklenen bağlantılar da bu yapıyı taşıyabilir. Buna karşılık yalnızca bir tıklama olayıyla çalışan öğenin aynı biçimde keşfedileceği varsayılmamalıdır.^[3]

<a href="/akulu-matkaplar/">Akülü matkap modelleri</a>

İç bağlantıları görevlerine göre ayırmak, şablonların ne yapacağını belirlemeyi kolaylaştırır:

• Global navigasyon: Sitenin ana bölümlerine erişim sağlar.
• Kategori navigasyonu: Kullanıcıyı ilgili alt gruplara ve liste öğelerine taşır.
• Bağlamsal bağlantılar: Bir açıklamadan ilgili rehbere, ürüne veya hizmete geçiş sağlar.
• Ürün ilişkileri: Doğrulanmış aksesuar, alternatif ve tamamlayıcıları birbirine bağlar.
• Yardımcı navigasyon: Teslimat, iade, destek ve iletişim gibi görevleri erişilebilir kılar.

Her URL’nin ana menüde bulunması gerekmez. Menü, bütün envanterin dökümü değil; temel gezinme kararlarının sunumudur. İkincil yollar kategori, rehber ve ürün şablonları üzerinden kurulabilir.

Anchor text neyi anlatmalı?

Bağlantı metni, kullanıcının hedef sayfada ne bulacağını açıklamalıdır. Google da açıklayıcı, makul ölçüde kısa ve kaynak ile hedef sayfayla ilgili bağlantı metinlerini önerir; ideal bir bağlantı sayısı tanımlamaz.^[3]

Örneğin seçim kriterlerini açıklayan bir paragrafta “akülü matkap seçerken dikkat edilecekler” ifadesi rehbere; ürünleri inceleme çağrısında “akülü matkap modelleri” ifadesi kategoriye yöneltilebilir. Aynı kelimeleri her bağlantıya zorlamak yerine, geçişin nedenini açık etmek daha kullanışlıdır.

Mobil menü ve erişilebilirlik de mimarinin parçasıdır

W3C; menü yapısının anlamlı HTML ile belirtilmesini, navigasyon bölgelerinin ayırt edilmesini ve geçerli konumun anlaşılır olmasını önerir. Ekran boyutları değişse de görünen menü öğelerinin adları, sıraları ve hedefleri tutarlı olmalıdır.^[4]

Bu yüzden masaüstünde çalışan bir menüyü görmek yeterli değildir. Aynı önemli bölüme mobilde ve klavye kullanarak da erişilip erişilemediği test edilmelidir. Arayüzde görünür olmak, her kullanıcı için kullanılabilir olmakla aynı değildir.

Breadcrumb hiyerarşiyi nasıl temsil eder?

Breadcrumb, kullanıcının sayfanın daha geniş yapıdaki yerini anlamasına yardımcı olur. Google, breadcrumb’ın URL klasörlerini kopyalamak yerine sayfaya giden tipik bir kullanıcı yolunu temsil etmesini önerir.^[5]

Örneğin adresi /urun/model-a/ olan bir sayfada “Elektrikli El Aletleri”, “Akülü Matkaplar” ve ürün adı anlamlı bir hiyerarşi oluşturabilir. Bu yolun kurulması için ürün adresinin yeniden yazılması gerekmez.

Bir sayfa birden fazla geçerli hiyerarşik yola sahip olabilir; Google’ın dokümantasyonu da birden çok breadcrumb yolunu destekler.^[5] Bununla birlikte bütün olası filtre seçimlerini breadcrumb olarak sunmak zorunlu değildir.

Görünür breadcrumb bağlantıları ile BreadcrumbList işaretlemesi de aynı şey değildir. İlki kullanıcıya geçiş sunar; ikincisi yapıyı makine tarafından okunabilir biçimde ifade eder. Yalnız işaretleme eklemek, eksik gezinme bağlantılarını oluşturmaz.

Sitemap varsa orphan sayfa sorunu çözülür mü?

Site içindeki diğer sayfalardan bağlantı almayan bir sayfa, genellikle orphan page olarak adlandırılır. Böyle bir sayfanın URL’si sitemap, dış bağlantı veya daha önceki keşif yoluyla biliniyor olabilir. Bu nedenle orphan olmak, arama motorunun sayfadan kesinlikle habersiz olması demek değildir.

Google, sitemap’in URL keşfine yardımcı olduğunu ancak tarama ve indeksleme garantisi vermediğini belirtir.^[6] Sitemap’e eklenen bir ürün, kullanıcı için otomatik olarak kategori listesine eklenmiş olmaz.

Bir başka durum da kendi içinde bağlantılı fakat ana gezinme yapısından kopuk sayfa grubudur. Bu gruptaki sayfalar birbirine link verdiği için her biri sıfır iç bağlantıya sahip olmayabilir; yine de ana sayfadan başlayan taramada erişilemeyebilir.

Bu nedenle iki ayrı kontrol yaparım: Sayfa iç bağlantı alıyor mu ve önemli başlangıç noktalarından ona ulaşılabiliyor mu? Sadece link saymak, kopuk kümeleri gözden kaçırabilir.

Canonical neden hiyerarşi etiketi değildir?

rel="canonical", yinelenen veya çok benzer sayfalar arasında tercih edilen URL’yi belirtmek için kullanılan bir sinyaldir. Bir sayfanın üst kategorisini tanımlamak için kullanılmaz. Google ayrıca site içindeki bağlantıların tercih edilen canonical URL’ye yöneltilmesini önerir.^[7]

Örneğin “Matkaplar” ile “Akülü Matkaplar” arasında üst-alt ilişkisi bulunması, alt kategorinin canonical’ının üst kategoriye verilmesini tek başına haklı çıkarmaz. İki sayfa farklı kapsam ve ürün listesi sunuyorsa hiyerarşik ilişki, içerik eşdeğerliği anlamına gelmez.

Aynı ürün farklı kategorilerde listeleniyorsa, bu listelerden tercih edilen tek ürün URL’sine bağlantı vermek düşünülebilir. Birden çok ürün URL’si zaten oluşuyorsa eşdeğerlik, yönlendirme ve canonical kararları ayrıca incelenir.

Kısacası kategori üyeliği bir ilişki kararıdır; canonicalization ise eşdeğer URL’lerin temsiliyle ilgilidir. Birini diğerinin yerine kullanmak, mimariyi açıklamak yerine çelişkili sinyaller üretebilir.

Faceted navigation mimarinin neresinde durur?

Filtreler, bir ürün veya içerik grubunun farklı özelliklerle daraltılmasını sağlar. Fakat her filtre durumu kalıcı bir organik açılış sayfası olmak zorunda değildir.

Google, kontrolsüz filtre kombinasyonlarının çok büyük URL alanları oluşturabileceğini; gereksiz tarama ve yeni, yararlı URL’lerin daha yavaş keşfedilmesi gibi sonuçlar doğurabileceğini açıklar.^[8]

Mimari planında filtreleri üç ayrı rolde ele alıyorum:

• Bağımsız ihtiyacı, yeterli ürün kapsamı ve sürdürülebilir değeri olan seçilmiş açılış sayfaları.
• Listeyi kullanmayı kolaylaştıran, ayrı organik hedef olması gerekmeyen arayüz durumları.
• Sıralama, tekrar veya anlamsız kombinasyonlarla oluşan, kontrol edilmesi gereken URL durumları.

Bu ayrım yapıldığında iç bağlantı politikası da netleşir: Seçilmiş sayfalar ilgili kategorilerden ve içeriklerden desteklenebilir. Her kombinasyonun otomatik olarak bütün şablonlardan bağlantı alması gerekmez.

Tarama ve indeksleme kontrollerinin nasıl seçileceğini faceted navigation ve filtre URL’leri rehberinde ayrıntılı ele alıyorum. Buradaki mimari karar, hangi filtre durumunun kalıcı sayfa rolüne sahip olacağıdır.

Pagination ürünlerin keşif yolunu nasıl etkiler?

Kategoriye bağlantı vermek, kategori içindeki bütün ürünlerin erişilebilir olduğu anlamına gelmez. İlk ekranda görünmeyen ürünler yalnızca bir butona basıldığında yükleniyorsa, ayrıca taranabilir keşif yolları gerekir.

Google crawler’ları genellikle kullanıcı etkileşimi gerektiren butonları çalıştırmaz. Google’ın önerisi, sayfalama bölümlerine gerçek <a href> bağlantıları ve ayrı URL’ler üzerinden erişilebilmesidir. Farklı ürünler gösteren sayfalama URL’lerinin tamamını ilk sayfaya canonical etmek de önerilmez; her sayfanın kendi canonical URL’si olmalıdır.^[9]

Bu yüzden kabul testi yalnızca “daha fazla yükle çalışıyor mu?” değildir. Listenin sonraki bölümündeki bir ürün, etkileşim gerektirmeyen bağlantı yollarından bulunabiliyor mu? Filtre değiştiğinde sayfalama aynı seçimi koruyor mu? Liste sonuna kadar gidildiğinde döngü veya boş tekrarlar oluşuyor mu?

Bu kontroller, kategori şablonunu katalog mimarisinin çalışan bir parçası olarak değerlendirmeyi sağlar.

Hırdavat kataloğu üzerinden mimari örneği

Aşağıdaki yapı temsilidir; gerçek bir projenin trafik veya satış sonuçlarını içermez. Seçilmiş filtre sayfasının bağımsız talebi ve sürdürülebilir ürün kapsamı bulunduğu varsayılmıştır.

Amaç, bütün sayfaları aynı sorguya yöneltmek değil; her sayfanın görevini ve bağlantı gerekçesini belirlemektir.

Sayfa	Rol	Örnek bağlantı hedefleri
Elektrikli El Aletleri	Geniş ürün ailesini düzenlemek.	Akülü matkaplar, zımparalar ve diğer gerçek alt gruplar.
Akülü Matkaplar	Ürünleri inceletmek ve seçenekleri daraltmak.	Ürünler, seçilmiş alt gruplar ve seçim rehberi.
Kömürsüz Akülü Matkaplar	Doğrulanmış daha dar ürün ihtiyacını karşılamak.	Bu kapsamdaki ürünler ve üst kategori.
Model A ürün sayfası	Tek ürünün özelliklerini ve satın alma koşullarını sunmak.	İlgili kategori, uyumluluğu doğrulanmış aksesuarlar ve gerekli açıklamalar.
Akülü Matkap Seçim Rehberi	Seçim kriterlerini açıklamak.	Kriterin uygulandığı kategori veya karşılaştırma sayfası.

Bu modelde ürünün hem ana kategoride hem seçilmiş filtre listesinde görünmesi, iki ürün URL’si gerektirmez. Rehberin kategoriye bağlantı vermesi de rehberin bir kategori kopyasına dönüşmesini gerektirmez.

Bağlantının gerekçesi kullanıcı görevinden çıkar: Kriteri öğrenen kişi ilgili ürün grubunu inceleyebilir; kategoriye gelen kişi karar vermek için rehbere ihtiyaç duyabilir. Her sayfadan her sayfaya bağlantı vermek yerine bu geçişler tanımlanır.

Bu yapının ürün verisi ve ticari arama yüzeyleriyle nasıl birleştiğini e-ticaret SEO’nun çalışma modelinde ele alıyorum. Mimari burada ürünlerin ve onları açıklayan içeriklerin birbirine bağlandığı katmandır.

Site mimarisi nasıl denetlenir?

1. Envanter ile taranabilen sayfaları karşılaştırın

Yalnızca ana sayfadan başlayan crawl çıktısına bakmak, hiç keşfedilmeyen sayfaları görünmez bırakabilir. CMS veya ürün envanterini; sitemap, Search Console ve mevcutsa sunucu kayıtlarıyla karşılaştırmak gerekir.

Envanterde olup taramada bulunmayan URL önce bir inceleme adayıdır. Nedeni orphan olması, bağlantının işlenememesi, crawl kapsamı veya erişim sorunu olabilir. Kontrol tamamlanmadan hepsini aynı hata sınıfına koymayın.

2. Bağlantıların sayısını değil, yapısını inceleyin

Önemli sayfalar için gelen bağlantıların kaynaklarını, şablonlarını ve hedef adreslerini çıkarın. Bin sayfada tekrarlanan tek footer bağlantısı ile farklı kullanıcı bağlamlarından gelen bağlantılar aynı yapıyı temsil etmez. Bu ayrım, Google’ın gizli ağırlıklarını hesapladığımız anlamına gelmez; bağlantı sayısının arkasındaki düzeni anlamaya yarar.

Search Console’un Links raporu yardımcıdır; ancak Google bu raporun bütün bağlantıları kapsamadığını, örneklem sunduğunu ve artık mevcut olmayan bağlantıları da içerebildiğini belirtir. Dolayısıyla raporda görünmeyen bir bağlantının sitede kesinlikle bulunmadığı söylenemez.^[10]

3. Şablonları ve kullanıcı yollarını birlikte test edin

Her sayfa türünden örnek seçin. Üst kategori, alt kategori, ürün, rehber ve sayfalama şablonlarında bağlantıları kontrol edin. JavaScript kullanılan yerlerde oluşturulan HTML’yi de inceleyin. Büyük bir sitede tek bir şablon hatası çok sayıda URL’yi etkileyebilir.

Ardından somut bir görev deneyin: “Bu ürün ailesini bul, seçenekleri daralt, seçim kriterini öğren ve ürüne geri dön.” Kullanıcı aynı işlemi mobilde tamamlayabiliyor mu? Geri dönüş yolu belirsiz mi? Bağlantı doğru sayfayı açıyor ama yanlış beklenti mi yaratıyor?

4. Uygulama ölçümü ile sonuç ölçümünü ayırın

İlk kontrol, değişikliğin doğru uygulanıp uygulanmadığıdır: Yeni bağlantılar çalışıyor mu, öncelikli sayfalara ulaşılabiliyor mu, eski adreslere giden gereksiz yollar kaldı mı?

Sonraki kontrol, görünürlük ve kullanıcı davranışıdır. İlgili sayfa grubunun organik performansını ve ölçülebilen işlemlerini önceki dönemle karşılaştırın. Stok, kampanya, sezon ve başka site değişikliklerini not edin. Bağlantı eklendikten sonra trafik artması, tek başına artışın yalnızca o bağlantıdan kaynaklandığını kanıtlamaz.

Mimariyi düzeltmek için URL’leri değiştirmek gerekir mi?

Her zaman değil. Kategori ilişkilerini düzeltmek, menüyü yeniden düzenlemek, eksik bağlantıları eklemek veya breadcrumb’ı anlamlı hale getirmek mevcut URL’ler korunarak yapılabilir.

Ben önce sorunun adreslerde mi, sayfa rollerinde mi yoksa erişim yollarında mı olduğunu ayırırım. Sorun yalnızca ürünlerin kategoriye bağlanmamasıysa bütün ürün URL’lerini taşımak doğrudan çözüm değildir.

URL değişikliği gerçekten gerekiyorsa, eski-yeni eşleştirmesiyle birlikte yönlendirmeler, canonical adresleri, iç bağlantılar ve sitemap güncellenmelidir. Google’ın taşıma rehberi de bu işleri birlikte ele alır; ilgisiz eski sayfaların tek genel hedefe yönlendirilmemesini ve gereksiz yönlendirme zincirlerinden kaçınılmasını önerir.^[11]

URL değişikliği, düzenli görünen klasörler elde etmek için otomatik uygulanacak bir işlem değil; etkisi ve bakım maliyeti değerlendirilmesi gereken bir değişikliktir.

Uygulanabilir bir site mimarisi planı ne içermeli?

Son teslimat yalnızca kutular ve oklar olmamalıdır. Planın siteye uygulanabilmesi için şu kararların kayıtlı olması gerekir:

1. Önemli kullanıcı görevleri ve bunları karşılayan sayfalar.
2. Sayfa türleri, üst-alt ilişkileri ve anlamlı yatay ilişkiler.
3. Korunacak, oluşturulacak, birleştirilecek veya kaldırılacak sayfalar.
4. URL üretimi ve tercih edilen adres kuralları.
5. Hangi şablonun hangi sayfalara bağlantı vereceği.
6. Filtre, sayfalama ve ürün değişikliklerinde uygulanacak kurallar.
7. Teknik kontroller, kullanıcı görevleri ve sonuç değerlendirme ölçütleri.

Yeni ürün veya içerik eklendiğinde nereye bağlanacağı belli değilse, mimari yalnızca o günkü envanter için çizilmiş demektir. İyi plan, sonraki değişikliklerin nasıl yönetileceğini de açıklar.

Site mimarisinin temel ilkesi

URL sayfanın adresini, hiyerarşi kapsam içindeki yerini, internal linking ise sayfalar arasındaki gerçek geçişleri tanımlar.

Bu parçalar birlikte çalıştığında kullanıcı hangi bölümde olduğunu ve nereye ilerleyebileceğini anlayabilir. Arama sistemleri de sayfaları keşfetmek ve aralarındaki ilişkileri değerlendirmek için daha açık bir yapıyla karşılaşır. İyi mimarinin çıktısı yalnızca düzenli adresler değil, anlamlı ve sürdürülebilir erişim yollarıdır.

Kaynaklar ve teknik referanslar

Kaynaklar ve bağlantı verilen mevcut yazıların adresleri 27 Ağustos 2026 tarihinde kontrol edildi. Örnekler ve uygulama çerçevesi açıklama amacıyla hazırlanmıştır.

1. Google Search Central — Help Google understand your ecommerce website structure
2. Google Search Central — URL structure best practices
3. Google Search Central — Link best practices
4. W3C Web Accessibility Initiative — Menu Structure
5. Google Search Central — Breadcrumb structured data
6. Google Search Central — What is a sitemap?
7. Google Search Central — How to specify a canonical URL
8. Google Crawling Infrastructure — Managing crawling of faceted navigation URLs
9. Google Search Central — Pagination and incremental page loading
10. Google Search Console Help — Links report
11. Google Search Central — Site moves and migrations