Web Sitesi Yaptırmadan Önce Ajansınıza Sormanız Gereken 20 Teknik Soru

Giriş

Yeni bir kurumsal web sitesi için ajans seçerken portfolyoya, tasarım diline ve teklif tutarına bakmak doğaldır. Fakat iki teklif arasındaki asıl fark çoğu zaman ilk bakışta görünmez: Aynı sayfa sayısını, benzer bir tasarımı ve aynı teslim süresini yazan iki teklif; içerik yönetimi, güvenlik, SEO, performans ve yayın sonrası destek açısından bambaşka işler tarif ediyor olabilir.

Bu yüzden “Ne kadara yaparsınız?” ve “Ne zaman biter?” soruları tek başına yeterli değildir. Bir web sitesinin teknik kalitesi yalnızca yazılan koddan değil; kapsamın nasıl tanımlandığından, verilerin kime ait olduğundan ve sitenin yıllar içinde nasıl yaşatılacağından da belirlenir. Aşağıdaki 20 soru, teklifleri karşılaştırılabilir hale getirmek ve proje başladıktan sonra çıkabilecek sürprizleri azaltmak için hazırlandı.

İyi bir ajansın her soruya tek bir “doğru” cevap vermesi gerekmez. Ama tercihinin nedenini, alternatiflerini ve bunun projenize etkisini açıklayabilmelidir. Her sorunun altında, iyi bir cevapta neyi duymanız ve hangi cevaplara dikkat etmeniz gerektiğini de özetledik.

Kısaca: Ajans tekliflerini karşılaştırırken fiyat ve teslim süresinin ötesine bakın. Kapsam ve değişiklik süreci, CMS tercihi ve içerik sahipliği, SEO ve performans hedefleri, güvenlik ve yedekleme sorumluluğu, eğitim, bakım ve devredilebilirlik yazılı olarak netleşmiyorsa teklifler gerçekte karşılaştırılabilir değildir.

Projenin Kapsamını Netleştiren Sorular

1. Web Sitesinin Başarısını Nasıl Ölçeceğiz?

Ajans yalnızca sayfa listesini mi konuşuyor, yoksa sitenin ne üretmesi gerektiğini de anlamaya çalışıyor mu? Başarı; teklif formu, nitelikli başvuru, ürün keşfi, yatırımcı bilgilendirmesi ya da içerik tüketimi olabilir. Hedef net değilse doğru bilgi mimarisini kurmak da, yayından sonra neyin işe yaradığını ölçmek de zorlaşır.

İyi bir cevap: Hedefleri ölçülebilir göstergelere bağlar (form dönüşümü, kariyer başvurusu, belirli sayfalara gelen organik trafik gibi) ve bu göstergelerin hangi analitik olaylarıyla izleneceğini proje başında tanımlar.

Dikkat: Başarı tanımı yalnızca “modern ve hızlı bir site” ise ölçüm planı büyük olasılıkla yayından sonraya kalır.

2. Proje Başlamadan Önce Nasıl Bir Analiz Yapacaksınız?

Mevcut sitenin verileri, kullanıcı ihtiyaçları, rakipler, içerik envanteri ve teknik yapı incelenmeden hazırlanan plan genellikle varsayımlara dayanır. Analizin kapsamını ve sonunda hangi kararların netleşeceğini sorun.

İyi bir cevap: Analizin somut çıktılarını sayar: içerik envanteri, site haritası taslağı, mevcut trafik ve dönüşüm verisinin özeti, teknik risk listesi ve entegrasyon haritası.

Dikkat: Analiz aşaması teklifte hiç yoksa ya da yalnızca bir “başlangıç toplantısı” olarak geçiyorsa, kapsamdaki belirsizlik er geç takvime yansır.

3. Teklife Tam Olarak Neler Dahil?

İçerik girişi, veri taşıma, fotoğraf düzenleme, metin yazımı, çeviri, lisanslar, hosting ve üçüncü taraf servisler her teklifte aynı şekilde ele alınmaz. “Web sitesi geliştirme” ifadesinin altında hangi işlerin bulunduğu açıkça yazılmalıdır.

İyi bir cevap: Dahil olan ve olmayan kalemleri ayrı ayrı listeler; lisans, hosting, CDN, e-posta ve form servisleri gibi yıllık tekrarlayan maliyetleri tek seferlik geliştirme bedelinden ayırır.

Dikkat: Toplam tutarı düşük ama “hariçler” listesi uzun bir teklif, ilk yılın sonunda en pahalı seçenek olabilir.

4. Proje Sırasında Kapsam Değişirse Ne Olacak?

Yeni ihtiyaçların nasıl değerlendirileceğini, ek işlerin nasıl fiyatlandırılacağını ve takvime nasıl yansıyacağını baştan konuşun. Değişiklik talebi süreci net değilse küçük görünen talepler hem bütçeyi hem teslim tarihini belirsizleştirir.

İyi bir cevap: Yazılı bir değişiklik talebi süreci tarif eder: talep, efor ve maliyet tahmini, takvim etkisi, onay. Revizyon turlarının sayısı ve kapsamı da tanımlıdır.

Dikkat: “Esnek çalışırız, sorun olmaz” cevabı başta rahatlatıcıdır; ama tanımsız esneklik genellikle proje sonunda tartışmaya dönüşür.

Teknoloji ve İçerik Yönetimi Soruları

5. Hangi CMS’i Öneriyorsunuz ve Neden?

Herkese uyan tek bir “en iyi CMS” yoktur. Önerilen sistem; kurumunuzun güvenlik, entegrasyon, içerik yönetimi, çoklu dil, ölçeklenme ve bakım ihtiyaçlarıyla ilişkilendirilebilmelidir. Teknoloji tercihi ajansın alışkanlığına değil, projenin gereksinimlerine dayanmalıdır.

İyi bir cevap: Tercihi gereksinimlerinizle gerekçelendirir; sistemin sürüm ve destek politikasını (uzun süreli destek sürümleri, güncelleme döngüsü), lisans modelini ve barındırma seçeneklerini açıkça anlatır.

Dikkat: Ajansa özel, kapalı bir yönetim sistemi önerildiğinde; ajansla çalışmayı bıraktığınızda sistemi kimin geliştirmeye devam edebileceğini mutlaka sorun.

6. İçerik Ekibimiz Neleri Kendi Başına Yönetebilecek?

Yeni sayfa oluşturmak, menüyü değiştirmek, kampanya alanı eklemek veya form düzenlemek için her seferinde geliştiriciye mi ihtiyaç duyacaksınız? Yönetim panelinin esnekliği kadar sınırları da anlatılmalıdır; kontrolsüz esneklik zamanla tasarım bütünlüğünü bozar.

İyi bir cevap: İçerik modelini somut örneklerle gösterir: hangi sayfa tipleri ve bileşenler olacak, editör hangi alanları değiştirebilecek, rol ve yetki yapısı nasıl kurulacak, yayın öncesi önizleme ve onay akışı olacak mı.

Dikkat: “Her şeyi panelden yapabilirsiniz” cevabı, sınırları tanımlanmamış bir sistemin işareti olabilir.

7. İçeriklerimiz ve Kaynak Kodumuz Kime Ait Olacak?

Proje sonunda içeriklerin, medya dosyalarının, alan adının, servis hesaplarının ve size özel geliştirilen kodun erişimi kurumunuzda olmalıdır. Lisanslı ürünler veya ajansa ait ortak bileşenler kullanılıyorsa bunların kullanım koşullarını ayrıca sorun.

İyi bir cevap: Kod deposunun kurumunuza devredileceğini, alan adının kurum adına kayıtlı kalacağını ve analitik, Search Console, DNS gibi hesaplarda kurumunuzun yönetici yetkisine sahip olacağını açıkça belirtir.

Dikkat: Alan adı veya DNS ajansın hesabında tutuluyorsa, ileride ajans değiştirmek istediğinizde ilk sorun genellikle buradan çıkar.

8. Mevcut Sitemizdeki İçerikler Nasıl Taşınacak?

İçerik taşıma yalnızca metinleri kopyalamak değildir. URL’ler, görseller, dosyalar, çoklu dil ilişkileri, meta veriler ve eski yönlendirmeler de planlanmalıdır.

İyi bir cevap: Taşımanın otomatik mi, manuel mi yoksa karma mı yapılacağını; hangi içeriklerin taşınıp hangilerinin arşivleneceğini ve taşınan içeriğin nasıl doğrulanacağını anlatır.

Dikkat: Taşıma kalemi teklifte “müşteri tarafından yapılacaktır” diye geçiyorsa, bu işin iç ekibinize getireceği yükü önceden hesaplayın.

SEO, Performans ve Erişilebilirlik Soruları

9. Mevcut SEO Değerini Nasıl Koruyacaksınız?

Yeni site yayına alındığında değişen URL’ler, eksik yönlendirmeler veya kaybolan meta veriler organik görünürlüğü ciddi biçimde etkileyebilir. Ajansın canlıya geçiş öncesinde ve sonrasında neleri kontrol ettiğini sorun.

İyi bir cevap: Eski ve yeni URL’leri birebir eşleyen bir 301 yönlendirme planından; title, meta description, canonical ve yapılandırılmış verinin (schema) korunmasından; çok dilli sitelerde hreflang kurgusundan; XML site haritasının yayın günü güncellenmesinden ve yayın sonrası Search Console takibinden söz eder.

Dikkat: “Yayından sonra SEO çalışması yaparız” cevabı, taşıma riskinin planlanmadığını gösterir. Kayıp çoğu zaman yayın günü yaşanır.

10. Performansı Hangi Metriklerle Değerlendireceksiniz?

Tek bir PageSpeed puanı bütün kullanıcı deneyimini anlatmaz. Laboratuvar testleri geliştirme sırasında yol gösterir; asıl değerlendirme ise gerçek kullanıcılardan toplanan saha verisiyle yapılmalıdır.

İyi bir cevap: Hedefleri Core Web Vitals üzerinden tanımlar: kullanıcıların en az %75’inde LCP 2,5 saniyenin, INP 200 milisaniyenin, CLS 0,1’in altında. Mobil ve masaüstünü, ana sayfa ile detay sayfası gibi farklı şablonları ayrı ayrı ele alır; görsel optimizasyonu, önbellekleme ve CDN yaklaşımını açıklar.

Dikkat: “PageSpeed’de 100 alıyoruz” vaadi, çoğu zaman tek bir sayfanın tek bir laboratuvar ölçümünü anlatır.

11. JavaScript Kullanımı İçeriklerin Görünürlüğünü Etkileyecek mi?

Modern arayüzlerde JavaScript kullanılması normaldir. Önemli olan, kritik içeriklerin arama motorları ve yapay zekâ sistemleri tarafından güvenilir biçimde okunabilmesidir. Google JavaScript’i işleyebilir; ancak Vercel ile MERJ’in Aralık 2024 tarihli tarama analizi, GPTBot ve ClaudeBot gibi büyük yapay zekâ tarayıcılarının JavaScript dosyalarını indirse de çalıştırmadığını gösterdi. Yalnızca tarayıcıda oluşan içerik, bu sistemler için sayfada hiç yoktur.

İyi bir cevap: Ana metinlerin, başlıkların, ürün bilgilerinin ve SSS gibi bölümlerin sunucu tarafında (SSR veya statik HTML olarak) üretileceğini, JavaScript’in etkileşim için kullanılacağını söyler ve bunu sayfa kaynağı üzerinden gösterebilir.

Dikkat: İçerik, sayfa açıldıktan sonra ayrı bir API isteğiyle yükleniyorsa ilk HTML’de bulunup bulunmadığını özellikle sorun. Bu konuyu Google’da 1. Sıradasınız Ama ChatGPT Sizi Önermiyor. Neden? yazımızda daha ayrıntılı ele aldık.

12. Erişilebilirlik Projenin Hangi Aşamasında Ele Alınacak?

Klavye ile kullanım, renk kontrastı, form etiketleri ve görsel açıklamaları proje sonunda eklenen maddeler olmamalıdır. Tasarım ve geliştirme sürecine baştan dahil edilmediklerinde düzeltmeleri daha maliyetli hale gelir.

İyi bir cevap: Hedef seviyeyi açıkça söyler (örneğin WCAG 2.2 AA), kontrastı tasarım aşamasında kontrol eder; otomatik test araçlarının yanında klavye ve ekran okuyucuyla manuel test yapar.

Dikkat: Erişilebilirliğin siteye sonradan eklenecek bir “erişilebilirlik eklentisi” ile çözüleceğinin söylenmesi. Bu araçlar, kod seviyesindeki sorunları ortadan kaldırmaz.

Güvenlik ve Teknik Operasyon Soruları

13. Güvenlik Güncellemelerini Kim Takip Edecek?

CMS, framework ve kullanılan paketlerin güncellemeleri proje sonrasında da devam eder. Hangi güncellemelerin bakım kapsamına girdiğini, kritik açıkların nasıl takip edildiğini ve müdahale sorumluluğunun kimde olduğunu netleştirin.

İyi bir cevap: Kullanılacak sürümün destek bitiş tarihini baştan söyler; güvenlik yamalarının hangi süre içinde uygulanacağını, paket bağımlılıklarının nasıl izlendiğini ve HTTPS, güvenlik başlıkları, WAF, yönetim paneline erişim kısıtı ve iki adımlı doğrulama gibi temel önlemleri anlatır.

Dikkat: Destek süresi bitmek üzere olan bir sürümle yeni bir proje başlatılması.

14. Hosting, Yedekleme ve Felaket Kurtarma Nasıl Yönetilecek?

“Günlük yedek alıyoruz” tek başına yeterli bir cevap değildir. Yedeklerin nerede tutulduğunu, ne kadar süre saklandığını, geri yükleme işleminin test edilip edilmediğini ve kesinti halinde kimin devreye gireceğini sorun.

İyi bir cevap: İki kavramı netleştirir: en fazla ne kadarlık veri kaybının göze alınabileceği (RPO) ve sitenin en geç ne kadar sürede yeniden ayağa kalkacağı (RTO). Veritabanının ve medya dosyalarının birlikte yedeklendiğini, en az bir kopyanın farklı bir konumda tutulduğunu ve geri yüklemenin düzenli olarak test edildiğini belirtir.

Dikkat: Yedeklerin canlı siteyle aynı sunucuda tutulması, sunucu kaybında yedeğin de kaybedilmesi demektir.

15. Test ve Canlıya Alma Süreci Nasıl İşleyecek?

Geliştirme, test ve canlı ortamların ayrılması değişikliklerin kontrollü biçimde yayınlanmasını sağlar. Kimlerin onay vereceği, kritik formların ve entegrasyonların nasıl test edileceği, sorun halinde geri dönüş planının ne olduğu açıklanmalıdır.

İyi bir cevap: Sürüm kontrolü üzerinden çalışıldığını, yayınların otomatik ya da tanımlı bir prosedürle yapıldığını, kabul testlerinin kim tarafından hangi kontrol listesiyle yapılacağını ve bir yayının nasıl geri alınacağını anlatır. Test ortamının arama motorlarına kapalı tutulacağını da belirtir.

Dikkat: Değişikliklerin doğrudan canlı sunucu üzerinde yapılması.

16. Entegrasyonlar İçin Sorumluluk Nasıl Paylaşılacak?

CRM, ERP, kariyer platformu, ödeme sistemi veya başka bir servisle bağlantı kurulacaksa tarafların sorumlulukları net olmalıdır. Dış serviste oluşan değişikliklerin, erişim bilgilerinin ve test ortamlarının kim tarafından yönetileceğini baştan konuşun.

İyi bir cevap: Her entegrasyon için veri akışını (hangi veri, nereye, ne sıklıkla), hata durumunda ne olacağını (yeniden deneme, kayıt, bildirim) ve API anahtarlarının nerede, nasıl saklanacağını tanımlar.

Dikkat: Karşı tarafın API dokümantasyonu ve test ortamı görülmeden verilen kesin süre ve fiyat.

Proje Sonrasını Belirleyen Sorular

17. Ekibimize Eğitim Verilecek mi?

İyi bir yönetim paneli bile kurumun içerik modeline göre anlatılmalıdır. Eğitimin kimlere verileceğini, kayıt veya dokümantasyon sağlanıp sağlanmayacağını ve yeni ekip üyelerinin sisteme nasıl adapte olacağını öğrenin.

İyi bir cevap: Editör ve yönetici gibi rollere göre ayrı eğitim, oturum kaydı ve sitenizin bileşenlerine özel kısa bir kullanım kılavuzu sunar.

Dikkat: Eğitimin, CMS’in genel kullanımını anlatan hazır videolarla sınırlı kalması.

18. Garanti ve Bakım Kapsamı Nedir?

Hata düzeltme ile yeni geliştirme aynı şey değildir. Garanti süresini, bakım anlaşmasının neleri kapsadığını, taleplerin hangi kanaldan iletileceğini ve yanıt sürelerini yazılı hale getirin.

İyi bir cevap: Hataları önceliğe göre ayırır (site erişilemiyor, form çalışmıyor, görsel kusur gibi) ve her öncelik için yanıt ve çözüm süresini (SLA) tanımlar. Aylık bakım saatlerinin kapsamını ve kullanılmayan saatlerin bir sonraki aya devredip devretmediğini açıklar.

Dikkat: Garanti süresinin başlangıcının tanımsız olması: Teslim tarihi mi, yayın tarihi mi?

19. Analitik ve Çerez Yönetimi Nasıl Kurulacak?

Yayın sonrası başarıyı ölçmek için analitik araçlarının doğru olaylarla yapılandırılması gerekir. Form gönderimi, telefon tıklaması veya dosya indirme gibi hedeflerin izlenip izlenmeyeceğini ve bunun çerez onayıyla nasıl uyumlandırılacağını sorun.

İyi bir cevap: İlk sorudaki hedeflere bağlı bir ölçüm planı sunar; çerezleri kategorilere ayırır ve zorunlu olmayan çerezleri kullanıcı onayı olmadan çalıştırmaz. KVKK’ya (Avrupa’daki kullanıcılara hizmet veriyorsanız GDPR’a da) uygun bir onay yönetimi ve Google araçları kullanılıyorsa Consent Mode yapılandırması önerir.

Dikkat: Ölçüm etiketlerinin kullanıcı onayı beklenmeden, sayfa açılır açılmaz yüklenmesi.

20. Siteyi Başka Bir Ekibe Devretmek Gerekirse Ne Olacak?

Sağlıklı bir proje, yalnızca onu geliştiren ekibin anlayabildiği kapalı bir yapı olmamalıdır. Kod deposu, kurulum bilgileri, servis hesapları, lisanslar ve temel teknik dokümantasyon kurumun erişebileceği şekilde teslim edilmelidir.

İyi bir cevap: Teslim paketinin içeriğini sayar: kod deposu, kurulum ve yayın adımlarını anlatan bir doküman, ortam ayarları listesi, entegrasyon ve servis hesapları envanteri, lisans bilgileri.

Dikkat: “İstediğiniz zaman veririz” denilen ama sözleşmede tanımlanmamış teslimler.

Cevaplardan Çok Gerekçelere Bakın

Bu soruların amacı ajansı köşeye sıkıştırmak veya en fazla özelliği vaat eden teklifi seçmek değildir. Bazı projelerde hazır bir altyapı doğruyken bazılarında özel geliştirme gerekir. Bazı kurumlar için esnek içerik yönetimi öncelikliyken bazıları daha kontrollü bir yayın akışına ihtiyaç duyar.

İyi bir ajans bu farkları görünür hale getirir. Bir özelliğin neden gerekli olduğunu, hangi maliyeti doğurduğunu ve vazgeçilirse ne olacağını açıkça anlatır.

Özellikle mevcut bir Umbraco projesi yenilenecekse ilk karar otomatik olarak “upgrade edelim” olmamalıdır; kod, içerik yapısı ve iş hedefleri birlikte değerlendirilmelidir.

Teklifte Yazılı Görmeniz Gerekenler

Görüşmelerde aldığınız cevapların teklif veya sözleşmede karşılığı olmalıdır. Teklifleri karşılaştırırken aşağıdaki başlıkların her birinde yazılı bir taahhüt arayın.

Sonuç

Web sitesi tekliflerini fiyat, sayfa sayısı ve teslim süresi üzerinden karşılaştırmak kolaydır. Fakat projenin uzun vadeli maliyetini; içerik yönetimi, bakım, güvenlik, performans ve devredilebilirlik belirler.

Ajans görüşmelerine bu 20 soruyla girdiğinizde bütün cevapların teknik ayrıntısını bilmeniz gerekmez. Önemli olan ekibin soruları ciddiye alması, tercihlerini açıklaması ve belirsiz kalan noktaları teklif kapsamına dönüştürebilmesidir.

Yeni bir kurumsal web sitesi planlıyorsanız veya mevcut projenizi yenilemeyi düşünüyorsanız, ihtiyaçlarınızı birlikte değerlendirip doğru kapsamı oluşturabiliriz.

Kaynaklar ve İleri Okuma

Bu yazıdaki teknik ölçütler için başvurduğumuz kaynaklar:

• Vercel — The rise of the AI crawler
• web.dev — Web Vitals
• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• Google Search Central — URL değişikliği içeren site taşımaları