Kurumsal site mi, web uygulaması mı?
Kurumsal site, içeriği okunmak için var olan sitedir: hizmetler, ürün tanıtımı, kurum bilgisi, iletişim, belki bir bilgi merkezi. Kullanıcı hesabı, sepet ya da müşteri paneli gerektiği anda iş bir web uygulamasına dönüşür ve başka bir mimari ister. Bu ayrımı başta yapmak, yarı yolda araç değiştirmekten ucuzdur.
| İhtiyaç | Uygun yaklaşım |
|---|---|
| Hizmet ve ürün tanıtımı, SSS, bilgi merkezi, iletişim | Statik site |
| Haftada birkaç yazı yayımlayan, teknik olmayan bir ekip | Statik site ve başsız (headless) bir içerik arayüzü ya da WordPress gibi bir içerik yönetim sistemi |
| İletişim formu, bülten kaydı | Statik site ve bir form servisi ya da küçük bir sunucusuz (serverless) fonksiyon |
| Üyelik, sepet, ödeme, stok, yönetim paneli | Web uygulaması: özel yazılım ve web uygulaması geliştirme |
Neden çoğu kurumsal site için statik HTML öneriyoruz?
Statik site, sayfaların ziyaretçi istemeden önce, yayın sırasında hazır HTML dosyalarına dönüştürüldüğü sitedir. Sunucu her istekte veri tabanına gitmez, şablon işlemez; dosyayı olduğu gibi gönderir. Pratikte bunun anlamı şu:
- Hız. Sunucunun ilk yanıt süresi (TTFB) neredeyse yalnızca ağ mesafesine ve CDN'e bağlıdır.
- Bakım. Yönetim paneli, eklenti ve veri tabanı olmadığı için saldırı yüzeyi dardır. "Bu ayın eklenti güncellemeleri" diye bir iş kalmaz.
- Taşınabilirlik. Çıktı düz dosyalardır; sağlayıcı değiştirmek dosyaları kopyalamaktır.
- Geçmiş. Kaynak dosyalar Git'te tutulduğunda her değişiklik tarihiyle ve açıklamasıyla kayda geçer. Bir metnin ne zaman değiştiği bir gün tartışılırsa, web sitesi incelemesinde ilk bakılacak kayıt budur.
Sınırları da açık. Form, site içi arama ya da kişiye özel içerik bir dış servis veya küçük bir fonksiyon gerektirir. Barındırmanın koşullarını okumak gerekir: GitHub Pages örneğin yayımlanan siteyi 1 GB ile sınırlar, aylık 100 GB'lık yumuşak bir bant genişliği sınırı koyar ve ağırlıklı olarak ticari işlem yürüten siteler için kullanılmamasını ister. Yanıt başlıklarını yapılandırma seçeneği de sunmaz; md9.net'in HTML yanıtları cache-control: max-age=600 ile geliyor ve farklı bir başlık gerekirse önündeki CDN katmanında eklenmesi gerekiyor.
Bizce WordPress kötü bir araç değil; ama ayda bir değişen on beş sayfalık bir sitenin, her hafta güncelleme bekleyen bir panel taşımasına gerek yok.
Ölçülebilir bir örnek: md9.net nasıl kuruldu?
Okuduğunuz site bu yaklaşımla kuruldu; herkes kendi tarayıcısında ölçebilir. Sayfa kaynakları, başında JSON meta bilgisi olan HTML parçalarıdır. Hiçbir dış pakete bağımlı olmayan küçük bir Python betiği bu parçaları şablona yerleştirir, GitHub Pages'e giden dosyaları üretir ve yayından önce her sayfayı denetler.
| Katman | md9.net'te | Nasıl kontrol edilir |
|---|---|---|
| HTML | İçerik sayfalarında JavaScript yok. Yalnızca tarayıcı araçları betik yükler, o da defer ile. | Sayfa kaynağında metnin tamamı görünür. |
| CSS | Tek stil dosyası küçültülüp her sayfanın <head> bölümüne gömülüyor, ayrı istek yok. | Ağ sekmesinde tek belge isteği. |
| Yazı tipi ve logo | Sistem yazı tipleri, web font indirmesi yok. Logo satır içi SVG. | Ağ sekmesinde font ya da logo isteği yok. |
| Boyut | Tipik bir hizmet sayfası yaklaşık 49 KB HTML; gzip ile 15 KB civarı. | Ağ sekmesindeki aktarılan boyut. |
| Denetim | Uzunluğu sınır dışında kalan başlık ve açıklama uyarı verir. Başka sayfayla aynı başlık, kırık iç bağlantı ve alt metinsiz görsel hatadır; hata varsa hiçbir dosya yazılmaz. | Üretim betiğinin denetim bölümü. |
| Arama altyapısı | Her sayfada JSON-LD grafiği ve canonical; bölümlere ayrılmış site haritaları; llms.txt ve llms-full.txt. | Ayrıntısı teknik SEO ve GEO sayfalarında. |
PageSpeed Insights'a bu sayfanın adresini yazarak laboratuvar ölçümünü kendiniz alabilirsiniz. Alan verisi, yani Chrome kullanıcılarından toplanan gerçek ölçüm (CrUX), sayfa yeterli ziyaret aldıktan sonra görünür; yeni bir sitede boş gelebilir. Tarihi ve cihaz profili yazılmamış hız puanını rapora koymuyoruz.
Semantic HTML neden önemli?
Anlamsal (semantic) HTML, sayfadaki her parçayı ne olduğunu söyleyen öğeyle işaretlemektir: bölüm başlığı h2, gezinme nav, tarih time (datetime="2026-09-27"), tablo başlığı th. Arama motoru, ekran okuyucu ve yapay zekâ tarayıcısı sayfayı bu öğeler üzerinden çözer. Görünüşü aynı iki sayfadan biri div yığınıysa, makine için ikisi aynı sayfa değildir.
- Sayfada tek
h1; başlıklar seviye atlamadan iner. - Asıl içerik
main, menü etiketli birnaviçinde; sayfa yolu (breadcrumb) sıralı listedir. - Tıklanan her şey
aya dabutton.divöğesine tıklama olayı bağlamak klavyeyle ulaşılamayan, tarayıcıların bağlantı saymadığı bir düğme üretir. - Mobil menüyü JavaScript'siz
detailsöğesiyle kuruyoruz; menü kapalıyken de bağlantılar HTML'de durur. <html lang="tr">. Google dili metinden kendisi belirler, ama ekran okuyucu telaffuzu bu özniteliğe göre seçer.
Core Web Vitals: LCP, INP ve CLS hedefleri
Core Web Vitals, Google'ın sayfa deneyimini ölçtüğü üç alan metriğidir. İyi sayılmak için gerçek ziyaretlerin 75. yüzdeliğinde, mobil ve masaüstünde ayrı ayrı, üçünün de eşiğin altında kalması gerekir.
| Metrik | Neyi ölçer | İyi eşik | Kurumsal sitelerde tipik sebep |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Görünen alandaki en büyük içerik öğesinin ekrana gelme süresi | ≤ 2,5 s | Ana sayfadaki büyük kapak görseli ya da slayt, geç yüklenen web font |
| INP (Interaction to Next Paint) | Tıklama, dokunma ya da tuşa basmadan sonra ekranın güncellenmesine kadar geçen süre | ≤ 200 ms | Sohbet balonu, etiket yöneticisi, reklam ve analiz betikleri |
| CLS (Cumulative Layout Shift) | Yükleme sırasında içeriğin beklenmedik kayması | ≤ 0,1 | Boyutu verilmemiş görseller, sonradan yerleşen çerez bandı |
INP, 12 Mart 2024'te FID'nin yerine Core Web Vital oldu. Lighthouse gibi laboratuvar araçları INP'yi ölçemez, çünkü ortada gerçek bir kullanıcı etkileşimi yoktur. Geliştirme sırasında toplam engelleme süresine (TBT) bakarız; asıl sonucu alan verisinde görürüz.
Hızın sıralamadaki yerini abartmamak gerekir; Google için alaka önce gelir. Hızın asıl getirisi, sayfayı açan kişinin beklemeden okumaya başlamasıdır.
Sayfa hızı optimizasyonunda sıra
Kurumsal sitelerdeki yavaşlığın çoğu sunucudan değil sayfanın kendisinden çıkar. Uyguladığımız sıra:
- Üçüncü taraf betikleri tek tek sayarız ve her biri için "bu olmasa neyi kaybederiz" diye sorarız. INP sorunlarının çoğu buradan çıkar.
- LCP öğesini belirleriz. Görselse AVIF ya da WebP'ye çevrilir,
fetchpriority="high"alır ve tembel yüklenmez;loading="lazy"yalnızca ekranın altındaki görsellere verilir. - Her
imgöğesinewidthveheightyazarız. Tarayıcı yeri önceden ayırır, sayfa kaymaz. - CSS'in kritik kısmını sayfaya gömeriz. Küçük sitelerde tamamı gömülebilir; bu sitede de öyle.
- Yazı tipi: mümkünse sistem yazı tipleri. Web font şartsa yalnızca kullanılan ağırlıklar,
font-display: swapve önceden yükleme. - Önbellek: görseller ve dosyalar uzun süre, HTML kısa süre önbellekte tutulur ki güncelleme gecikmeden görünsün.
Tipik bir durum: ana sayfada her biri 1–2 MB beş fotoğraflı bir slayt, köşede bir sohbet balonu, sayfa açıldıktan sonra aşağıdan kayan bir çerez bandı. Slaytı boyutları belirli tek bir görsele indirmek LCP'yi, sohbet betiğini ilk etkileşime kadar ertelemek INP'yi, bandın yerini baştan ayırmak CLS'yi düzeltir. Üçü de tasarım kararıdır; sunucu hızıyla ilgileri yoktur.
Mobil uyumluluk: Google sitenin mobil sürümünü okur
Google, dizine ekleme ve sıralama için sitenin akıllı telefon tarayıcısıyla alınan mobil sürümünü kullanır. Masaüstünde görünen ama mobilde kaldırılan içerik, arama açısından yok hükmündedir.
- Mobil ve masaüstü sürüm aynı içeriği, başlık ve açıklamayı, aynı yapılandırılmış veriyi taşımalı; duyarlı (responsive) tasarım bu yüzden ayrı mobil siteden az sorun çıkarır.
- Birincil içerik kaydırma, tıklama ya da yazma gibi bir etkileşimle yüklenmemeli; Google böyle içeriği yüklemez. Akordeon ya da sekme içindeki metin HTML'de durduğu sürece sorun yoktur.
- Geniş tablolar sayfayı yana taşırmamalı. Bu sitede her tablo, yatay kaydırılabilen bir kabın içinde.
Testi gerçek bir telefonda ve yavaş bir bağlantıyla yaparız; tarayıcının cihaz öykünmesi bunun yerini tutmaz.
Çok dilli sitelerde hreflang nasıl kurulur?
hreflang, aynı sayfanın farklı dil ya da bölge sürümlerini arama motoruna bildiren işarettir; doğru kurulduğunda arayan kişiye kendi dilindeki sürüm gösterilir. Kuralları azdır ama affetmez:
- Her sürüm hem kendini hem diğer bütün sürümleri listeler. Karşılıklı olmayan işaret yok sayılabilir.
- Kod ISO 639-1 dil kodudur (
tr,en), istenirse ülkeyle birlikte (tr-TR). Yalnızca ülke kodu geçersizdir. - Eşleşmeyen diller için
x-defaulttanımlanır. - URL'ler tam ve kanonik olmalı. hreflang'in gösterdiği sayfa canonical ile başka bir sayfayı işaret ediyorsa iki sinyal çelişir.
- HTML
linköğesi, HTTP başlığı ya da site haritası: Google için üçü eşdeğerdir.
Bu sitede çok dilli olan bölüm UDF Mobil (md9) tanıtım sayfalarıdır. Türkçe ve İngilizce sürümler birbirini gösterir, x-default İngilizce sürümdür; aynı ilişki hem sayfaların head bölümünde hem site haritasında yazılıdır:
<link rel="alternate" hreflang="tr" href="https://www.md9.net/udfmobil/tr/">
<link rel="alternate" hreflang="en" href="https://www.md9.net/udfmobil/en/">
<link rel="alternate" hreflang="x-default" href="https://www.md9.net/udfmobil/en/">En sık hata, ziyaretçiyi IP adresine ya da tarayıcı diline göre otomatik olarak başka bir dil sürümüne yönlendirmektir. Google'ın taramalarının çoğu ABD'den yapılır; otomatik yönlendirme Türkçe sürümün hiç taranmamasına yol açabilir. Dil seçimini görünür bir bağlantıyla kullanıcıya bırakın.
Nasıl çalışıyoruz?
- Sayfa planı. Her sayfanın hedef aramalarını ve komşu sayfalarla sınırını bir plan dosyasına yazarız; iki sayfa aynı aramayı hedeflemez.
- Adres ve menü yapısı. Küçük harfli, Türkçe karakterleri sadeleştirilmiş, tireli adresler (
/yazilim/teknik-seo/); sonda eğik çizgi; iki üç seviyeden derin olmayan bir menü. - Şablon ve içerik. Önce içerik şablonu (başlık, ilk paragrafta cevap, bölümler, SSS), sonra görsel tasarım. Metinleri siz yazarsınız ya da birlikte yazarız; başlık yapısını ve teknik doğruluğu biz kontrol ederiz.
- Denetim ve ölçüm. Bağlantılar, başlıklar, yapılandırılmış veri ve hız; sonuçlar tarihiyle kayda geçer.
- Yayın. Search Console, Bing ve Yandex kayıtları, site haritasının gönderilmesi, eski adreslerden 301 yönlendirmeleri.
Test ortamındaki noindex etiketinin canlıya taşınması. Eski sitenin adreslerinin yenilerine yönlendirilmemesi. Alan adının ve barındırma hesabının kurumun değil ajansın adına açılması. Sonuncusu teknik değil sözleşme sorunudur ve çoğu zaman ayrılık anında fark edilir. Belirsiz şartnamenin ve kabul kriteri eksikliğinin nereye varabildiği: yazılım projesi teslim uyuşmazlığı.
Teslimde neler var?
- Kaynak dosyalar, üretim komutu ve kurulum notuyla sizin Git deponuzda.
- Alan adı, DNS ve barındırma hesabı sizin adınıza.
- Ölçüm kaydı: sayfa, tarih, cihaz profili, LCP, CLS ve TBT değerleri.
- Sitede çalışan üçüncü taraf servislerin listesi ve her birinin hangi veriyi aldığı. KVKK aydınlatma metnini hazırlayacak hukukçunun ihtiyaç duyduğu teknik girdi budur.
- Düzenleme kılavuzu: yeni sayfa ekleme, tarih güncelleme, görsel boyutlandırma.