Web Sitesi Yenileme Zamanı Geldi mi? Karar İçin Sekiz Test

Web sitenizi yenileme zamanı, sitenin eski görünmesiyle değil, aşağıdaki sekiz testten kaçında altyapı kaynaklı bir başarısızlık çıktığıyla belirlenir. Testlerin çoğu düzeltilebilir sorunlar gösteriyorsa yeni bir site yerine hedefli düzeltmeler daha az risklidir; sorunlar sitenin kurulduğu altyapıdan geliyorsa ve birden fazla testte tekrarlıyorsa yenileme mantıklı hale gelir. Bu yazıda her testi bir saatten kısa sürede kendiniz yapabileceğiniz biçimde tarif ediyoruz, sonuçları tek bir karar tablosunda topluyoruz ve yenilemenin çoğu teklifte yazmayan maliyetini, yani adreslerin ve dizin geçmişinin korunmasını, ayrıca ele alıyoruz.

Okuru bir diş kliniği, bir emlak ofisi ya da on sayfalık bir KOBİ sitesi olarak düşünerek yazdık. Testler büyük e-ticaret sitelerinde de işe yarar, ama orada ürün adreslerinin taşınması ayrı bir iştir.

"Eski görünüyor" bir yenileme gerekçesi midir?

Tek başına değildir. Görünüm, ziyaretçinin güvenini etkileyen gerçek bir faktördür; ama eski görünen bir site çoğu zaman yeni bir tema, yeni fotoğraflar ve yeniden yazılmış bir ana sayfa ile toparlanabilir. Bunun için sitenin bütün altyapısını değiştirmek gerekmez.

Görünüm şikâyetinin arkasında genellikle başka bir sorun durur. "Sitemiz eski" diyen bir işletme sahibine neyi kastettiğini sorduğumuzda cevap çoğu zaman şunlardan biri olur: telefonda düzgün açılmıyor, bir metni değiştirmek için ajansı aramak gerekiyor, formdan talep gelmiyor ya da Google'da hiç görünmüyor. Bunların her biri ölçülebilir bir sorundur ve her birinin çözümü farklıdır. Yenileme kararını görünüme değil bu ölçülebilir sorunlara bağlamak, hem gereksiz harcamayı hem de gereksiz riski önler.

Aşağıdaki sekiz test bu sorunları tek tek ayırmak için kuruldu. Her testin sonunda iki soruya cevap vereceksiniz: test geçti mi, geçmediyse sorun içerikten mi yoksa altyapıdan mı kaynaklanıyor?

Test 1 ve 2: sunucudan gelen metin ve mobil kullanım

Test 1, sunucudan gelen metin. Tarayıcıda sitenizin bir hizmet sayfasını açın, sağ tıklayıp "sayfa kaynağını görüntüle" seçeneğini seçin ve sayfadaki ana paragraflardan birini bu kaynak kodda arayın. Metin kaynakta görünüyorsa sayfa sunucudan dolu geliyor demektir. Görünmüyorsa içerik yalnız JavaScript çalıştıktan sonra ekrana basılıyordur. Google bu tür sayfaları işleyebiliyor, ama JavaScript çalıştırmayan bazı yapay zeka tarayıcıları ve önizleme araçları boş bir sayfa görür. Hazır site kurucularında bu testin nasıl sonuç verdiğini hazır sitelerin yapay zeka aramalarındaki durumu yazısında ayrıntılı anlattık.

Başarısızlığın kaynağına bakın. Sorun tek bir kaydırıcıdan ya da bir eklentiden geliyorsa düzeltilebilir. Sitenin tamamı içeriği tarayıcıda çizen ve sunucu tarafında sayfa üretme seçeneği olmayan bir yapıdaysa, bu altyapı kaynaklı bir başarısızlıktır.

Test 2, mobil kullanım. Sitenizi kendi telefonunuzda açın ve üç şeyi kontrol edin: sayfa yana kayıyor mu, düğmeler parmakla rahat basılacak büyüklükte mi, telefon numarası dokunulduğunda arama başlatıyor mu? Bir de masaüstü tarayıcınızda geliştirici araçlarından ekran genişliğini 375 piksele indirip aynı sayfaya bakın. Tek bir tablonun taşması bir düzeltmedir. Tema mobil düzeni hiç tanımıyorsa ve her sayfada aynı taşma tekrarlıyorsa, bu altyapıya işaret eder.

Test 3 ve 4: hız ve iletişim formu

Test 3, hız. Hız için üç ölçüt var ve sınırları Google'ın Core Web Vitals açıklamasında yazılı: en büyük içeriğin ekrana gelme süresi (LCP) 2,5 saniye ya da altı, etkileşime yanıt süresi (INP) 200 milisaniye ya da altı, görsel kayma (CLS) 0,1 ya da altı. Aynı belge bu sınırların kullanıcıların yüzde 75'inde karşılanmasını hedef olarak koyuyor. PageSpeed Insights'a ana sayfanızın ve en önemli hizmet sayfanızın adresini girerek hem gerçek kullanıcı verisini (varsa) hem de laboratuvar ölçümünü görebilirsiniz.

Hızda düzeltilebilir ile yapısal olanı ayırmak kolaydır. Büyük fotoğraflar, sıkıştırılmamış görseller, ana sayfada otomatik oynayan bir video ya da gereksiz bir sohbet eklentisi düzeltilebilir. Her sayfada yüzlerce kilobaytlık bir tema kodu yükleniyorsa ve tema bunun kapatılmasına izin vermiyorsa, sorun yapısaldır.

Test 4, form ve iletişim yolu. Sitenizden kendinize bir test talebi gönderin. Talep hangi adrese düşüyor, kaç dakikada ulaşıyor, spam klasörüne mi gidiyor? Formun altındaki onay kutusu ve aydınlatma metni bağlantısı çalışıyor mu? Bir de telefon ve WhatsApp bağlantılarını mobilde deneyin. Bu test görünüşte basit ama sık başarısız olur: form e-postası yıllar önce ayrılmış bir çalışanın adresine gidiyor olabilir. Bu sorunların neredeyse tamamı düzeltilebilir sınıftadır. Formun ziyaretçiyi talebe dönüştürememesinin başka nedenlerini web sitesinden talep gelmemesi teşhisi konulu yazıda adım adım ele aldık.

Test 5 ve 6: içerik güncelleme ve mülkiyet

Test 5, içerik güncelleme. Bir hizmet sayfasındaki tek bir cümleyi değiştirmek için ne yapmanız gerekiyor? Kendiniz bir yönetim panelinden beş dakikada değiştirebiliyorsanız test geçmiştir. Bir ajansa e-posta atıp birkaç gün bekliyorsanız, sorun iki türlü olabilir: panel var ama size erişim verilmemiş (düzeltilebilir), ya da site her değişikliğin kodda yapılmasını gerektiren bir yapıda (altyapı kaynaklı).

Bu test sanıldığından önemlidir. Güncellenemeyen bir site, fiyat değiştiğinde, yeni bir hizmet eklendiğinde ya da bir çalışan ayrıldığında eskimeye başlar. Yeni hizmet için yeni sayfa açılamıyorsa, aramada o hizmet için görünmenin yolu da kapanır.

Test 6, mülkiyet. Alan adı kimin adına kayıtlı? Hosting hesabı kimin? Yönetim panelinin yönetici şifresi sizde mi? Google Search Console ve analitik hesabında sahip olarak siz mi görünüyorsunuz? Bu dört sorudan birinin cevabı "ajans" ya da "bilmiyorum" ise, yenileme kararından önce bunu çözmeniz gerekir. Mülkiyet sorunu bir yenileme gerekçesi değil, yenilemenin önündeki engeldir: alan adı sizin adınıza değilse yeni site de aynı riski taşır. Hangi varlığın kimin adına olması gerektiğini ve devrin nasıl yapılacağını dijital varlık mülkiyeti kontrol listesi içinde sıraladık.

Test 7 ve 8: dizin durumu ve talep yolu

Test 7, dizin durumu. Search Console'da "Sayfalar" raporunu açın ve dizine eklenmiş sayfa sayısını sitenizdeki gerçek sayfa sayısıyla karşılaştırın. Önemli hizmet sayfalarınızdan biri "dizine eklenmemiş" grubundaysa nedenine bakın. Google arama kutusuna "site:" yazarak sayım yapmak güvenilir bir yöntem değildir; Search Console'un raporu esas alınmalı. Sayfanın neden dizinde olmadığını durum durum okumak için Search Console dizin durumu teşhisi yazımıza bakabilirsiniz.

Dizin sorunları çoğunlukla düzeltilebilir: yanlış bir noindex, robots.txt'de unutulmuş bir engel, site haritasının gönderilmemiş olması. Altyapı kaynaklı olan, sitenin her sayfa için ayrı bir adres üretememesi ya da aynı içeriği onlarca adreste tekrarlamasıdır.

Test 8, talep yolu. Müşterinizin en sık aldığı üç hizmeti düşünün. Her biri için sitede ayrı bir sayfa var mı? Ana sayfadan o sayfaya ve oradan iletişime kaç tıkla ulaşılıyor? Hizmet sayfası müşterinin sorduğu soruları (ne yapılıyor, kime uygun, süreç nasıl işliyor, nasıl iletişime geçilir) cevaplıyor mu? Tek bir "Hizmetlerimiz" sayfasında beş hizmetin ikişer cümleyle sıralanması bu testi geçmez. Bu sorun neredeyse her zaman içerik kaynaklıdır ve yenileme olmadan çözülür; bir hizmet sayfasının hangi bölümlerden oluşması gerektiğini hizmet sayfası nasıl yazılır başlıklı yazıda anlattık.

Karar tablosu: düzeltmek mi, yenilemek mi?

Sekiz testi yaptıktan sonra sonuçları aşağıdaki tabloya işleyin. Her satır için üç olasılık var: geçti, geçmedi ama düzeltilebilir, geçmedi ve altyapı kaynaklı.

Kararı şu kural üzerine kurabilirsiniz. Bu bir yasa değil, bir başlangıç ölçütüdür:

• Altyapı kaynaklı başarısızlık yoksa: yenilemeyin. Düzeltmeleri önceliğe göre sıralayın; çoğu birkaç haftada biter.
• Bir ya da iki altyapı kaynaklı başarısızlık varsa: önce o başarısızlığın mevcut altyapıda çözülüp çözülemeyeceğini bir uzmana sordurun. Çözülebiliyorsa kademeli iyileştirme planı daha az risklidir.
• Üç ya da daha fazla altyapı kaynaklı başarısızlık varsa, ya da test 1 ve test 5 birlikte altyapı kaynaklıysa: yenileme mantıklıdır. Bu iki test birlikte başarısızsa site hem okunmuyor hem de güncellenemiyor demektir.

Test 6 tabloda yalnız bir koşul olarak durur. Mülkiyet çözülmeden hiçbir karar uygulanmamalıdır.

Yenilemenin görünmeyen maliyeti: adresler ve dizin geçmişi

Yenileme tekliflerinin çoğu tasarımı, sayfa sayısını ve teslim süresini yazar. Mevcut adreslerin ne olacağını yazmaz. Oysa yenilemede en sık kaybedilen şey sayfaların adresleri ve o adreslerin arama motorlarında biriktirdiği geçmiştir.

Google'ın URL değişikliği içeren site taşıma belgesi bunu açıkça yazıyor: siteye yapılan önemli bir değişiklikte Google siteyi yeniden tararken sıralamada dalgalanma görülebilir; orta ölçekli sitelerde Google'ın eski adresler yerine yenilerini göstermeye başlaması birkaç hafta ya da daha uzun sürebilir. Aynı belge eski adreslerden yenilerine kalıcı yönlendirme yapılmasını, yönlendirmelerin zincir oluşturmamasını ve genel olarak en az bir yıl korunmasını öneriyor.

Bu yüzden yenileme kararı verildiği anda bir adres envanteri çıkarılmalı: sitedeki her adres, yeni sitedeki karşılığı ve karşılığı yoksa ne yapılacağı. Bu envanterin nasıl çıkarıldığını ve eşleme tablosunun hangi sütunlardan oluştuğunu site yenilemede sıralama koruma yazımızda ayrıntılı anlattık. Envanter teklif aşamasında istenmezse, yenileme bittikten sonra ortaya çıkan kayıp, yenilemenin kendi maliyetinden büyük olabilir.

Bir de yeniden yazılan içeriğin riski var. Yeni sitede hizmet sayfaları kısaltılırsa, eski sayfaların aramada aldığı gösterim de kısalır. Yenileme, içeriği silmek için değil iyileştirmek için bir fırsat olarak ele alınmalı.

Kademeli iyileştirme planı: yenilemeden önce denenecek sıra

Altyapı kaynaklı başarısızlık az ise, düzeltmeleri dört dalgada yapmak riskleri dağıtır. Her dalganın sonunda Search Console ve analitik verisine bakıp bir sonrakine geçin.

1. Birinci dalga, mülkiyet ve ölçüm. Alan adı, hosting ve panel erişimini kendi adınıza alın. Search Console ve analitikte sahip olun. Test 4'teki formu düzeltin. Bunlar görünür bir değişiklik yaratmaz ama sonraki adımların ölçülebilmesini sağlar.
2. İkinci dalga, teknik engeller. Dizin engellerini kaldırın, site haritasını gönderin, ağır görselleri sıkıştırın, gereksiz eklentileri kapatın.
3. Üçüncü dalga, talep yolu. En çok iş getiren üç hizmet için ayrı ve eksiksiz sayfalar yazın, iletişim yolunu her sayfada görünür yapın.
4. Dördüncü dalga, görünüm. Tema güncellemesi, yeni fotoğraflar, ana sayfanın yeniden düzenlenmesi.

Bu sıranın bir mantığı var: görünüm en sona bırakılıyor, çünkü diğer üç dalga yapılmadan yapılan görsel yenileme, sorunu çözmeden yalnızca görünüşünü değiştirir. Dört dalga bittikten sonra sekiz testi yeniden yapın. Altyapı kaynaklı başarısızlıklar hâlâ duruyorsa, yenileme kararı artık veriye dayanır.

Yenileme kararı verildiyse ilk üç adım

Testler yenilemeyi gösterdiyse, teklif istemeden önce üç işi tamamlamanız ileride ortaya çıkabilecek çoğu sorunu önler.

Birinci adım, mevcut durumun fotoğrafı. Search Console'dan son on iki ayın sayfa bazlı tıklama ve gösterim verisini dışa aktarın. Hangi sayfaların trafik aldığını bilmek, yeni sitede hangi adreslerin mutlaka korunacağını gösterir. Aynı fotoğraf, yenileme sonrasında karşılaştırma yapmanızı da sağlar.

İkinci adım, adres envanteri. Mevcut sitedeki bütün adresleri bir tabloya dökün. Sayfa sayısı azsa bunu elle yapabilirsiniz; site haritanız varsa oradan başlayın.

Üçüncü adım, kabul ölçütleri. Yeni sitenin teslim alınmadan önce hangi testlerden geçeceğini yazın. Yukarıdaki sekiz testin kendisi iyi bir başlangıç listesidir. Yayın öncesinde neye bakılacağını web sitesi teslim kabul testi içinde madde madde sıraladık.

Teklif istemeden önce hazırlanacak tek sayfalık belge

Teklif almak için ajanslara gönderilecek belge, iki teklifi aynı ölçüyle karşılaştırmanızı sağlamalı. Bu belgenin bir sayfayı geçmesi gerekmez ama şu başlıkları içermelidir:

• Test sonuçları: sekiz testin tablosu, hangi başarısızlığın altyapı kaynaklı olduğu.
• Korunacak adresler: trafik alan sayfaların listesi ve yeni sitede karşılıklarının istendiği.
• Sayfa planı: her hizmet için ayrı sayfa, iletişim, hakkımızda ve gerekli hukuki sayfalar.
• İçerik sorumluluğu: metinleri kimin yazacağı, kimin onaylayacağı.
• Mülkiyet: alan adı, hosting, panel ve hesapların teslimde kimin adına olacağı.
• Yayın sonrası: güncelleme, yedekleme ve güvenlik yamalarının kimde olacağı.

Son madde çoğu teklifte eksik kalır. Yayından sonra sitenin bakımını kimin, hangi yanıt süresiyle üstleneceğini web sitesi bakım sözleşmesi yazısında madde madde ele aldık. Bu belgeyle gelen iki teklif, aynı soruya cevap verdiği için karşılaştırılabilir hale gelir.

Sekiz testin sonucunu okumak: düzeltme mi, yenileme mi

Sekiz testin tamamını teknik bilgi gerektirmeden kendiniz yapabilirsiniz; toplam süresi yarım günü geçmez. Test sonuçlarını tabloya işlemek ve düzeltilebilir ile altyapı kaynaklı başarısızlığı ayırmak ise bazen bir uzman görüşü ister. Özellikle test 1, 3 ve 5'te bir sorunun mevcut altyapıda çözülüp çözülemeyeceğini anlamak, o altyapıyı tanıyan birinin bakmasını gerektirir.

Ön görüşmede bu testlerin sonucunu birlikte okuruz; sonuç "yenilemeyin, şu üç düzeltmeyi yapın" da olabilir. Yenileme kararı verildiğinde kurumsal bir sitenin sayfa planı, teknik altyapı ve teslim kapsamının nasıl kurulduğunu kurumsal web sitesi hizmeti sayfamızda anlattık. Yenilemeyi kiminle yaparsanız yapın, kararı sitenin nasıl göründüğüne değil, sekiz testin sonucuna dayandırmanızı öneriyoruz.

Sıkça Sorulan Sorular

Web sitemi ne zaman yenilemeliyim?

Sitenin eski görünmesi tek başına yeterli bir gerekçe değildir. Sunucudan gelen metin, mobil kullanım, hız, form, içerik güncelleme, mülkiyet, dizin durumu ve talep yolu testlerinden üç ya da daha fazlası altyapı kaynaklı bir başarısızlık gösteriyorsa yenileme mantıklıdır. Özellikle site hem sunucudan boş geliyor hem de içeriği güncellenemiyorsa, düzeltme yerine yenileme daha az maliyetli olabilir.

Web sitesini yenilemek Google sıralamasını düşürür mü?

Düşürebilir. Google'ın site taşıma belgesi, önemli değişikliklerde Google siteyi yeniden tararken sıralamada dalgalanma görülebileceğini ve orta ölçekli sitelerde yeni adreslerin eskilerinin yerini almasının birkaç hafta ya da daha uzun sürebileceğini yazıyor. Kaybı sınırlamanın yolu, eski adreslerden yenilerine kalıcı yönlendirme yapmak, zincir yönlendirmeden kaçınmak ve yönlendirmeleri en az bir yıl korumaktır.

Mevcut siteyi düzeltmek mi yeni site yaptırmak mı daha ucuz?

Sorunların çoğu içerik ya da ayar kaynaklıysa düzeltmek neredeyse her zaman daha ucuz ve daha az risklidir. Sorunlar sitenin kurulduğu altyapıdan geliyorsa, örneğin site sunucu tarafında sayfa üretemiyor ya da her metin değişikliği kod gerektiriyorsa, sürekli yama yapmak zamanla yeni bir siteden pahalıya gelebilir. Karşılaştırmayı tutarlarla yapmak için iki teklifi aynı test tablosuna dayandırın.

Web sitesi kaç yılda bir yenilenmeli?

Sabit bir süre yoktur ve sabit süre vermek yanıltıcıdır. Bir site beş yıl sonra da bütün testleri geçebilir, bir başkası iki yılda altyapı sorunu biriktirebilir. Yılda bir kez sekiz testi tekrarlamak ve sonuçları önceki yılla karşılaştırmak, yenileme zamanını takvimden değil sitenin kendi durumundan okumanızı sağlar.

Web sitesi yenilemede eski içerikler korunabilir mi?

Korunabilir ve trafik alan içerikler korunmalıdır. Yenileme öncesinde Search Console'dan sayfa bazlı veriyi dışa aktarıp hangi sayfaların gösterim ve tıklama aldığını belirleyin, bu sayfaların metnini yeni sitede kısaltmadan taşıyın ve adresleri değişiyorsa her birini yeni karşılığına kalıcı olarak yönlendirin. İçeriği yeniden yazmak gerekiyorsa, mevcut metni silmek yerine geliştirmek daha güvenli yoldur.