'Bitti' Web Sitesi Bir Efsanedir: Patronunu Bakıma İkna Et

Summary

Çoğu küçük pazarlama ekibi, yayını bitiş çizgisi olarak görür, ancak canlı bir web sitesi tekrar eden bir sorumluluktur: alan adları yenilenmeli, barındırma için ödeme yapılmalı, yazılımlar yamalanmalı ve içerik güncellenmelidir. Teknik olmayan bir patrona sunum, 'daha fazla web sitesi işi' olarak çerçevelendiğinde başarısız olur ve geliri ve itibarı korumak olarak çerçevelendiğinde başarılı olur. Bu makale, gerçek başarısızlık modunu — yayından sonra sessizce çürüyen bir site — inceliyor ve alan adı kaydı, güvenlik ve arama görünürlüğü etrafında somut örnekler kullanarak bakım bütçesi için pratik bir gerekçe oluşturuyor. Projeden sisteme zihinsel geçişi, yayından sonra gerçekleşmesi gereken belirli görevleri ve bir patronu gerçekten ikna eden konuşmayı kapsar. Ayrıca güvenlik argümanının neden bilgisayar korsanlarıyla başlamaması gerektiğini ve bakımın teknik işler yerine iş sonuçlarıyla nasıl ilişkilendirileceğini öğreneceksiniz.

Patronunuz az önce web sitesinin "bittiğini" ilan etti — peki neden bu kelime midenizi bulandırıyor?

Bunu daha önce yaşadınız. Dört hafta önce yayınladınız ve kutlamalar henüz sönmedi. Sonra ilk düzenleme talebi gelir (fiyatlandırma sayfasında bir yazım hatası var). Sonra bir satış elemanı sitenin neden Google'dan kaybolduğunu kontrol eden olup olmadığını sorar. Sonra şifre yöneticiniz tanımadığınız bir giriş hakkında sizi uyarır. Hiçbir şey felaket derecede bozuk değil ve sorun tam olarak bu: site yüz küçük yönden çürüyor ve patronunuz hâlâ projenin bittiğine inanıyor çünkü kimse canlı bir sitenin devam eden bir iş gerektirdiğini söylemedi.

Asıl boşluk bu. Web sitesi oluşturma kılavuzları genellikle planlama, bilgi mimarisi, tel kafes (wireframe), tasarım, içerik, geliştirme, test ve yayın aşamalarını anlatır. Bu, insanların çoğu yeni web sitesi sahibinin atladığı planlama adımını atlamasına neden olan aynı boşluktur, ancak bu sefer yayından sonraki adımdır. Bakım, dokuzuncu, görünmez aşamadır ve sitenizin bir varlık olarak mı kalacağını yoksa yavaşça bir yükümlülüğe mi dönüşeceğini belirleyen aşamadır.

Bu boşluğun maliyeti görünmezdir, ta ki görünür hale gelene kadar: bir ürün lansmanı sırasında süresi dolan bir alan adı, yeniden tasarımdan bir hafta önce sessizce başarısız olan bir yedek, bir aydır hiçbir şey toplamayan bir form. Bunların hiçbiri dramatik değil. Hepsi pahalı.

Build mode and live mode are different jobs

Web sitenizi yönettiğiniz bir mülk gibi düşünün. Bir bina inşa etmek bir projedir; onu işletmek bir süreçtir. Bir depo inşa edip sonra çatıyı hiç kontrol etmez, envanteri yeniden sipariş etmez veya bir çalışan ayrıldığında kilitleri değiştirmezsiniz. Bir web sitesi de aynı şekilde davranır, ancak proje/süreç ayrımı kaybolur çünkü inşaat malzemeleri dijitaldir ve maliyetler küçüktür.

Bu ayrım tek bir nedenle önemlidir: patronunuzun neyi onayladığını değiştirir. Yapım modunda hedef "gerçek yapmak"tır. Canlı modda hedef "güvenilir tutmak"tır. Aşağıdaki tablo, teknik olmayan paydaşlarla kullandığım sürümdür, çünkü "bitti" gibi hissettiren her şeyi, site canlı olduğunda gerçekte ne anlama geldiğiyle eşleştirir.

Alan	Patronun "bitti" derken kastettiği	"Bitti" aslında ne anlama geliyor
Alan adı	Adresi satın aldık, yani bizim	Adres belirli bir süre için kayıtlıdır; ICANN'in süreç açıklamasına göre, bir isim seçer, bir kayıt şirketi aracılığıyla kullanılabilirliği kontrol eder ve iletişim bilgilerini sağlarsınız. Bu bilgiler yenileme bildirimlerini kimin alacağını belirler, bu yüzden doğru ve takip ediliyor olmalıdır
Barındırma	Dosyalar internette bir yerde	IBM, web barındırmayı sitenizin dosyalarını internet erişimi için bir sunucuda saklamak olarak tanımlar. Bu sunucu maliyeti olan yinelenen bir ilişkidir ve birinin ona nasıl giriş yapılacağını bilmesi gerekir
Yazılım	En son sürümle yayınladık	Yazılımlar yamalanır, eklentiler güncellenir ve entegrasyonlar gözden geçirilmeli. Tüm bunlar yayından sonra olur, öncesinde değil
İçerik	Metin onaylandı	İçerik, pazarınızla bir konuşmadır. Teklifler, fiyatlar, kanıt noktaları ve ürün adları değiştikçe bayatlar
Arama	Google bizi biliyor	Arama motorlarının yeniden ziyaret edilmesi gerekir; XML site haritalarına yeni URL'ler eklenmeli, robots.txt dosyaları doğru kalmalı ve teknik temel sağlıklı kalmalı

Bu tabloyu iki şekilde okuyabilirsiniz. Bir iş listesi olarak, bunaltıcı. Web sitenizin aslında ne olduğunun bir açıklaması olarak — sizin kontrol ettiğiniz girdileri olan bir sistem — aydınlatıcı. Patronunuz kapanış istemekte yanlış değil. Kapanışın neye benzediği konusunda yanlışlar.

Burada ayrıca bir no-code uyarısı var. Siteniz sürükle-bırak bir oluşturucuyla yapıldıysa, platform sağlayıcısı sunucu kodunu halleder, ancak içeriğiniz, erişiminiz ve entegrasyonlarınız yine de bakım gerektirir. No-code, yapım işinin çoğunu ortadan kaldırır; canlı mod işini ortadan kaldırmaz.

Make maintenance a calendar, not a scare story

Peki nereden başlıyorsunuz? Dramatik bir güvenlik sunumuyla değil. En somut, en az duygusal tekrarlanan görevle başlayın ve etrafında bir takvim oluşturun.

Alan adını ele alalım. Kurucunun beş yıl önce kişisel bir e-posta adresiyle kaydettiğini düşünün. Kayıt şirketinin paneli, yalnızca bir kişinin bildiği bir girişin arkasında. ICANN'in alan adı kayıt süreci bir isim seçmekle başlar, kayıt şirketi aracılığıyla kullanılabilirliği kontrol etmekle ve iletişim bilgileri sağlamakla — ve bu iletişim bilgisi, kayıt şirketini gerçek bir insana bağlayan kordondur. İletişim e-postası izlenmezse, yenileme bildirimi kimsenin okumadığı bir posta kutusuna düşebilir. Çözüm teknolojik bir revizyon değil; bir elektronik tablo satırı, paylaşılan bir gelen kutusu ve yenilemeden üç hafta önce bir takvim hatırlatıcısı. Sıkıcı. Bu yüzden ilk madde için mükemmel: bakımın küçük, yönetilebilir görevlerden oluştuğunu kanıtlıyor.

Şimdi barındırmayı yapın. IBM'in açıklaması kulağa basit geliyor — dosyalarınız bir sunucuda yaşar — ancak her sunucunun depolama sınırları, bant genişliği maliyetleri ve kimlik bilgileri vardır. Barındırmayı kuran kişi, alan adını kuran kişiyle aynıysa ve o kişi altı ay önce ayrıldıysa, kendi sitenizden kilitlenmenize bir giriş uzaktasınız. Bakım çözümü, her hizmeti tek bir belgeye taşımak, kimin erişimi olduğunu not etmek ve yıllık bir denetim planlamaktır. Büyük bir bütçe istemiyorsunuz. Kapıların kilitlenmesini önlemek için ayda bir saat istiyorsunuz.

Aynı mantık bağımlı olduğunuz her hizmet için geçerlidir: e-posta listeleri, ödeme işlemcileri, form araçları. Her birinin bir girişi, bir fatura döngüsü ve orijinal sahibi ayrılırsa onu kurtarabilmesi gereken biri vardır. Hepsini tek bir tabloya koyun. Takvimle başlamanın güzelliği, eski "bu bir teknoloji sorunu" itirazını aşmasıdır. Yenilemeler ve erişim incelemeleri takvimi bir proje yönetimi sorunudur ve her teknik olmayan patron proje yönetimini anlar.

The threat that isn't a hacker

Güvenlik konuşması genellikle yanlış kötü adamla başladığı için başarısız olur. "Biz küçük bir pazarlama sitesiyiz" dersiniz kendinize. "Kimse bizi hedeflemiyor." Ve muhtemelen haklısınız — ancak en olası tehdit hedefli bir bilgisayar korsanı değil. İhmal.

UpGuard'ın web sitesi güvenliği kılavuzu standart önlemleri sıralar: yazılımı güncel tutun, çok faktörlü kimlik doğrulama gibi güçlü kimlik doğrulama uygulayın, kullanıcı ayrıcalıklarını sınırlayın, verileri yedekleyin ve SSL/TLS şifrelemesi kullanın. Bu listede ne fark ederseniz edin, önemli olan kip (zaman) ekidir. Bunlar devam eden uygulamalardır, yayın günü onay kutuları değil.

Somut hale getirelim. Birçok dahili ekip, herkesin kullandığı tek bir paylaşılan yönetici girişine sahip bir siteyi devralır: satış ekibi, pazarlama stajyeri, tek bir blog yazısı yazan serbest çalışan. Serbest çalışanın kim olduğunu kimse bilmiyor. UpGuard buna kullanıcı ayrıcalığı sorunu der; siz buna patronunuzun zaten anladığı bir risk diyebilirsiniz. Kimin giriş yapabileceğini bilmiyorsanız, ana sayfayı kimin düzenleyebileceğini, fiyatlandırmayı kimin değiştirebileceğini veya orada olmaması gereken bir şeyi kimin yükleyebileceğini bilemezsiniz. Çözüm basit: şifreleri sıfırlayın, bireysel hesaplar oluşturun ve insanlar ayrıldığında erişimi kaldırın. Bu bir güvenlik projesi değil; bir güvenlik işi.

Ters bir öneri yapacağım: bütçe için teklif verirken güvenlikle başlamayın. Küçük bir ekip için "güvenlik" kelimesi ya "BT bütçemiz yok" ya da "bu bize olmaz" tepkisini tetikler. Eylemi tetikleyen şey somut bir ramak kala: süresi dolmuş bir SSL/TLS sertifikası nedeniyle tarayıcı uyarısı, hiç çalışmayan bir yedek, hâlâ giriş yapabilen eski bir yüklenici. Aylık bir "site sağlığı" bloğu için bir gerekçe oluşturmak üzere bu somut öğeleri kullanın. Korku satmıyorsunuz; yeterlilik satıyorsunuz.

Ve şu anda yeni bir site kuruyorsanız, ilk günden itibaren SEO ve güvenlikle no-code bir site başlatmayı başka bir yerde ele aldık — ancak ilk gün disiplini, yalnızca on ikinci ay disiplinine dönüşürse işe yarar.

Search doesn't wait for you

Bir sitenin çürümesinin ikinci nedeni daha sessizdir çünkü site dışında gerçekleşir. Arama motoru optimizasyonu tek seferlik bir kurulum değildir. Digital Marketing Institute'un kılavuzu SEO'yu, arama sıralamalarını, kullanıcı deneyimini ve marka güvenilirliğini iyileştirmek için içeriği, yapıyı ve teknik unsurları optimize etmek olarak tanımlar. "Optimize etme" kelimesi zaman içinde değişimi ima eder, bitmiş bir durumu değil.

Gerçekçi bir senaryo: satış müdürünüz, kendi ürün adınızda neden bir rakibin sizden üstün sıralandığını sorar. Araştırırsınız ve XML site haritasının yayından beri güncellenmediğini ve robots.txt dosyasının yeni sayfaların bir bölümünü engellediğini bulursunuz. Bunların ikisi de ilk günde bitmiş gibi hissettiren teknik kurulum görevleridir. Çözüm, on dakikalık aylık bir incelemedir: site haritasına yeni URL'ler ekleyin, yeniden gönderin ve robots dosyasının en iyi içeriğinizi gizlemediğini kontrol edin. SEO rehberliği üzerine araştırmalar ayrıca teknik temelin bir parçası olarak HTTPS güvenliğine işaret eder — bu da az önce planladığınız güvenlik görevlerine geri döner.

Arama çürümesinin en kötü yanı, ilerleyici olmasıdır. Sıralamaları nadiren tek bir günde kaybedersiniz; bir pozisyon orada, bir pozisyon burada kaybedersiniz, ta ki bir rakip bir sayfanın yerini tamamen alana kadar. Arama aynı zamanda bakım için en iyi iş argümanıdır çünkü doğrudan gelire bağlanır. Arama altyapısını korumayan bir site dramatik bir "hack"te kaybolmaz; teknik düzenini koruyan rakiplere müşterileri sessizce teslim eder.

Selling upkeep to the person who signs the checks

Bu bizi kaçındığınız konuşmaya getiriyor. Bütçe istemeniz veya en azından ekibin takviminde boşluk istemeniz ve patronun gözleri donmadan "evet" demesi gerekiyor.

Gelir korumasıyla başlayın. "Teknik borcumuz var" veya "CMS'mizi güncellememiz gerekiyor" demeyin. "Site vitrindir ve vitrinlerin düzenli bakıma ihtiyacı vardır" deyin. Daha önce oluşturduğunuz bakım takvimini kanıt olarak kullanın: işte yenileme tarihleri, işte erişim incelemeleri, işte her ay çalıştırdığımız yedek testi. Patrondan size güvenmesi istenmiyor; zaten çalışan bir sistem gösteriliyor.

Sonra onlara bir seçenek verin. İki veya üç kademe sunun: minimum bakım (alan adı, barındırma, yedekler, SSL), sağlıklı bakım (içerik güncellemeleri ve arama kontrolleri ekleyin) ve aktif büyüme (denemeler, açılış sayfaları ve özel destek ekleyin). Kararı "hangi güvenilirlik seviyesini istiyorsunuz?" olarak çerçevelediğinizde, "daha fazla para harcayabilir miyiz?" yerine, patron bir sonuç seçiyor, bir teknoloji harcamasını onaylamıyor.

Bir uyarı: patron yine de hayır diyebilir. Bu olursa, en önemli iki riski — genellikle erişim kontrolü ve yedek doğrulama — alın ve ne kadar boş zamanınız olursa olsun yine de düzeltin. "Hayır"ı görmezden gelmiyorsunuz; bakımın ölçülebilir bir fark yarattığını göstermek için zaman kazanıyorsunuz. Bu, müşteri sitesi bakım olgunluk modelinin arkasındaki mantıkla aynıdır, "müşteriniz" kendi iç paydaşınız olsa bile. Model, bir siteyi yangınlardan çerçevelere taşır ve iki kişilik pazarlama ekibinde de ajans kadar iyi çalışır.

The finished website doesn't exist

Yayınladığınız web sitesi, işlettiğiniz web sitesi değildir. İşiniz değiştiği için, yazılımlar değiştiği için ve web'in kendisi değiştiği için değişir. Tek gerçek soru, bu değişimi bilinçli olarak, küçük bir bütçe ve takvimle mi yoksa kazara, bir dizi panik içinde mi yöneteceğinizdir.

En küçük somut şeyle başlayın: bir takvim hatırlatıcısı, paylaşılan bir gelen kutusu, bir hesap denetimi. Bu gösterişsiz görevler genel gider değildir. İnşa etmek için çok çalıştığınız sitenin kaputun altında sessizce paslanmasını önleyen şeylerdir. Patronunuz sırada ne olduğunu sorduğunda gülümseyin ve takvimi gösterin. Sitenin gerçek devam eden işi budur.