Kurumsal Web Sitesi Bilgi Mimarisi: Menü, URL ve Sayfa Hiyerarşisi

Menü, tasarımcının ekrana sığdırabildiği kadar başlıktan oluşuyorsa bilgi mimarisi yok demektir. Kurumsal web projelerinin çoğu tasarım taslağıyla başlar; site büyüdükçe yeni hizmetler “Diğer” altına, sektör sayfaları footer’a, blog yazıları ilgisiz kategorilere düşer. İki yıl sonra kimse hangi sayfanın neden orada olduğunu açıklayamaz. Bilgi mimarisi, içeriği kullanıcının görevine göre organize ederek bu dağınıklığı baştan önler. Bu rehber web ekipleri, pazarlama sorumluları ve proje yöneticileri için içerik envanteri, kart sıralama, menü derinliği, URL hiyerarşisi ve hizmet–içerik bağlantı kurgusunu platformdan bağımsız anlatır.

Bilgi mimarisi neden tasarımdan önce gelir

Tasarım, bilgi mimarisinin görsel ifadesidir. Hangi sayfaların olacağı, birbirine nasıl bağlanacağı ve kullanıcının hangi yoldan ilerleyeceği belli olmadan çizilen ana sayfa, eklenen her yeni içerikle biraz daha bozulur. Sırayı doğru kurmanın pratik sonuçları:

• Şablon sayısı belli olur: Hizmet, sektör, çözüm, referans ve rehber gibi sayfa türleri netleşince her biri için bir şablon tasarlanır; sayfa sayfa tasarım yapılmaz.
• Menü baştan doğru kurulur: Menü başlıkları içerik gruplarından türetilir, tasarımdaki yatay alandan değil.
• URL’ler kalıcı olur: Hiyerarşi baştan belli olduğu için ilk yıl içinde URL değiştirme ihtiyacı doğmaz.
• Taşıma riski düşer: Yeniden tasarım projelerinde mevcut URL’lerin yeni yapıyla eşlemesi bu aşamada yapılır.

Yeniden tasarım aynı zamanda bir taşıma projesiyse URL eşlemesi ve yönlendirme planı için web sitesi taşırken SEO kaybını önleme rehberi bu çalışmanın doğrudan devamıdır. Eşleme tablosu yoksa taşıma da yoktur.

İçerik envanteri ve kullanıcı görevleri

İlk adım, mevcut tüm sayfaların listesi. Bir tarama aracıyla veya CMS’den dışa aktarılan listeyle her sayfa için şu bilgiler tabloya alınır: URL, başlık, sayfa türü, sahibi, son güncelleme tarihi, organik trafik ve gelen iç bağlantı sayısı. Her satıra bir karar sütunu eklenir: koru, birleştir, yeniden yaz veya kaldır. Tarama aracının bulduğu sayı ile CMS’deki yayın sayısını karşılaştırın; aradaki fark genellikle menüden kopmuş yetim sayfaları ve unutulmuş kampanya sayfalarını gösterir.

İkinci adım, sitenin hizmet ettiği kullanıcı görevlerini yazmak. Kurumsal bir IT hizmetleri sitesinde görevler genellikle şunlardır:

• Belirli bir sorunu çözecek hizmeti bulmak (“sunucu yedekleme hizmeti veriyorlar mı?”).
• Kendi sektörüne uygun deneyimi görmek.
• Teknik bir konuyu araştırmak ve kaynağın yetkinliğini değerlendirmek.
• Teklif istemek veya iletişime geçmek.
• Mevcut müşteri olarak destek kanalına ulaşmak.

Envanterdeki her sayfa en az bir göreve hizmet etmeli. Hiçbir göreve bağlanamayan sayfa ya birleştirilir ya kaldırılır. Birden çok sayfa aynı görevi aynı şekilde karşılıyorsa bu içerik çakışmasıdır; arama motoru da hangisini göstereceğini bilemez.

Kart sıralama ve kategori adlandırma

Kart sıralamada (card sorting) içerik başlıkları kartlara yazılır ve katılımcılardan bunları gruplamaları istenir. Üç türü vardır:

Tür	Nasıl yapılır	Ne zaman
Açık	Katılımcı grupları kendisi oluşturur ve adlandırır	Yeni yapı keşfi
Kapalı	Gruplar hazırdır, katılımcı kartları yerleştirir	Önerilen yapının testi
Hibrit	Hazır gruplar var, yeni grup açılabilir	Mevcut yapının iyileştirilmesi

Katılımcıları hedef kitleden seçin: müşteri tarafındaki IT yöneticileri, satın alma sorumluları, mümkünse mevcut müşteriler. Yalnız şirket içinden katılımcıyla çalışırsanız kurumun organizasyon şeması menüye taşınır. Kullanıcı “Sistem Departmanı” aramaz. “Sunucu ve yedekleme” arar.

Kart sıralamadan sonra ağaç testi (tree testing) önerilen hiyerarşiyi doğrular. Katılımcıya yalnız metin halindeki menü ağacı gösterilir ve “Yedeklerinizin geri yüklenebildiğini test ettirmek istiyorsunuz; nereye bakarsınız?” gibi görevler verilir. Yanlış dala gidilen görev, kategori adının veya yerinin sorunlu olduğunu gösterir. Tasarım yokken yapılır, bu yüzden ucuzdur.

Adlandırma kuralları basit: kullanıcının arama ve konuşmada kullandığı terimi seçin, kurum içi kısaltmalardan kaçının, aynı düzeydeki başlıkları aynı dilbilgisi yapısında yazın. “Çözümler” ile “Hizmetler” gibi anlamı örtüşen iki başlığı aynı menüye koymayın; koyacaksanız farkını tanımlayın ve iki sayfada da aynı biçimde açıklayın.

Menü derinliği ve mega menü kararları

Ana menü sitenin bütün içeriğini göstermek zorunda değil; temel görevlere giden en kısa yolu göstermeli. Birinci düzeyde beş ile yedi başlık çoğu kurumsal site için yönetilebilir bir aralıktır. Derinlik için pratik kural: kullanıcı bir hizmet sayfasına en fazla iki menü seçimiyle ulaşabilmeli. Daha derin içerik ilgili kategori sayfasından sunulur.

Durum	Önerilen yapı
Başlık altında 2–6 hedef	Basit açılır menü
Başlık altında gruplanabilir 8+ hedef	Gruplu mega menü
Her grup kendi içinde 10+ sayfa	Mega menüde grup başlığı, ayrıntı kategori sayfasında
Ayrı alt alan adında uzman site	Ana menüde açık etiketli geçiş bağlantısı

Mega menüler kontrolsüz büyümeye meyillidir. Her yeni sayfa menüye eklenirse birkaç ay içinde menü bir site haritasına döner. Mega menüde yalnız grup başlıklarını ve en çok kullanılan hedefleri gösterin, grubun tamamını kategori sayfasında listeleyin. Erişilebilirlik de mimari kararın parçası: menü klavyeyle açılabilmeli, aria-expanded durumu doğru güncellenmeli, mobilde dokunma hedefleri yeterli büyüklükte olmalı. Denetimlerde sık gördüğümüz durum, yalnız fareyle üzerine gelindiğinde açılan menüdür. Dokunmatik ekranda ve klavyede çalışmaz.

Ağda birden çok uzman site varsa (ana kurumsal site ve konu bazlı alt alan adları gibi) kullanıcı hangi siteye geçtiğini anlamalı. Alt siteye giden bağlantının etiketi bunu açıkça göstermeli; tüm sitelerde ortak bir üst gezinme veya “ağdaki diğer siteler” bölümü aynı yerde, aynı biçimde durmalı.

URL hiyerarşisi ve kalıcılığı

URL, içeriğin kalıcı adresidir ve menüden bağımsız düşünülmeli. W3C’nin “Cool URIs don’t change” ilkesi bugün de geçerli: URL’ye zamanla değişebilecek bilgi (departman adı, kampanya yılı, dosya uzantısı, CMS sayfa kimliği) konmaz. Örnek bir site haritası:

/                                   Ana sayfa
/hizmetler/                         Hizmetler kategori sayfası
/hizmetler/sunucu-yedekleme/        Hizmet sayfası
/hizmetler/ag-guvenligi/            Hizmet sayfası
/sektorler/                         Sektörler kategori sayfası
/sektorler/otomotiv-tedarik/        Sektör sayfası
/rehberler/                         İçerik arşivi
/rehberler/yedekleme-kurali/        Rehber yazısı
/hakkimizda/
/iletisim/

Bu yapıda dikkat edilen noktalar:

• Hizmet adresleri kategori klasöründe ama tek seviyede. Alt hizmet eklenince üçüncü seviye açılmaz, gerekirse kardeş sayfa olarak eklenir.
• Rehber yazıları kategori adını URL’de taşımaz; yazının kategorisi değişince adresi değişmez.
• Slug’lar Türkçe karaktersiz, küçük harf ve tireli; aynı kural tüm sitede geçerli.
• Sonda eğik çizgi kullanılıp kullanılmayacağı seçilir, diğer biçim kalıcı yönlendirmeyle tek biçime toplanır. İki biçim de 200 dönüyorsa her sayfanın iki kopyası vardır.

Breadcrumb, URL hiyerarşisinin görünür karşılığıdır ve yapılandırılmış veriyle (BreadcrumbList) işaretlenebilir. Dizinlenmesi istenmeyen filtre ve parametreli adreslerin yönetimi canonical, noindex, robots.txt ve sitemap yazısının konusu; çok dilli bir yapı planlanıyorsa dil klasörlerinin hiyerarşiye nasıl ekleneceği için çok dilli site mimarisi rehberine bakın. URL yapısına ilişkin arama motoru tarafındaki öneriler için birincil kaynak Google Search Central dokümantasyonudur.

Hizmet sayfaları ile içerik arasındaki bağlantı kurgusu

Kurumsal sitelerde rehber ve blog içeriği genellikle hizmet sayfalarından kopuk durur. Yazı trafik alır ama okuru ilgili hizmete yönlendirmez; hizmet sayfası da konuyu derinleştiren içeriğe bağlanmaz. Trafik var, talep yok. Bağlantı kurgusu bu ilişkiyi baştan tanımlar:

1. Her hizmet sayfası için o hizmetin çözdüğü sorunları anlatan bir içerik kümesi belirlenir.
2. Kümedeki her yazı bağlam içinde ilgili hizmet sayfasına en az bir bağlantı verir.
3. Hizmet sayfası, kümedeki en kapsamlı iki üç yazıya “ilgili rehberler” bölümüyle bağlanır.
4. Aynı kümedeki yazılar birbirine, tekrar etmeden konuyu tamamlayan noktalarda bağlanır.
5. Kategori ve etiket arşivleri bu kümelerle örtüşecek şekilde tanımlanır; her yazıya rastgele etiket eklenmez.

Bunun CMS’de nasıl uygulanacağı ayrı bir karardır. WordPress’te hizmetler özel içerik türü olarak kurulursa ilgili yazılar özel alanla ilişkilendirilip şablonda otomatik listelenebilir; Elementor tabanlı sitelerde bu yaklaşımı Elementor ile ölçeklenebilir site yapısı yazısında anlattık. Kurgunun ayakta kalması için içerik takviminde her yeni yazının hangi hizmet kümesine ait olduğu yayından önce belirlenmeli.

Çalışmanın çıktısı yazılı olmalı: içerik envanteri tablosu, kullanıcı görevleri listesi, onaylanmış site haritası, menü yapısı, URL kuralları ve hizmet–içerik küme eşlemesi. Bu belgeler tasarım ekibinin de içerik editörlerinin de ortak referansıdır. Yazıya dökülmeyen karar unutulur. Bilgi mimarisi ve site yapısının kurgulanması için kurumsal web sitesi tasarımı ve teknik SEO ve site mimarisi, editoryal süreçlerin bu yapıya bağlanması için kurumsal içerik yönetimi hizmetlerimizi inceleyebilirsiniz.

Sık sorulan sorular

Bilgi mimarisi çalışması küçük bir kurumsal site için de gerekli mi?

Ölçeği küçültülerek evet. On beş sayfalık bir sitede de içerik envanteri, kullanıcı görevleri ve menü kararı birkaç saatlik çalışmayla yazıya dökülebilir. Asıl fayda, site büyüdüğünde yeni sayfanın nereye ekleneceğinin önceden belli olmasıdır.

URL’de kategori klasörü kullanmak SEO için zorunlu mu?

Değil. Arama motorları düz URL’leri de sorunsuz tarar. Klasör yapısının faydası daha çok kullanıcıya ve site yönetimine yöneliktir: içerik gruplarını raporlamak, yönlendirme kuralı yazmak, breadcrumb’ı tutarlı tutmak. Önemli olan seçilen yapının kalıcı olmasıdır.

Mega menü kullanmak ne zaman doğru bir karardır?

Birinci düzeydeki bir başlığın altında gruplanabilir çok sayıda hedef varsa ve kullanıcının seçim yapmadan önce seçenekleri birlikte görmesi gerekiyorsa. Yalnız birkaç alt bağlantı varsa basit açılır menü daha hızlı ve daha erişilebilirdir.

Menü yapısı değişince URL’ler de değişmeli mi?

Hayır. Menü kullanıcıya sunulan gezinme yoludur ve zamanla değişebilir; URL kalıcı adrestir. Menüdeki yer değişikliği için URL değiştirmek yönlendirme yükü ve bağlantı kaybı yaratır. URL’yi ancak içeriğin kendisi değiştiğinde ve bir yönlendirme planıyla değiştirin.