Web Sitesi Tasarlanırken SEO: Yayına Almadan Önce Kontrol Listesi

SEO web tasarım sürecinin hangi aşamasında başlar?

SEO, web tasarım sürecinin keşif ve bilgi mimarisi aşamasında, yani ilk ekran tasarımı çizilmeden önce başlar. Hangi sayfaların olacağı, hangi aramaya hangi sayfanın cevap vereceği ve adreslerin nasıl kurulacağı bu aşamada belirlenir; tasarım bittikten sonra eklenen SEO ise çoğu zaman şablon, URL ve içerik değişikliği anlamına gelir.

Sık karşılaştığımız tablo şu: site görsel olarak beğenilerek yayına alınıyor, birkaç ay sonra farklı hizmetlerin tek bir sayfada toplandığı, başlıkların görselin içine gömüldüğü ya da ana görselin sayfayı yavaşlattığı fark ediliyor. Bunları sonradan düzeltmek, baştan doğru kurmaktan daha pahalı. Ziyaretçi açısından da durum aynı: her kullanıcı internette aynı ölçüde deneyimli değil ve aradığını menüden, başlıklardan ya da sayfa içi bağlantılardan kolayca bulamayan ziyaretçi siteden ayrılıyor.

Tasarımda gizli metin ya da anahtar kelime doldurma gibi kısa yollara yer yoktur; ikisi de Google’ın spam politikalarında açıkça sayılan uygulamalardır. Beyaz ve siyah şapka SEO ayrımını black hat SEO yazımızda ayrıca anlattık.

Bilgi mimarisi ve sayfa haritası SEO’yu nasıl belirler?

Bilgi mimarisi, her arama niyetine tek ve net bir sayfanın karşılık gelmesini sağlayarak SEO’nun iskeletini kurar. Sayfa haritası hangi konuların ayrı sayfa, hangilerinin bir sayfanın bölümü olacağını belirler; bir niyete cevap veren sayfa yoksa o aramada görünmek de zordur.

En sık hata, birbirinden farklı hizmetleri tek bir “Hizmetlerimiz” sayfasında toplamak. Kurumsal bir sitede “kurumsal web tasarım”, “e-ticaret sitesi” ve “web sitesi bakımı” ayrı arama niyetleridir; her biri kendi başlığı, içeriği ve adresi olan bir sayfayı hak eder. Ters yöndeki hata da var: aynı niyete cevap veren birden fazla sayfa açmak, sayfaların birbiriyle yarışmasına yol açar.

1. Arama talebini çıkarın. Hedef kitlenin kullandığı sorguları ve soruları ürün ya da hizmet başlıklarına göre gruplayın.
2. Kümeleri sayfalara eşleyin. Her küme için tek bir ana sayfa belirleyin; ana ve ikincil anahtar kelimeleri bu sayfanın içerik iskeletine yazın.
3. Hiyerarşiyi kurun. Ana hizmet, alt hizmet ve destekleyici içerik arasındaki ilişkiyi ağaç biçiminde çizin; önemli sayfalar ana sayfadan az sayıda bağlantı uzakta olmalı.
4. İç bağlantı planını yazın. Menü, alt bilgi, içerik içi bağlantılar ve ilgili sayfa kutularının hangi sayfaları birbirine bağlayacağını tasarımdan önce belirleyin.
5. İçerik modelini tanımlayın. Hizmet sayfası, proje, ürün ya da blog yazısı gibi her içerik türü için hangi alanların (başlık, özet, görsel, SSS, yazar) doldurulacağını belirleyin.

İçerik modeli, yönetim panelinde içeriğin nasıl girileceğini de belirler; içeriği yayımlama biçiminiz tasarımda kullanılan bileşenlerle doğrudan ilişkilidir. Kurumsal bir sitede hangi sayfaların mutlaka bulunması gerektiğini kurumsal web sitesinde olması gerekenler yazımızda ayrıca listeledik.

URL yapısı, gezinme ve breadcrumb nasıl planlanır?

URL yapısı kısa, okunabilir ve sayfa hiyerarşisini yansıtan kelimelerle; gezinme ise tarayıcının izleyebildiği gerçek bağlantılarla planlanır. Breadcrumb (içerik yolu) bu hiyerarşiyi hem ziyaretçiye hem de arama motoruna gösterir. Üç karar da yayından sonra değiştirildiğinde yönlendirme gerektirdiği için en baştan sabitlenmelidir.

• Okunabilir kelimeler kullanın. Google, uzun kimlik numaraları yerine okunabilir kelimeler ve kelimeleri ayırmak için alt çizgi yerine tire kullanılmasını öneriyor; /web-tasarim/e-ticaret-sitesi gibi.
• Benzer konuları dizinlerde toplayın. Google’a göre konuları klasörlerle gruplamak, her dizindeki adreslerin ne sıklıkla değiştiğini anlamasına yardımcı olabilir.
• Türkçe karakter kararını baştan verin. Google, ASCII dışı karakterlerin adreste yüzde kodlamasıyla (percent-encoding) yer almasını bekliyor. Biz paylaşıldığında okunabilir kalması için adreslerde ç, ğ, ı, ö, ş, ü yerine c, g, i, o, s, u kullanmayı tercih ediyoruz; önemli olan, seçilen kuralın bütün sitede tutarlı uygulanması.
• Ayrı içerikleri # ile açmayın. Google Arama URL parçalarını (fragment) genellikle desteklemez; sekmeyle ya da # ile değişen içerik ayrı bir sayfa olarak dizine girmez.
• Gezinmeyi gerçek bağlantılarla kurun. Menü ve kategori bağlantıları href özniteliği taşıyan <a> öğeleri olmalı; yalnızca JavaScript olayıyla çalışan bir menü öğesini Google bir bağlantı olarak izleyemez.

Breadcrumb ziyaretçiye nerede olduğunu gösterir ve üst sayfaya tek adımda dönmesini sağlar. BreadcrumbList işaretlemesiyle desteklendiğinde Google bu yolu masaüstü arama sonuçlarında gösterebiliyor; işaretleme sayfada görünen breadcrumb ile birebir aynı olmalı. Şema türlerinin ayrıntısını yapılandırılmış veri rehberimizde anlattık.

Şablonlarda başlık, meta ve yapılandırılmış veri nasıl kurgulanır?

Başlık, meta açıklama ve yapılandırılmış veri, sayfa sayfa hatırlanarak yazılan metinler olarak değil; şablonlarda tanımlanan ve her sayfada doldurulması zorunlu alanlar olarak kurgulanır. Böylece yüzlerce sayfanın aynı başlığı taşıması, meta açıklamanın boş kalması ya da şemanın içerikle çelişmesi tasarım aşamasında önlenir.

Google her sayfanın <title> öğesinde kendine özgü, açıklayıcı ve kısa bir başlık taşımasını öneriyor; teknik bir karakter sınırı yok, ama arama sonucundaki başlık cihaz genişliğine göre kısaltılıyor. Meta açıklama için de sınır tanımlanmıyor; Google snippet’i çoğunlukla sayfa içeriğinden üretiyor ve meta açıklamayı sayfayı daha doğru anlattığında kullanıyor. Başlık hiyerarşisinde Google’a göre başlıkların sırası Arama açısından belirleyici değil, ama anlamsal sıra ekran okuyucular için önemli; bu yüzden her şablonda tek bir H1 ve mantıklı bir H2-H3 düzeni kuruyoruz.

Yapılandırılmış veri sayfada görünen içerikle birebir örtüşmeli ve zengin sonuç garantisi olarak görülmemeli. Örneğin Google, SSS zengin sonuçlarını 2023’te tanınmış kamu ve sağlık siteleriyle sınırladı, 7 Mayıs 2026’dan itibaren ise Arama’da hiç göstermiyor; bu yüzden şemayı bir görünüm bileti değil, sayfayı makinenin anlayacağı biçimde etiketleyen bir katman olarak ele alıyoruz. Kanonik etiket de şablonun parçası olmalı: her sayfa kendi temiz adresini göstermeli.

Tasarım kararları hızı ve Core Web Vitals’ı nasıl etkiler?

Hızı en çok, yayından sonra değil tasarım sırasında verilen kararlar belirler: ekranın üst kısmındaki ana görsel ya da video, yazı tipi sayısı, animasyonlar ve üçüncü taraf betikler doğrudan Core Web Vitals değerlerine yansır. Google’ın “iyi” eşikleri LCP için 2,5 saniye, INP için 200 milisaniye, CLS için 0,1’dir ve gerçek kullanıcı verisinin 75. yüzdeliğinde, mobil ve masaüstü için ayrı ayrı değerlendirilir.

Bu yüzden projelere bir performans bütçesiyle başlıyoruz: sayfa başına izin verilen görsel ağırlığı, yazı tipi dosyası ve betik sayısı tasarımdan önce yazılı hâle geliyor. Bütçeyi aşan her bileşen, sağladığı faydayla birlikte tartışılıyor.

• Ana görsel (LCP): Sıkıştırılmış, modern biçimde (WebP ya da AVIF) ve doğru boyutta sunulmalı; sayfanın ana görseli tembel yüklemeye bırakılmamalı.
• Slider ve arka plan videosu: Otomatik dönen, her karede ağır görsel yükleyen slider’lar ve üst alandaki videolar LCP’yi uzatır; çoğu zaman tek ve güçlü bir görsel daha iyi çalışır.
• Yazı tipleri: Aile ve kalınlık sayısını sınırlamak, geç yüklenen yazı tipinin metni yerinden oynatmasını azaltır.
• Etkileşim (INP): Menü, filtre ve form etkileşimlerinde ana iş parçacığını kilitleyen uzun JavaScript görevleri INP’yi yükseltir.
• Boyut rezervasyonu (CLS): Görsel, video ve gömülü alanlara width ve height değeri verilmeli; sonradan eklenen bantlar içeriği aşağı itmemeli.

Hızlı sayfa ziyaretçiyi karar anında tutar; ancak iyi Core Web Vitals değerleri tek başına sıralama garantisi değildir. Metriklerin ayrıntısını ve ölçüm araçlarını Core Web Vitals rehberimizde ele aldık.

Mobil ve erişilebilir tasarım neden SEO’nun parçası?

Mobil tasarım SEO’nun parçasıdır, çünkü Google dizine ekleme ve sıralamada sitenin akıllı telefon tarayıcısıyla taranan mobil sürümünün içeriğini kullanır; erişilebilir tasarım ise arama motorlarının da okuduğu anlamsal yapıyı güçlendirir. Masaüstünde görünen ama mobil HTML’de bulunmayan bir içerik, Google için büyük ölçüde yok hükmündedir.

Mobil tasarımda iki kontrol öne çıkıyor. Birincisi içerik eşitliği: ana metin, başlıklar, görseller ve alt metinleri, iç bağlantılar ve yapılandırılmış veri mobil sürümde de bulunmalı; sekme ya da akordeon içindeki içerik HTML’de yer aldığı sürece sorun oluşturmaz. İkincisi kullanım: web.dev dokunma hedefleri için yaklaşık 48 piksellik boyut ve hedefler arasında yaklaşık 8 piksel boşluk öneriyor; ekranı kaplayan açılır pencereler de mobil deneyimi bozar.

• Anlamsal HTML: Başlıklar gerçek başlık öğesi, listeler gerçek liste, bağlantılar gerçek bağlantı olmalı.
• Alternatif metin: Bilgi taşıyan görsellerin alt metni, görme engelli kullanıcıya ve görsel aramaya aynı bilgiyi verir.
• Kontrast ve okunabilirlik: Açık gri zemin üzerine ince yazı hem erişilebilirlik hem de mobilde okunabilirlik sorunudur.
• Klavye ve form etiketleri: Her form alanının görünür bir etiketi olmalı, menüler klavyeyle kullanılabilmeli.

Google erişilebilirliği doğrudan bir sıralama sinyali olarak tanımlamıyor; ama erişilebilir bir sayfa hem daha fazla ziyaretçinin kullanabildiği hem de makinelerin daha doğru okuyabildiği bir sayfadır. Mobil tarafın teknik ayrıntılarını mobil SEO rehberimizde anlattık.

CMS, alan adı ve hosting seçimi SEO’yu etkiler mi?

Etkiler, ama çoğu zaman sanıldığı yönden değil: alan adındaki anahtar kelime neredeyse hiç avantaj sağlamazken, içerik yönetim sisteminin (CMS) başlık, URL, yönlendirme ve şema üzerinde verdiği kontrol ile sunucunun hızı ve kararlılığı SEO’yu doğrudan etkiler.

• Alan adı: Google’a göre alan adındaki ya da URL yolundaki anahtar kelimelerin tek başına sıralamaya etkisi, breadcrumb’da görünmenin ötesinde neredeyse yok. Alan adı yapılan işle uyumlu olmalı, ama bunun ölçüsü akılda kalıcılık ve marka; tam eşleşen bir alan adı avantaj değil. Uzantı da yalnızca belirli bir ülkeyi hedefliyorsanız önem taşıyor ve o durumda bile etkisi genellikle düşük.
• Hosting: Sunucu yanıt süresi LCP’nin ilk halkasıdır; kesinti ve yavaşlık hem taramayı hem de ziyaretçiyi etkiler. HTTPS bugün her sitenin temel koşulu; Google 2014’te HTTPS’i hafif bir sıralama sinyali olarak tanımlamıştı, ama asıl değeri form ve ödeme güvenliği ile ziyaretçinin güvenidir.
• CMS: İyi bir içerik yönetim sistemi her sayfanın başlığını, meta açıklamasını, URL’sini, kanonik adresini ve yönlendirmesini panelden düzenlemeye, XML site haritasını kendiliğinden üretmeye ve şablonlara yapılandırılmış veri eklemeye izin verir. Bu kontroller yoksa her SEO düzeltmesi bir geliştirme işine dönüşür.

Hazır tema ile özel tasarım arasındaki seçimde belirleyici olan, temanın bu kontrolleri verip vermediği ve gereksiz kod yükü taşıyıp taşımadığıdır. İki yaklaşımın farkını web tasarım sayfamızda karşılaştırdık; kendi projelerimizde bilgi mimarisi ve içerik planı tasarımdan önce hazırlanıyor.

Yayına almadan önce hangi SEO kontrolleri yapılmalı?

Yayından önce sitenin taranabilir ve dizine eklenebilir olduğu, eski adreslerin doğru yönlendirildiği, her sayfanın kendine özgü başlık ve açıklama taşıdığı, hız ve mobil testlerin geçildiği ve ölçüm araçlarının kurulduğu kontrol edilmelidir. Test ortamından kalan tek bir noindex etiketi ya da robots.txt’deki Disallow: / satırı, bütün siteyi aramanın dışında bırakabilir.

1. Test ortamı izleri: Geliştirme sırasında kullanılan noindex etiketi ve robots.txt engeli kaldırıldı mı? Google gizli içerik için doğru yöntemin şifre koruması olduğunu belirtiyor; test ortamı da yayından önce bu şekilde korunmalı.
2. Yönlendirme haritası: Eski sitenin her önemli adresi, içeriği karşılayan yeni adrese tek adımda 301 ile yönlendiriliyor mu?
3. Durum kodları: Olmayan bir adres gerçekten 404 dönüyor mu; http ve www varyantları tek bir sürüme yönleniyor mu?
4. Başlık ve açıklama: Her sayfanın <title> öğesi ve meta açıklaması dolu ve kendine özgü mü?
5. Kanonik ve site haritası: Kanonik etiketler, iç bağlantılar ve XML site haritası aynı temiz adresleri gösteriyor mu?
6. Yapılandırılmış veri: Şemalar Zengin Sonuçlar Testi’nden hatasız geçiyor ve görünen içerikle örtüşüyor mu?
7. Hız ve mobil: Ana şablonlar mobilde test edildi, ana görsel ve yazı tipleri optimize edildi mi?
8. Ölçüm: Search Console doğrulaması, analitik etiketi ve form ya da satış gibi önemli etkinlikler çalışıyor mu?
9. İç bağlantılar: Menü, alt bilgi ve içerikteki bağlantılar test alan adına değil, canlı alan adına gidiyor mu?

Yayın günü XML site haritasını Search Console’a gönderiyor, en önemli sayfaları URL Denetimi aracıyla kontrol ediyor ve sonrasında Sayfa dizine ekleme raporunu düzenli olarak izliyoruz. Mevcut bir sitenin yerine yenisi geçiyorsa adres değişikliklerinin tamamını site taşıma rehberimize göre planlamak gerekir; teknik kontrollerin tamamı teknik SEO nedir yazımızda. Yayından sonraki içerik ve otorite çalışması için SEO paketlerimizi inceleyebilirsiniz.