Karar şu ayrımdan çıkar: sorun görünüşte ve içerikteyse düzeltme yeter, sorun altyapıdaysa baştan yapmak daha az masraflı olur. Yönetim panelinden sayfa eklenemiyor, şablonun üretici desteği bitmiş, mobil görünüm şablonun kendisinden bozuk ise her düzeltme bir sonrakini zorlaştırır; buna karşılık yazı tipi eski, metinler yetersiz ya da sayfa yavaş diye siteyi baştan yapmak gereksiz bir masraftır. Aşağıda belirtiye göre bir karar tablosu, baştan yapılırken korunması gerekenler ve düzeltme yolunu seçtiyseniz izlenecek sıra var.
Önce teşhis: üç soru
Teklif almadan önce şu üç sorunun cevabını kendiniz verin. Birincisi: içeriği kendiniz güncelleyebiliyor musunuz? Bir fiyat listesini, bir hizmet metnini ya da bir fotoğrafı değiştirmek için her seferinde dışarıya iş açılıyorsa, sitenin yönetilebilirliği kaybolmuş demektir. İkincisi: site telefonda kullanılabiliyor mu? Ziyaretin büyük bölümü mobilden geliyor; menü açılmıyorsa, yazı okunmuyorsa ya da sayfa yana kayıyorsa bu düzeltilebilir bir hata da olabilir, şablonun yapısal sınırı da. Üçüncüsü: teknik olarak güncellenebiliyor mu? Altyapı ya da şablon artık güncelleme almıyorsa, güvenlik tarafı zamanla kendiliğinden kötüleşir.
Bu üç sorunun cevabı "evet" ise elinizde düzeltilecek bir site var. İkisi "hayır" ise tartışma baştan yapmaya kayar. Karar vermeden önce ölçüm yapmak da işe yarar: Search Console'da hangi üç raporu okumak yeterli yazısı, sitenin aramada ne durumda olduğunu görmenin en kısa yolunu anlatıyor; mevcut sitenin aramadan iş getiren sayfaları varsa bunları bilerek karar vermek gerekir.
Karar tablosu
Tablodaki her satır tek bir belirti ve o belirtinin hangi tarafa işaret ettiği:
| Belirti | Düzeltme yeter | Baştan yapmak gerekir |
|---|---|---|
| Yazı tipi, renk ve görseller eski duruyor | Evet | — |
| Metinler yetersiz, hizmet sayfaları ince | Evet | — |
| Sayfa yavaş açılıyor | Çoğu durumda evet | Şablon ağırsa ve değiştirilemiyorsa |
| Telefonda tek sayfada yana kayma var | Evet | — |
| Mobil görünüm şablonun tamamında bozuk | — | Evet |
| Panelden yeni sayfa eklenemiyor | — | Evet |
| Şablon ya da altyapı güncelleme almıyor | — | Evet |
| Site tekrar tekrar zararlı kod alıyor | Bir kez olduysa temizlik | Tekrarlıyorsa evet |
| Menü ve adres yapısı dağılmış | Evet, yönlendirmeyle | — |
| Yeni dil, yeni şube ya da yeni iş kolu eklenecek | Yapı izin veriyorsa | Yapı tek sayfaya kurulmuşsa |
| Siteyi kimin yönettiği ve dosyaların nerede olduğu bilinmiyor | — | Önce envanter, sonra karar |
Son satır özellikle önemli: erişimlerin ve dosyaların kimde olduğu bilinmeden verilen "baştan yapalım" kararı, çoğu zaman yarısı eski yarısı yeni bir siteyle sonuçlanır. O tabloyu dijital varlık envanteri yazısındaki yöntemle çıkarmak, kararın kendisinden önce gelir.
Baştan yapılıyorsa korunacaklar
Yeni site, eski sitenin kazandığı değeri silmek zorunda değil. Sırayla korunacaklar:
- Adresler. Aramadan trafik alan sayfaların adresi değişiyorsa her biri yeni karşılığına yönlendirilir. Hangi durumda yönlendirme, hangi durumda sayfanın kapatılması gerektiği silinen sayfa 404 mü kalsın, 301 ile mi yönlendirilsin yazısında duruyor.
- İçerik ve görseller. Eski sitedeki metinler ve fotoğraflar, yeni site açılmadan önce kaynağıyla birlikte indirilir; yayın kapanınca geri dönmek zorlaşır.
- Kurumsal e-posta. Site taşınırken alan adı kayıtlarına dokunulur ve posta kayıtları yanlışlıkla silinirse e-posta durur. Yeni sunucuya geçmeden önce mevcut kayıtların bir kopyası alınır.
- Arama konsolu geçmişi. Yeni site aynı mülk üzerinde kalırsa karşılaştırma yapabileceğiniz geçmiş de kalır.
- Alan adı sahipliği. Alan adı işletmenin kendi hesabında durur; yeni siteyi yapan taraf yönetici olarak eklenir, sahibi olmaz.
- Formlar ve ölçüm hedefleri. Eski sitede çalışan form ve ölçüm hedefleri yeni sitede yeniden kurulur; aksi hâlde yeni site "daha az iş getiriyor" gibi görünür.
Düzeltme yolunu seçtiyseniz sıra
Düzeltme kararında en sık yapılan hata rastgele başlamaktır. İş getiren sırası şu: önce ölçüm kurulur, sonra hangi sayfaların gösterim aldığı görülür, düzeltme o sayfalardan başlar. Ardından mobil tarafı: taşma, dokunma alanları, okunurluk. Sonra hız; sonra içerik derinliği; en sonda görsel tazeleme. Erişilebilirlik tarafını da bu sıraya katmak gerekir, çünkü oradaki hatalar hem kullanıcıyı hem aramayı etkiler.
Düzeltme sırasında her değişikliği tek tek yayına almak, bozulan şeyi bulmayı kolaylaştırır. Toplu bir müdahalede sayfa hızı düşse ya da bir sayfa aramadan kaybolsa nedenini ayırmak zorlaşır.
Düzeltme yolunun bir avantajı daha var: işi parçalara bölebildiğiniz için her adımın sonucunu görerek ilerlersiniz. Bir hizmet sayfasını yeniden yazdıktan sonra o sayfanın gösterimi ve tıklaması değişti mi, formdan talep geldi mi, bunlar ölçülebilir. Baştan yapma kararında ise sonuç ancak yayından sonra görülür; bu yüzden baştan yapmaya giden işletmenin yayın öncesinde hangi sayfaların iş getirdiğini yazılı olarak bilmesi gerekir. Aksi hâlde yeni sitenin daha iyi mi kötü mü olduğu tartışması ölçüye değil izlenime kalır.
Yayına almadan önce
- Hazırlık sırasında kapatılan dizine ekleme engeli kaldırıldı mı?
- Site haritası güncellendi ve gönderildi mi?
- Eski adreslerin yönlendirmeleri tek tek denendi mi?
- Formlar gerçek bir adrese ileti düşürüyor mu?
- Kurumsal e-posta gönderip almaya devam ediyor mu?
- Yayın öncesi ve sonrası yedek alındı mı? (neyi, nereye, ne sıklıkla yedeklemeli)
Özet
Siteyi baştan yapma kararı yaşla değil belirtiyle verilir: yönetilemeyen panel, güncellenmeyen altyapı ve yapısal mobil bozukluk baştan yapmayı haklı çıkarır; görünüş, metin ve hız çoğu zaman düzeltmeyle kapanır. Hangi yolu seçerseniz seçin adresleri, içeriği, e-postayı ve alan adı sahipliğini korumak aynı kalır. DigiWSS, bu kararı ölçümle veren ve her iki yolda da işletmenin mevcut varlıklarını kaybetmeyen bir düzen kurar.