Bir web sitesi teslim edildiğinde işletmenin elinde genellikle çalışan bir adres ve yönetim paneli bulunur. Ancak birkaç ay sonra alan adı yenilemesi, ekip değişikliği veya başka bir hizmet sağlayıcıyla çalışma gündeme geldiğinde daha farklı sorular ortaya çıkar. Hesap kimin adına açılmıştır? Kaynak dosyalar hangi kapsamda teslim edilecektir? Ajansın aboneliği sona ererse hangi bileşenler güncelleme almaya devam edecektir? Bu soruların cevapları, sitenin günlük işleyişini doğrudan etkiler.
Web Tasarım Sistemleri olarak önerimiz, sahipliği tek bir cümleyle geçiştirmek yerine yönetilebilir parçalara ayırmanızdır. Bir web tasarım ajansı ile çalışırken alan adı, barındırma, içerik, yazılım, lisanslar ve destek için ayrı sorumluluklar belirlenmelidir. Böylece proje sonunda yalnızca görünen sayfalar değil, işletmenin kullanabileceği erişimler ve sürdürebileceği bir çalışma düzeni de tanımlanır. Bu rehber, teklif ve teslim görüşmelerinde kullanabileceğiniz pratik kontrolleri ele alır; her projedeki hak ve yükümlülüklerin anlaşma ve ilgili kullanım koşullarıyla ayrıca belirlenmesi gerekir.
Site Sahipliğini Tek Bir Hesap Olarak Düşünmeyin
Bir sitenin alan adı, dosyaları ve ziyaretçi ölçüm hesabı farklı sistemlerde bulunabilir. Panelde içerik yayımlayabilmeniz, alan adını başka kayıt kuruluşuna taşıyabildiğiniz veya sunucudaki bütün uygulamaları yönetebildiğiniz anlamına gelmez. Benzer şekilde fatura ödediğiniz hesabın erişim düzeyi ile tasarım dosyalarının kullanım koşulları birbirinden farklı konulardır. Her parçayı kendi işlevi üzerinden değerlendirmek, teslim görüşmesini somutlaştırır.
Başlangıçta kısa bir varlık envanteri hazırlayın. Her satırda hizmetin adı, hesap yöneticisi, işletme içindeki sorumlu, ajansın erişim rolü, yenileme tarihi ve teslim kanıtı yer alsın. Parolaları bu tabloya eklemeyin; tablo yalnızca erişimin nasıl yönetildiğini göstermelidir. Özellikle bir kurumsal web sitesi birden fazla departmanın çalışmasına bağlıysa, muhasebe sorumluluğu ile teknik yönetim sorumluluğunun aynı kişide bulunduğunu varsaymayın.
- Alan adı: Kayıt kuruluşu, yönetici hesabı, yenileme ve kurtarma sorumlusu.
- Barındırma: Hizmet kapsamı, dosya ve veri tabanı erişimleri, yedeklerin konumu.
- İçerik ve tasarım: Teslim edilecek metinler, görseller ve düzenlenebilir kaynaklar.
- Yazılım ve lisanslar: Bileşen listesi, kullanım koşulları, abonelik ve güncelleme sorumluluğu.
- Ölçüm ve entegrasyonlar: Hesap rolleri, veri erişimi ve hizmet değişikliğinde izlenecek yol.
Alan Adı Yönetimini İşletmenin Sürekliliğine Bağlayın
Alan adı kaydının hangi hesap üzerinden yönetildiğini ve hesap bilgilerinin kimin tarafından güncel tutulduğunu öğrenin. Yenileme bildiriminin yalnızca projeden ayrılabilecek tek bir kişinin adresine gitmesi, operasyonel bir belirsizlik yaratır. Bildirimleri takip edecek yetkiliyi, yedek sorumluyu ve hesap kurtarma düzenini başlangıçta belirleyin. Kontrolünüz, bir ekran görüntüsünün paylaşılmasıyla sınırlı kalmasın; yetkili kişinin kendi erişimiyle gerekli bilgileri görebildiği de doğrulansın.
Alan adını taşımak ile web sitesinin dosyalarını başka sunucuya taşımak farklı işlemlerdir. ICANN kapsamındaki genel üst düzey alan adlarında kayıt kuruluşları arasında transfer için kullanılan yetkilendirme kodunun işlevi, ICANN Auth-Code açıklamasında tanımlanır. Kullandığınız uzantının ve kayıt kuruluşunun güncel aktarım koşullarını ayrıca kontrol edin. Her alan adı için aynı süreç, bekleme süresi veya teslim yöntemi geçerliymiş gibi bir plan kurmayın.
DNS kayıtlarını kimin yönettiği de envanterde yer almalıdır. Web sitesi, e-posta ve başka hizmetler aynı alan adına bağlı olabilir. Bu nedenle bir devir planında yalnızca yeni sunucu adresini yazmak yeterli olmaz. Mevcut hizmetler listelenmeli, değişikliğin kapsamı anlaşılmalı ve kontrol sorumluları belirlenmelidir. Ajansın teknik işlemleri yürütmesi ile işletmenin yönetim bilgisini elinde tutması birlikte planlanabilir.
Barındırma Erişimi ile Uygulama Teslimini Ayırın
Barındırma hizmeti ortak bir ajans hesabında sağlanıyorsa işletmeye hangi erişimlerin verilebildiğini açıkça sorun. Bazı hizmetlerde bağımsız müşteri hesabı oluşturulabilir; bazılarında yönetim ajans üzerinden yürütülür. Bu modelleri değerlendirirken hesap yapısının size hangi işlemleri yapma olanağı sunduğunu ve ayrılma halinde hangi verilerin hangi biçimde sağlanacağını karşılaştırın. Tek başına sunucu parolasının paylaşılması, düzenli bir teslim süreci oluşturmaz.
Uygulama dosyaları, veri tabanı, yüklenen görseller ve kurulum bilgileri ayrı teslim kalemleri olabilir. Özel bir web yazılım geliştirme çalışmasında çalıştırma ortamı, bağımlılıklar ve entegrasyon ayarlarının açıklanması da gerekebilir. Sadece arşiv dosyasının teslim edilmesiyle başka bir ekibin sistemi çalıştırabileceğini varsaymayın. Teslim biçimi, kurulumu kimin yapacağı ve gösterimin hangi ortamda gerçekleşeceği belirlenmelidir.
Hizmet olarak sunulan bir platformda ise uygulamanın kaynak kodları yerine belirli veri dışa aktarma seçenekleri sağlanabilir. Karar verirken özel yazılım ve hazır sistem karşılaştırmasını bu taşınabilirlik sorusuyla birlikte değerlendirin. İşletmenin ihtiyaç duyduğu bağımsızlık düzeyi, seçilen ürünün teslim modeliyle uyumlu olmalıdır. Karşılanmayan bir beklentiyi proje sonunda keşfetmek yerine teklif aşamasında görünür hale getirin.
Kaynak Dosyaları ve Lisansları Ayrı Kalemlerde Tanımlayın
Teslim listesinde “tüm dosyalar” yazması, pratikte yeterince açıklayıcı olmayabilir. Yayındaki sıkıştırılmış görseller, düzenlenebilir tasarım dosyaları, özgün fotoğraflar ve kullanılan yazı tipleri farklı kapsamlar taşır. Hangilerinin teslim edileceğini, hangi formatta verileceğini ve sonraki çalışmalarda nasıl kullanılabileceğini ayrı ayrı görüşün. Üçüncü taraf bileşenlerde geçerli koşulları ilgili lisans veya hizmet belgesi üzerinden kontrol edin.
Bir tema ya da eklenti ajansın çoklu kullanım aboneliğiyle sağlanıyorsa abonelik sona erdiğinde destek, güncelleme ve kullanım açısından ne olacağını sorun. Bunların aynı anda sona erdiğini veya hiçbirinin etkilenmeyeceğini peşinen kabul etmeyin. Ürün bazında koşullar değişebilir. İşletme adına ayrı lisans alınması gerekiyorsa tedarik, yenileme ve ödeme sorumluluğunu proje kapsamına ekleyin.
Kaynak kodunun teslimi ile bütün bileşenler üzerindeki kullanım haklarını aynı şey olarak değerlendirmeyin. Projeye özel geliştirilen parçalar, önceden mevcut araçlar ve üçüncü taraf ürünler envanterde ayrıştırılmalıdır. Web tasarım tekliflerini karşılaştırırken bu ayrımı maliyet ve teslim kapsamıyla birlikte ele alın. Amaç, iki teklifin aynı başlık altında farklı bağımlılıklar içerip içermediğini görebilmektir.
Yönetim ve Ölçüm Hesaplarında Roller Belirleyin
Bütün ekip üyelerine aynı yönetici hesabını vermek yerine, yapacakları işe uygun kişisel erişimler planlayın. İçerik sorumlusunun yazı yayımlaması, muhasebenin hizmet faturalarını takip etmesi ve teknik ekibin entegrasyonları yönetmesi farklı ihtiyaçlardır. Kimlerin kullanıcı ekleyebildiği, erişim kaldırabildiği ve hesap kurtarma sürecini yürütebildiği net olmalıdır. Ekip değiştiğinde hangi kontrollerin tekrarlanacağını da görev listesine ekleyin.
Ölçüm araçlarında rapor görüntülemek ile kullanıcı yönetmek farklı yetkiler olabilir. Örneğin Google Analytics kullanıcı yönetimi belgesi, hesap ve mülk düzeyinde erişim tanımlanabildiğini açıklar. Hesap düzeyinde verilen erişim altındaki mülkleri de kapsayabilir. İşletmenizin ihtiyacını ilgili hizmetin rol yapısına göre değerlendirin; yalnızca bir rapor bağlantısına sahip olmayı hesabın yönetimini teslim almakla eş tutmayın.
Arama görünürlüğü ve ölçüm kurulumu için hangi hesapların kullanıldığını, hangi verilerin erişilebilir kaldığını ve değişiklikleri kimin onayladığını yazılı hale getirin. Bu başlıkları profesyonel web tasarım teklifindeki SEO kapsamı ile birlikte kontrol edebilirsiniz. Ajans değişikliği gündeme geldiğinde geçmiş raporlara erişimin devam etmesi, yeni ekibin mevcut durumu anlamasını kolaylaştırır.
Yedek Teslimini Geri Dönüş Gösterimiyle Tamamlayın
“Yedek alınıyor” ifadesinin karşılığını netleştirin: Hangi veriler yedekleniyor, kopyalar nerede tutuluyor, ne kadar süre saklanıyor ve gerektiğinde kim geri yüklüyor? Sitenin değişim sıklığına uygun bir düzen belirleyin. Yeni kayıtların yoğun olduğu bir e-ticaret sitesi ile seyrek güncellenen bir tanıtım sitesinin kayıp toleransı aynı olmayabilir. Yedekleme sıklığını alışkanlıkla değil, işletmenin kabul edebileceği veri kaybıyla ilişkilendirin.
Dosya yedeği ile veri tabanı yedeğinin kapsamı farklı olabilir. Örneğin WordPress yedekleme dokümantasyonu, tipik bir WordPress sitesini bütünüyle geri yüklemek için dosya ve veri tabanı bileşenlerinin birlikte gerektiğini belirtir. Kendi altyapınız için gerekli bileşenleri teknik ekiple listeleyin. Arşivin bulunduğunu görmek ile içindeki verilerden çalışan bir sistem elde etmek aynı kontrol değildir.
Geri dönüş gösterimini, canlı işletme verilerini riske atmayan uygun bir test ortamında planlayın. Seçilen yedeğin tarihi, kurulum için gereken bilgiler ve gösterilen işlevler kayıt altına alınsın. Örnek olarak hizmet sayfalarının açılması, görsellerin görünmesi ve yönetim panelinden bir test içeriğinin düzenlenmesi kontrol edilebilir. Eksik bir bağımlılık çıkarsa teslim dosyası buna göre tamamlanır; sorun yaşandığında ilk kez denenmek üzere bırakılmaz.
Destek Kapsamını Talep Türü ve Takip Kaydıyla Yönetin
Destek hakkının pratik karşılığı, hangi talebin kim tarafından ve hangi koşullarda ele alınacağının anlaşılmasıdır. Destek kanalını, çalışma saatlerini, yetkili talep sahiplerini ve öncelik tanımlarını belirleyin. İlk yanıt, incelemeye başlama, geçici çözüm ve kalıcı düzeltme farklı aşamalardır. Her biri için üzerinde anlaşılmış koşulları esas alın; genel bir destek ifadesinden kesin çözüm süresi çıkarmayın.
Bir talep kaydı örneği hazırlayın: Etkilenen sayfa, beklenen davranış, görülen sorun, ilk fark edilme zamanı ve işletmeye etkisi. Gizli müşteri verilerini veya parolaları sıradan destek mesajlarına eklemeyin. Sorunun tekrar gösterilebilmesi için gerekli bilgileri uygun kanaldan paylaşın. Bu düzen, ekibin sorunu anlamasını ve yapılan işlemlerin daha sonra izlenmesini kolaylaştırır. Kapanışta hangi kontrolün yapıldığı da kayıtta yer almalıdır.
Hata giderme, içerik güncelleme ve yeni geliştirme taleplerini örneklerle ayırın. Daha önce çalışan bir formun hata vermesi ile yeni bir bayi başvuru süreci kurulması aynı kapsam değildir. Teklifin genel çerçevesi için kurumsal site paketlerinde teslim ve destek rehberimizi kullanabilirsiniz. Buradaki ek kontrol, her talebin sınıflandırmasının, varsa ek maliyetinin ve onayının uygulamadan önce görünür olmasıdır.
Teslim Toplantısını Gerçek Görevler Üzerinden Yapın
Varsayımsal bir üretim şirketinin yeni sitesi için üç kişilik bir teslim toplantısı düşünün: İşletme yöneticisi, içerik sorumlusu ve ajansın teknik temsilcisi. Yönetici hesap envanterini inceler; içerik sorumlusu kendi hesabıyla bir hizmet metnini düzenler; teknik temsilci yedekten geri dönüşün hangi kayıtla doğrulandığını gösterir. Toplantı, yalnızca ekranların gezildiği bir sunumdan çıkarak işletmenin siteyi yönetebildiği bir kontrole dönüşür.
Bu senaryoda her teslim maddesinin bir kanıtı vardır. Erişim için başarılı oturum ve doğru rol, lisans için ürün ve koşul kaydı, yedek için geri dönüş sonucu, destek için örnek talep kaydı kullanılır. Kontrol edilemeyen maddeler açık konu olarak bırakılır; sorumlusu ve tamamlanma tarihi belirlenir. Başlangıçtaki kurumsal web tasarım briefi bu kabul maddelerini içerirse proje boyunca aynı beklentiler takip edilebilir.
- Yetkili işletme temsilcisi kendi hesabıyla gerekli yönetim alanlarına erişebiliyor mu?
- Teslim dosyalarının içeriği ve kullanılabilirliği örnek bir işlemle gösterildi mi?
- Lisansların yenileme ve hizmet sağlayıcı değişikliği koşulları kayıtlı mı?
- Yedek, geri dönüş ve destek sorumluları işletme tarafından biliniyor mu?
- Eksik teslimler ile bunların kapanış ölçütleri ortak takip listesine eklendi mi?
Ajans Değişikliğini Başlangıçta Planlanabilir Hale Getirin
İş birliğinin bir gün sona erebilmesini konuşmak, günlük çalışmanın parçası olan bir süreklilik planıdır. Devir talebinin hangi kanaldan yapılacağı, hangi dosyaların hazırlanacağı, hangi erişimlerin gözden geçirileceği ve varsa geçiş desteğinin nasıl değerlendirileceği baştan belirlenebilir. Böylece ayrılık anında bütün teknik ayrıntıları yeniden keşfetmek gerekmez. Kapsam ve koşulların açık olması, tarafların iş yükünü de görünür kılar.
Geçişte içerik güncellemelerinin hangi noktada durdurulacağını ve son değişikliklerin yeni ortama nasıl aktarılacağını belirleyin. Alan adı, e-posta, formlar, ölçüm ve dış servisler için kontrol sorumluları atayın. Eski erişimlerin gözden geçirilmesini ve gereksiz yetkilerin kaldırılmasını teslimin tamamlanmasına bağlayın. Geçiş takvimini de web tasarım aşamaları ve teslim planı içindeki bağımlılıklar gibi, karşılıklı tamamlanması gereken işler üzerinden kurun.
Site Sahipliği Konusunda Sık Sorulan Sorular
Panel Şifresini Almak Bütün Siteyi Teslim Almak mıdır?
Panel erişimi, verilen rolün izin verdiği işlemleri yapmanızı sağlar. Alan adı yönetimi, barındırma hesabı, kaynak dosyalar ve üçüncü taraf hesaplar farklı teslimler olabilir. Envanterde her birini ayrı kontrol edin. Eksik kalan erişimin günlük yönetimi veya gelecekteki geçişi nasıl etkileyeceğini ajansınızla görüşün.
Ajans Değişince Siteyi Baştan Yaptırmak Gerekir mi?
Bu karar kullanılan altyapıya, teslim kapsamına, lisans koşullarına ve yeni ekibin sistemi sürdürebilmesine bağlıdır. Baştan geliştirme gerektiğini ya da taşımanın mutlaka sorunsuz olacağını inceleme yapılmadan varsaymayın. Önce mevcut varlıkları, bağımlılıkları ve çalıştırma koşullarını değerlendirin; ardından uygulanabilir geçiş kapsamını belirleyin.
Destek Paketi Bütün Yenileme Masraflarını Kapsar mı?
Alan adı, barındırma, ücretli bileşenler ve teknik destek farklı hizmetler olabilir. Teklifte hangilerinin dahil olduğunu, yenilemelerin kim tarafından takip edildiğini ve ek giderlerin nasıl onaylandığını kontrol edin. İlk dönem kapsamı ile sonraki dönem koşullarının aynı olduğu varsayımı üzerinden bütçe oluşturmayın.
İşletmenizin Elinde Kullanılabilir Bir Teslim Dosyası Olsun
İyi hazırlanmış teslim dosyası, yeni bir ekip üyesinin sitenin nasıl yönetildiğini anlayabileceği kadar açık olmalıdır. Hesap envanteri, dosya listesi, lisans bilgileri, yedek kontrolü ve destek işleyişi aynı proje kapsamında bir araya gelmelidir. Listeyi yalnızca teslim gününde hazırlayıp bırakmayın; sorumlu kişiler veya kullanılan hizmetler değiştiğinde güncelleyin. Böylece operasyonel bilgi tek bir kişinin hafızasına bağlı kalmaz.
Yeni site projenizde bu kapsamı oluşturmak veya mevcut sitenizin teslim başlıklarını değerlendirmek için projenizi Web Tasarım Sistemleri ile paylaşabilirsiniz. Görüşmeye mevcut hesap ve hizmet listenizle gelmeniz, ihtiyaçların daha açık tanımlanmasını sağlar. Doğru başlangıç noktası, hangi varlıkları yönettiğinizi, hangi işlemleri işletme içinde sürdüreceğinizi ve hangi alanlarda düzenli desteğe ihtiyaç duyduğunuzu birlikte netleştirmektir.
Bu makalenin uzunluğu 1785 kelimedir.
Bu makale 2026-10-09 tarihinde yayınlanmıştır.