Site yenilendi. Tasarım daha iyi, sayfalar daha hızlı, herkes memnun. Üç hafta sonra trafik yarı yarıya düşmüş durumda ve kimse ne olduğunu anlamıyor.
Bu, SEO’da en sık tekrarlanan ve en pahalı senaryodur. Pahalıdır çünkü kaybedilen şey yıllar içinde birikmiş bir sinyal yığınıdır — ve tamamı geri gelmeyebilir.
İyi haber: sebepler kısıtlı ve neredeyse hepsi düzeltilebilir. Kötü haber: ne kadar geç fark edilirse toparlanma o kadar uzun sürer.
Bu yazı hem düşüş yaşamış siteler için teşhis rehberi, hem de yenileme planlayan siteler için önleme listesi. Ayrıca 2026 itibarıyla sık karşılaşılan yeni nesil site oluşturucuların (headless CMS, no-code platformlar) yenileme projelerine kattığı ek riskleri de kapsıyor.
Neden Yenileme Bu Kadar Riskli?
Bir sitenin arama motorundaki değeri, göründüğü şeyden ibaret değildir. Her URL, arkasında yıllarca biriken bir kayıt taşır: hangi sorgularda gösterildiği, kaç kişinin tıkladığı, hangi sitelerin ona bağlantı verdiği, hangi sayfalarla ilişkilendirildiği.
Bu kaydın tamamı adrese bağlıdır. Adres değiştiğinde ve doğru şekilde devredilmediğinde, kayıt yeni adrese taşınmaz — sıfırdan başlanır.
Tasarımcının gördüğü: Sayfa daha iyi görünüyor, içerik aynı, her şey yerli yerinde.
Arama motorunun gördüğü: Yıllardır bildiği yüzlerce adres kayboldu, yerine hiç tanımadığı yeni adresler geldi.
Yenilemenin SEO tarafı, tasarımdan bağımsız bir iştir ve genellikle proje planında yer almadığı için sonradan fark edilir.
Yenileme projelerinde SEO’nun neden gözden kaçtığı
Bu durumun kök sebebi genellikle organizasyonel. Yenileme projesi tipik olarak şu ekipler tarafından yürütülüyor: tasarım ekibi (görsel dil), geliştirme ekibi (teknik altyapı) ve pazarlama ekibi (içerik). SEO ise çoğu zaman bu üç ekibin “birinin işi” değil, “aralarında bir yerde” kalan bir sorumluluk olarak görülüyor. Proje planlaması yapılırken “SEO denetimi” ayrı bir görev olarak listelenmediği sürece, hiçbir ekip bunu kendi sorumluluğu saymıyor ve süreç sonunda kimse yönlendirme haritasını hazırlamamış oluyor.
İkinci sebep ise zaman baskısı. Yenileme projeleri genelde bir teslim tarihine bağlı yürütülüyor ve bu tarih yaklaştıkça “gerekli olmayan” işler listeden çıkarılıyor. SEO denetimi, görsel olarak fark edilmediği için bu listede ilk çıkarılan kalemlerden biri oluyor — ta ki trafik düşüşü fark edilene kadar.
Sebep 1: Yönlendirmeler Kurulmadı veya Eksik Kuruldu
Vakaların büyük çoğunluğunun sebebi budur.
Eski URL yapısı /hizmetler/web-tasarim.html idi, yeni yapı /hizmetler/web-tasarim/ oldu. Aradaki köprü kurulmadıysa:
- Eski adrese gelen ziyaretçi 404 sayfası görür
- Yıllardır o adrese verilmiş dış bağlantılar boşa düşer
- Arama sonuçlarındaki mevcut kayıtlar hatalı sayfaya gider
- Birikmiş sinyal yeni adrese aktarılmaz
Doğrulama:
Yaygın hata: Tüm eski URL’leri toplu olarak ana sayfaya yönlendirmek. Bu, teknik olarak 404’ten iyidir ama neredeyse aynı ölçüde zararlıdır — çünkü Google alakasız yönlendirmeleri “yumuşak 404” olarak değerlendirebilir. Her sayfa, içerik olarak en yakın karşılığına yönlendirilmelidir.
Karşılığı olmayan sayfalar için doğru cevap ana sayfa değil, en yakın kategori sayfasıdır.
Yönlendirme kurulumunda platform bazlı farklılıklar
Kullandığınız platforma göre yönlendirme kurulumunun zorluk derecesi değişir:
| Platform tipi | Yönlendirme kurulumu | Dikkat edilecek |
|---|---|---|
| Klasik CMS (kendi sunucusu) | Sunucu yapılandırma dosyası veya eklenti üzerinden | Zincirlenme riski, eklenti çakışması |
| Barındırılan site oluşturucu | Panel üzerinden basit arayüz | Toplu (bulk) yönlendirme desteği sınırlı olabilir |
| Headless CMS + özel önyüz | Kod seviyesinde, geliştirme ekibi tarafından | Yayın öncesi test ortamında doğrulanmalı |
| E-ticaret platformu geçişi | Platforma özgü taşıma araçları | Ürün/kategori URL yapısı genelde köklü değişir, harita büyük olur |
Hangi platformda olursanız olun, temel kural değişmiyor: yönlendirme haritası yayın öncesi hazırlanmalı ve yayın sonrası tek tek test edilmeli.
Sebep 2: İçerik Sadeleştirildi
”Daha temiz görünsün” gerekçesiyle metinler kısaltılır. Uzun açıklamalar çıkarılır, SSS bölümleri kaldırılır, alt başlıklar birleştirilir.
Görsel olarak sonuç iyidir. Ama o metinler yalnızca dolgu değildi — sayfanın hangi sorgulara cevap verdiğini tanımlayan şeydi.
Belirti: Sıralamalar düşmemiş ama gösterim aldığınız sorgu çeşitliliği azalmış. Search Console’da sorgu sayısını dönemsel karşılaştırdığınızda net görülür.
Doğrulama: Yenileme öncesi ve sonrası için Search Console’dan sorgu listelerini çıkarıp karşılaştırın. Kaybedilen sorguların hangi metinlerle ilişkili olduğunu bulmak, neyin geri gelmesi gerektiğini gösterir.
Çözüm: Kaldırılan içeriği aynen geri koymak zorunda değilsiniz. Ama o içeriğin cevapladığı soruların yeni tasarımda bir karşılığı olmalı — açılır bölümler, ayrı bir sayfa veya yeniden yazılmış bir bölüm olarak.
Yenileme öncesi yapılması gereken: Trafik alan her sayfanın mevcut metnini bir yere kaydedin. Yenilemeden sonra “burada ne yazıyordu” sorusuna cevap verebilmenin başka yolu yoktur — ve bu soru mutlaka sorulur.
İçerik sadeleştirmesinin gizli maliyeti
Tasarım ekipleri genelde “daha az metin, daha çok görsel” prensibiyle çalışıyor ve bu, kullanıcı deneyimi açısından çoğu zaman doğru bir tercih. Ancak arama motoru tarafı için doğru çözüm, metni tamamen kaldırmak değil, metni erişilebilir tutup görünürlüğünü tasarımla yönetmek. Örneğin:
- Uzun açıklamaları “daha fazla oku” ile açılır hâle getirmek, metni sayfadan silmez, sadece varsayılan görünümü kısaltır.
- SSS bölümlerini ayrı bir akordiyon bileşenine taşımak, hem tasarımı sadeleştirir hem de içeriği korur.
- Sayfa başına bir “teknik detaylar” veya “sıkça sorulan sorular” alt sayfası açmak, ana sayfayı sade tutarken içeriği bir tık ötede saklı tutar.
Bu üç yöntem de aynı prensibi izliyor: görsel sadelik ile içerik derinliğini birbirinden ayırmak, ikisini birbirine feda etmemek.
Sebep 3: Sayfalar Silindi
Yenileme sırasında “artık gereksiz” görülen sayfalar kaldırılır. Eski kampanya sayfaları, eski blog yazıları, alt hizmet sayfaları.
Sorun şu: bir sayfanın işletme için gereksiz olması, arama motoru için değersiz olduğu anlamına gelmez. Silinen sayfaların bir kısmı düzenli trafik alıyor, bir kısmı dış bağlantı taşıyor olabilir.
Doğrulama: Yenileme öncesi Search Console verisinde tıklama alan sayfaların listesini çıkarın ve hangilerinin artık var olmadığını işaretleyin.
Çözüm sırası:
- Trafik alıyorsa geri getirin — yeni tasarımda yeniden yayınlayın
- Getirilemiyorsa, konu olarak en yakın sayfaya 301 ile yönlendirin
- Yakın karşılığı yoksa ve dış bağlantı taşıyorsa, o bağlantıyı kurtaracak bir sayfa üretmeyi değerlendirin
- Hiçbiri geçerli değilse 410 döndürerek net bir sinyal verin
Hangi sayfaların “gizli değerli” olduğunu nasıl tespit edersiniz
Bir sayfanın işletme açısından önemsiz görünüp arama motoru açısından değerli olabileceği üç tipik durum var:
- Eski bir kampanya sayfası — kampanya bitmiş olsa bile, sayfa hâlâ belirli bir sorguda (örneğin “[ürün] indirim” gibi mevsimsel bir arama) gösterim alıyor olabilir.
- Arşivlenmiş bir blog yazısı — konusu güncelliğini yitirmiş görünse de, düzenli olarak organik arama getiriyor olabilir; bu durumda silmek yerine güncellemek daha isabetli.
- Eski bir basın bülteni veya duyuru sayfası — haber sitelerinden veya sektör yayınlarından dış bağlantı taşıyor olabilir; sayfa silindiğinde o bağlantıların değeri de kayboluyor.
Bu üç durumu tespit etmenin en güvenilir yolu, silme kararı vermeden önce her sayfanın son 12 aylık tıklama ve gösterim verisini kontrol etmek.
Sebep 4: Geliştirme Ayarları Canlıya Taşındı
Geliştirme sırasında sitenin arama motorlarına görünmemesi için konulan engeller, yayına geçerken kaldırılmayı unutulur.
<meta name=“robots” content=“noindex”> etiketinin sayfalarda kalması. Site kusursuz çalışır, dizinden yavaşça silinir.robots.txt içinde Disallow: / satırının kalması. Tüm site taramaya kapalı hâle gelir.Doğrulama: Search Console → URL inceleme aracıyla birkaç önemli sayfayı canlı test edin. “Dizine eklenebilir mi” sorusuna verilen cevap, bu sebeplerin hepsini tek seferde eler.
Belirti: Dizine eklenen sayfa sayısında yenileme tarihinden itibaren düzenli ve keskin bir azalma.
Bu hatanın bu kadar sık tekrarlanmasının sebebi
noindex etiketinin canlıya taşınması, teknik açıdan basit ama insani açıdan anlaşılır bir hata. Geliştirme ortamı genelde şablon veya tema düzeyinde bir “geliştirme modu” bayrağıyla korunuyor; bu bayrak genelde tek bir ayar dosyasında veya panelde bulunuyor. Yayın günü onlarca farklı kontrol yapılırken bu tek ayarın gözden kaçması sürpriz değil — özellikle proje son anda aceleye geldiyse. Bunu önlemenin en güvenilir yolu, yayın öncesi kontrol listesine bu maddeyi ilk sıraya koymak ve yayından hemen sonra bağımsız bir kişiye (mümkünse projeyle ilgisi olmayan biri) canlı siteyi kontrol ettirmek.
Sebep 5: İç Bağlantı Yapısı Çöktü
Eski sitede sayfalar birbirine bağlıydı: hizmet sayfasından alt hizmete, blog yazısından hizmet sayfasına, kategoriden ürüne. Yeni tasarımda menü sadeleştirildi, gövde metinlerindeki bağlantılar kaldırıldı.
Sonuç: sayfalar hâlâ var ama site içinde desteklenmiyorlar. Ana sayfadan uzaklaşan, kimsenin bağlantı vermediği sayfalar, hem daha az taranır hem daha zayıf değerlendirilir.
Belirti: Belirli sayfalarda — genellikle alt hizmet ve derin blog sayfalarında — yoğunlaşan düşüş. Ana sayfa ve üst seviye sayfalar etkilenmemiş.
Doğrulama: Trafik kaybeden bir sayfanın kendi sitenizde kaç yerden bağlantı aldığını sayın. Yenileme öncesi sayıyla karşılaştırın.
Çözüm: Menü sadeleştirmesi kalabilir — ama gövde metinlerinde bağlam içi bağlantılar yeniden kurulmalıdır. Yöntemi iç linkleme yazısında ele aldım.
Sebep 6: Teknik Altyapı Değişti
Yapay zeka destekli geliştirme araçlarının getirdiği yeni risk
2026 itibarıyla birçok yenileme projesi, tasarım ve kod üretiminde yapay zeka destekli araçlardan yararlanıyor. Bu araçlar hız kazandırırken, iki yeni risk türü de beraberinde getiriyor:
- Otomatik üretilen sayfa başlıkları ve meta açıklamalar. Yapay zeka araçları genelde şablon bazlı, tekrarlayan başlıklar üretiyor; özenle yazılmış özgün başlıkların yerini generik ifadeler alabiliyor.
- Otomatik kod optimizasyonunun beklenmedik yan etkileri. Bazı araçlar “performans iyileştirmesi” adı altında görsel gecikmeli yükleme (lazy loading) veya betik ertelemesi uyguluyor; bu, bazı durumlarda ana içeriğin tarayıcı tarafından geç görülmesine yol açabiliyor.
Bu araçları kullanmak yenileme sürecini hızlandırabilir, ama çıktının SEO açısından da gözden geçirilmesi gerektiği gerçeğini değiştirmiyor — otomatik üretilen her şeyin insan tarafından kontrol edilmesi hâlâ gerekli.
Teşhis Akışı
Yenileme sonrası düşüşte sırayla yapılacaklar
İlk üç adım, vakaların büyük bölümünü çözer ve birkaç saatte tamamlanır. Sıra atlanmamalı — ikinci adımdaki liste, dördüncü ve beşinci adımın girdisidir.
Yönlendirme Haritası Nasıl Hazırlanır?
Bu, yenileme projesinin en teknik ama en yüksek getirili çıktısıdır. Doğru hazırlandığında bu yazıdaki sebeplerin yarısı hiç oluşmaz.
Adım 1 — Eski URL listesini çıkarın. Kaynaklar: mevcut sitemap, Search Console’un sayfa raporu, analiz aracının en çok görüntülenen sayfalar listesi, sunucu logları. Dördünü birleştirip tekilleştirin — hiçbiri tek başına tam liste vermez.
Adım 2 — Önceliklendirin. Her URL eşit değildir. Sıralama ölçütü: aldığı organik tıklama, dış bağlantı sayısı, dönüşüm katkısı. Yüzlerce URL varsa, ilk yüzü doğru eşleştirmek geri kalanının hepsinden değerlidir.
Adım 3 — Yeni karşılığını yazın. Üç sütunlu basit bir tablo: eski URL, yeni URL, not. Not sütunu, karşılığı olmayan sayfalar için kararın gerekçesini taşır.
Adım 4 — Karşılığı olmayanlara karar verin. Sırasıyla: en yakın konudaki sayfa → o konunun kategori sayfası → (hiçbiri yoksa) 410 ile net kapatma. Ana sayfa bu listede yok — bilinçli olarak.
Adım 5 — Yayın sonrası doğrulayın. Listedeki her satırı tek tek test edin. Otomatik bir betikle yapmak mümkündür ve elle kontrolden güvenilirdir; her satırın döndürdüğü durum kodunu ve son varılan adresi kaydedin.
Beşinci adım atlanmamalı. Yönlendirme kuralları yazılmış olabilir ama sunucu yapılandırması, önbellek katmanı veya güvenlik duvarı araya girebilir. “Kural yazıldı” ile “yönlendirme çalışıyor” farklı iki durumdur ve aradaki fark yalnızca test ederek görülür.
Yönlendirme haritası şablonu
Aşağıdaki gibi basit bir tablo, ekip içinde paylaşılabilir ve yayın sonrası kontrol için de kullanılabilir:
| Eski URL | Yeni URL | Öncelik | Not | Test durumu |
|---|---|---|---|---|
| /hizmetler/web-tasarim.html | /hizmetler/web-tasarim/ | Yüksek | Doğrudan karşılığı var | Doğrulandı |
| /kampanya/yaz-indirimi | /hizmetler/web-tasarim/ | Orta | Kampanya bitti, en yakın konu | Doğrulandı |
| /blog/eski-yazi-2019 | /blog/guncel-yazi/ | Düşük | Konu güncellenmiş yeni yazıya taşındı | Beklemede |
Bu tablo formatı, büyük projelerde yüzlerce satıra çıkabilir; önemli olan her satırın öncelik ve test durumu sütunlarının doldurulmuş olması — aksi hâlde hangi satırların gerçekten çalıştığı belirsiz kalır.
Vaka Kurgusu: Kurumsal Bir Sitenin Yenileme Sonrası Toparlanması
Aşağıdaki senaryo, sektörde sık görülen bir örüntüyü betimlemek için kurgulanmıştır; belirli bir şirkete ait gerçek veri değildir.
Başlangıç durumu: B2B hizmet veren orta ölçekli bir şirket, altı yıldır aynı platformda çalışan sitesini tamamen yeni bir altyapıya taşıyor. Yeni site görsel olarak çok daha modern, mobilde daha hızlı çalışıyor. Proje ekibi tasarım ve geliştirmeye odaklanmış, SEO denetimi son haftada “zaman kalırsa yapılır” şeklinde plana alınmış ve zaman kalmadığı için atlanmış.
Belirti: Yayından üç hafta sonra organik trafik yaklaşık yarıya düşüyor. Pazarlama ekibi önce “yeni site henüz oturmadı, normaldir” diye düşünüyor, ama dördüncü haftada düşüş durmayınca teşhis süreci başlatılıyor.
Teşhis: Search Console’daki 404 raporu incelendiğinde, yayın tarihinden sonra birkaç yüz URL’nin bulunamama hatası verdiği görülüyor — eski URL yapısı .html uzantılı iken yeni yapı uzantısız ve farklı klasörleme kullanıyor. Hiçbir yönlendirme kurulmamış. Ayrıca dizine eklenen sayfa sayısının yayın sonrası belirgin şekilde düştüğü, birkaç önemli sayfada canonical etiketinin hâlâ geliştirme alan adını gösterdiği tespit ediliyor.
Uygulama: İlk hafta içinde eski URL listesi (sitemap arşivi, analiz aracı verisi ve sunucu logları birleştirilerek) çıkarılıyor ve öncelik sırasına göre yönlendirme haritası hazırlanıyor. Canonical etiketleri düzeltiliyor, yeni sitemap oluşturulup gönderiliyor. İkinci hafta yönlendirmeler devreye alınıyor ve listedeki her satır tek tek test ediliyor. Üçüncü haftadan itibaren 404 raporu günlük izleniyor, yeni beliren birkaç eksik yönlendirme hızla ekleniyor.
Sonuç penceresi: Dizine eklenen sayfa sayısı iki hafta içinde eski seviyesine yaklaşıyor. Organik trafik, sekizinci haftadan itibaren kademeli olarak toparlanmaya başlıyor ve on ikinci haftada yenileme öncesi seviyenin biraz üzerine çıkıyor — çünkü yeni sitenin hızı ve mobil deneyimi gerçekten daha iyi. Ancak birkaç eski blog yazısının dış bağlantıları, uzun süre 404 kaldıkları için geri kazanılamıyor; bu kayıp kalıcı kabul ediliyor.
Öğrenilen ders: Ekip, gelecekteki her yenileme projesinde SEO denetimini ayrı ve zorunlu bir proje kalemi olarak plana koymaya karar veriyor; “zaman kalırsa” ifadesi artık proje planlarında kullanılmıyor.
(Vaka temsilidir.)
Yenileme Sonrası İlk 30 Gün
Yayın günü işin bitişi değil, izleme döneminin başlangıcıdır.
Toparlanma Ne Kadar Sürer?
Düzeltmeler yapıldıktan sonra iyileşme anında olmaz. Google’ın yeni durumu yeniden taraması ve değerlendirmesi gerekir.
Son satır, hızlı davranmanın neden önemli olduğunu özetler: bazı kayıplar geri alınabilir, bazıları alınamaz — ve hangisi olacağını geçen süre belirler.
Yenileme Öncesi Kontrol Listesi
Henüz yenileme yapmadıysanız, bu bölüm yukarıdaki her şeyi gereksiz kılabilir.
Tek bir tavsiye seçmek gerekseydi: URL yapısını değiştirmeyin. Tasarımı, içeriği, altyapıyı, sunucuyu değiştirin — ama adresler aynı kalsın. Bu tek karar, bu yazıdaki sebeplerin çoğunu baştan ortadan kaldırır.
Yenileme projesi sözleşmesine eklenebilecek bir madde
Ajans veya freelancer ile çalışıyorsanız, proje sözleşmesine veya iş tanımına şu maddeyi eklemek faydalı olabilir: “Yenileme kapsamında mevcut tüm URL’ler için yönlendirme haritası hazırlanacak, yayın öncesi noindex/robots.txt/canonical kontrolü yapılacak ve yayın sonrası ilk otuz gün boyunca haftalık indeksleme raporu paylaşılacaktır.” Bu tür net bir madde, SEO denetiminin “zaman kalırsa yapılan” bir iş olmaktan çıkıp projenin ayrılmaz bir parçası hâline gelmesini sağlıyor.
En Sık Yapılan Dokuz Hata
- SEO denetimini proje planına dahil etmemek. Tasarım ve geliştirme takvimlenir, SEO “zaman kalırsa” kategorisine düşer ve genelde atlanır.
- Yönlendirme haritasını yayın gününe bırakmak. Bu iş yayından haftalar önce başlamalı; son gece hazırlanan bir harita eksiksiz olamaz.
- Tüm eski URL’leri ana sayfaya yönlendirmek. Hızlı ve kolay görünür ama sinyal aktarımını neredeyse tamamen keser.
- İçeriği “temiz görünsün” diye kısaltmak. Kısa metin daha estetik olabilir ama sorgu çeşitliliğini daraltır.
- Geliştirme ortamı ayarlarını canlıya taşımayı unutmak. noindex, robots.txt ve canonical kontrolü yayın öncesi son kontrol listesinde olmalı.
- İç bağlantıları menü sadeleştirmesiyle birlikte kaybetmek. Menüde sadeleşme olabilir ama gövde metnindeki bağlamsal bağlantılar korunmalı.
- Sitemap’i güncellemeden bırakmak. Eski sitemap, arama motorunu var olmayan sayfalara yönlendirmeye devam eder.
- Yayın sonrası izlemeyi ihmal etmek. İlk otuz gün pasif geçirilirse, düzeltilebilecek sorunlar kalıcı kayba dönüşebilir.
- Yapay zeka araçlarının ürettiği içeriği kontrolsüz yayınlamak. Otomatik üretilen başlık, açıklama ve kod optimizasyonlarının SEO açısından da gözden geçirilmesi gerekiyor.
Düşüşün yenilemeden değil başka bir sebepten kaynaklandığını düşünüyorsanız trafik neden azaldı yazısı, verinin kendisinden şüpheleniyorsanız Search Console tıklama yazısı, sayfalar dizine girmiyorsa indeksleme rehberi devam noktanız olsun.
Yenileme planlıyorsanız veya sonrasında kayıp yaşadıysanız iletişim sayfasından ulaşabilirsiniz.
Ekip İçi Sorumluluk Dağılımı
Yenileme projelerinin SEO tarafını sağlıklı yürütmek için, projeye dahil olan her tarafın hangi konudan sorumlu olduğunu baştan netleştirmek faydalı oluyor. Aşağıdaki tablo, tipik bir yenileme projesinde rollerin nasıl dağıtılabileceğine dair bir çerçeve sunuyor:
| Görev | Sorumlu taraf | Ne zaman tamamlanmalı |
|---|---|---|
| Mevcut URL listesi ve trafik verisinin arşivlenmesi | Pazarlama / SEO sorumlusu | Yenileme başlamadan önce |
| Yönlendirme haritasının hazırlanması | SEO sorumlusu + geliştirme ekibi | Yayından en az iki hafta önce |
| noindex / robots.txt / canonical kontrolü | Geliştirme ekibi | Yayın günü, canlıya almadan hemen önce |
| Sitemap güncelleme ve gönderimi | Geliştirme ekibi | Yayın günü |
| İlk otuz gün izleme raporu | SEO sorumlusu | Haftalık, ilk ay boyunca |
| Yapılandırılmış veri kontrolü | Geliştirme ekibi + SEO sorumlusu | Yayın öncesi test ortamında |
Bu tablo küçük ekipler için fazla resmi görünebilir, ama tek kişilik bir ekip olsanız bile aynı listeyi kendi kontrol listeniz olarak kullanabilirsiniz. Önemli olan her maddenin bir sahibi ve bir zamanlaması olması — aksi hâlde iş “birinin yapacağını sandığı ama kimsenin yapmadığı” bir göreve dönüşüyor.
Büyük ölçekli projelerde (yüzlerce veya binlerce sayfa) bu sorumluluk dağılımına bir de “eskale etme” kuralı eklemek gerekiyor: 404 raporunda beklenmedik bir artış görüldüğünde kime haber verilecek, kim müdahale edecek ve ne kadar sürede düzeltilecek. Bu netlik olmadan, tespit edilen bir sorun günlerce “birinin bakması gereken” bir durum olarak beklemede kalabiliyor — ki bu da tam olarak yukarıda anlatılan kalıcı kayıpların oluşma sebebi.
