Teknik SEO, sayfa mimarisi ve tasarım nasıl birleşir?

Teknik SEO, içerik mimarisi ve tasarım birlikte ele alınmalıdır; çünkü kullanıcı, arama motoru ve içerik ekibi aynı sayfa sistemini kullanır. Teknik olarak taranabilen fakat soruyu yanıtlamayan bir sayfa değer üretmez. Güçlü metni olan fakat mobilde okunamayan bir tasarım dönüşümü zorlaştırır. Etkileyici görünen fakat ana içeriği ağır istemci kodunun arkasında bırakan bir deneyim ise hem performans hem keşfedilebilirlik açısından risk taşır. Üç disiplin ortak hedef, veri ve kabul kriterleriyle ilerlediğinde site daha anlaşılır, yönetilebilir ve büyümeye açık olur.

Sorun genellikle ekiplerin uzmanlığı değil, çalışma sırasıdır. Önce görsel şablonlar hazırlanır, sonra gerçek içerik bu kutulara sığdırılır, en son SEO kontrol listesi uygulanır. Bu sıra; yanlış URL kararları, tekrar eden sayfalar, eksik başlık hiyerarşisi ve sonradan pahalıya dönüşen performans düzeltmeleri üretir.

Üç disiplin aynı probleme farklı açıdan bakar

Teknik SEO, sistemin taranabilir, indekslenebilir, hızlı ve anlamlı işaretlere sahip olmasını sağlar. İçerik mimarisi hangi bilginin hangi sayfada, hangi ilişki içinde ve hangi modelle yönetileceğini belirler. Tasarım ise bu bilgiyi kullanıcının okuyabileceği, tarayabileceği ve eyleme dönüştürebileceği deneyime çevirir.

Rolleri şöyle ayırabiliriz:

• Teknik SEO: URL, canonical, metadata, render, performans, sitemap ve yapılandırılmış veri.
• İçerik mimarisi: Sayfa görevleri, konu kümeleri, içerik alanları, başlık yapısı ve iç bağlantılar.
• Tasarım: Görsel hiyerarşi, okunabilirlik, navigasyon, responsive davranış ve etkileşim.

Bu alanların sınırları vardır; fakat kararları birbirini etkiler. Örneğin filtre tasarımı URL üretimini, kart bileşeni içerik alanlarını, hareket sistemi ise sayfanın render ve performans davranışını değiştirebilir.

Uygulama kapsamı arıyorsanız web tasarım ve UI/UX teslimlerini inceleyin. Görünürlüğün ve içerik çalışmalarının sorumlulukları ise SEO/GEO hizmet kapsamımızda ayrı açıklanır.

Sayfa görevi ortak başlangıç noktasıdır

Her sayfaya tek, açık bir görev vermek üç disiplinin aynı problem üzerinde çalışmasını sağlar. Bir hizmet sayfası belirli bir arama niyetine cevap vermeli, kullanıcıya kapsamı anlatmalı ve ilgili kanıta geçiş sunmalıdır. Teknik yapı bu sayfanın benzersiz URL ve metadata ile yayınlanmasını sağlar; içerik modeli gerekli alanları tanımlar; tasarım ise bilgiyi doğru sırada gösterir.

Sayfa görevi tanımlanırken şu sorular sorulabilir:

1. Kullanıcı bu sayfaya hangi soruyla gelir?
2. İlk bölümde hangi kısa cevabı görmelidir?
3. Karar vermek için hangi ayrıntı ve kanıta ihtiyaç duyar?
4. Sayfanın birincil sonraki adımı nedir?
5. Hangi ilgili sayfalar bu kararı destekler?

Bu cevaplar olmadan hazırlanan şablon genellikle her sayfada aynı hero, aynı kart sırası ve aynı genel CTA'yı tekrarlar.

URL ve navigasyon kararlarını tasarımdan ayırmayın

Navigasyon yalnızca header içindeki bağlantılar değildir. Site içindeki bilgi ilişkilerinin kullanıcıya görünen yüzüdür. Teknik SEO açısından URL'lerin kalıcı, açıklayıcı ve tekil olması; içerik açısından her sayfanın benzersiz bir kapsam taşıması; tasarım açısından ise önemli yolların bulunabilir olması gerekir.

Örneğin bütün hizmetleri tek sayfada göstermek görsel olarak kompakt olabilir. Fakat özel yazılım, web tasarım ve SEO/GEO farklı kullanıcı soruları taşıyorsa her birinin kendi detay sayfasına ihtiyacı vardır. Ana hizmet sayfası bu alanlar arasında ilişki kurar; detay sayfaları answer-first açıklama, teslimler, süreç, vaka ve SSS sunar.

Hizmet yapımızda bu model kullanılır. Böylece kullanıcı genel kapsamı görebilir, aradığı uzmanlık alanına ilerleyebilir ve ilgili gerçek projeye ulaşabilir.

Gerçek içerik tasarımdan önce görünür olmalı

Yer tutucu veya birkaç satırlık örnek metinle hazırlanan tasarım, gerçek içerik geldiğinde bozulur. Türkçe başlık uzunlukları, teknik terimler, SSS yanıtları ve hizmet listeleri kart yüksekliğini, grid yapısını ve mobil akışı değiştirir.

Tasarım başlamadan bütün metnin son hâlde olması gerekmez. Ancak her içerik türü için gerçekçi alanlar ve örnekler bulunmalıdır:

• Başlık ve answer-first özet
• Problem ve teslim listeleri
• Süreç adımları
• Vaka bağlamı ve sonuçlar
• Görsel alt metinleri
• SSS soru ve yanıtları
• İlgili hizmet ve içerik bağlantıları

Bu alanlar TypeScript data veya MDX frontmatter gibi doğrulanabilir modellerde tutulduğunda hem içerik hem arayüz aynı sözleşmeyi kullanır. Eksik alanlar yayından önce test edilebilir.

Başlık hiyerarşisi görsel hiyerarşiyle eşleşmeli

Bir metni büyük göstermek onu semantik başlık yapmaz; H2 etiketi vermek de görsel olarak önemli hâle getirmez. Kullanıcıların ve yardımcı teknolojilerin sayfa yapısını anlayabilmesi için semantik ve görsel hiyerarşi aynı anlatıyı taşımalıdır.

Sağlıklı yapı:

• Sayfada ana konuyu tanımlayan tek, görünür H1
• Ana bölümler için anlamlı H2'ler
• Bölüm altındaki gerçek alt konular için H3'ler
• Sadece görsel amaçla atlanmayan heading seviyeleri
• Başlık olmayan etiketler için uygun düz metin veya eyebrow bileşeni

Editoryal tasarım büyük tipografi kullanabilir; ancak başlığın mobilde kırpılması, dekoratif çizginin metni kapatması veya düşük kontrast nedeniyle okunmaması içerik görevini bozar.

JavaScript ve hareket kritik içeriği gizlememeli

Modern web tasarımında animasyon anlamlı vurgu sağlayabilir. Ancak içerik yalnızca scroll tetikleyicisi çalıştıktan sonra görünür oluyorsa hata veya reduced-motion durumunda kaybolabilir. Ana metin ve bağlantılar server-rendered HTML içinde bulunmalı, hareket bunların üzerine aşamalı geliştirme olarak eklenmelidir.

Hareket sistemi için ortak kurallar şunlardır:

• Başlangıç HTML'inde içerik erişilebilir olmalı.
• Reduced-motion tercihinde pin, parallax ve büyük dönüşümler kapatılmalı.
• Mobilde hover bağımlılığı bulunmamalı.
• Animasyon kodu küçük client island içinde kalmalı.
• Scroll ve resize dinleyicileri temizlenmeli.
• Görsel hareket CLS oluşturmamalı.

Bu kararlar teknik performansı, erişilebilirliği ve tasarım kalitesini aynı anda korur.

Görsel varlık stratejisi SEO ve güveni etkiler

Gerçek proje ekranı yerine üretilmiş sahte dashboard kullanmak yalnızca etik bir sorun değildir; vaka anlatısının kanıt değerini de yok eder. Görsellerin kaynağı, boyutu, kırpma biçimi ve alt metni içerik modelinin parçası olmalıdır.

İyi bir görsel iş akışı şunları içerir:

1. Gerçek asset envanteri ve kullanım izni
2. Desktop ve mobile ihtiyaçlarına uygun aspect ratio
3. WebP veya AVIF optimizasyonu
4. Boyut ve sizes tanımları
5. Dekoratif görsel için boş, anlamlı görsel için açıklayıcı alt metni
6. Uzak kaynağa production bağımlılığı bırakmama

EkoPark vaka çalışmasındaki gerçek site görüntüleri, içerik mimarisi ve web deneyimi ilişkisinin görsel kanıtıdır. Görsel yalnızca süs değil, anlatının parçasıdır.

Teknik performans tasarım sisteminde başlar

Performans sorunlarını yalnızca build sonunda çözmeye çalışmak geç kalmış bir yaklaşımdır. Çok sayıda font ağırlığı, kontrolsüz video, her bölümde büyük istemci bileşeni veya ölçüsüz görsel kullanımı tasarım kararları sırasında oluşur.

Ortak performans kriterleri belirleyin:

• Hero görseli için doğru öncelik ve sabit oran
• Kritik olmayan medya için lazy loading
• Sınırlı font ailesi ve ağırlığı
• CSS ile yapılabilecek geçişlerde ağır kütüphane kullanmama
• Ana içeriği Server Component olarak tutma
• Üçüncü taraf scriptleri yalnız gerçek ihtiyaç ve izin varsa yükleme
• Mobilde ağır pin ve parallax yerine doğal akış

Bu kriterler yaratıcılığı kısıtlamaz. Tasarımın hangi öğesinin gerçekten değer taşıdığını seçmeye zorlar.

İç bağlantılar hem kullanıcı hem konu mimarisi içindir

İç bağlantı planı SEO ekibinin sonradan metne serpiştirdiği anahtar kelimeler olmamalıdır. Kullanıcının karar yolunu destekleyen doğal bağlantılar tasarımda görünür yer bulmalıdır.

Bir hizmet sayfası şunlara bağlanabilir:

• İlgili vaka çalışmaları
• Süreci açıklayan rehberler
• Tamamlayıcı hizmetler
• Proje başlatma adımı

Bir blog yazısı ise tanımı verdiği hizmete, kullandığı gerçek örneğe ve uygun CTA'ya bağlanmalıdır. Anchor metni bağlantının hedefini açıklamalı; “buraya tıklayın” gibi bağlamsız ifadelerden kaçınılmalıdır.

Sayfalar erişilebilir hâle geldikten sonra arama gösterimi ile yapay zekâ kaynak gösterimini ayrı izlemek için SEO ve GEO ölçüm yaklaşımını kullanın.

Yapılandırılmış veri tek içerik kaynağından üretilmeli

Schema sonradan elle yazıldığında görünür içerikle kolayca ayrışır. Service schema'daki ad ve açıklama hizmet verisinden, Article schema'daki tarih ve yazar MDX frontmatter'ından, BreadcrumbList ise route modelinden üretilmelidir.

Bu yaklaşım üç fayda sağlar:

• Aynı bilgi farklı yerlerde tekrar yazılmaz.
• İçerik güncellendiğinde schema da güncel kalır.
• Sahte veya görünmeyen alan ekleme riski azalır.

Yapılandırılmış veri içeriğin yerine geçmez. Sayfada görünmeyen rating, ödül, adres veya SSS bilgisini schema içine eklemek doğru değildir.

Ekipler için ortak çalışma sırası

Teknik SEO, içerik ve tasarımı birleştirmek için şu sıra uygulanabilir:

1. İş hedefi ve öncelikli kullanıcıları tanımlayın.
2. Mevcut URL ve içerik envanterini çıkarın.
3. Konu kümeleri ile sayfa görevlerini belirleyin.
4. Sitemap, URL ve iç bağlantı modelini kurun.
5. Gerçek içerik alanlarıyla düşük çözünürlüklü akışları tasarlayın.
6. Görsel sistem ve responsive davranışları geliştirin.
7. Server render, metadata ve schema katmanını aynı veriye bağlayın.
8. Erişilebilirlik, performans ve tarama testlerini birlikte yürütün.
9. Yayın sonrası davranış ve görünürlük verisinden backlog oluşturun.

Her aşamada farklı disiplinlerin aynı kabul kriterini görmesi gerekir. Böylece SEO “son kontrol”, içerik “kutuları dolduran metin” ve tasarım “bağımsız görsel katman” olmaktan çıkar.

EkoPark örneğinde üç sayfa görevi

Aşağıdaki türler EkoPark vaka çalışmasında gösterilen katalog, hesaplayıcı ve içerik ekranlarını esas alır. Başlık sütunu, bu türler için önerilen görev tanımıdır; ölçülmüş sıralama sonucu veya canlı sayfanın bire bir başlığı değildir.

Sayfa türü	Ziyaretçinin görevi	Başlığın yanıtlaması gereken konu	Sonraki bağlantı
Ürün / uygulama	Malzemenin kullanım alanını ve niteliğini anlamak	Ürün nedir, hangi uygulamaya uygundur?	İlgili ürün, teknik bilgi ve hesaplama
Malzeme hesaplayıcı	İhtiyaç miktarını belirlemek	Hangi ölçülerle miktar hesaplanır?	Ürün ve proje bağlamıyla teklif
Rehber içerik	Terimi veya uygulama kararını öğrenmek	Sorunun doğrudan cevabı ve sınırları	İlgili ürün, uygulama veya hizmet

Bu üç sayfayı aynı başlık ve metinle çoğaltmak yerine görevlerini ayırın. SEO/GEO hizmetinde teknik erişimi, içerik kapsamını ve kayıtlı talebi aynı raporda farklı sütunlarla değerlendiriyoruz.

Sık sorulan sorular

SEO tasarım bittikten sonra eklenebilir mi?

Bazı metadata ve teknik düzeltmeler sonradan yapılabilir. Ancak URL, sayfa kapsamı, içerik hiyerarşisi, iç bağlantılar ve performans kararları tasarım sırasında verilirse çok daha tutarlı ve düşük riskli olur.

İçerik mimarisi yalnızca sitemap midir?

Hayır. Sitemap yalnızca sayfa haritasıdır. İçerik mimarisi sayfa görevlerini, alanları, ilişkileri, başlık yapısını, iç bağlantıları ve içeriğin nasıl büyüyeceğini de tanımlar.

Sade tasarım SEO açısından daha mı iyidir?

Sadelik tek başına ölçüt değildir. İçerik açık, hızlı, erişilebilir ve semantik biçimde sunuluyorsa güçlü bir görsel sistem de kullanılabilir. Sorun, dekorasyonun görevi engellemesidir.

Sonuç: Tek sayfa, ortak sistem

Kullanıcı tasarım, içerik ve teknik yapıyı ayrı ayrı deneyimlemez; tek bir sayfayla karşılaşır. Bu nedenle ekiplerin de aynı sayfa görevi ve içerik modeli üzerinden çalışması gerekir. Görünürlük ve deneyim altyapınızı birlikte kurmak için SEO ve GEO hizmetimizi inceleyebilir veya projenizi paylaşabilirsiniz.

Kaynaklar ve ek okuma

• Google Search Central: taranabilir bağlantılar: İç bağlantının taranabilir HTML ile kurulması ve bağlantı metninin hedefi açıklaması için teknik temeldir.

• Google Search Central: yapılandırılmış veriye giriş: Yapılandırılmış verinin ne işe yaradığını ve görünür içerikle ilişkisini açıklar; işaretleme eklemek arama özelliği veya sıralama garantisi vermez.

• web.dev: Core Web Vitals: İçerik ve tasarım kabulüne dahil edilen LCP, INP ve CLS performans ölçütlerini tanımlar.