Web Sitesi Analizi Nasıl Yapılır? Hız, SEO ve Yapılandırılmış Veri Rehberi

Bir web sitesinin "iyi" olup olmadığı sorusu çoğu zaman tek bir ekran görüntüsüyle cevaplanır: bir denetim aracına adres yazılır, çıkan renkli puana bakılır, iş bitmiş sayılır.

Oysa o puan üç ayrı sorunun karışımıdır ve üçü birbirinden bağımsızdır:

• Site ziyaretçiye yeterince hızlı geliyor mu?
• Arama motorları sayfaları bulup indeksleyebiliyor mu?
• Sayfadaki bilgi makinenin anlayabileceği biçimde işaretlenmiş mi?

Bir site bu üçünden ikisinde iyi, birinde kötü olabilir. Çok hızlı ama arama motoruna kapalı bir site de, mükemmel işaretlenmiş ama mobilde açılmayan bir site de mümkündür. Bu yüzden web sitesi analizi tek bir sayıya indirgenmez; katman katman yapılır.

Bu rehber üç katmanı sırayla ele alıyor. Her bölümün sonunda kendi sitenizde neye bakacağınızı somut olarak bulacaksınız.

Puan değil, eşik

Başlamadan önce bir alışkanlığı bırakmakta fayda var: puan avcılığı.

Denetim araçlarının verdiği 0-100 arası puan, standart bir cihaz ve bağlantı varsayımıyla üretilen bir tahmindir. Gerçek ziyaretçilerinizin deneyimi değildir. Puanı 100'e çıkarmak için harcanan emeğin bir kısmı, hiçbir kullanıcının fark etmeyeceği ayrıntılara gider.

Daha sağlıklı yaklaşım, puan yerine eşik düşünmektir: ölçüm belirli bir sınırın içinde mi, değil mi? Aşağıdaki bölümlerde bu eşikleri tek tek göreceksiniz.

Birinci katman: hız ve performans analizi

Hız teknik bir konu gibi görünür ama sonuçları tamamen insani: yavaş açılan sayfa terk edilir. Ziyaretçi "site yavaş" diye düşünmez bile; çoğu zaman sekmeyi kapatır ve bunu neden yaptığını kendisi de bilmez.

Bu yüzden performans, tasarım kadar kullanıcı deneyiminin parçasıdır.

Core Web Vitals: üç ölçüm, üç farklı soru

Google'ın sayfa deneyimini ölçmek için standartlaştırdığı üç metrik var. Her biri farklı bir şeyi sorar:

• LCP (Largest Contentful Paint) — Sayfanın ana içeriği ne zaman göründü? Genelde kapak görseli ya da başlık bloğu. İyi kabul edilen eşik: 2,5 saniyenin altı.
• INP (Interaction to Next Paint) — Kullanıcı bir şeye tıkladığında sayfa ne kadar sürede tepki verdi? 2024 Mart'ında eski FID metriğinin yerini aldı ve tek bir ilk tıklamayı değil, ziyaret boyunca yaşanan etkileşimleri ölçer. İyi eşik: 200 milisaniyenin altı.
• CLS (Cumulative Layout Shift) — Sayfa yüklenirken içerik yerinden oynadı mı? Tam tıklayacakken düğmenin aşağı kayması bu metrikte görünür. İyi eşik: 0,1'in altı.

Üçü birlikte şunu anlatır: içerik ne zaman geldi, dokununca cevap verdi mi, altınızdan kaydı mı.

Laboratuvar verisi ile saha verisi aynı şey değil

Analiz yaparken en sık karıştırılan ayrım budur.

Laboratuvar verisi (lab data), sayfanın kontrollü bir ortamda simüle edilerek ölçülmesidir. Tekrarlanabilir olduğu için geliştirme sırasında çok kullanışlıdır: bir değişikliğin etkisini hemen görürsünüz.

Saha verisi (field data), sitenizi gerçekten ziyaret eden kullanıcılardan toplanan ölçümdür. Google bunu Chrome kullanıcılarından derler ve 28 günlük kayan bir pencerede, kullanıcıların %75'inin yaşadığı deneyimi esas alır.

İkisi çeliştiğinde saha verisi esastır. Laboratuvarda 90 puan alan bir site, ziyaretçilerinin çoğu eski telefonlardan ve zayıf bağlantıdan geliyorsa sahada takılıyor olabilir. Tersi de geçerlidir.

Saha verisi yalnızca yeterli trafiği olan adresler için oluşur. Yeni ya da az ziyaret edilen bir sitede bu veri hiç görünmeyebilir — bu bir hata değil, yalnızca henüz yeterli ölçüm birikmediği anlamına gelir.

Mobil performansı ayrıca ölçün

Masaüstünde iyi görünen bir sitenin mobilde aynı olduğunu varsaymak yaygın bir hata. Telefon hem daha yavaş işlemciyle hem de çoğu zaman daha kötü bağlantıyla çalışır; aynı sayfanın mobil ölçümü belirgin biçimde düşebilir.

Google'ın indeksleme tarafında da mobil sürüm esas alınır. Yani sitenizin arama motoru için "asıl" hâli, sizin masaüstünde gördüğünüz hâli değildir.

Yavaşlığın en sık sebepleri

Pratikte karşılaşılan sorunların büyük kısmı birkaç başlıkta toplanıyor:

• Optimize edilmemiş görseller. Tek başına en yaygın sebep. Ekranda 600 piksel genişliğinde görünen bir görselin dosyası 3000 piksel olabiliyor. Modern formatlar (WebP, AVIF) aynı görsel kaliteyi belirgin biçimde daha küçük dosyayla verir.
• Boyutu belirtilmemiş görsel ve gömüler. Tarayıcı yüklemeden önce ne kadar yer kaplayacağını bilmezse, görsel geldiğinde alttaki içerik aşağı kayar. CLS sorunlarının klasik kaynağı.
• Üçüncü taraf betikleri. Analitik, sohbet balonu, reklam, ısı haritası, sosyal medya gömüsü... Her biri tek başına küçük görünür, toplamı sayfayı taşır. Üstelik bu betiklerin performansı sizin kontrolünüzde değildir.
• Render'ı bloklayan CSS ve JavaScript. Tarayıcı bazı dosyaları indirip işlemeden ekrana hiçbir şey çizemez.
• Yazı tipi yüklemesi. Özel fontlar yüklenirken metin ya görünmez ya da sonradan yerinden oynar.
• Sunucu yanıt süresi. İlk baytın gelme süresi yüksekse, ön taraftaki hiçbir iyileştirme bunu telafi etmez. Sorun barındırmada, veritabanında veya önbelleklemenin olmayışında olabilir.

Performans tarafında neye bakmalı

• Ana sayfayı ve en çok ziyaret edilen iki üç iç sayfayı ayrı ayrı ölçün — sadece ana sayfaya bakmak yanıltır.
• Mobil ölçümü masaüstünden bağımsız değerlendirin.
• Saha verisi varsa onu esas alın, yoksa laboratuvar verisiyle çalışın ama sonucu "kesin" saymayın.
• En büyük üç dosyayı bulun; genellikle hepsi görseldir.
• Sayfadaki üçüncü taraf betiklerini listeleyin ve her biri için "bu gerçekten gerekli mi?" sorusunu sorun.

İkinci katman: SEO analizi

Performans sitenin ziyaretçiye nasıl geldiğiyle ilgiliydi. Teknik SEO ise ziyaretçinin siteyi bulabilmesiyle ilgili.

Önce indekslenebilirlik

Bu, diğer her şeyin önkoşulu. Bir sayfa arama motoru tarafından taranamıyor ya da indekslenmiyorsa, o sayfadaki başlık da açıklama da işaretleme de hiçbir işe yaramaz.

Kontrol edilmesi gerekenler:

• Sayfa robots.txt ile taramaya kapatılmış mı?
• Sayfada noindex etiketi var mı? Bu en sinsi hatalardan biridir — geliştirme ortamında konulup canlıya taşınırken kaldırılmayı unutan bir noindex, siteyi aramadan tamamen silebilir.
• Sayfa doğru HTTP durum kodunu döndürüyor mu? Var olmayan bir adres 404 vermeli; "sayfa bulunamadı" yazıp 200 döndüren sayfalar arama motorunu yanıltır.
• Arama motoru sayfanın içeriğini gerçekten görebiliyor mu? İçerik yalnızca tarayıcıda çalışan bir betikle sonradan geliyorsa, taranan hâli boş olabilir.

Title ve meta description

Title hâlâ sayfadaki en önemli tek metin alanı. Her sayfa için benzersiz olmalı, sayfanın ne hakkında olduğunu açıkça söylemeli ve arama sonuçlarında kesilmeyecek uzunlukta kalmalı — pratikte 60 karakter civarı güvenli bir sınır. Aynı title'ın onlarca sayfada tekrarlanması yaygın ve kolay düzeltilebilir bir sorundur.

Meta description ise bir sıralama faktörü değildir. Etkisi başka yerde: arama sonucunda görünen bu iki satır, kullanıcının tıklayıp tıklamamasını belirler. Google bazen yazdığınız açıklamayı kullanmayıp sayfadan kendi seçtiği bir parçayı gösterir; bu normaldir ve bir hata işareti değildir.

Başlık hiyerarşisi

Başlık etiketleri (h1, h2, h3) sayfanın içindekiler tablosudur. Yazı tipini büyütmek için değil, yapıyı anlatmak için kullanılır.

Sağlıklı bir yapıda sayfada tek bir h1 bulunur, ana bölümler h2, alt bölümler h3 olur ve seviyeler atlanmaz. Yalnızca büyük görünsün diye h2 kullanılan bir cümle, hem arama motoru hem de ekran okuyucu kullananlar için sayfanın yapısını bozar.

Canonical

Aynı içerik birden fazla adresten açılabiliyorsa, arama motoru hangisini "asıl" sayacağını bilmek ister. Canonical etiketi bunu söyler.

En sık karşılaşılan çoğalma sebepleri:

• www ile www'suz sürümün ikisinin de açılması,
• http ile https'in ayrı ayrı yanıt vermesi,
• adres sonundaki eğik çizginin bazen olup bazen olmaması,
• takip parametreleriyle (kampanya etiketleri gibi) aynı sayfanın onlarca varyasyonunun oluşması.

Bunların her biri bağlantı değerini böler. Canonical, dağılan değeri tek adreste toplar.

robots.txt ve site haritası

robots.txt tarayıcılara nereye bakmamaları gerektiğini söyler. Bir sayfayı arama sonuçlarından gizlemek için kullanılan bir araç değildir — bunun için noindex gerekir.

Site haritası (sitemap.xml) ise yayında olan adreslerin listesidir. İyi bir site haritası yalnızca gerçekten indekslenmesini istediğiniz, 200 döndüren adresleri içerir. Silinmiş sayfaların, yönlendirilen adreslerin veya taslak içeriklerin site haritasında durması karışıklık yaratır.

Dahili bağlantılar

Sitenin kendi içindeki bağlantılar iki iş yapar: ziyaretçiye yol gösterir ve sayfalar arasında önem aktarır.

Bakılacak iki şey var. Birincisi yetim sayfalar: siteye hiçbir yerden bağlantı verilmemiş, yalnızca site haritasında var olan sayfalar. İkincisi bağlantı metni: "buraya tıklayın" yerine hedefi tarif eden bir ifade kullanmak, hem kullanıcıya hem arama motoruna ne bulacağını söyler.

Mobil uyumluluk

Mobil uyum artık sadece "sığıyor mu" sorusu değil. Yatay kaydırma oluşuyor mu, dokunma hedefleri parmakla basılabilecek büyüklükte mi, metin yakınlaştırmadan okunabiliyor mu, açılır menü kapatılabiliyor mu — hepsi bu başlığın altında.

Performans ile SEO ilişkisi: abartmadan

Bu konuda iki uç da yanlış.

Bir uçta "hız SEO'nun her şeyidir" iddiası var; doğru değil. Core Web Vitals sıralamada dikkate alınan sinyallerden biridir ama ağırlığı, içeriğin sorguya uygunluğunun yanında küçüktür. İçeriği zayıf ama hızlı bir sayfa, içeriği güçlü ve biraz yavaş bir sayfayı geçmez.

Diğer uçta "hız önemsiz" var; o da doğru değil. Hızın asıl etkisi sıralamada değil, sıralamaya geldikten sonra ortaya çıkar: sayfaya gelen ziyaretçi kalıyor mu, formu dolduruyor mu, aradığını bulabiliyor mu?

Sağlıklı çerçeve şu: hızı sıralama numarası için değil, gelen ziyaretçiyi kaybetmemek için düzeltin.

Üçüncü katman: yapılandırılmış veri analizi

İlk iki katman sayfanın gelmesiyle ve bulunmasıyla ilgiliydi. Üçüncüsü farklı bir soru soruyor: arama motoru sayfanızda ne olduğunu gerçekten anlıyor mu?

Schema.org ve JSON-LD nedir?

Bir insan sayfaya baktığında "bu bir hizmet sayfası, şurası fiyat, şu da iletişim bilgisi" diye ayırt eder. Makine için bunların hepsi metindir.

Schema.org, bu ayrımı yapabilmek için arama motorlarının ortaklaşa kullandığı bir sözlüktür. "Bu bir Kuruluş", "bu bir Makale", "bu bir Ürün" gibi türleri ve her türün hangi alanlara sahip olabileceğini tanımlar.

JSON-LD ise bu sözlüğü sayfaya eklemenin bugün önerilen yöntemidir. Sayfanın HTML'i içine, görünmeyen ayrı bir blok olarak yerleştirilir. Avantajı şu: işaretleme sayfanın görsel yapısına karışmaz. Tasarımı değiştirdiğinizde işaretleme bozulmaz, çünkü ikisi birbirine bağlı değildir.

Arama motorları bunu neden kullanıyor?

Üç sebep var:

• Belirsizliği azaltmak. Sayfadaki "24" sayısının fiyat mı, saat mi, adet mi olduğunu tahmin etmek yerine, işaretlemeden okumak daha güvenilir.
• Zengin sonuçlar. Bazı içerik türlerinde arama sonucunda ek bilgi gösterilebilir. Bu görünürlüğü artırır.
• Varlıkları ilişkilendirmek. Bir kuruluşun adı, logosu, adresi ve sosyal hesapları işaretlenmişse, arama motoru bunların hepsinin aynı kuruluşa ait olduğunu tahmin etmek zorunda kalmaz.

Burada net olmakta fayda var: yapılandırılmış veri doğrudan bir sıralama faktörü değildir. Sayfanızı yukarı taşımaz. Yaptığı şey, sayfanın doğru anlaşılmasını ve uygun durumlarda daha zengin görünmesini sağlamaktır.

Hangi tür nerede kullanılır?

Çoğu site için gereken tür sayısı sanıldığından az:

• Organization — Kuruluşun kendisi: ad, logo, iletişim bilgisi, resmi sosyal medya hesapları. Genellikle ana sayfada tanımlanır ve site genelinde tektir. Aynı site içinde birbiriyle çelişen birden fazla Organization tanımı yaygın bir hatadır.
• Article — Blog yazıları, rehberler, haberler. Başlık, yayın tarihi, güncelleme tarihi, yazar ve kapak görseli alanlarını taşır.
• Product — Yalnızca gerçekten satılan bir ürün varsa. Fiyat ve stok durumu işaretlenecekse bunların sayfada da görünmesi ve güncel olması gerekir.
• BreadcrumbList — Sayfanın site içindeki konumu. Uygulaması en kolay, getirisi en istikrarlı türlerden biridir; arama sonucunda uzun adres yerine okunabilir bir yol gösterilmesini sağlar.
• FAQPage — Sayfada gerçekten bir soru-cevap bölümü varsa. Burada bir ayrıntıyı bilmekte fayda var: Google 2023'te SSS zengin sonuçlarını büyük ölçüde sınırladı ve çoğu site için artık bu görünümü göstermiyor. İşaretleme hâlâ sayfanın anlaşılması açısından değerli, ancak "SSS ekleyince arama sonucunda açılır liste çıkar" beklentisi bugün için gerçekçi değil.

En sık yapılan işaretleme hataları

• Sayfada olmayan bilgiyi işaretlemek. Bu kuralın en önemlisi. Yapılandırılmış veri, sayfada zaten bulunan bilgiyi tarif eder. Sayfada yazmayan bir fiyatı ya da gösterilmeyen bir değerlendirme puanını işaretlemek politika ihlalidir.
• Olmayan yorum ve puanları işaretlemek. Uydurma değerlendirme verisi, manuel işlem alma ihtimali en yüksek hatalardan biridir.
• Şablonu kopyalayıp alanları güncellememek. Başka bir siteden alınan bir JSON-LD bloğunun içindeki eski kuruluş adı ya da eski adres sayfada öylece kalır.
• Eski ve yeni yöntemi karıştırmak. Sayfada hem HTML içine gömülü eski tip işaretleme hem de JSON-LD varsa ve ikisi farklı şey söylüyorsa, ortaya çelişki çıkar.
• Bilgiyi güncel tutmamak. İşaretleme bir kere yazılıp unutulan bir şey değildir. Değişen telefon numarası ya da kaldırılan bir hizmet, işaretlemede kalmaya devam eder.

Yapılandırılmış veri nasıl kontrol edilir?

Üç farklı kontrol noktası var ve üçü farklı sorulara cevap verir:

• Zengin Sonuç Testi — Bu sayfadaki işaretleme Google'ın desteklediği bir zengin sonuç üretebilir mi?
• Schema Markup Validator — İşaretleme Schema.org sözlüğüne göre geçerli mi? Google'ın desteklemediği türleri de kontrol eder.
• Search Console — Asıl önemlisi bu. Yukarıdaki iki araç tek bir sayfaya bakar; Search Console ise sitenin tamamında zaman içinde biriken hataları gösterir. Tek sayfada görünmeyen bir şablon hatası burada yüzlerce sayfada ortaya çıkar.

Sırayla ne yapmalı?

Kendi sitenizin analizine nereden başlayacağınızı bilmiyorsanız, şu sıra işe yarar. Üstten aşağı ilerleyin — her adım bir öncekinin üzerine biniyor:

1. Sitenin arama motoruna kapalı olmadığını doğrulayın — robots.txt ve noindex kontrolü.
2. Ana sayfa dâhil birkaç önemli sayfanın gerçekten indekslendiğini Search Console'dan teyit edin.
3. Tek bir asıl adres belirleyin (www var mı yok mu, https) ve diğer tüm varyasyonların oraya yönlendiğini doğrulayın.
4. Title'ların benzersiz olduğunu kontrol edin; tekrar edenleri düzeltin.
5. En çok ziyaret edilen üç sayfayı mobil ölçümle test edin.
6. Bu sayfalardaki en büyük dosyaları bulun; büyük ihtimalle görsellerdir.
7. Üçüncü taraf betiklerini listeleyip gereksizleri kaldırın.
8. Site haritasının yalnızca yayında olan, 200 döndüren adresleri içerdiğinden emin olun.
9. Organization ve BreadcrumbList işaretlemesini ekleyin; içerik sayfalarına Article ekleyin.
10. Değişikliklerden sonra Search Console'u birkaç hafta takip edin.

Bu listenin ilk dört maddesi genellikle en büyük farkı yaratır ve hiçbiri büyük bir teknik yatırım gerektirmez.

Analiz tek seferlik bir iş değil

Bir denetim yapıp sorunları düzelttiğinizde iş bitmiş olmaz. Site canlı bir şeydir: yeni sayfa eklenir, tasarım güncellenir, bir eklenti kurulur, bir görsel yanlış boyutta yüklenir.

İki pratik alışkanlık yeterli. Birincisi, gözle görülür her değişiklikten sonra en önemli birkaç sayfayı yeniden kontrol etmek. İkincisi, bir iyileştirmenin etkisini ölçerken aceleci olmamak — gerçek kullanıcı verisi 28 günlük pencerede toplandığı için, dün yapılan bir düzeltmenin sonucunu bugün göremezsiniz.

Biz bu konuları nasıl ele alıyoruz

Bu rehberde anlatılanlar bizim için bir projeden sonra yapılan denetim işi değil; projenin kendisinin parçası.

Bir web platformu ya da web sitesi geliştirirken içerik yapısı, adres düzeni, başlık hiyerarşisi, canonical kuralları, site haritası ve yapılandırılmış veri baştan kurulur. Sebebi basit: bunlar sonradan eklenen şeyler olduğunda hem daha pahalıya mal olur hem de yarım kalır. Adres yapısı yanlış kurulmuş bir sitede canonical'ı sonradan düzeltmek, baştan doğru kurmaktan çok daha zahmetlidir.

Performans tarafında da yaklaşım aynı: görsellerin nasıl işleneceği, hangi betiklerin sayfaya gireceği ve içeriğin nasıl sunulacağı, tasarım tamamlandıktan sonra düşünülen konular değil.

Bu teknik katmanlarda profesyonel desteğe ihtiyaç duyuyorsanız web platformu ve web sitesi geliştirme hizmetimize göz atabilirsiniz.

İleride: kendi kontrolünüzü yapabileceğiniz araçlar

Bu rehberde anlatılan kontrollerin çoğu, doğru aracı bilen biri için birkaç dakikalık iş. Bilmeyen biri içinse nereden başlayacağını kestirmek bile zor.

İçerik Yöneticisi olarak, web sitesi sahiplerinin kendi sitelerini kendilerinin kontrol edebileceği ücretsiz araçlar geliştirmeyi planlıyoruz. Bu henüz bir plan — hangi kontrollerin ilk sırada olacağı ve ne zaman yayınlanacağı konusunda verilmiş bir söz yok.

O gün gelene kadar bu rehberdeki sıra, elinizdeki siteyi kendi başınıza değerlendirmeniz için yeterli.