Web sitesi yaptırmadan önce işin kapsamını netleştirmek
Web sitesini kurarken belirlememiz gerek ilk adım amaçtır. Bu amaca göre hedef kitleyi berlileriz. Bu hedef kitleye göre içeriği, kurumsal dili ve tasarım uyumunu berlileriz. SEO ve güvenlik tarafını da planlarız. Ayrıca bizim için en kolay olan kısım güçlü alt yapıyı inşa ederiz. Mobil uyum, Hız, Zengin Snippet vs. hepsinin uygun olduğu yapıyı size sunarız.
1. Hedefi ve kullanıcıyı doğru tanımlamak
Belirsiz hedef, web sitesi projelerinde sık karşılaştığımız sorundur. Yazılım firmasında süreç, sağlık tarafında güven, eğitimde ise başarı daha erken görünmelidir. Kimin için yazdığımız belli değilse, cümleler de boşta kalır.
Yaş, şehir, sektör tek başına yetmez. Karar verme süresi, fiyat hassasiyeti, güven arayışı ve mobil kullanım alışkanlığı da görülmelidir. Örneğin sağlıkta kullanıcı 30 saniyede iletişim bilgisi arar; yazılım tarafında “nasıl çalışıyor?” sorusu öne çıkar. Biz buna göre sayfa sırasını değiştiririz.
2. Alan adı ve marka adı uyumunu kontrol etmek
Alan adı kısa olmalı, yazımı kolay olmalı, telefonda tek seferde söylenebilmelidir. Türkçe karakterli, uzun ve rakam yüklü adresler sık karışır. Geçen ay bir projede marka adı ile alan adı farklı yazıldığı için e-posta adresi üç kez düzeltilmişti. Küçük detay, iş büyütmüştü.
Marka adı, sosyal medya hesabı ve web adresi aynı çizgide durmalıdır. Farklı isimler kullanınca kullanıcı tereddüt eder; “aynı firma mı?” sorusu başlar. Özellikle yeni kurulan markalarda bu uyum ilk görüşmede güven sağlar; sonradan toparlamak zor olur.
3. Mobil uyumluluğu şart görmek
Telefon ekranında bozuluyorsa masaüstü tasarımının bir anlamı kalmaz. Gelenlerin çoğu siteye telefondan bakıyor; buton küçükse, menü kapanmıyorsa ya da yazı sıkışmışsa hemen çıkıyor. Biz testleri önce dar ekranda açarız, sonra büyük ekrana bakarız.
Mobil uyum yalnızca ekranı küçültmek değildir. Dokunma alanı yeterli olacak, metin rahat okunacak, yatay kaydırma çıkmayacak. Bir e-ticaret işinde 44 pikselden küçük butonlar yüzünden sepete ekleme oranı düşmüştü; başparmakla yanlış yere dokunuluyordu. Telefonda kullanım, gerçekten denenmeden anlaşılmaz.
4. Hız performansını baştan planlamak
Yavaş açılan sayfada iyi tasarım da gölgede kalır. Büyük görseller, gereksiz eklentiler, ağır animasyonlar ve dağınık kod en sık gördüğümüz sebepler. Bir kurumsal sitede 9 saniyelik açılış süresi vardı; görselleri sıkıştırınca 3 saniyenin altına indi. Fark hemen hissedildi.
Hız yalnız kullanıcıyı değil, arama görünürlüğünü de etkiler. Sunucu seçimi, önbellekleme, kullanılmayan dosyaların temizlenmesi ve görsel boyutlarının doğru ayarlanması bu yüzden ilk aşamada yapılmalıdır. Sonradan toparlamak mümkün, ama daha pahalıdır.
5. İçerik yapısını tasarımla birlikte düşünmek
İçeriği sona bırakınca tasarım, boşluk doldurma işine döner. Metin kısa ise de, uzunsa da, sayfa düzeni değişir. Biz içerik gelmeden ana sayfayı kilitlemeyiz; başlık, açıklama ve çağrı düğmesinin yeri metne göre belirlenir.
Sayfaların akışı kullanıcının sorusuna göre kurulmalı: ana sayfa, hizmet sayfası, hakkımızda, referans, sık sorulan sorular, iletişim. Bir sağlık projesinde randevu sayfası ana menüde gizli kalmıştı; kullanıcı bulamayınca form oranı düşmüştü. Düzen, doğrudan davranışı etkiler.
6. Kurumsal dili ve tonu doğru kurmak
Metinlerin tonu, kurumun nasıl algılanacağını belirler. Fazla samimi dil de sert resmiyet de güveni düşürür. Açık, sade ve işi bilen bir ses daha iyi çalışır; ziyaretçi cümleyi okurken “bu ekip ne yaptığını biliyor” hissini almalıdır.
Aynı tonun her sayfada korunması gerekir. Ana sayfada başka, hizmetlerde başka, iletişimde başka konuşulursa site dağılır. Biz projelerde bunu sıkı tutarız; ana sayfadaki netlik iletişim sayfasına kadar aynı kalır. Bir bölümde abartı varsa, diğer bölümde de onu düzeltmek yetmez.
7. Tasarımın markayla uyumunu değerlendirmek
Tasarım renk seçimi değildir yalnız. Boşluk, tipografi, ikon kullanımı ve görsel sertlik ya da yumuşaklık markanın karakterini taşır. Çocuk odaklı bir marka ile hukuk bürosu aynı görsel dili kullanınca ikisi de zayıf görünür. Hazır şablon burada çoğu kez kısa kalır.
Logonun çevresindeki boşluk, başlık kalınlığı, buton rengi ve görsellerin tonu aynı çizgide olmalı. Geçen sene bir sağlık markasında mavi yerine fazla parlak turuncu kullanılmıştı; ekip geri adım attı, çünkü güven duygusu sertleşmişti. Ayrıntı gibi görünür, etkisi büyüktür.
8. Yönetim panelinin kullanım kolaylığını sorgulamak
Site teslim alındıktan sonra işler bitmez; asıl kullanım başlar. Metin değişecek, kampanya açılacak, yeni referans eklenecek, telefon numarası güncellenecek. Panel karmaşıksa her değişiklik için teknik destek gerekir. Bu da günlük işi yavaşlatır.
Menü yapısı anlaşılır mı, görsel yükleme kolay mı, SEO alanları girilebiliyor mu? Bunları proje başında sorarız. İçerik eklemek için kod açmak gerekiyorsa, sistem ağır demektir. Siz de paneli kullanacak olan kişiyi düşünün; işi o devralacaksa, düzen sade olmalı.
9. Güvenlik önlemlerini ihmal etmemek
Site canlıya çıktığında güvenlik ikinci plana atılmaz. SSL, güçlü şifre, yetki sınırı, yedekleme ve güncel yazılım yapısı temel konulardır. Bir giriş panelinde zayıf parola yüzünden iki kez deneme botu kilidi kurmak zorunda kaldık; küçük açık, gereksiz uğraş çıkardı.
Yedek nerede tutuluyor, ne sıklıkla alınıyor, geri yükleme deneniyor mu? Bunlar net değilse güvenlik yarım kalır. Özellikle giriş yapılan sistemlerde sonradan ortaya çıkan açıklar sık olur; bakım yapılmayan site, sessizce risk biriktirir.
10. SEO altyapısını kurulum aşamasında hazırlamak
SEO’yu yayından sonraya bırakırsanız sayfaları tekrar açıp düzeltmek gerekir. Başlık yapısı, açıklama metinleri, temiz adresler, iç bağlantılar ve görsel alt metinleri baştan düşünülmelidir. Bir siteyi sonradan düzeltmek, en azından iki kat iş çıkarır.
Arama motoru için yazılmış gibi duran metinleri değil, okunabilir yapıyı tercih ederiz. Teknik SEO, sayfa hızı, mobil uyum ve yerel bilgiler birlikte işler. Örneğin şehir adı yazılmayan bir hizmet sayfası, yerel aramalarda geride kalabilir. Kurulumda atlanan ayrıntı, yayından sonra görünür olur.
11. İçerik yönetiminde esneklik istemek
İşletme büyüdükçe sayfa yapısı değişir; yeni hizmet gelir, yeni şube açılır, kampanya çıkar. Sıkışık bir sistemde bu güncellemeler için yeniden yazılım gerekir. Biz modüler yapı tercih ediyoruz; bloklar yer değiştirebilmeli, yeni alanlar eklenebilmelidir.
Esneklik denetimsizlik değildir. Düzen korunarak içerik eklenir. Bir projede yeni ürün kategorisi açmak için altı sayfa yeniden yazılmıştı; çünkü yapı baştan kilitlenmişti. Teknik olarak sağlam ama pratikte dar bir düzen, ilk ay rahatlatır; sonra sıkıştırır.
12. Referanslar, örnekler ve sosyal kanıt alanlarını yerleştirmek
Ziyaretçi sözden önce iş görmek ister. Bitmiş projeler, müşteri yorumu, vaka örneği, sayısal sonuç gibi parçalar güveni yükseltir. Bir teklif görüşmesinde önceki işleri göstermediğimizde tereddüt artıyor; bunu defalarca gördük. İnsan, özellikle benzer işi gördüğünde karar veriyor.
Burada abartı değil, doğrulanabilir bilgi çalışır. Proje adı, sektör, ne yapıldığı ve varsa sayı açık yazılmalıdır. “Harika sonuçlar” gibi boş ifadeler yerine gerçek veri kullanılmalıdır. Örneğin 8 haftada tamamlanan bir kurulum, 4 sayfalık hizmet yapısı ya da yüzde 35 artış gibi veriler daha etkilidir.
13. İletişim kanallarını görünür ve erişilebilir yapmak
Telefon, e-posta, adres ve harita bağlantısı saklanmamalı. Kullanıcı iletişim kurmak istiyorsa aradığı alanı hızlı bulmalı. İyi hazırlanmış site, gizlenmiş iletişim yüzünden iş kaybetmez. Biz iletişim düğmesini çoğu projede ana görünümde tutarız.
Form alanı çok uzun olursa bırakılır, çok kısa olursa eksik bilgi gelir. Ad, e-posta, telefon ve mesaj çoğu iş için yeterlidir. Bir sağlık markasında sadece ad-soyad ve telefonla dönüş oranı daha iyi olmuştu; fazla alan sormadık, çünkü insanlar acele ediyordu.
14. Yasal ve kurumsal sayfaları eksiksiz hazırlamak
Gizlilik politikası, çerez bildirimi, kullanım şartları ve gerekiyorsa mesafeli satış metni eksik kalmamalı. Veri toplayan, form kullanan ya da satış yapan sitelerde bu sayfalar ayrı önem taşır. Ziyaretçi kendi verisinin nerede ve nasıl saklandığını sayfada net görmeli.
Kurumsal sayfalar yalnız mevzuat işi değildir; düzeni de gösterir. Kopyala-yapıştır hazırlanmış metinler hemen belli olur. Bir e-ticaret işinde çerez bildirimini eksik bıraktığımızda test aşamasında uyarı aldık; sonra içerik yeniden düzenlendi. Böyle küçük bir eksik bile dikkat çeker.
15. Bakım, destek ve güncelleme planını baştan konuşmak
Site yayına alınca iş bitmez. Güncellemeler gelir, güvenlik yamaları çıkar, içerik değişir, yeni kampanyalar açılır. Destek süresi konuşulmadığında ilk sorun çıktığında herkes birbirine bakar. Biz bakım kapsamını en başta yazılı hale getiririz.
Hangi iş bakım içinde, hangi iş yeni geliştirme sayılacak, müdahale süresi ne olacak? Bunlar netse tartışma azalır. Web sitesi teslim edilen dosya değildir; yaşayan bir araçtır. Desteksiz bırakılan projelerde küçük arızalar bile haftalarca bekleyebilir.
Hazır tema mı, özel yazılım mı?
| Başlık | Hazır tema | Özel yazılım |
|---|---|---|
| Kurulum süresi | Daha hızlı başlar | Planlama ve geliştirme uzun sürer |
| Esneklik | Şablon sınırları içindedir | İş akışına göre şekillenir |
| Bakım | Hazır yapı bazı alanlarda sınır koyar | Kontrol proje bazında kurulur |
| Farklılaşma | Benzer sitelerle aynı görünüme yaklaşabilir | Markaya özel görünüm sağlar |
| Uzun vadeli uyum | Büyüdükçe yetersiz kalabilir | Yeni ihtiyaçlara göre genişletilebilir |
Teklif alırken sorulması gereken sorular
Fiyat tek başına karar verdirmez. Kullanılacak teknoloji, içerik kimden gelecek, revizyon sayısı kaç, destek ne kadar sürecek, güvenlik ve bakım dâhil mi? Bunlar sorulmadan verilen teklif eksik kalır. Sadece rakam görmek, işin yarısını görmektir.
Bir teklifin içine sunucu, lisans, eklenti, içerik girişi ve bakım giriyorsa maliyet doğal olarak değişir. Geçen ay iki teklif arasında 18 bin lira fark vardı; biri sadece kurulum, diğeri bir yıllık destek içeriyordu. Karşılaştırma yapılırken kapsam okunmalı.
Kurulum sırasında yapılan sık hatalar
En sık hata, ihtiyaç yerine görüntüden başlamak. Kullanıcı ne arıyor belli olmadan yapılan tasarım kısa sürede revize edilir. Bir başka hata da her şeyi ana sayfaya yüklemek. Ana sayfa kapı gibi çalışmalı; depo gibi değil.
Hız, SEO, güvenlik ve mobil kullanım sanki sonra eklenirmiş gibi bırakılıyor. Bu yaklaşım baştan yanlış. Stok görseli gelişigüzel kullanmak, fontları karıştırmak, butonları küçültmek, iletişimi görünmez yapmak da sık yapılan hatalar. Her biri kullanıcıyı soğutur.
İçerik tesliminde dikkat edilmesi gerekenler
Metin, görsel ve video tek tek kontrol edilmeli. Eski numara, yanlış adres, düşük çözünürlüklü dosya ve yazım hatası sık çıkar. Canlıya geçmeden önce her bağlantıyı açar, formu dener, sayfa kaymasını telefonda kontrol ederiz. Bir saatlik kontrol, sonradan iki günlük işi önler.
İçerik güncel değilse site güçlü görünmez. Kapanmış kampanya, eski referans, çalışmayan link hemen fark edilir. Teslim sonrası düzenli içerik kontrolü yapılması gerekir; yoksa site iyi kurulmuş olsa da kısa sürede yıpranmış görünür.
Performans, güvenlik ve içerik için kontrol listesi
- Sitenin amacını en başta netleştiriyoruz.
- Alan adının marka ile uyumunu kontrol ediyoruz.
- Mobil uyumu tüm ekranlarda test ediyoruz.
- Sayfa açılış süresini ölçüyoruz.
- Yönetim panelinin kolay kullanılıp kullanılmadığını inceliyoruz.
- SSL, yedekleme ve yetki düzenini doğruluyoruz.
- SEO başlıkları ve açıklamalarını hazırlıyoruz.
- İletişim bilgilerini görünür yerde tutuyoruz.
- Yasal sayfaları eksiksiz tamamlıyoruz.
- Bakım ve destek süresini yazılı konuşuyoruz.
Sektöre göre önceliklerin değişmesi
Her sektörde öncelik farklıdır. Sağlıkta güven ve randevu akışı, e-ticarette ürün filtreleri ve ödeme güvenliği, hizmet sektöründe teklif toplama ve referans gösterme öne çıkar. Bir sağlık firmasına ürün kataloğu mantığıyla sayfa kurmak hata olur.
Kurumsal tanıtım siteleri daha sakin ilerler; satış odaklı yapılarda ise dönüşüm akışı kurulmalıdır. Bazı projelerde 20 sayfa gerekir, bazılarında 8 sayfa yeterlidir. Bu yüzden “herkes için tek site” yaklaşımı bizde çalışmaz.
Teknik yapının sonradan genişlemeye uygun olması
İşletmeler büyür, site de büyümek zorunda kalır. Yeni hizmet, yeni şube, yeni dil veya yeni entegrasyon geldiğinde yapı buna dayanmalı. Bugün küçük görünen bir sistem, yarın CRM bağlantısı isteyebilir. Baştan modüler kurulan yapı bu geçişi daha rahat taşır.
Bugün tek dil yeterliyken yarın İngilizce sayfa gerekebilir. Bugün basit form yeterliyken yarın randevu sistemine bağlanmak gerekebilir. Bu yüzden altyapıyı yalnız bugüne göre değil, bir sonraki aşamaya göre de düşünmek gerekir.
İş tesliminde belge ve erişimlerin eksiksiz alınması
Alan adı, hosting, panel yetkileri, e-posta ayarları ve lisans anahtarları teslimde açıkça yazılmalı. Kimde ne olduğu belirsiz kalırsa ufak bir değişiklik bile uzar. Biz teslim dosyasında erişimleri tek tek listeleriz; sonradan “şifre kimdeydi?” sorusu çıkmasın diye.
Şifre kadar hesap adı ve bağlı sistem de önemlidir. Bir ay sonra “bu giriş hangi site içindi?” diye bakmak zorunda kalmamak için kayıt düzeni gerekir. Özellikle ekip değişince bu belge çok işe yarar.
Fiyatı değerlendirirken kapsamı okumak
Ucuz teklif bazen eksik kapsam demektir; destek yoktur, SEO yoktur, güvenlik yüzeysel geçilmiştir. Yüksek fiyat da tek başına garanti sağlamaz. Esas bakılması gereken, hangi işlerin gerçekten dahil olduğudur.
Tasarım sayısı, revizyon hakkı, içerik girişi, bakım, teknik destek ve özel geliştirme birlikte okunmalıdır. İki teklif aynı rakamı verebilir; biri sadece kurulum yapar, diğeri bir yıllık bakım da ekler. Fark, satırların arasında gizlenir.
Yayına aldıktan sonra takip edilmesi gereken alanlar
Site açıldıktan sonra hangi sayfada çıkış yapıldığı, hangi formun dolduğu, hangi cihazdan girildiği izlenmelidir. Trafik var diye iş yürümüyor; davranış görülmeden karar verilmez. Bir sayfa 1.000 ziyaret alıp hiç dönüşüm getirmiyorsa sorun vardır.
Analiz araçları doğru kurulmadıysa veriler yanıltır. Telefon tıklaması, form gönderimi, buton kullanımı ve kaydırma davranışı takip edilmeli. Biz düzenli raporda bu dört alanı mutlaka ayrı bakarız; hangi bölüm çalışıyor, hangi bölüm zayıf, oradan anlaşılır.
İçerik sahipliği ve teslim biçimi
Metin, görsel ve video kime ait; teslimde açık yazılmalı. Bizde en çok karışıklık burada çıkar: dosya ayrı yerde, sürüm ayrı yerde, müşteri başka sürümle çalışıyor. Bu yüzden içerik sahipliği ve son güncelleme tarihi teslim listesinde durur.
Özgün fotoğraf, ikon seti, stok görsel ve video için kullanım hakkı ayrıca belirtilmelidir. Kullanılmış olması yetmez; hangi hakların devredildiği netleşmelidir. Telif konusu sonradan değil, baştan konuşulmalı.
| Öğe | İstenen kayıt | Niçin gerekir |
|---|---|---|
| Metinler | Dosya adı, sürüm, son güncelleme tarihi | Eski metinle yenisi karışmasın diye |
| Görseller | Kaynak, lisans, kullanım alanı | İleride telif sorunu çıkmasın diye |
| Videolar | Ham dosya ve yayınlanmış sürüm | Yedekleme ve yeniden boyutlandırma için |
| Grafikler | Kaynak dosya ve dışa aktarılmış hali | Düzenleme yapılabilsin diye |
Revizyon sınırını baştan belirlemek
Revizyon hakkı küçük görünür, işin akışını belirler. Sınırsız revizyon denince sınır, çoğu zaman ortada tartışılır. Tasarım için ayrı, içerik için ayrı, teknik iş için ayrı sınır koymak daha temizdir.
Renk değişikliği ile sayfa yapısını yeniden kurmak aynı şey değildir. Ana menüyü taşımakla bütün akışı değiştirmek de aynı yük sayılmaz. Bu ayrım yapılmadığında küçük istekler projeyi uzatır; bizde en çok gecikme, bu farkın kaçırılmasından çıkar.
- Tasarım revizyonlarını ayrı yazıyoruz.
- İçerik revizyonlarını ayrı sınırlandırıyoruz.
- Teknik değişiklikler için ek onay mekanizması kuruyoruz.
- Ek işlerin ücretlendirme yöntemini netleştiriyoruz.
Bakım ve güncelleme sorumluluğunu ayırmak
Bakım ile geliştirme aynı şey değildir. Çekirdek güncellemesi, eklenti denetimi, yedekleme ve hata kontrolü ayrı başlıklardır. Hepsini tek torbaya atınca kimin ne yapacağı karışır; sonra küçük bir hata büyür.
Bakım süresi de yazılmalı: aylık mı, üç aylık mı, yıllık mı? Bizde bir projede içerik güncellemesi ilk ay içinde sorulmamış, üçüncü ayda telefon numarası değişince ihtiyaç ortaya çıkmıştı. Destek sınırı baştan net olsa tartışma çıkmaz.
| Bakım kalemi | Sıklık | Not |
|---|---|---|
| Yedek alma | Günlük ya da haftalık | Site türüne göre değişir |
| Güncelleme kontrolü | Haftalık | Çekirdek ve eklentiler ayrı izlenir |
| Hata takibi | Sürekli | Form, ödeme ve yönlendirme test edilir |
| İçerik desteği | İhtiyaca göre | Yeni sayfa, metin ve görsel güncellemesi |
Yedekleme ve geri dönüş planını sormak
Yedek alınması yeterli değildir; geri yükleme de çalışmalıdır. Hangi sıklıkta yedek alındığı, nerede saklandığı ve ne kadar sürede geri dönülebildiği bilinmelidir. Geçen yıl bir form sorunu yaşadık; 24 saatlik yedek sayesinde kayıp kısa sürdü, 7 günlük olsaydı tablo farklı olurdu.
Geri dönüş testi yapılmayan yedek, kağıt üzerinde güven verir. E-ticaret ve randevu sistemlerinde gece oluşan bir hata sabaha kadar satış ya da kayıt kaybı çıkarabilir. Küçük site de olsa, en azından haftalık bir geri yükleme kontrolü yapılmalıdır.
- Yedek alma sıklığı yazılı olarak belirtilir.
- Yedeklerin hangi sunucuda tutulacağı açıklanır.
- Geri yükleme süresi için hedef süre yazılır.
- Test geri yüklemesi periyodik yapılır.
Erişimlerin tek merkezde toplanması
Domain, hosting, panel, e-posta ve analiz araçları farklı kişilerde kalırsa yönetim karışır. Şifre güncellenince kimde ne olduğu belirsizleşir. Bu yüzden erişim listesi proje başında hazırlanmalı, teslim anında güncellenmelidir.
Biz erişim kaydında sadece kullanıcı adını değil, hangi sisteme ait olduğunu da yazarız. “Şifre var” yetmez; bir ay sonra hangi hesabın hangi işe yaradığı unutulur. Ajans değişiminde ya da ekip ayrılığında bu kayıt doğrudan işe yarar.
| Erişim türü | Kimde olmalı | Kontrol sıklığı |
|---|---|---|
| Alan adı | İşletme sahibi | 6 ayda bir |
| Hosting | İşletme ve teknik sorumlu | Aylık |
| Yönetim paneli | İçerik yöneticisi | Yetki değişiminde |
| Analiz araçları | Pazarlama ekibi | Raporlama döneminde |
Ölçüm araçlarını doğru kurmak
Siteyi yayınlamak başka, ölçmek başka iştir. Sadece analiz aracı eklemek yetmez; form gönderimi, telefon tıklaması ve WhatsApp geçişi olay olarak tanımlanmalı. Aksi durumda trafik görünür ama davranış okunmaz.
Biz temel olayları ayrı izleriz: sayfa görüntüleme, form gönderme, telefon tıklama, e-posta tıklama, dış bağlantı tıklaması. Bir sayfada 10.000 ziyaret olup 3 form alınmasıyla 700 ziyaret olup 20 form alınması aynı tablo değildir. Kararı sayılar verir.
| Takip edilen olay | Ne gösterir | Karar etkisi |
|---|---|---|
| Form gönderimi | İletişim isteği | Sayfa dönüşümü ölçülür |
| Telefon tıklaması | Hızlı iletişim tercihi | Mobil davranış anlaşılır |
| Sayfa kaydırma | İçerik tüketimi | Metin yoğunluğu ayarlanır |
| Buton tıklaması | İlgilenme düzeyi | CTA yerleşimi iyileştirilir |
İç bağlantı yapısını planlamak
Sayfalar birbirine bağlanmazsa kullanıcı bir yerde kalır. Ana sayfadan hizmete, hizmetten örnek işe, oradan iletişime geçen yapı daha rahat çalışır. Bağlantı rastgele kurulursa ziyaretçi sonraki adımı bulamaz; çıkış yapmak kolay gelir.
“Daha fazla bilgi” gibi belirsiz linkler yerine hedefi açık metinler kullanmak daha doğrudur. SEO için değil yalnız; insan için de gerekir bu. Tıklamadan önce nereye gidileceği anlaşılmalıdır.
- Hizmet sayfaları arasında ilişki kuruyoruz.
- Blog yazılarını hizmetlere bağlıyoruz.
- Başvuru ve iletişim sayfalarını görünür tutuyoruz.
- Önemli sayfalara 2-3 tıklamayla ulaşıyoruz.
Teknik borcu baştan sınırlamak
Teknik borç, hızlı teslim uğruna ertelenen kararların birikmesidir. Kısa sürede açılan sitelerde bu sık görülür. Dokümansız kod, fazla eklenti ve testsiz yayın, birkaç ay sonra bakım süresini uzatır.
Bir projede iki farklı geliştirici aynı sayfayı anlamak için saat harcamıştı; çünkü yapı notlanmamıştı. Fazla katman her zaman güvenlik getirmez, bazen kırılganlık üretir. Acele edilen işin faturası, sonra çıkar.
| Teknik risk | Görünme şekli | İleri etkisi |
|---|---|---|
| Dokümansız kod | Değişikliklerde zorlanma | Bakım süresi uzar |
| Aşırı eklenti | Yavaşlama ve çakışma | Hata ihtimali artar |
| Planlanmamış yapı | Sayfa düzeni dağılır | Yeni özellik eklemek zorlaşır |
| Test yapılmaması | Yayın sonrası hata | Kullanıcı kaybı yaşanır |
İşin teslim tarihi ile gerçek teslimi ayırmak
Takvimde tarih yazması, işin tamamlandığı anlamına gelmez. Taslak hazır olabilir, mobil menü bozuk olabilir, form mailleri gitmeyebilir. Bu yüzden taslak, test ve canlı teslim ayrı ele alınmalıdır.
Biz projelerde bu ayrımı açık tutarız. Taslakta yapı görülür, testte hata aranır, canlıda son veri aktarılır. Bu sıra korunmazsa müşteri iş bitti sanır, ekip hâlâ düzeltme yapıyor olur.
- Taslak sürüm incelenir.
- Test ortamında hata kontrolü yapılır.
- İçerik aktarımı tamamlanır.
- Canlıya geçiş için son onay alınır.
İletişim sonrası cevap süresini belirlemek
Form koymak tek başına yetmez; ne kadar sürede dönüleceği de yazılmalıdır. 5 dakikada cevaplanan başvuru ile iki gün sonra dönülen başvuru aynı etkiyi vermez. Özellikle hizmet işlerinde ilk cevap süresi fırsatı belirler.
Telefon, e-posta ve WhatsApp kanallarında çalışma saatleri belirtilmezse yanlış beklenti oluşur. Gece gelen başvuruya sabah döneceğimizi açık yazmak daha doğru olur. Böylece ekip de, ziyaretçi de boş yere beklemez.
| Kanal | Beklenen dönüş | Not |
|---|---|---|
| Form | İş günü içinde | Otomatik bildirim kurulmalı |
| Telefon | Çalışma saatinde | Kaçan çağrı kaydı tutulmalı |
| Mümkünse kısa sürede | Hazır mesaj yapısı planlanmalı | |
| E-posta | En geç 24 saat içinde | Gelen kutusu düzenli kontrol edilmeli |
Sıkça sorulan sorular
- Web sitesi yaptırırken kaç sayfa gerektiği nasıl belirlenir?
- Web sitesinin kapsamı, hedefi, sayfa sayısı ve ziyaretçinin tamamlayacağı işlem belirlenerek netleşir. Bir projede 12 sayfa gerekirken başka projede 5 sayfa yeterli olabilir. Kurumsal tanıtım, e-ticaret, sağlık ve sanayi sitelerinin akışları farklıdır. Bu sorular cevaplanmadan tasarıma geçmek, bütçeyi ve proje süresini dağıtır.
- Web sitesi mobil uyumlu değilse ne gibi sorunlar yaşanır?
- Mobil uyum, ekranı küçültmekten ibaret değildir. Butonlar rahat dokunulmalı, metin okunmalı ve yatay kaydırma oluşmamalıdır. Bir e-ticaret projesinde 44 pikselden küçük butonlar, sepete ekleme oranını düşürdü. Mobil testleri önce dar ekranda yapmak, sorunları yayından önce görmemizi sağlar.
- Web sitesi kaç saniyede açılmalı ve hız nasıl artırılır?
- Yavaş açılan sayfalarda büyük görseller, gereksiz eklentiler ve ağır animasyonlar sık görülür. Bir kurumsal sitede 9 saniyelik açılış süresi, görsel sıkıştırmayla 3 saniyenin altına indi. Sunucu seçimi, önbellekleme ve kullanılmayan dosyaların temizliği kurulum aşamasında planlanmalıdır.
- SEO çalışması web sitesi yapılırken mi başlamalı?
- SEO altyapısı yayından önce kurulmalıdır. Başlıklar, açıklamalar, temiz adresler, iç bağlantılar ve görsel alt metinleri başlangıçta hazırlanır. Sonradan yapılan düzenlemeler en az iki kat iş çıkarır. Mobil uyum, sayfa hızı ve yerel bilgiler de arama görünürlüğünü birlikte etkiler.
- Web sitesi yönetim panelinde hangi özellikler bulunmalı?
- Yönetim paneli, teknik destek almadan metin, kampanya, referans ve telefon bilgisi güncellemeye izin vermelidir. Görsel yükleme ve SEO alanları anlaşılır olmalıdır. İçerik eklemek için kod açmak gerekiyorsa sistem ağırlaşır. Güvenlik için SSL, güçlü şifre, yetki sınırı ve yedekleme de tanımlanmalıdır.
Kaynakça
- Google Arama Merkezi: Arama Motoru Optimizasyonu (SEO) Başlangıç Kılavuzu — Yazıdaki başlık hiyerarşisi, meta etiketleri, taranabilirlik ve teknik SEO gereksinimlerinin temeline dayanak oluşturur.
- web.dev: Core Web Vitals (Web Önemli Göstergeleri) — Yazıda yer alan sayfa yükleme hızı, görsel optimizasyonu ve kullanıcı etkileşim performansı standartlarını belgeler.
- Google Arama Merkezi: Mobil Öncelikli İndeksleme (Mobile-First Indexing) — Mobil uyumluluğun ve responsive arayüz tasarımının arama motoru görünürlüğü için zorunlu kılınmasını açıklar.
- Nielsen Norman Group: Web Form Design Guidelines — İletişim formlarının uzunluğu, alan sayısı ve kullanıcı deneyimi standartlarına ilişkin tespitleri destekler.
