Çevik SEO

TL;DR — Çevik SEO, yazılım ekiplerinin yaptığı gibi SEO işini de kısa döngülerde yürütmektir: genellikle bir ila dört haftalık sprint’ler, önceliklendirilmiş bir backlog ve her işin ayrı bir ticket olarak yazılması. Büyük bir yıllık planı beklemek yerine küçük değişiklikleri sürekli yayımlar ve ilerledikçe ayarlarsınız. Yazılım geliştirmeden alınmış isteğe bağlı bir işletim modelidir; Google bunu icat etmemiş veya onaylamamıştır, ekipler kendi iş akışlarına uyarlayabilir.

Çevik SEO nedir?

SEO tavsiyelerinin çoğu, şemayı eklemek, canonical’ı düzeltmek veya başlığı yeniden yazmak gibi işi hemen yapabileceğinizi varsayar. Gerçek bir şirkette genellikle yapamazsınız. Değişiklik başkasının sahip olduğu kodda yaşar ve o kişinin kendi iş sırası olan bir mühendis olması muhtemeldir. Çevik SEO, bu sırayla savaşmak yerine onunla birlikte çalışma biçimidir.

“Çevik” sözcüğü yazılım geliştirmeden gelir. Mühendislik ekipleri uzun zaman önce bir yılı baştan planlayıp sonunda teslim etmeye (eski “waterfall” tarzına) çalışmayı bıraktı. Bunun yerine kısa patlamalar hâlinde çalışırlar:

• Sprint’ler — çoğu zaman iki hafta süren, ekibin küçük bir iş grubuna taahhüt verdiği ve bitirdiği sabit, kısa dönemler.
• Backlog — yapılabilecek her şeyin, en önemlisi üstte olacak şekilde, önceliklendirilmiş tek listesi.
• Ticket’lar — işi alacak kişinin tam olarak ne yapacağını bilmesi için yeterli ayrıntıyla ayrı birer öğe olarak yazılan görevler.

Çevik SEO, SEO işinizi bu aynı sisteme koymak demektir. “Ürün sayfalarına FAQ şeması ekle” fikriniz bir ticket’a dönüşür, backlog’a girer, diğer işlerle birlikte önceliklendirilir ve bir sprint’te yayımlanır.

Ekipler neden böyle çalışır?

Web değişir: sıralamalar oynar, Google güncellemeler yayımlar, rakipler değişir. Katı bir 12 aylık plan buna yanıt veremez; birkaç haftada bir yeniden önceliklendirdiğiniz bir backlog verebilir. Değişiklikleriniz mühendislik ekibinin normal sprintleriyle birlikte ilerlediği için gerçekten oluşturulur; kimsenin uygulamadığı bir sunumda beklemez.

Yeni başlayanların yaptığı tek büyük hata

“Çevik SEO”nun uyulacak, Google tarafından onaylanmış özel bir yöntem olduğunu sanırlar. Öyle değildir. Google ve Bing bunu tanımlayan hiçbir şey yayımlamamıştır. Yazılımdan alınmış bir sektör alışkanlığıdır; esnek olmasının nedeni de budur — sizin mühendislik ekibinizin çalışma biçimine uyarlarsınız.

Uygulayıcı sürümünü — mühendislerin kabul edeceği ticket’ları yazmayı, törenleri yürütmeyi ve binlerce ticket’lık backlog’u puanlamayı — görmek için Advanced sekmesine geçin.

TL;DR — Çevik SEO, SEO çalışmalarını mühendislik iş akışı gibi yürütür: zaman kutulu sprint’ler, sürekli iyileştirilen bir iş listesi ve sabit bir çeyreklik yol haritası yerine yinelemeli teslimat. Yaklaşım yazılım Scrum/Kanban’ından esinlenir; Google veya Bing’in tanımladığı tek bir çevik SEO çerçevesi yoktur. Pratik temel üç parçadır. Törenler: mühendisliğin zaten yaptığı sprint planlaması, standup (yeni iş önermek için değil), iş listesi düzenleme ve retrospektif toplantılarına katılın. Ticket’lar: her biri tek bir sorunu, somut teknik ayrıntıyı (“sayfa hızını iyileştir” yerine tam render engelleyen kaynağı), ölçülebilir kabul kriterlerini (“bu ticket şu olduğunda tamamdır…”) ve beklenen etki/KPI’ları içersin. Önceliklendirme: büyük iş listesini SEO’ya uyarlanmış RICE veya ICE ile puanlayın, değişkenleri mühendisliğin anlayacağı terimlere çevirin ve listeyi mühendisliğin çalıştığı Jira’da tutun; kimsenin açmadığı bir e-tabloda değil. Kurumsal ölçekte ticket’ları epiklerde gruplayın ve tek seferde çok ticket’ı temizleyen şablon düzeyi düzeltmeleri tercih edin. Scrum, sabit bir zaman aralığına sığdırabildiğiniz işleri taşır; WIP limitli Kanban akışı, bağımlılıklar nedeniyle düzensiz ilerleyen SEO işlerine uyar — çoğu kurumsal program ikisini birlikte kullanır.

Çevik SEO ile çeyreklik yol haritası karşılaştırması

Şu ayrımı net yapmak gerekir: Çevik SEO, “SEO’yu daha hızlı yapmak” değildir; farklı bir işletim modelidir.

Eski model waterfall’dur: büyük bir strateji belgesi, çeyreklik veya yıllık bir yol haritası, doğrusal aşamalar ve planlama ile teslimat arasında uzun bir boşluk. Slaytta düzenli görünür ama uygulamada kırılgandır; SERP değiştiği veya öncelik kaydığı anda plan eskir ve kolayca ayarlama yolu kalmaz.

Çevik SEO bunun yerine bir ritim koyar. Search Engine Journal’daki Jes Scholz’un çerçevesi şöyledir: “Agile SEO involves incremental iteration” (çeviri) (Türkçe çeviri: “Agile SEO artımlı yinelemeyi içerir.”) — Büyük planı küçük, sık değişikliklere böler ve sürüm ritminizi mühendislik ekibininkiyle eşleştirirsiniz. Scholz’un belirttiği gibi bu, “two weeks also promotes small but constant releases from the SEO team” (çeviri) (Türkçe çeviri: “İki haftalık döngü, SEO ekibinden küçük ama sürekli sürümleri de teşvik eder.”). Uzun strateji belgelerini tek sayfalık taktik brifinglerle değiştirmek ve planlama döngünüzü yalnızca SEO takvimi yerine BT departmanının sprint takvimiyle eşleştirmek, Scholz’un pratik önerisidir.

Bu yöntem alınmıştır, kutsanmış değildir

Çoğu çevik SEO içeriğinin sessizce geçiştirdiği bir konuda dürüst olmak istiyorum: Google veya Bing’in çevik SEO tanımı yoktur. Araştırdım. Google Search Central ve Search Off the Record podcast’i “çevik SEO”yu, sprint’leri veya SEO ticket’larını bir metodoloji olarak tanımlayan ya da onaylayan hiçbir şey yayımlamadı. En yakın resmî kaynak, Google’ın arama için geliştirici kılavuzu, geliştirici arama kılavuzundaki genel iş birliği rehberidir. Bu kaynak SEO ile mühendislik iş birliğinin neden önemli olduğunu (Google’ın anlayamadığı içeriği sıralayamayacağınızı) açıklar, ancak sürecin nasıl yürütüleceğini söylemez. Bing de aynıdır: Bing Webmaster Blog’u iş akışını değil araç özelliklerini kapsar.

Bu nedenle bu makalenin devamındaki her şey — RICE, story point’leri, tören listesi — arama motoru rehberliği değil, yazılım ürün yönetiminden alınmış sektör pratiğidir. Bu bir zayıflık değil, asıl noktadır. Yöntemi kuruluşunuza uyarlarsınız ve kurumsal ekiplerin bunu gerçekten nasıl yaptığı, otoriteye yapılan her türlü başvurudan daha önemlidir.

Bir SEO uzmanının gözünden çevik törenler

Mühendislik ekibiniz Scrum kullanıyorsa dört düzenli törene katılırsınız. Her birindeki göreviniz mühendisinkinden farklıdır.

Sprint planlaması. Ekip burada backlog’dan ticket’ları bir sonraki sprint’e alır ve onlara taahhüt verir. Bu sizin anınızdır: mühendislik zamanına talip diğer işlere karşı SEO ticket’larınızı savunur ve yeni işin meşru biçimde eklenmesini sağlarsınız. Önceliklendirilmiş, iyi yazılmış ticket’lar ve bir etki gerekçesiyle gelin; dilekle değil.

Standup’lar. Kısa, genellikle günlük durum eşgüdümleridir. Under Armour’da Lead SEO Product Manager olan Holly Miller Anderson’ın Search Engine Land’de vurguladığı kritik kural şudur: “standups are not the place to introduce new work. An appropriate time for that is sprint planning.” (çeviri) (Türkçe çeviri: “Standup’lar yeni iş tanıtma yeri değildir. Bunun uygun zamanı sprint planlamasıdır.”) Taahhüt edilmiş işteki ilerlemeyi bildirmek ve engelleri belirtmek için gelin; ekibi yeni bir SEO isteğiyle hazırlıksız yakalamayın.

Backlog düzenleme (grooming). Sprint öncesinde ticket’ların netleştirildiği, tahmin edildiği ve yeniden sıralandığı aşamadır. Anderson bunu şöyle anlatır: “the product manager and project manager talk with the teams (engineering, design/user experience, etc.) about the work and the level of effort involved with each ticket before adding it into a sprint.” (çeviri) (Türkçe çeviri: “Ürün ve proje yöneticileri, sprint’e eklemeden önce ekiplerle (mühendislik, tasarım/kullanıcı deneyimi vb.) işi ve her ticket’ın gerektirdiği çabayı konuşur.”) Ticket’larınızın gerçekten hazır olduğundan emin olduğunuz ve istediğiniz işin gerçek çaba maliyetini öğrendiğiniz yer burasıdır.

Retrospektifler. Her sprint’ten sonra Anderson’ın belirttiği gibi, “the entire team comes together to talk about what went well/what didn’t in the recent sprint and how they can improve for the future.” (çeviri) (Türkçe çeviri: “Tüm ekip, son sprintte neyin iyi gittiğini veya gitmediğini ve gelecekte nasıl iyileşebileceklerini konuşmak için bir araya gelir.”) SEO işinin nerede geri plana atıldığını veya bir ticket’ın nerede belirsiz kaldığını ortaya çıkarmak için kullanın; böylece sonraki sprint daha akıcı ilerler.

Genel bir çevik uyarı da ekleyelim; SEO’ya özgü değildir: Bu ritüelleri mekanik olarak uygulamak programı çevik yapmaz. Önemli olan mekanikler değil, yanıt verebilirliktir. SERP değiştiğinde hiç yeniden önceliklendirmeyen bir ekip standup yapsa da çevik tiyatro sergiler.

Scrum Guide, “Scrum”un anlamlı kalması için sorumlulukları ve artefaktları korumalıdır: üç sorumluluk (Product Owner, Scrum Master, Developers), her biri bir taahhüt taşıyan küçük bir artefakt kümesi (Product Backlog, Sprint Backlog, Increment) ve inceleme ile uyarlamaya yarayan etkinlikler. Bir durum toplantısına “standup” adını verip taahhütleri ve incele/uyarla döngüsünü atlarsanız Scrum uygulamış olmazsınız; yalnızca bir toplantının adını değiştirmiş olursunuz. meeting. Cargo cult için somut test budur, bir sezgi değil.

Scrum ve Kanban: Uygun akışı seçin

Bu makale Scrum tarzı törenlere yaslanıyor; çünkü şirket içi mühendislik ekiplerinin çoğu bunu kullanıyor. Ancak Scrum tek çevik seçenek değildir ve SEO bağımlılıklarının geliş biçimine her zaman uymaz.

Kanban Guide bunun yerine Kanban’ı üç uygulama etrafında tanımlar: iş akışını tanımlayıp görselleştirmek, devam eden işi (WIP) açıkça sınırlamak ve WIP, throughput, iş öğesi yaşı ve çevrim süresi gibi ölçümlerle akışı etkin biçimde yönetmek. Sprint taahhüdü yoktur; ticket’lar sabit iki haftalık kutulara toplamak yerine WIP sınırlandırılmış bir panoda sürekli ilerler.

SEO ticket’larının güvenilir biçimde gruplanıp ekiple birlikte taahhüt edilen sürede teslim edilebildiği durumda Scrum uygundur. Kanban tarzı akış, SEO işi bir geçiş veya yeniden tasarım nedeniyle uzun süre bloklanıyor, sonra sprint taahhüdüne sığmayan öngörülemez bir dizi bağımsız düzeltme hâlinde geliyorsa daha iyi uyar. Biri diğerinden “daha çevik” değildir; ikisi de backlog akışını bağımlılıkların gerçek geliş biçimiyle eşleştiren farklı yanıtlardır. Kurumsal programların çoğu pratikte hibrittir: planlı şablon/mimari işi sprint tabanlı, öngörülemeyen tek seferlik düzeltmeler akış tabanlıdır.

Mühendislerin gerçekten kabul edeceği SEO ticket’larını yazma

SEO programlarının çoğu burada başarılı olur veya tökezler. Belirsiz yazılmış parlak bir öneri geri plana atılır, yanlış uygulanır ya da görmezden gelinir. Ticket yazmak gerçekten bir zanaattır ve iki uygulayıcı bunu iyi belgelemiştir.

Indeed’de SEO Product Manager olan Gus Pelogia, iyi SEO ticket’ları yazmak için altı öneri sunar: ticket başına tek sorun, isteğe bağlam eklemek, yapılacak işi ve beklenen etkiyi açıklamak, görev bağımlılıklarını düzenlemek ve “henüz düzeltmeyin”. Bağlam için “Doing […] will allow search engines to […]” (çeviri) “Doing […] arama motorlarının […] yapmasına izin verecek.” ifadesini kullanır; böylece mühendis nedenini anlar. Ayrıca “clear and specific instructions” (çeviri) “açık ve belirli talimatlar” ile “examples, screenshots, [and] mockups.” (çeviri) “örnekler, ekran görüntüleri ve maketler.” ister.

Gray Dot Company’den Heather Kaeowichien ve Tory Gray, SEO mühendislik ticket’ları yazma kılavuzlarında daha derine iner. Benimsenmesi gereken tanımları şudur: “Acceptance Criteria are quantifiable, testable conditions that the work has to meet for the ticket to be completed.” (çeviri) “Kabul kriterleri, işin ticket’ın tamamlanması için karşılaması gereken ölçülebilir ve test edilebilir koşullardır.” Anderson da doğrulama açısından aynı noktayı vurgular: “the more quantifiable you can make it, the easier it is to validate and give the team the thumbs up that the work is done.” (çeviri) (Türkçe çeviri: “Bunu ne kadar ölçülebilir yaparsanız, doğrulamak ve ekibe işin bittiğini onaylamak o kadar kolay olur.”)

En büyük kaldıraç teknik özgüllüktür. Gray Dot belirsiz bir isteği somut olanla karşılaştırır: “sayfa hızını iyileştir” yazmayın; “Remove secondary (render-blocking) call to hero image on article template.” (çeviri) “Makale şablonundaki ikincil (render-blocking) hero image çağrısını kaldırın.” yazın. İlki bir dilektir, ikincisi mühendisin alıp bitirebileceği görevdir. Değerlendireceğiniz KPI’ları (“click, impressions, avg. SERP position”) adlandırın ve şu şablon örneğindeki gibi somut bir tahmin verin: “We expect to see a 20% increase in organic traffic to blog category pages with a custom H1 within three months of launch.” (çeviri) “Yayınlandıktan sonraki üç ay içinde özel H1 içeren blog kategori sayfalarına gelen organik trafikte %20 artış görmeyi bekliyoruz.”

Tam ticket şablonları on bir bileşen içerir: açık başlık, kapsamdaki özellikler, örnek URL’ler, ayrıntılı açıklama, kullanıcı hikâyeleri, hatalarda site davranışı, hataları yeniden üretme adımları, etki, teknik notlar, kabul kriterleri ve test notları. Her ticket’ta on birinin tamamına ihtiyacınız olmayabilir; ancak yazarken başvuracağınız kontrol listesi budur. (İyi ve belirsiz ticket’ı yan yana görmek için Examples sekmesine bakın.)

Şablona veya geniş bir URL kümesine dokunan her ticket’ta iki şeyi daha yazılı hâle getirin: değişiklik beklenen sonucu vermez ya da geri alınması gerekirse kararı kimin vereceği ve “geri alındı”nın somut anlamı (flag, git revert veya içerik geri alma). Değişiklik güvenli görünse bile bunu atlamayın; geri döndürülebilirliği sevkiyattan önce yazmak ucuz, sonradan yeniden kurmak pahalıdır. Jira’nın alanlarının veya issue türlerinin şablonla bire bir eşleşmesini de beklemeyin: Atlassian belgelerinde proje yöneticilerinin hangi alan ve iş türlerinin kullanılabilir olduğunu yapılandırdığı belirtilir. Bu nedenle on bir bileşeni kavram olarak kapsayın; kendi örneğinizde literal alan adlarını aramayın.

Büyük bir SEO backlog’una öncelik verme: RICE, ICE ve ötesi

İşiniz backlog’a girdikten sonra, özellikle liste uzadığında, onu sıralamak için bir yönteme ihtiyacınız olur. En sık alınan iki çerçeve ICE (Impact, Confidence, Ease) ve RICE’tır (Reach, Impact, Confidence, Effort). RICE, ürün önceliklendirmesi için Intercom’da ortaya çıktı ve her öğeyi (Reach × Impact × Confidence) / Effort olarak puanlar.

Spike’tan Deepesh Kumar, bunların doğrudan aktarılmadığını açıkça söyler: “Off-the-shelf frameworks like ICE (Impact, Confidence, Ease) or the RICE framework are useful starting points, but they often fail for SEO.” (çeviri) (Türkçe çeviri: “ICE (Etki, Güven, Kolaylık) veya RICE gibi hazır çerçeveler iyi başlangıç noktalarıdır, ancak SEO’da sıkça başarısız olurlar.”) Gerekçesi şudur: “they were designed for product management, where ‘reach’ is more deterministic and ‘impact’ is less volatile” (çeviri) (Türkçe çeviri: “Ürün yönetimi için tasarlandılar; burada ‘erişim’ daha belirlenebilir, ‘etki’ daha az değişkendir.”) — SEO’nun SERP oynaklığı ve kontrol etmediğiniz mühendislik kapasitesine bağımlılığınız, ham puanları daha az güvenilir kılar.

Düzeltme çerçeveyi bırakmak değil, her değişkeni mühendisliğin eyleme dökebileceği terimlere çevirmektir. Kumar’ın uyarlaması:

• Erişim (Reach) → etkilenen URL sayısı × URL başına aylık oturum
• Etki (Impact) → dolar cinsinden risk altındaki gelir
• Güven (Confidence) → düzeltme güveni (Yüksek / Orta / Düşük)
• Çaba (Effort) → geliştirici saatleri cinsinden uygulama maliyeti

Ve bütün bunları işler hâle getiren operasyon kuralı şudur: backlog “has to live where engineering already works, in Jira or whatever you use, with SEO tickets scheduled into engineering sprints like any other work, not parked in a separate spreadsheet developers never open.” (çeviri) (Türkçe çeviri: “Mühendisliğin zaten çalıştığı yerde, Jira’da veya kullandığınız başka bir araçta bulunmalı; SEO ticket’ları diğer işler gibi mühendislik sprintlerine planlanmalı, geliştiricilerin hiç açmadığı ayrı bir e-tabloda bekletilmemelidir.”) Mühendisliğin göremediği önceliklendirilmiş backlog özel bir günlükten ibarettir.

Mühendislikle bağımlılık eşleme

Puanlama neyin değerli olduğunu, bağımlılık eşleme ise şu anda neyin mümkün olduğunu söyler. Mühendisliğin iki çeyrek boyunca dokunmayacağı bir platform geçişine bağlı yüksek RICE puanlı ticket, puanı ne kadar iyi olursa olsun sıranın önüne geçemez.

Bu nedenle düzenleme sırasında bağımlılıkları açıkça eşleyin: hangi ticket’lar diğerleri tarafından engelleniyor, hangileri bir şablon veya bileşeni paylaşıyor (dolayısıyla birlikte yayımlanmalı) ve hangileri yol haritasındaki mevcut bir mühendislik girişimine eklenebilir? En ucuz SEO kazanımları genellikle mühendisliğin zaten yapacağı işe ekleyebildiğiniz işlerdir. Pelogia’nın altı önerisinden biri olan “görev bağımlılıklarını düzenleyin”in nedeni tam olarak budur; eşlenmemiş bağımlılık ticket’ın sessizce takılmasına yol açar.

Kurumsal ölçekte SEO backlog’larını yönetme

Kurumsal ölçekte backlog’da onlarca değil yüzlerce veya binlerce ticket bulunur; darboğaz SEO fikri değil mühendislik kapasitesidir. (Belirli bir ticket sayısı vermekten kaçınıyorum; bulduğum yaygın rakamlar doğrulanabilir birincil kaynak olmadan üçüncü taraf bloglara dayanıyor. Bu nedenle kesin sayılara şüpheyle yaklaşın.) Birkaç düzenleme tekniği bu büyüklükteki backlog’u yönetilebilir tutar:

• Ticket’ları epiklerde gruplayın. Bin dağınık ticket’ı yönetmeyin; ilişkili ticket’ları içeren birkaç düzine tematik epik yönetin (ör. “kategori sayfalarında iç bağlantı”, “yapılandırılmış veri yayılımı”). Sprint planlamasında tutarlı bir konuşma yürütmenin yolu budur.
• Şablon ve mimari düzeyi düzeltmeleri tercih edin. Makale şablonundaki render-blocking bir varlığı düzelten tek ticket, aksi hâlde on binlerce sayfa ticket’ını çözebilir. Sorunun sayfa mı şablon mu olduğunu her zaman sorun; kaldıraç etkisi çok büyüktür. Bu, kurumsal SEO’nun işletim modeli yönüdür: bilgi değil, birçok ekip arasındaki koordinasyon sorunudur.
• Zaman tahmini yerine story point kullanın. Pelogia ticket’ları saat yerine story point’leriyle boyutlandırmayı önerir. Story point göreli boyutlandırmadır (bu ticket şundan “daha büyük”) ve mühendisliğin zaten kullandığı uygulamadır; SEO’ya özgü yeni bir ölçek icat etmek yerine ekibin mevcut ölçeğine kalibre olursunuz. Fazla düşünmeyin: mühendislik ekibiniz ne kullanıyorsa onu benimseyin.

Programınız OKR’larla da çalışıyorsa şunu unutmayın: çevik törenler ve puanlanmış backlog, hedeflerin tanımladığı neyi gerçekleştirme yöntemini oluşturur. İkisi farklı yüksekliklerde durur ve rekabet etmek yerine birbirini tamamlar.

AI özet

Advanced sürümün özeti:

• Çevik SEO bir işletim modelidir, “daha hızlı SEO” değil. Kısa, zaman kutulu sprint’ler, sürekli düzenlenen backlog ve sabit çeyreklik yol haritasının yerini alan yinelemeli teslimat kullanır.
• Alınmıştır, kutsanmış değildir. Google veya Bing’in çevik SEO tanımı yoktur; yöntem yazılım Scrum/Kanban’ından alınmıştır. Arama motoru onayı varmış gibi davranmayın.
• Bir SEO uzmanının gözünden törenler. Sprint planlamasında ticket’larınızı savunup yeni iş önerirsiniz; Holly Miller Anderson’a göre standup bunun yeri değildir. Backlog düzenleme netleştirir ve tahmin eder, retrospektif sonraki sprint’i iyileştirir. Gerçek yeniden önceliklendirme yoksa ritüeller tiyatrodur; Scrum Guide’ın testi toplantı adının değil, sorumlulukların, artefaktların ve inceleme/uyarlamanın korunmasıdır.
• Scrum tek seçenek değildir. Scrum’ın sprint taahhüdü gruplanabilir işe uyar; Kanban Guide’ın akış modeli (iş akışını tanımlama, WIP’i sınırlama, akışı ölçme) düzensiz ve bağımlılıklarla bloklanan SEO işine daha iyi uyar. Kurumsal programların çoğu ikisini birlikte kullanır.
• Programlar ticket’larla yaşar veya ölür. Ticket başına tek sorun, somut teknik özgüllük (“sayfa hızını iyileştir” değil şablondaki render-blocking çağrıyı kaldır), ölçülebilir kabul kriterleri, beklenen etki/KPI’lar ve şablon ya da geniş URL kümesine dokunan her değişiklik için geri alma sahipliği gerekir.
• RICE/ICE’yi uyarlayarak kullanın. Spike’tan Deepesh Kumar, hazır çerçevelerin “SEO’da sıkça başarısız olduğunu” söyler; çünkü erişim ve etki belirlenebilir değildir. Değişkenleri mühendislik terimlerine çevirin (etkilenen URL × oturum, risk altındaki gelir, Y/O/D güven, geliştirici saati) ve backlog’u geliştiricilerin açmadığı bir e-tablo yerine Jira’da tutun.
• Bağımlılıkları eşleyin. Değer neyin önemli olduğunu, bağımlılıklar şimdi neyin yapılabilir olduğunu gösterir. SEO işini zaten yol haritasındaki mühendislik girişimlerine ekleyin.
• Kurumsal ölçekte konu koordinasyondur. Yüzlerce/binlerce ticket’ı epiklerde gruplayın, çok ticket’ı aynı anda temizleyen şablon/mimari düzeyi düzeltmeleri seçin ve mühendisliğin mevcut ölçeğini kullanarak story point’lerle boyutlandırın.

Resmî dokümantasyon

Google veya Bing’in “çevik SEO”yu, sprint’leri ya da SEO ticket’larını bir metodoloji olarak tanımlayan resmî dokümantasyonu yoktur; her ikisinde de doğrudan arama bunu doğrular. En yakın birincil kaynak, mühendislikle çalışmanın nedenini (nasılını değil) açıklayan genel geliştirici iş birliği rehberidir.

Google

• Search’e başlarken: geliştirici kılavuzu — SEO ile mühendislik iş birliğinin neden önemli olduğunu, arama motorlarının içeriği anlamasına nasıl yardımcı olunacağını değil nedenini açıklar.
• Google Search Essentials — gerçek işin önceliklendirildiği evrensel yönergeler.
• Yararlı, güvenilir, insanları önceleyen içerik oluşturma — açacağınız ticket’ların arkasındaki içerik standardı.

Bing / Microsoft

• Bing Webmaster Guidelines — genel kalite ve taranabilirlik rehberliği; Bing tarafında da çevik SEO veya iş akışı içeriği yoktur.

Sonuç: Bir çevik SEO çerçevesinin kaynağı olarak arama motoruna atıf yapmayın. Metodoloji sektör pratiğidir; nasıl için uygulayıcılara, işin ulaşmaya çalıştığı ne için arama motorlarına atıf yapın.

Kaynaktan alıntılar

Adı geçen uygulayıcıların kayda geçmiş ifadeleri. Her bağlantı, kaynak sayfanın alıntıyı desteklediği bölüme doğrudan gider.

Holly Miller Anderson, Under Armour Lead SEO Product Manager (Search Engine Land)

• Sprint’ler hakkında: “time-boxed for 1-2 weeks, during which all tickets (slated work) are completed.” (çeviri) “1–2 haftalık zaman kutularında planlanan tüm ticket’lar tamamlanır.” Alıntıya git
• Kabul kriterleri hakkında: “the more quantifiable you can make it, the easier it is to validate and give the team the thumbs up that the work is done.” (çeviri) “Bunu ne kadar ölçülebilir yaparsanız doğrulamak ve işin bittiğini onaylamak o kadar kolay olur.” Alıntıya git
• Standup’lar hakkında: “standups are not the place to introduce new work. An appropriate time for that is sprint planning.” (çeviri) “Standup’lar yeni iş tanıtma yeri değildir; bunun uygun zamanı sprint planlamasıdır.” Makaleyi okuyun

Jes Scholz, pazarlama danışmanı (Search Engine Journal)

• Yöntem hakkında: “Agile SEO involves incremental iteration.” (çeviri) “Agile SEO artımlı yinelemeyi içerir.” Alıntıya git
• Ritim hakkında: iki haftalık döngü “two weeks also promotes small but constant releases from the SEO team.” (çeviri) “İki haftalık döngü, SEO ekibinden küçük ama sürekli sürümleri de teşvik eder.” Alıntıya git

Deepesh Kumar, Spike (SEO için RICE/ICE hakkında)

• “Off-the-shelf frameworks like ICE (Impact, Confidence, Ease) or the RICE framework are useful starting points, but they often fail for SEO.” (çeviri) “ICE veya RICE gibi hazır çerçeveler iyi başlangıç noktalarıdır, ancak SEO’da sıkça başarısız olurlar.” Makaleyi okuyun
• “They were designed for product management, where ‘reach’ is more deterministic and ‘impact’ is less volatile.” (çeviri) “Ürün yönetimi için tasarlandılar; burada erişim daha belirlenebilir, etki daha az değişkendir.” Makaleyi okuyun

Heather Kaeowichien ve Tory Gray, Gray Dot Company (ticket yazımı hakkında)

• “Acceptance Criteria are quantifiable, testable conditions that the work has to meet for the ticket to be completed.” (çeviri) “Kabul kriterleri, işin ticket’ın tamamlanması için karşılaması gereken ölçülebilir ve test edilebilir koşullardır.” Makaleyi okuyun

Scrum Guide (“Scrum”un anlamlı kalması için korunması gerekenler hakkında)

• “Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.” (çeviri) “Scrum, Scrum Takımı içinde Geliştiriciler, Ürün Sahibi ve Scrum Master olmak üzere üç sorumluluk tanımlar.” Kılavuzu okuyun

Kanban Guide (sprint yerine akış tabanlı çalışma hakkında)

• “Kanban system members must explicitly control the number of work items in a workflow from started to finished.” (çeviri) “Kanban sistemi üyeleri, bir iş akışında başlatılan işlerden bitirilenlere kadar iş öğelerinin sayısını açıkça kontrol etmelidir.” Kılavuzu okuyun

SOP: Çevik SEO iş akışı kurma

Mevcut bir mühendislik kuruluşunda SEO programını statik yol haritasından çevik çalışma biçimine taşımak için tekrarlanabilir prosedür.

1. Mühendisliğin nerede çalıştığını bulun. Aracı (Jira, Linear, Azure DevOps) ve ritmi (sprint uzunluğu, başlangıç günü) belirleyin. Siz uyarlanın; onlar size uyarlanmayacaktır.
2. SEO backlog’unu bu araçta oluşturun. E-tablo kullanmayın. Her SEO önerisi aynı sistemde bir ticket’a dönüşsün.
3. Her ticket’ı şablona göre yazın. Başlık, kapsam içi sayfalar/şablonlar, örnek URL’ler, neden açıklaması, teknik notlar, beklenen etki/KPI’lar ve ölçülebilir kabul kriterleri. (Checklists sekmesine bakın.)
4. Backlog’u puanlayın. SEO’ya uyarlanmış değişkenlerle RICE veya ICE uygulayın (etkilenen URL × oturum, risk altındaki gelir, Y/O/D güven, geliştirici saati). SERP ve site değiştikçe yeniden puanlayın.
5. Bağımlılıkları eşleyin. Bloklanan ticket’ları, şablon paylaşanları ve mevcut bir mühendislik girişimine eklenebilecekleri işaretleyin.
6. Törenlerde yer alın. Netleştirmek/tahmin etmek için backlog düzenlemeye, en yüksek puanlı ticket’larınızı sprint’e almak için sprint planlamasına katılın.
7. Standup’ta ilerlemeyi bildirin, yeni işi planlamada önerin. Standup’ta yeni istek ortaya atmayın.
8. Retro turu yapın. Her sprint’ten sonra neyin geri plana atıldığını veya yanlış yapıldığını not edin; buna yol açan ticket yazımını ya da puanlamayı düzeltin.
9. Epiklere yükseltin. Backlog büyüdükçe ticket’ları tematik epiklerde gruplayın; planlama tutarlı kalsın.

Playbook: SEO işini mühendislik kuyruğunda önceliklendirme

Çevik SEO’daki sürekli zor sorun neyi düzelteceğinizi bilmek değil, mühendisliğin kendi backlog’u varken işin oluşturulmasını sağlamaktır. İşe yarayan bir oyun planı:

1. Görevlerle değil etkiyle konuşun. Mühendislik değer ve çabaya göre önceliklendirir. “hreflang ekle” diyen bir ticket kötü yarışır; “[markets] içinde yanlış dilde sıralanma nedeniyle kaybedilen tahmini X oturum/ayı geri kazandırır” diyen iyi yarışır. Mümkünse risk altındaki geliri ekleyin.

2. Yalnızca etkiyi artırmayın, çabayı azaltın. Düzenlemede ticket’ı neyin pahalı yaptığını sorun, sonra bölün. Bir kez yayımlanan şablon düzeyi düzeltme, çok sayfalı dağınık ticket’tan çoğu zaman iyidir; küçük ticket sprint taahhüdü eşiğini aşar.

3. Zaten planlanmış işe eklenin. Mühendislik gelecek sprint’te ürün şablonuna dokunuyorsa ürün şablonu SEO düzeltmeniz de onunla ilerlemeli. Ek çaba neredeyse sıfırdır ve kuyruğu meşru biçimde atlarsınız.

4. Önce retroda, sonra planlamada kazanın. Bir SEO ticket’ı ölçülebilir sonuç verdiğinde bunu retroda gösterin. Yayına alınmış, doğrulanmış başarıların kaydı, sonraki sprint planlamasında elinizdeki en güçlü argümandır.

5. Ekibi şaşırtmayın. Yeni iş puan ve kabul kriterleriyle düzenleme ve planlamadan geçer; standup’a ya da Slack başlığına bırakılmaz. Öngörülebilir istekler güven kazanır, pusular geri plana atılır.

Çevik SEO anti-patternleri

Çevik SEO’nun yanlış gitmesinin yaygın yolları — çoğu mitlerin hayata geçmiş hâlidir.

Çevik tiyatro. SERP değiştiğinde yeniden önceliklendirmeden standup yapıp sprint’lere “sprint” demek. Ritüeller değil yanıt verebilirlik önemlidir; hareketleri taklit etmek programı çevik yapmaz.

Belirsiz ticket’lar. “Sayfa hızını iyileştir” yazıp geri kalanını mühendisin çözmesini beklemek. Gray Dot’un düzeltmesi tam kaynağı adlandırmaktır: “makale şablonundaki render-blocking hero-image çağrısını kaldır.” Belirsiz ticket’lar geri plana atılır veya yanlış yapılır.

Kabul kriteri yok. Ölçülebilir bir “tamam” koşulu olmayan ticket doğrulanamaz; kimse güvenle kapatamaz ve ticket sürüncemede kalır.

Özel backlog. Önceliklendirilmiş SEO backlog’unu mühendisliğin hiç açmadığı bir e-tabloda tutmak. Spike’a göre backlog Jira’da (veya mühendisliğin çalıştığı yerde) yaşamalıdır; aksi hâlde işi yapanlar için yoktur.

Standup’ta yeni iş önermek. Under Armour’dan Holly Miller Anderson’a göre standup’lar ilerleme ve engeller içindir; yeni iş sprint planlamasına aittir. Ekibi hazırlıksız yakalamak güveni aşındırır.

Ham RICE/ICE puanlarına güvenmek. Hazır ürün çerçevelerini uyarlamadan uygulamak. SEO’nun SERP oynaklığı ve kontrol etmediğiniz mühendislik kapasitesine bağımlılığı ham puanları güvenilmez kılar; değişkenleri uyarlamazsanız backlog’u yanlış sıralarsınız.

Google’ın çevik SEO’yu onayladığını iddia etmek. Resmî bir Google veya Bing çerçevesi yoktur. Böyle bir iddia ikna etmeye çalıştığınız mühendisler karşısındaki güvenilirliğinizi zedeler.

İyi bir ticket ile belirsiz bir ticket karşılaştırması

Aynı temel istek iki biçimde açıldı. Birinin ilerleyip diğerinin takılmasının nedeni budur. (Gray Dot Company ve Gus Pelogia’nın ticket rehberliğinden uyarlanmıştır.)

❌ Belirsiz — geri plana atılabilir veya yanlış yapılabilir

Başlık: Sayfa hızını iyileştir Açıklama: Makale sayfalarımız yavaş. Onları hızlandırabilir miyiz? Bu SEO’ya zarar veriyor.

Belirli bir kaynak, adlandırılmış bir şablon, “tamam” koşulu veya etki gerekçesi yok. Mühendis tahmin yapamaz, kapsam belirleyemez ve ne zaman bittiğini söyleyemez.

✅ Somut — mühendis alıp bitirebilir

Başlık: Makale şablonundaki ikincil (render-blocking) hero image çağrısını kaldır Kapsam: /blog/* makale şablonu (yaklaşık 4 000 makale URL’sinin tamamı) Örnek URL’ler: /blog/example-post-a/, /blog/example-post-b/ Açıklama / neden: Hero image iki kez isteniyor — biri render-blocking içinde <head>, bir kez de gövdede. Render-blocking çağrıyı kaldırmak tarayıcının ana içeriği daha erken çizmesini ve sıralamayla ilişkili temel Web Vital olan LCP’yi iyileştirmesini sağlar. Teknik notlar: Yinelenen çağrı article.hbs dosyasında yaklaşık 40. satırdadır. Waterfall’ı gösteren ekran görüntüsü eklidir. Beklenen etki / KPI’lar: Makale sayfalarında ölçülebilir bir LCP iyileşmesi bekliyoruz; yayından sonraki 3 ay boyunca alan LCP’sini, blog bölümü gösterimlerini ve ortalama konumu izleyin. Kabul kriterleri: Makale şablonu hero image için tam olarak tek istek yaptığında, render-blocking çağrı kaldırıldığında ve iki örnek URL’deki laboratuvar LCP’si değişiklik öncesi tabana göre iyileştiğinde bu ticket tamamlanır.

Bir sorun, bir ticket. Somut kaynak, ölçülebilir “tamam”, belirtilmiş etki. Farkın tamamı budur.

SEO bileti kontrol listesi

Her ticket’ı düzenlemeye girmeden önce bununla kontrol edin:

• Ticket başına tek sorun — gevşekçe ilişkili düzeltmelerden oluşan paket değil.
• Açık, belirli başlık — bir hedefi (“improve speed”) değil gerçek değişikliği adlandırır.
• Kapsamdaki sayfalar/şablonlar belirtilmiş — sayfa mı şablon mu olduğu açık.
• Örnek URL’ler eklenmiş.
• Açıklama nedenini anlatıyor — “X’i yapmak arama motorlarının Y yapmasını sağlar.”
• Teknik özgüllük — ekran görüntüsü veya maketle tam kaynak/dosya/satır.
• Beklenen etki + KPI’lar — değerlendireceğiniz metrikler ve somut tahmin.
• Bağımlılıklar eşlenmiş — neyin engellediği, hangi şablonla paylaşıldığı.
• Ölçülebilir kabul kriterleri — “bu ticket şu olduğunda tamamlanır…” ifadesi test edilebilir terimlerle yazılır.
• Geri alma/tersine çevrilebilirlik not edilmiş — kararı kimin verdiği ve başarısız olursa “geri alındı”nın anlamı.
• Story point’lerle boyutlandırılmış — saat değil, mühendisliğin mevcut ölçeği.

Birikim sağlığı kontrol listesi

• Backlog mühendisliğin zaten kullandığı araçta (Jira/Linear vb.) yaşıyor; e-tabloda değil.
• Her öğe SEO’ya uyarlanmış değişkenlerle (RICE/ICE) puanlanıyor ve değiştikçe yeniden puanlanıyor.
• Backlog birkaç düzineyi aştığında ticket’lar tematik epiklerde gruplanıyor.
• Şablon/mimari düzeyi düzeltmeler yüksek kaldıraçlı olarak işaretleniyor.
• SEO ticket’ları paralel SEO süreci olarak değil, mühendislik sprintlerine planlanıyor.

Zihinsel modeller

1. Yol haritası değil backlog + sprint’ler. Büyük statik planı sürekli düzenlediğiniz önceliklendirilmiş backlog’la değiştirin ve kısa artışlarla teslim edin. SERP değiştiğinde baştan planlamak yerine yeniden önceliklendirin.

2. Alınmış, kutsanmış değil. Çevik SEO yazılım Scrum/Kanban’ından alınmıştır. Hiçbir arama motoru bunu tanımlamaz. Mühendislik ekibinize uyarlayın; bunun kaynağı olarak Google’a atıf yapmayın.

2a. Gruplanabilir iş için Scrum, düzensiz bağımlılıklar için Kanban. Sprint taahhütleri, güvenilir biçimde gruplanıp sabit bir aralıkta teslim edilebilen ticket’lara uyar. WIP sınırlı, sürekli akışlı Kanban panosu uzun süre bloklanan ve sonra öngörülemez patlamalar hâlinde gelen işe uyar. Kurumsal programların çoğu ikisini kullanır.

3. Özgüllük ticket’ların para birimidir. Değer birimi öneri değil ticket’tır. Somut kaynak + ölçülebilir kabul kriterleri + belirtilmiş etki, yayımlanan ticket demektir. Belirsiz olan takılır.

4. Standup raporlar, planlama önerir. Standup’ta ilerleme ve engeller; yeni iş sprint planlamasında. Ekibi asla hazırlıksız yakalamayın.

5. Puanlayın, sonra puanı uyarlayın. RICE = (Erişim × Etki × Güven) / Çaba. SEO’da değişkenleri mühendislik terimlerine çevirin ve ham puanlara kuşkuyla bakın; erişim ve etki üründeki kadar belirlenebilir değildir.

6. Değer ve yapılabilirlik. Puanlama neyin yapılmaya değer olduğunu, bağımlılık eşleme neyin şimdi yapılabileceğini söyler. SEO işini yol haritasındaki mühendislik girişimlerine ekleyin.

7. Sayfayı değil şablonu düzeltin. Ölçekte tek şablon düzeyi ticket binlerce sayfa düzeyi sorunu temizleyebilir. Her zaman şunu sorun: Bu bir sayfa sorunu mu, şablon sorunu mu?

Çevik SEO kısa başvuru

Waterfall ve çevik SEO

Dört tören (her birindeki göreviniz)

• Sprint planlaması → ticket’larınızı savunun; yeni iş önerin
• Standup → ilerleme + engelleri bildirin (yeni iş önermeyin)
• Backlog düzenleme → netleştirin, tahmin edin, yeniden sıralayın
• Retro → neyin takıldığını ortaya çıkarın; ticket/puanlamayı düzeltin

Ticket’ın olmazsa olmazları

1. Tek sorun 2. Somut başlık 3. Kapsamdaki şablonlar + örnek URL’ler
2. Neden 5. Tam kaynak/dosya (+ ekran görüntüsü) 6. Etki + KPI’lar
3. Bağımlılıklar 8. Ölçülebilir kabul kriterleri 9. Story point’leri

RICE, SEO’ya uyarlanmış

• Erişim = etkilenen URL’ler × URL başına oturum
• Etki = risk altındaki gelir ($)
• Güven = Y/O/D düzeltme güveni
• Çaba = geliştirici saatleri
• Puan = (E × Et × G) / Ç — ancak ham puanlara kuşkuyla bakın; SEO erişimi/etkisi belirlenebilir değildir

Ölçek kuralları

• Ticket’ları epiklerde gruplayın
• Şablon/mimari düzeyi düzeltmeleri tercih edin (tek ticket binlercesini temizler)
• Backlog’u e-tabloda değil Jira’da tutun

Çevik SEO için araçlar

• Mühendislik ekibinizin issue tracker’ı (Jira, Linear, Azure DevOps, GitHub Issues) — en önemli araç. Backlog mühendisliğin zaten çalıştığı yerde yaşamalı; aksi hâlde iş oluşturulmaz.
• Mühendisliğin kullandığı aynı pano/sprint görünümleri — oraya katılın ve ticket açın; paralel, yalnızca SEO’ya ait bir sistem kurmayın.
• Önceliklendirme e-tablosu veya puanlama eklentisi — RICE/ICE puanlarını hesaplamak için uygundur; sonuçta önceliklendirilmiş ticket’lar tracker’a geri dönmelidir.
• Google Search Console + Bing Webmaster Tools — ticket kabul kriterlerine ve etki tahminlerine yazacağınız KPI’ların (tıklamalar, gösterimler, ortalama konum) kaynağı.
• Crawler / site denetim aracı (ör. Ahrefs Site Audit) — backlog ticket’ına dönüşecek sorunları ölçekte ortaya çıkarır ve sorunun sayfa değil şablon sorunu olduğunu görmenize yardımcı olur.
• Dokümantasyon yüzeyi (Confluence, Notion veya tek sayfalık taktik brifingler) — Jes Scholz’un “uzun strateji belgelerini tek sayfalık brifinglerle değiştirme” önerisine göre epiklerin bağlamı için.

Mühendislerin kabul edeceği bir ticket taslağı hazırlayın

Sorun kanıtını, etkilenen şablonu veya kaynağı ve bilinen kısıtları bu prompt’a yapıştırın. Çıktı mühendislikle düzenleme için bir taslak olmalı; onların tahmininin veya uygulama kararının yerine geçmemelidir.

Turn the SEO problem below into one engineering ticket. Use this exact structure:
1. Title
2. User story
3. Problem statement
4. Evidence
5. Affected URLs or templates
6. Steps to reproduce
7. Expected SEO impact
8. Technical notes and constraints
9. Quantifiable acceptance criteria
10. Dependencies
11. Open questions

Rules:
- Keep one problem per ticket.
- Name the exact template, component, resource, or response behavior involved.
- Do not prescribe a technical implementation unless the evidence requires it.
- Write acceptance criteria as observable pass/fail checks beginning with
  "This ticket is complete when..."
- Separate facts from assumptions and flag missing evidence.
- Do not invent traffic, revenue, effort, or impact estimates.

Problem evidence:
[PASTE CRAWL DATA, GSC DATA, URL EXAMPLES, SCREENSHOTS, OR REPRODUCTION NOTES]

Known constraints and dependencies:
[PASTE CONSTRAINTS OR WRITE "UNKNOWN"]

Belirsiz bir SEO isteğini sıkılaştırın

Backlog öğesi “sayfa hızını iyileştir” veya “canonical’ları düzelt” gibi geniş bir şey söylediğinde bunu kullanın.

Audit the SEO backlog item below for ticket readiness. Return:
1. The ambiguous phrases that would block engineering
2. The evidence still needed
3. The smallest single problem this ticket should cover
4. A rewritten title and problem statement
5. Three to five quantifiable acceptance criteria
6. Dependencies and open questions

Do not invent implementation details, benchmarks, or estimates. If the request
contains multiple problems, split them into separate proposed tickets.

Backlog item:
[PASTE THE CURRENT TICKET]

Kendinizi test edin: Çevik SEO

SEO’yu çevik bir program olarak yürütme üzerine beş soru. Her biri için bir yanıt seçin, sonra kontrol edin.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• Maksimum büyüme için kurumsal SEO stratejileri — çevik SEO’nun işlediği kurumsal SEO’nun ölçeği ve kurumsal koordinasyonu.
• Teknik SEO için başlangıç rehberi — çoğu SEO ticket’ının aslında ilgili olduğu teknik temeller.

Konuşmalarım

• Enterprise SEO Chaos (SMX Advanced, IBM’de Technical SEO olduğum dönemden) — çok ekipli koordinasyon sorunu ve “her şeyin birlikte çalışması gerekir” ilkesinin çevik SEO’nun yönettiği dünyayı açıklaması.

Sektörden

• SEO uzmanları için çevik yaklaşım: Şirket içi ekipler projeleri nasıl önceliklendiriyor — Holly Miller Anderson, Search Engine Land — şirket içi SEO ürün yöneticisinin her töreni ayrı ele alan bakışı.
• Çevik SEO: Stratejiden eyleme — Jes Scholz, Search Engine Journal — artımlı yineleme, tek sayfalık taktik brifingler ve ritmi mühendislik sprint’leriyle eşleme.
• İyi SEO ticket’ları yazmak için altı basit öneri — Gus Pelogia — ticket başına tek sorun, bağlam, etki, bağımlılıklar ve zaman tahmini yerine story point’leri.
• SEO çalışması için mühendislik ticket’ları nasıl yazılır — Gray Dot Company — 11 parçalı ticket şablonu ve ölçülebilir kabul kriterlerinin tanımı.
• SEO önceliklendirmesi: Bir puanlama çerçevesi — Deepesh Kumar, Spike — RICE/ICE’nin “SEO’da sıkça başarısız olmasının” nedeni ve değişkenleri mühendislik terimlerine çevirme.
• Geliştiricileriniz için mükemmel SEO ticket’ı nasıl yazılır — Sitebulb — özgüllük ve kabul kriterlerini pekiştiren uygulayıcı rehberi.
• RICE puanlama modeli — ProductPlan — RICE’ın kökeni ve formülü hakkında genel ürün yönetimi arka planı (SEO’ya özgü değil).
• Scrum Guide — yukarıda değinilen Scrum sorumlulukları, artefaktları ve inceleme/uyarlama mekaniklerinin birincil kaynağı.
• Kanban Guide — yukarıda değinilen Kanban iş akışı, WIP sınırı ve akış ölçümlerinin birincil kaynağı.

Değişiklik günlüğü