Geliştiriciye SEO Talebi: Ticket Şablonu ve Kabul Kriteri

İyi bir SEO talebi dört şeyi taşır: gözlenen sorun, bu sorunun kanıtı, sayfanın nasıl davranması gerektiği ve bunu doğrulayacak ölçülebilir kabul kriteri. "Canonical'ları düzeltin" cümlesi geliştiriciyi tahmine iter; "şu şablonda canonical, sayfanın kendi temiz adresini göstermeli, şu iki URL ile test edilsin" cümlesi ise iş olarak kapatılabilir. Aşağıdaki şablon, SEO uzmanı, ajans yöneticisi ve ürün sahibinin aynı dili konuşması için bir çalışma yöntemidir. Google'ın belgeleri ticket yazmayı anlatmaz; belgeler yalnız yönlendirme, durum kodu, robots kuralı ve canonical gibi teknik davranışları tarif eder. Bu yüzden süreç önerileri burada deneyime dayalı şablon olarak sunulur, teknik davranış cümleleri ise ilgili Google sayfasına bağlanır.

Neden SEO Talepleri Geri Dönüyor?

SEO talepleri çoğu zaman geliştiricinin isteksizliğinden değil, talebin yazılış biçiminden geri döner. Geliştirici bir ticket'ı sprint'e alırken üç soruya cevap arar: tam olarak ne yapılacak, bittiğini nasıl anlayacağım ve bunu bozarsam kim fark eder? SEO denetim raporundan kopyalanmış bir madde bu soruların hiçbirine cevap vermez. Rapor bulguyu üretir; ticket ise bulguyu uygulanabilir işe çevirir. Aradaki çeviri yapılmadığında iş ya "belirsiz" diye bekler ya da yanlış yorumlanarak teslim edilir.

Belirsiz istek: Ne istendiği tahmin edilir

"Sayfa hızını iyileştirin", "başlıkları düzeltin", "teknik SEO sorunlarını giderin" gibi cümleler bir hedef bildirir, bir iş tanımı vermez. Geliştirici hangi sayfada, hangi ölçüde, hangi araçla ölçerek iyileştirme yapacağını bilemez. Bu yüzden talep ya sorularla geri döner ya da geliştirici en kolay yorumu seçer. Belirsiz isteğin ilacı, tek bir davranış değişikliğini tek bir ticket'a yazmaktır: "Bu URL deseninde bu HTTP yanıtı dönsün" gibi.

Kanıtsız istek: Neden önemli olduğu görünmez

Geliştirici açısından SEO talebi, ürün özelliği talepleriyle aynı sprint kapasitesi için yarışır. Kanıt eklenmemiş bir talep "yapılırsa iyi olur" kategorisine düşer. Kanıt, rakam uydurmak demek değildir: Search Console'daki ilgili rapordan bir ekran görüntüsü, canlı sitede örnek bir URL, tarayıcıda görülen yanıt kodu ya da sayfa kaynağından bir satır yeterlidir. Kanıt, talebin kişisel bir tercih olmadığını gösterir ve sonradan kontrolün neye göre yapılacağını sabitler.

Test edilemeyen istek: Bitti denilemez

Bir iş için kabul kriteri yoksa "bitti" kararı kişiye göre değişir. Geliştirici kodu birleştirdiğinde işi bitmiş sayar; SEO uzmanı yayına çıkmış sayfada davranışı görmeden bitmiş saymaz. Aradaki uyuşmazlık haftalarca sürebilir. Kabul kriteri bu tartışmayı baştan kapatır, çünkü iki taraf da aynı kontrolü aynı URL'lerle tekrarlayabilir.

Yanlış öncelik: Her şey acil, hiçbir şey sıralı değil

Denetimden çıkan kırk maddeyi tek seferde ticket'a dökmek, sprint planlamasında hepsinin birden ertelenmesine yol açar. Geliştirici hangi maddenin sitenin taranmasını ve dizinlenmesini bozduğunu, hangisinin iyileştirme düzeyinde kaldığını göremez. Bu yazının son bölümündeki etki, efor ve risk sıralaması bu sorunu hafifletmek için vardır.

Google'ın SEO Başlangıç Kılavuzu da değişikliklerin ölçülü yapılmasını önerir. Kılavuz, hemen siteyi baştan düzenlemeye girişmemek gerektiğini, bazı değişikliklerin birkaç saat, bazılarının ise aylar sonra etkisini gösterebileceğini ve çalışmanın yararlı olup olmadığını değerlendirmek için birkaç hafta beklemek isteyebileceğinizi yazar. Bu cümleler ticket sürecine de uyar: küçük, ayrı ve izlenebilir değişiklikler, tek bir toplu paketten daha kolay ölçülür. Aynı kılavuz, yönergelere uymanın belirli bir sitenin dizine girmesini garanti etmediğini de belirtir; yani ticket'ın vaadi "sıralama" değil, "belirli bir davranışın doğrulanması" olmalıdır.

Ortak dil: Sık karışan kavramlar

Talepler geri dönmeden önce çoğu zaman iki taraf aynı kelimeyi farklı anlar. Aşağıdaki küçük tablo, ticket'ta kullanılacak kelimeleri sabitlemek için bir çalışma sözlüğüdür.

Ticket Şablonu: Sorun, Kanıt, Beklenen Davranış, Kabul Kriteri

Aşağıdaki alanlar bir çalışma şablonudur; Google'dan gelen bir zorunluluk değildir. Amacı, her SEO talebinin geliştiriciye aynı sırayla ve aynı ayrıntıyla ulaşmasıdır.

Şablonun alanları

İyi bir kabul kriteri nasıl yazılır?

Kabul kriteri "evet" ya da "hayır" ile cevaplanabilmelidir. "Başlıklar iyileşmiş olmalı" bir görüş cümlesidir; "listelenen on şablon örneğinin her birinde title öğesi bulunur ve sayfaya özgüdür" bir kontrol cümlesidir. Pratik kural: kabul kriterini okuyan, SEO bilgisi olmayan bir test sorumlusu işi tek başına doğrulayabiliyorsa kriter yeterince somuttur. Kriterlerde üç şeyi ayırın: zorunlu davranış (olmazsa iş kapanmaz), kapsam örnekleri (hangi URL'lerde denenecek) ve ölçüm penceresi (yayından sonra hangi raporda ne zaman bakılacak). Sıralama gibi dış etkenlere bağlı sonuçları kabul kriteri yapmayın; geliştirici bunların hiçbirini kontrol edemez.

Hazır şablon metni

1. Başlık: Davranışı ve kapsamı içeren tek cümle.
2. Sorun: Mevcut durum, etkilenen URL deseni, kime zarar verdiği.
3. Kanıt: En az iki örnek URL, ilgili rapor ya da kaynak kod parçası, ölçüm tarihi.
4. Beklenen davranış: Sistemin nihai durumu; uygulama yolu geliştiriciye bırakılır.
5. Kabul kriteri: Evet ya da hayır kontrol listesi ve test URL'leri.
6. Kapsam dışı: Bu işte dokunulmayacak alanlar.
7. Yayın ve geri alma: Hangi ortamda test edilir, geri dönüş yolu nedir.
8. Yayın sonrası izleme: Hangi rapora, kaç gün sonra bakılır.

Kanıt eklemenin pratik yolları

Kanıtın biçimi, sorunun türüne göre değişir. Yanıt kodu sorunlarında adres ve dönen kod yeterlidir. Şablon sorunlarında sayfa kaynağından ilgili satır ve en az iki farklı sayfadan örnek gerekir; böylece geliştirici sorunun tek bir sayfaya mı, tüm şablona mı ait olduğunu görür. Dizinleme sorunlarında Search Console raporunun adı ve ölçüm tarihi yazılır. Google'ın SEO Başlangıç Kılavuzu, sayfanın Google tarafından nasıl görüldüğünü kontrol etmek için Search Console'daki URL Denetim Aracı'nı önerir; aynı kılavuz, Google'ın kullanıcının tarayıcısıyla aynı kaynaklara erişebilmesi gerektiğini de söyler. Bu iki cümle, kanıt toplarken hem kendi tarayıcınızı hem de URL Denetim Aracı'nı kullanmak için bir gerekçedir.

Tam doldurulmuş örnek ticket

Örnek senaryo: Bir içerik sitesinin yazı arşivinde sayfalama adresleri var. Ticket şöyle yazılabilir.

1. Başlık: Arşiv sayfalarında title öğesi her sayfaya özgü üretilsin.
2. Sorun: Arşivin ikinci ve sonraki sayfaları, birinci sayfayla aynı title ile açılıyor. Bu, arama sonuçlarında ve tarayıcı sekmelerinde sayfaları ayırt edilemez kılıyor.
3. Kanıt: Birinci, ikinci ve üçüncü arşiv sayfasının kaynak kodundaki title satırı; ilgili Search Console başlık raporu varsa ekran görüntüsü.
4. Beklenen davranış: Arşiv şablonu, sayfa numarasını içeren ayırt edici bir title üretsin. İlk sayfa mevcut title'ını korusun.
5. Kabul kriteri: Üç örnek sayfanın title değerleri birbirinden farklıdır; ilk sayfanın title'ı değişmemiştir; title boş değildir; başka şablonların title'ı etkilenmemiştir.
6. Kapsam dışı: Meta açıklama ve başlık hiyerarşisi bu ticket'ta değiştirilmez.
7. Geri alma: Şablon değişikliği tek dosyada, önceki sürüme dönülebilir.
8. İzleme: Yayından sonraki ilk iş günü kaynak kontrolü; birkaç hafta sonra Search Console'da başlık raporuna bakılır.

Dikkat edin: ticket sıralama vaat etmiyor, tek bir davranışı tarif ediyor ve test eden kişi SEO uzmanı olmadan da işi doğrulayabiliyor. İyi bir ticket'ın sınaması budur.

Örnek Talepler: Yönlendirme, Noindex, Canonical, İşaretleme

Aşağıdaki dört örnek, şablonun uygulanmış halidir. Örnek senaryolardır; adresler ve sonuçlar gerçek bir siteye ait değildir. Google'a atfedilen cümleler ilgili belgenin söylediği kadardır.

Örnek 1: Eski ürün adreslerinin yönlendirilmesi

Sorun: Adres yapısı değişti, eski ürün adresleri 404 dönüyor. Beklenen davranış: Kalıcı olarak taşınan her eski adres, yeni karşılığına tek adımda kalıcı yönlendirme yapsın. Google'ın yönlendirme belgesi, 301 ve 308 kodlarının sayfanın kalıcı olarak yeni konuma taşındığını gösterdiğini; kalıcı yönlendirmenin hedefin arama sonuçlarında görünmesine yol açtığını, geçici yönlendirmenin ise kaynak sayfayı sonuçlarda tuttuğunu söyler. HTTP durum kodları belgesi de 301'in hedefin işlenmesi için güçlü, 302'nin ise zayıf bir sinyal olduğunu belirtir. Dolayısıyla taşıma kalıcıysa kalıcı kod seçilir.

Kabul kriteri: Eski adres listesinden seçilen beş örnek, yeni adrese zincir olmadan tek yönlendirmeyle gider; yanıt kodu 301 ya da 308'dir; hedef sayfa 200 döner; hedef sayfada noindex yoktur. JavaScript ile yönlendirme kabul edilmez, çünkü Google belgesi bunu son çare olarak tarif eder ve işlemenin çeşitli nedenlerle başarısız olabileceğini söyler. Yönlendirmeleri ne kadar süre tutacağınız belgede ayrıca belirtilmez; bu süre için ticket'a "kaldırma kararı ayrı bir ticket ile verilir" notu eklemek güvenli bir çalışma kuralıdır.

Örnek 2: Arama sonuç sayfalarına noindex

Sorun: Site içi arama sonuç sayfaları dizinde görünüyor ve ince içerik üretiyor. Beklenen davranış: Bu desendeki sayfalar noindex alsın, ancak taranabilir kalsın. Robots meta etiketi belgesi, noindex kuralının sayfayı arama sonuçlarında göstermemeyi söylediğini, kuralların HTTP başlığı olarak X-Robots-Tag ile de verilebildiğini ve PDF gibi HTML olmayan dosyalarda başlığın kullanılması gerektiğini anlatır. En kritik ayrıntı şudur: bir sayfa robots.txt ile taramaya kapatılmışsa dizinleme kuralları okunmaz ve yok sayılır; kuralın etkili olmasını istiyorsanız URL taramaya kapatılmamalıdır.

Kabul kriteri: Üç örnek arama adresinin yanıtında ya robots meta etiketinde ya X-Robots-Tag başlığında noindex vardır; robots.txt dosyasında bu desene Disallow kuralı yoktur; normal ürün ve kategori sayfalarında noindex bulunmaz. Son madde önemlidir: şablon düzeyinde yapılan noindex hatası, sitenin bölümlerini dizinden düşürebilir. Aynı belge, çelişen kurallarda daha kısıtlayıcı olanın uygulandığını söylediği için aynı sayfada iki ayrı sistem farklı kural koymamalıdır.

Örnek 3: Canonical tutarlılığı

Sorun: Aynı ürün hem parametreli hem parametresiz adreste açılıyor. Beklenen davranış: Her iki sürüm, tercih edilen temiz adresi gösteren tek canonical üretsin. Google'ın yinelenen URL belgesi canonical belirtmenin yollarını sinyal gücüyle anlatır: yönlendirme güçlü sinyal, rel="canonical" bağlantısı güçlü sinyal, site haritası zayıf sinyaldir. Belge, canonical bağlantı öğesinin yalnızca HTML'nin head bölümünde kabul edildiğini, mutlak adreslerin tercih edilmesi gerektiğini, canonical amacıyla robots.txt ve noindex kullanılmaması gerektiğini söyler.

Kabul kriteri: Dört örnek adresin kaynağında head içinde tek bir canonical bağlantısı vardır; adres mutlaktır ve https ile temiz biçimdedir; canonical'daki hedef 200 döner; hedef noindex değildir; site haritasında yalnız tercih edilen adresler yer alır. Sinyal gücü yüzünden "canonical koyduk, sorun bitti" demek de yanlış olur: ticket'a yayından sonra Search Console URL denetiminde Google'ın seçtiği canonical'a bakma adımı eklenir. Bu adım çalışma yöntemi olarak önerilir; yinelenen URL belgesi bu aracı anmaz.

Örnek 4: Yapılandırılmış veri (işaretleme) eklenmesi

Sorun: Yazı sayfalarında yapılandırılmış veri yok. Beklenen davranış: Makale şablonu, sayfada görünen bilgilerle uyumlu bir JSON-LD bloğu üretsin. Ticket yazarken iki tuzak vardır: işaretlemeyi "zengin sonuç garantisi" olarak sunmak ve sayfada görünmeyen bilgiyi işaretlemeye koymak. İkinci tuzak için ticket'a "sayfada görünmeyen alan eklenmeyecek" kuralını yazın; zengin sonuç çıkıp çıkmayacağını ise kabul kriteri yapmayın, çünkü bu geliştiricinin elinde değildir.

Kabul kriteri: Üç örnek yazıda işaretleme bloğu bulunur, yazının başlığı ve yayın tarihi görünen içerikle aynıdır, blok geçerli JSON'dur, sayfada olmayan hiçbir değer içermez. Doğrulama için Google'ın zengin sonuç testi gibi araçlar kullanılabilir; bunlar iş akışının parçasıdır ve sonuç garantisi vermez. Bu örneğin işaretleme kuralları, bu yazıda bağlanan Google sayfalarında değil, yapılandırılmış veri belgelerinde yer alır; uygulamadan önce güncel belgeye bakın.

Yayın Öncesi SEO Testi ve Geri Alma

Birçok SEO hatası kod hatası değil, ortam farkı hatasıdır: test ortamında kapalı olması gereken noindex yayına taşınır, ya da yayında olması gereken canonical test adresini gösterir. Bu nedenle ticket'ın kabul kriteri iki aşamalı yazılır: yayın öncesi test ortamında ve yayın sonrası canlıda.

Yayın öncesi kontrol listesi

• Yanıt kodları: Taşınan ve silinen URL'ler beklenen kodu dönüyor mu? Google, 2xx yanıtın dizinlemeyi garanti etmediğini, hata gibi görünen 2xx sayfaların soft 404 olarak işaretlenebileceğini belirtir; boş sonuç sayfası 200 dönüyorsa bunu ticket'ta ayrıca yazın.
• robots.txt: Yeni kural, taranması gereken bir bölümü kapatıyor mu? Noindex konulan sayfalar taramaya açık mı?
• Meta robots ve X-Robots-Tag: Test ortamından kalan noindex şablon dosyasında duruyor mu? Aynı sayfada çelişen iki kural var mı?
• Canonical: head içinde tek, mutlak, canlı alan adını gösteren bağlantı var mı?
• Yönlendirmeler: Zincir yok, döngü yok, hedef 200 dönüyor mu? Google belgesi yönlendirmelerin varsayılan olarak en fazla on adıma kadar izlendiğini söyler; zincirler gereksiz uzamasın.
• Site haritası: Yalnız dizinlenmesi istenen, 200 dönen adresler var mı?
• Başlık ve açıklama: Şablon her sayfaya özgü title üretiyor mu? SEO Başlangıç Kılavuzu, iyi bir title'ın sayfaya özgü, açık, kısa ve içeriği doğru anlatan olması gerektiğini söyler.
• Görünürlük: Tarayıcının erişebildiği kaynaklara Google da erişebiliyor mu? URL Denetim Aracı ile sayfanın nasıl görüldüğü kontrol edilebilir.

Karar kuralı: Yayını durdur, yayınla ya da izleyerek yayınla

Kuralın mantığı basit: arama motorunun siteyi görmesini ya da doğru adresi seçmesini engelleyen hata yayını durdurur; verimi düşüren ama işlevi bozmayan hata izleyerek yayınlanır; kozmetik fark ise bekleyebilir. Bu sınıflama bir çalışma yöntemidir, eşik değerlerini ekibinizin risk toleransına göre ayarlayın.

Test ortamı ile canlı ortam arasındaki fark

Test ortamları genellikle arama motorlarına kapatılır; bu nedenle test sırasında noindex, parola koruması ya da robots.txt engeli bulunması normaldir. Sorun, bu korumaların canlıya taşınmasıdır. Ticket'ta iki ayrı satır tutmak işe yarar: "test ortamında beklenen durum" ve "canlıda beklenen durum". Örneğin test ortamında noindex olmalı, canlıda olmamalıdır; test ortamındaki canonical test alan adını gösterebilir, canlıdaki ise canlı alan adını göstermelidir. Yayın günü kontrol listesine "ortam bayraklarını doğrula" maddesini ekleyin ve bu maddeyi geliştirme tarafında bir kişiye atayın. Böylece en pahalı SEO hatalarından biri, bir yapılandırma satırının yanlış ortamda kalması, sıradan bir kontrol maddesine dönüşür.

Geri alma planı

Geri alma, ticket'ın ayrı bir alanı olmalıdır. Hangi dosya ya da yapılandırma önceki sürüme döner, hangi önbellek temizlenir, geri alma kararını kim verir ve kaç dakikada uygulanır, yazılı olmalıdır. Yönlendirme ve noindex gibi değişikliklerde geri almanın etkisi hemen görülmeyebilir: Google, 4xx dönen URL'lerin tarama sıklığını kademeli azalttığını ve 5xx hatalarında taramayı geçici yavaşlattığını, sunucu yeniden 2xx döndürdüğünde hızı yavaş yavaş artırdığını belirtir. Yani teknik düzeltme hızlı, arama tarafındaki toparlanma yavaş olabilir. Ticket'a bu beklentiyi yazın ve toparlanma süresini kabul kriteri yapmayın.

Yayın sonrası izleme penceresi

Yayından hemen sonra yapılacak kontroller (örnek URL'lerin yanıtı, kaynak kod, robots.txt) aynı gün tamamlanır. Dizin ve performans raporlarına bakmak için SEO Başlangıç Kılavuzu'ndaki "birkaç hafta bekleyin" ilkesi çalışma penceresi olarak kullanılabilir. Ticket'ta "yayından sonra ilk iş günü: davranış kontrolü; birkaç hafta sonra: Search Console'da ilgili rapor" biçiminde iki ayrı kutucuk olsun. Birinci kutucuğu geliştiriciyle, ikincisini SEO sorumlusuyla ilişkilendirin.

Önceliklendirme: Etki, Efor, Risk

Tüm denetim maddelerini aynı anda ticket'a çevirmek, sprint'in dolmasına ve kritik işlerin diğerlerinin içinde kaybolmasına yol açar. Önceliklendirme de bir çalışma yöntemidir; Google belgelerinde bu sıralamanın karşılığı yoktur, deneyimden gelen bir çerçevedir.

Üç eksenli puanlama

Her talebe üç soru sorulur. Etki: bu sorun taramayı, dizinlemeyi ya da önemli sayfaların görünürlüğünü engelliyor mu? Efor: geliştirici bunu kaç saatte ya da kaç sprintte tamamlar, başka ekibe bağımlılığı var mı? Risk: yanlış uygulanırsa neyi bozabilir, geri alma kolay mı? Puanları yüksek, orta, düşük gibi kaba sınıflarla verin. Sahte kesinlik üreten sayısal formüllere gerek yoktur; amaç tartışmayı yapılandırmaktır, sonucu hesaplamak değildir.

Önceliklendirme tablosu

Birlikte çalışma kuralları

• Bir ticket, bir davranış. Karma ticket'lar kabul kriterini bulanıklaştırır.
• Önce engelleyiciler: taramayı ya da dizinlemeyi bozan hatalar, optimizasyonlardan önce gelir.
• Uygulama yöntemini geliştiriciye bırakın; SEO beklenen sonucu ve kontrolü tarif eder.
• Her ticket'ta tek soru sahibi olsun: SEO tarafında kim, geliştirme tarafında kim.
• Reddedilen talebin gerekçesi ticket'a yazılsın; aynı talep üç ay sonra yeniden açılırsa tarihçe görünsün.
• Haftalık kısa senkronizasyon: açık, test bekleyen ve kapanan SEO ticket'ları tek ekranda.

Ajans ve iç ekip için küçük bir uyarlama

Ajans çalışıyorsa ticket'ı müşterinin kendi iş takip aracında açmak ve ajansı yalnız yorum ve doğrulama için eklemek, sürecin sahipliğini netleştirir. Ürün sahibi için pratik soru şudur: bu iş yapılmazsa taranabilirlik ya da dizinleme etkilenir mi? Cevap evet ise ticket, ürün işiyle aynı ciddiyette ele alınır. Cevap hayır ise iş, iyileştirme listesinde yerini alır ve sprint kapasitesi uygunsa yapılır.

İlgili rehberler: SEO A/B Testi: Cloaking Olmadan Başlık ve Şablon Denemesi, Search Console Mülk Türü ve Doğrulama Rehberi.

Sonuç

SEO talebinin geri dönmemesi için yazarken beş şeyi sabitleyin: tek davranış, kanıt, beklenen son durum, evet ya da hayır cevaplı kabul kriteri ve geri alma yolu. Teknik cümleleri Google'ın ilgili sayfasına bağlayın; süreç cümlelerinin ise bir çalışma yöntemi olduğunu açıkça söyleyin. Önceliği etki, efor ve riskle belirleyin ve ticket'ın sonucunun sıralama değil, doğrulanmış davranış olduğunu hatırlayın.

Bağlantı profili tarafındaki çalışmayı destekleyecek hizmetlere göz atmak isterseniz Akua Adforce'taki backlink paketleri sayfasında kapsam ve koşullar listelenir. İlgili okumalar: teknik SEO denetimi kontrol listesi ve önceliklendirme, ajanslar için SEO projesi başlangıç kontrol listesi, aylık SEO raporu şablonu ve SEO ajansı mı iç ekip mi karşılaştırması.

Teknik davranışların kaynağı olan Google sayfaları: SEO Başlangıç Kılavuzu (yeni sekmede açılır), HTTP durum kodları ve tarama (yeni sekmede açılır), robots meta etiketi (yeni sekmede açılır), yinelenen URL'lerin birleştirilmesi (yeni sekmede açılır) ve yönlendirmeler (yeni sekmede açılır). Bu sayfalardaki sınırlar ve öneriler değişebilir; uygulamadan önce güncel sayfaya bakın.

Sık Sorulan Sorular

SEO talebi ile SEO denetim raporu aynı şey mi?

Hayır. Denetim raporu bulguları listeler; talep ise tek bir bulguyu geliştiricinin uygulayabileceği iş haline getirir. Talepte sorun, kanıt, beklenen davranış ve kabul kriteri bulunur. Rapor maddesini olduğu gibi ticket'a yapıştırmak çoğu zaman geri dönüşe yol açar.

Kabul kriteri sıralama artışı olabilir mi?

Olmamalı. Sıralama geliştiricinin kontrol edemediği etkenlere bağlıdır ve Google'ın SEO Başlangıç Kılavuzu belirli bir sitenin dizine gireceğinin garanti edilmediğini söyler. Kabul kriteri yanıt kodu, kaynak koddaki satır ya da robots kuralı gibi doğrulanabilir bir davranış olmalıdır.

Uygulama yöntemini ticket'ta belirtmeli miyim?

Genelde hayır. Beklenen son durumu ve kontrolü yazın, yöntemi geliştiriciye bırakın. Yönlendirme ya da noindex gibi teknik gereklilikler varsa, örneğin kalıcı taşımada kalıcı yönlendirme kodu, bunu kabul kriteri olarak ekleyin.

Noindex koyduğum sayfayı robots.txt ile de kapatmalı mıyım?

Hayır. Google'ın robots meta etiketi belgesine göre robots.txt ile taramaya kapatılmış sayfanın dizinleme kuralları okunmaz ve yok sayılır. Noindex'in etkili olması için URL'nin taramaya açık kalması gerekir.

Aynı anda kaç SEO ticket'ı açmalıyım?

Sabit bir sayı yoktur. Önce taramayı ve dizinlemeyi engelleyen hatalara öncelik verin, her ticket'ta tek davranış tutun ve sprint kapasitesini etki, efor ve riske göre paylaştırın. Bu bir çalışma yöntemidir, Google belgesinden bir kural değildir.

Yayından sonra sonuçlara ne zaman bakmalıyım?

Davranış kontrolü yayından hemen sonra yapılır. Arama tarafındaki etki için SEO Başlangıç Kılavuzu bazı değişikliklerin birkaç saat, bazılarının aylar sürebileceğini ve sonuçları değerlendirmeden önce birkaç hafta beklemek isteyebileceğinizi söyler.