SEO Kalite Güvence Süreci Nasıl Kurulur?

SEO QA (Kalite Güvence) süreci, teknik, içerik ve tasarım standartlarını korumak için oluşturulan bir iş akışıdır. Hataları canlıya geçmeden yakalayarak organik performansı korur.

Web platformlarında yürütülen yazılım güncellemeleri, tasarım revizyonları ve altyapı göçleri, organik arama görünürlüğünü doğrudan etkileyen yüksek riskli süreçlerdir. Yazılım ekipleri genellikle işlevsellik ve kod kararlılığına odaklanırken, arama motoru botlarının siteyi nasıl taradığı ve dizine eklediği gözden kaçabilir. Bu rehberde, dijital karar vericiler ve teknik ekipler için kurumsal ölçekte SEO Kalite Güvence Süreci Nasıl Kurulur? sorusunun operasyonel adımları, CI/CD entegrasyon metodolojileri, risk önleme protokolleri ve test senaryoları detaylandırılmaktadır.

SEO QA Nedir ve Neden Bir Tercih Değil, Zorunluluktur?

SEO Kalite Güvence (Quality Assurance) süreci; bir web sitesinde yapılan kod, tasarım, altyapı, içerik ve bilgi mimarisi değişikliklerinin, arama motoru botları ve organik arama performansı üzerindeki olası negatif etkilerini henüz geliştirme aşamasında tespit edip engelleyen sistematik denetim mekanizmasıdır. Geleneksel yazılım test süreçleri sistemin çökmemesini, veri tabanı sorgularının çalışmasını ve kullanıcı arayüzü butonlarının tıklanabilirliğini doğrular. Ancak bir butonun arka plandaki yönlendirmeyi bozması, dinamik JavaScript bileşenlerinin Googlebot tarafından işlenememesi veya staging ortamındaki noindex direktifinin canlı sunucuya aktarılması standart yazılım QA testlerinde bir hata (bug) olarak algılanmaz.

Arama motorları algoritmik olarak tarama bütçesi (crawl budget), sayfa işleme (rendering), dizine ekleme (indexing) ve sıralama (ranking) aşamalarından oluşan karmaşık bir boru hattı işletir. Canlıya alınan tek bir hatalı kod satırı; binlerce URL'in arama motoru dizininden silinmesine (deindexing), canonical etiketlerinin kopmasına, dahili link ağının parçalanmasına veya Core Web Vitals metriklerinin kritik seviyelere düşmesine yol açabilir. SEO QA, bu riskleri reaktif olarak canlı ortamda düzeltmek yerine, proaktif olarak üretim (production) öncesi yakalayan bir kurumsal sigorta görevi görür.

Gelişmiş mühendislik kültürüne sahip organizasyonlarda SEO, yayın sonrasında çağrılan bir danışmanlık katmanı değil, yazılım geliştirme yaşam döngüsünün (SDLC) ayrılmaz bir kalite kriteridir (DoD - Definition of Done). Bu yaklaşım, teknik borcun (technical debt) birikmesini engellerken ürün yöneticileri, yazılımcılar ve pazarlama departmanı arasında ortak bir kalite standardı oluşturur.

Kritik SEO Hatalarının Şirketlere Finansal Maliyeti

Teknik SEO hatalarının canlıya sızması, işletmeler için doğrudan ciro kaybı, müşteri edinme maliyetlerinde (CAC) artış ve itibar zedelenmesi anlamına gelir. Özellikle e-ticaret platformları, SaaS çözümleri ve yüksek hacimli yayıncılar için arama motoru dizininden geçici olarak bile çıkarılmak yüz binlerce dolarlık gelir kaybı yaratır.

Finansal riskin temel kaynakları şu alanlarda yoğunlaşır:

• Trafik Kaybını Telafi Etmek İçin Harcanan Ücretli Reklam Bütçesi: Organik sıralamalarını kaybeden sayfaların oluşturduğu trafik açığını kapatmak için anlık olarak Google Ads (PPC) bütçelerine yüklenmek gerekir. Bu durum müşteri edinme maliyetini katlayarak marjları tüketir.

• Geliştirici Eforu ve Acil Düzeltme Maliyetleri (Hotfix Cost): Canlı ortamda patlayan bir hatayı düzeltmek; planlanmış sprintleri durdurur, yazılımcıları acil hata ayıklama (debugging) sürecine iter ve yeni özellik geliştirmelerini geciktirir.

• Arama Motoru Güveninin Yeniden İnşası: Google algoritmaları, 404/500 hataları veren veya taranamayan sayfaları dizinden düşürdükten sonra, hata düzeltilse dahi eski sıralamaların ve tarama sıklığının geri kazanılması haftalar veya aylar sürebilir.

"Canlıya Geçiş" (Deployment) Sonrası Yaşanan Trafik Kayıplarının Anatomisi

Canlıya geçiş sonrası yaşanan organik trafik kayıpları nadiren tek bir büyük çöküşle sınırlı kalır; genellikle kademeli ve teşhisi zor aşamalar halinde gerçekleşir. Yaygın senaryoda, Cuma akşamı canlıya alınan bir sürümde test ortamındaki Disallow: / kuralı canlı robots.txt dosyasına taşınır. Googlebot hafta sonu boyunca siteyi taramayı durdurur; pazartesi günü Search Console üzerinde tarama istatistiklerinde sert bir düşüş başlar ve çarşamba gününe gelindiğinde anahtar kelimelerin büyük kısmı dizinden çekilir.

Bir diğer sinsi senaryo ise JavaScript tabanlı tek sayfa uygulamalarında (SPA) görülür. Sunucu taraflı işleme (SSR) yerine tamamen istemci taraflı işlemeye (CSR) dönüştürülen ürün sayfalarında, arama motoru botlarının ilk taramada sadece boş bir HTML gövdesi (<div id="root"></div>) görmesi durumunda, içerik indeksleme kuyruğuna (render queue) atılır. Bu kuyruktaki gecikmeler, Google'ın içeriği geç işlemesine veya tamamen atlamasına neden olarak sıralamaları haftalarca geriletir.

Adım Adım SEO QA Süreci Kurulumu ve İş Akışı

Kurumsal bir SEO QA süreci oluşturmak, yalnızca bir kontrol listesi hazırlamaktan ibaret değildir; ürün yönetimi, yazılım mühendisliği ve dijital pazarlama ekiplerinin senkronize çalıştığı tekrarlanabilir bir sistem tasarlamayı gerektirir. Süreç, proje planlama aşamasından (Sprint Planning) başlayarak kodun canlıya alınması ve sonrasındaki izleme protokollerine kadar uzanır.

İş akışının temel felsefesi "Shift-Left" yaklaşımıdır. Yazılım test mühendisliğinde sıkça kullanılan bu kavram, test süreçlerinin canlıya geçiş anına yığılması yerine, geliştirme döngüsünün en soluna (yani planlama ve tasarım aşamasına) çekilmesini ifade eder. SEO gereksinimleri bir projenin teknik spesifikasyon dokümanında (PRD) baştan tanımlandığında, yazılımcı kodu bu mimariye göre yazar ve hata oranı başlangıçta minimize edilir.

Sistematik bir iş akışının kurulması, hem manuel inceleme sürelerini kısaltır hem de insan hatasına bağlı gözden kaçırma risklerini ortadan kaldırır.

1. Adım: Rollerin ve Sorumlulukların Tanımlanması (SEO, Yazılımcı ve Ürün Sahibi)

SEO QA sürecinin sürdürülebilir olması için RACI (Responsible, Accountable, Consulted, Informed) matrisinin net olarak kurgulanması şarttır. Ekipler arasındaki rol belirsizliği, hataların fark edilip kimse tarafından sahiplenilmemesine yol açar.

Rol dağılımı aşağıdaki yapı üzerinden işletilmelidir:

• SEO Uzmanı / Teknik SEO Lideri (Accountable & Consulted): Değişikliklerin teknik SEO standartlarına uygunluğunu belirler, test kriterlerini (acceptance criteria) yazar, test ortamı taramalarını gerçekleştirir ve canlıya alım için onay (sign-off) verir.

• Ürün Sahibi / Product Owner (Responsible): SEO gereksinimlerinin sprint kapsamına alınmasını sağlar, iş önceliklendirmesinde organik arama risklerini göz önünde bulundurur ve SEO testleri tamamlanmadan görevin "Done" statüsüne geçmesine izin vermez.

• Yazılım Geliştirici / Front-end & Back-end Developer (Responsible): Belirlenen teknik SEO spesifikasyonlarına (semantik HTML, doğru HTTP başlıkları, şema işaretlemeleri, SSR uyumluluğu) uygun kod yazar ve birim (unit) testleri kurgular.

• Kalite Güvence Mühendisi / QA Tester (Responsible): Fonksiyonel testlerin yanı sıra temel SEO kontrol maddelerini (kırık linkler, meta etiket varlığı, temel yönlendirmeler) kendi test senaryolarına (test cases) dahil eder.

2. Adım: Test (Staging) Ortamının Güvenli Bir Şekilde Hazırlanması

Staging veya User Acceptance Testing (UAT) ortamları, geliştirilen özelliklerin canlıya çıkmadan önce birebir taklit edildiği ortamlardır. Ancak bu ortamların SEO QA testlerine hazır hale getirilmesi iki kritik güvenlik gereksinimi doğurur: test sitesinin Google tarafından taranmasının engellenmesi ve aynı zamanda SEO analiz araçlarının bu siteyi eksiksiz tarayabilmesi.

Test ortamının güvenliğini sağlarken en sık yapılan hata, sadece robots.txt ile engelleme yapmaktır. Google, harici bir bağlantı bulduğunda Disallow kuralı olsa dahi URL'i içeriğini görmeden dizine ekleyebilir.

Güvenli bir test ortamı mimarisi şu adımlarla kurulmalıdır:

1. HTTP Basic Authentication (Kullanıcı Adı/Şifre): Sunucu düzeyinde parola koruması uygulanmalıdır. Bu yöntem, arama motoru botlarının siteye erişmesini %100 oranında engeller.

2. IP Beyaz Listesi (IP Whitelisting): Yalnızca şirket ofisi, VPN ve test araçlarının (Screaming Frog, Sitebulb sunucuları vb.) sabit IP adreslerine erişim izni verilmelidir.

3. HTTP Başlığında X-Robots-Tag: noindex, nofollow Kullanımı: Test ortamının tüm HTTP yanıtlarına bu başlık eklenmelidir. Böylece Basic Auth kaldırılsa bile sayfalar dizine girmez.

4. Tarama Araçlarına Özel Erişim: Test edilecek SEO tarayıcılarının User-Agent veya özel HTTP başlıkları (Custom Header) üzerinden parola korumasını aşması sağlanmalıdır.

3. Adım: Otomatik Tarama ve İzleme Sistemlerinin Kurulması

Büyük ölçekli web sitelerinde binlerce sayfanın tek tek manuel olarak incelenmesi operasyonel açıdan imkansızdır. Bu nedenle SEO QA süreci, periyodik ve otomatik çalışan tarama sistemleriyle desteklenmelidir.

Otomasyon altyapısı şu iki temel bileşenden oluşmalıdır:

• Staging Tarama Otomasyonu: Her yeni sürüm adayı (Release Candidate) staging ortamına yüklendiğinde, komut satırı arayüzü (CLI) veya API üzerinden tetiklenen otomatik Screaming Frog ya da Sitebulb taraması başlatılır. Tarama çıktısı, belirlenen regresyon eşikleriyle (örneğin "404 veren sayfa sayısı 0 olmalı", "canonical uyuşmazlığı 0 olmalı") karşılaştırılır.

• Canlı Ortam Değişiklik İzleme: Canlıya alınan kodların ardından devreye giren ContentKing gibi gerçek zamanlı izleme araçları, web sayfalarındaki robots direktifleri, meta etiketler veya şema verilerinde beklenmedik bir değişiklik olduğunda anında Slack/E-posta üzerinden alarm üretir.

Kapsamlı SEO QA Kontrol Listesi (Checklist)

Teknik SEO QA sürecinin omurgasını, her sürüm öncesi eksiksiz uygulanması gereken kontrol listesi (checklist) oluşturur. Bu liste; tarama, dizine ekleme, sayfa içi hiyerarşi, performans ve veri yapılandırmasını kapsayan çok boyutlu bir filtre görevi görür. Her kontrol maddesi için "Geçti", "Kaldı" veya "Bloklayıcı Hata (Blocker)" şeklinde durum ataması yapılmalıdır.

Kontrol listesinin doğru işletilmesi, regresyon (daha önce çalışan bir özelliğin yeni kodla bozulması) riskini sıfıra indirir.

Yayına Alım Öncesi (Pre-Deployment) Teknik SEO Kontrolleri

Yazılım staging ortamındayken yapılan ilk teknik değerlendirme katmanıdır. Bu aşamada sitenin arama motoru standartlarına temel uyumluluğu taranır:

• HTTP Yanıt Kodları: Test edilen tüm birincil sayfaların 200 yanıtı verdiği, geçici olarak kaldırılan sayfaların 302 ile doğru hedefe yönlendirildiği ve silinen içeriklerin 404 veya 410 döndürdüğü doğrulanmalıdır.

• HTML Başlık (Title) ve Meta Açıklamaları: Dinamik şablonların değişkenleri (ürün adı, kategori adı, fiyat, şehir vb.) doğru çekip çekmediği, çift (duplicate) başlıkların oluşup oluşmadığı ve karakter uzunluğu sınırları denetlenmelidir.

• Başlık Hiyerarşisi (H1-H6): Her sayfada yalnızca bir adet <h1> etiketi bulunmalı, başlık sırası mantıksal bir sıra (H1 > H2 > H3) izlemeli ve boş başlık etiketleri bulunmamalıdır.

• Görsel Optimizasyonu ve Alt Nitelikleri: Yeni eklenen veya değişen tüm görsellerin alt etiketlerinin dinamik olarak doldurulduğu, modern görsel formatlarının (WebP/AVIF) kullanıldığı ve görsel boyutlarının doğru tanımlandığı incelenmelidir.

Kritik Tarama ve İndekslenme Engellerinin (noindex, robots.txt) Denetimi

Canlıya geçiş sırasında organik görünürlüğü en hızlı yok eden hatalar bu grupta yer alır. Bu nedenle bu bölümdeki hatalar istisnasız "Canlıya Geçişi Durduran (Release Blocker)" olarak etiketlenmelidir:

• Robots Meta Etiketi: Canlıya gidecek kod tabanındaki robots etiketinde kazara noindex veya nofollow kalmadığı doğrulanmalıdır.

• robots.txt Yapılandırması: Canlıya alınacak robots.txt dosyasının içeriği test edilmeli, CSS/JS dosyalarını veya taranması gereken kritik kategori/ürün yollarını engelleyen kuralların bulunmadığı teyit edilmelidir.

• Canonical (Kurallı) Etiketler: Her sayfanın kendi kurallı URL'ini (self-referencing canonical) veya parametreli sayfalarda orijinal ana sayfayı işaret ettiği, protokolün (HTTPS) ve alan adının staging ortamı URL'i değil, canlı ortam URL'i olduğu denetlenmelidir.

• Sayfalama (Pagination) ve Filtreler: E-ticaret sitelerinde filtreleme parametrelerinin canonical etiketleri ve robots direktifleri üzerinden dizin kirliliği yaratmayacak şekilde kurgulandığı doğrulanmalıdır.

Sayfa Mimarisi, URL Yapısı ve Yönlendirme (Redirect) Testleri

Site mimarisindeki değişiklikler, PageRank akışını ve kullanıcı deneyimini doğrudan etkiler:

• URL Formatı ve Standartları: Yeni oluşturulan URL'lerin küçük harf kullandığı, Türkçe karakter içermediği, boşluk yerine tire (-) ile ayrıldığı ve trailing slash (/) kullanımının tüm sitede tutarlı olduğu kontrol edilmelidir.

• Yönlendirme Zincirleri ve Döngüleri (Redirect Chains & Loops): Yapılan 301 yönlendirmelerinin doğrudan nihai hedef URL'e ulaştığı (ör: A -> B -> C yerine A -> C), araya birden fazla atlama noktası girmediği ve sonsuz döngülerin (infinite loop) oluşmadığı doğrulanmalıdır.

• Dahili Bağlantı (Internal Linking) Bütünlüğü: Menü, alt bilgi (footer), kırıntı menü (breadcrumbs) ve içerik içi linklerin yönlendirmeye (301) uğramadan doğrudan nihai canonical URL'lere çıkış yaptığı kontrol edilmelidir.

• XML Site Haritası (Sitemap) Güncelliği: XML site haritasının yalnızca 200 durum kodu veren, canonical olan ve indekslenebilir URL'leri içerdiği; haritanın güncel tarihle (<lastmod>) otomatik yenilendiği doğrulanmalıdır.

Site Hızı ve Core Web Vitals Standartlarının Korunması

Yeni yazılan kod blokları, eklenen üçüncü taraf kütüphaneler (tracking scripts) veya tasarım revizyonları sayfa hızını olumsuz etkileyebilir:

• Largest Contentful Paint (LCP): Sayfanın ana içerik ögesinin (kahraman görseli, ana başlık vb.) yüklenme süresinin 2.5 saniyenin altında kaldığı test edilmelidir.

• Interaction to Next Paint (INP): Sayfadaki JavaScript yükünün kullanıcı tıklama ve form doldurma etkileşimlerini bloke etmediği (200 ms altında yanıt verdiği) Lighthouse ve laboratuvar testleriyle doğrulanmalıdır.

• Cumulative Layout Shift (CLS): Sayfa yüklenirken sonradan yüklenen reklamlar, fonts veya görseller nedeniyle düzenin kaymadığı (CLS skorunun 0.1 altında olduğu) teyit edilmelidir.

• Sunucu Yanıt Süresi (TTFB): Arka uç kod revizyonlarının ve veri tabanı sorgu optimizasyonlarının sunucu ilk yanıt süresini (Time to First Byte) 800 ms sınırının üzerine çıkarmadığı kontrol edilmelidir.

Yazılım Geliştirme (CI/CD) Süreçlerine SEO QA Entegrasyonu

Geleneksel organizasyonlarda SEO QA'in en büyük handikapı, testlerin manuel olarak yapılması ve bu durumun yazılım yayın hızını yavaşlatmasıdır. Modern mühendislik standartlarında bu problem, SEO kontrollerinin Sürekli Entegrasyon ve Sürekli Dağıtım (CI/CD - Continuous Integration / Continuous Deployment) boru hatlarına dahil edilmesiyle çözülür.

SEO kontrolleri otomatikleştirildiğinde; geliştirici GitHub, GitLab veya Bitbucket üzerinde bir Pull Request (PR) açtığı anda arka planda otomatik test script'leri çalışır. Bu testler sitenin kritik sayfalarını tarar; eğer bir sayfada canonical etiketi silinmişse, title bozulmuşsa veya noindex eklenmişse derleme (build) işlemi otomatik olarak başarısız (fail) olur ve kodun canlı sunucuya birleştirilmesi (merge) engellenir.

Bu yaklaşım, SEO ekibinin her küçük değişiklik için manuel mesai harcamasını engellerken, yazılımcıya anında geri bildirim (feedback loop) sağlayarak hatanın kaynağında düzeltilmesini sağlar.

Geliştiriciler (Developers) ile SEO Ekipleri Arasındaki İletişim Bariyerini Aşmak

Yazılım mühendisleri ile SEO uzmanları arasındaki en büyük sürtüşme, teknik gereksinimlerin ifade edilme biçiminden kaynaklanır. "Bu sayfayı SEO uyumlu yapalım" şeklindeki soyut talepler yazılımcılar için geçersizdir. Mühendislik ekipleri net girdiler, beklenen çıktılar ve test edilebilir sınırlar ile çalışır.

İletişim bariyerini aşmak için şu prensipler benimsenmelidir:

• Gherkin / BDD (Behavior Driven Development) Formatında Kabul Kriterleri: Talepler "Given-When-Then" mantığıyla yazılmalıdır. (Örn: Given bir kullanıcı /kategori/ayakkabi URL'ine girdiğinde, When sayfa yüklendiğinde, Then HTML <head> alanında canonical etiketi yer almalıdır.)

• Teknik Nedenlerin Açıklanması: Bir kuralın neden istendiği (örneğin hydration hatasının neden Google render bütçesini tükettiği) teknik gerekçeleriyle anlatılmalıdır.

• Hata Raporlarında Kanıt Sunumu: Hata bildirimlerinde sadece "yönlendirme çalışmıyor" demek yerine; cURL komut çıktısı, HTTP yanıt başlıkları (headers) ve ekran görüntüleri eklenmelidir.

Jira, Asana veya Trello Üzerinde SEO QA Görev Kartlarının Yapılandırılması

Proje yönetim araçlarında SEO görevlerinin doğru yapılandırılması, süreçlerin takibini şeffaf hale getirir. Her yazılım geliştirme kartına zorunlu bir "SEO QA Check" alt görevi veya kontrol alanı eklenmelidir.

Standart bir Jira SEO QA kartı aşağıdaki bileşenleri içermelidir:

• Özet (Summary): Yapılacak değişikliğin net teknik tanımı.

• SEO Etki Derecesi (Impact Level): Düşük, Orta, Yüksek, Kritik (Kritik ve Yüksek seviyeler SEO onayı olmadan canlıya alınamaz).

• Teknik Spesifikasyon (Technical Specs): İlgili sayfaların URL yapısı, meta şablonları, şema yapılandırması ve yönlendirme mantığı.

• Kabul Kriterleri (Acceptance Criteria): Test mühendisinin ve SEO uzmanının kontrol edeceği maddeler.

• Test Ortamı URL'leri: Değişikliğin inceleneceği staging linkleri.

• Sign-off Onayı: SEO uzmanının test tamamlandıktan sonra verdiği dijital onay.

SEO QA Sürecinde Kullanılması Gereken En İyi Araçlar ve Otomasyon

Ölçeklenebilir bir SEO QA operasyonu, doğru seçilmiş bir araç yığını (tool stack) üzerinde yükselir. Araçlar; derinlemesine test ortamı tarayıcıları, sürekli entegrasyon test kütüphaneleri ve canlı ortam anlık izleme sistemleri olmak üzere üç ana kategoride konumlandırılmalıdır.

Bu sistemlerin birbirini tamamlayacak şekilde yapılandırılması, hem planlı sürümlerde hem de habersiz yapılan sıcak düzeltmelerde (hotfix) tam koruma sağlar.

Gerçek Zamanlı İzleme ve Uyarı Sistemleri (Örn: ContentKing)

Periyodik taramalar sitenin o anki fotoğrafını çekerken, gerçek zamanlı izleme araçları 7/24 kesintisiz çalışan bir radar gibi işlev görür. Bu araçlar sitenin sayfalarını sürekli tarayarak meydana gelen mikro ve makro değişiklikleri anında kaydeder.

Gerçek zamanlı sistemlerin temel kullanım alanları:

• Anlık Direktif Değişiklikleri: Bir kategorideki robots meta etiketinin noindex olarak değişmesi durumunda 15 dakika içinde bildirim üretmesi.

• Canonical Uyuşmazlıkları: Yanlışlıkla yapılan bir kod birleştirmesi sonrası canonical etiketlerinin ana sayfaya dönmesi gibi yıkıcı hataların anında yakalanması.

• Başlık ve H1 Kayıpları: İçerik yönetim sisteminde (CMS) yapılan bir şablon güncellemesinin başlık etiketlerini silmesi durumunda alarm oluşturulması.

• Entegrasyon: Bu araçların doğrudan kurumsal iletişim platformlarına (Slack, Microsoft Teams) veya olay yönetim sistemlerine (PagerDuty) webhook aracılığıyla bağlanması.

Test Ortamı Taramaları İçin Screaming Frog ve Sitebulb Ayarları

Masaüstü ve sunucu tabanlı tarayıcılar, staging ortamındaki kapsamlı regresyon testlerinin merkezinde yer alır. Ancak bu araçların test ortamına özgü doğru ayarlarla yapılandırılması gerekir.

Test ortamı taramalarında yapılması gereken teknik ayarlar:

1. Kimlik Doğrulama Yapılandırması (Authentication): Staging ortamı Basic Auth ile korunuyorsa, Screaming Frog içinde Configuration > Authentication sekmesinden kullanıcı adı ve parola tanımlanmalıdır.

2. Özel Başlık Ekleme (Custom HTTP Headers): Sunucu IP veya User-Agent yerine özel bir güvenlik başlığı (X-QA-Token: SecretKey123) bekliyorsa, tarayıcıya bu başlık tanıtılmalıdır.

3. JavaScript Rendering Modu: Tek Sayfa Uygulamaları (React, Vue, Angular) test ediliyorsa, tarayıcı Spider > Rendering > JavaScript moduna alınmalı; AJAX istekleri ve DOM içerikleri eksiksiz işlenmelidir.

4. URL Yeniden Yazma (URL Rewriting): Staging ortamındaki URL'ler (https://staging.example.com) taranırken, canonical etiketlerinin canlı alan adını (https://example.com) doğru gösterip göstermediğini test etmek için Configuration > URL Rewriting kuralları kullanılmalıdır.

5. Crawl Comparison (Tarama Karşılaştırma): Canlı sitenin güncel tarama verisi ile staging ortamının tarama verisi karşılaştırılarak kaybolan sayfalar, değişen durum kodları ve bozulan linkler tek bir raporda filtrelenmelidir.

Canlıya Alım Günü (Deployment Day) Kritik Eylem Planı

Tüm test ortamı süreçleri başarıyla tamamlansa dahi, kodun canlı sunuculara dağıtıldığı (deployment) an en kırılgan zaman dilimidir. Sunucu önbellekleri (CDN cache), ortam değişkenleri (environment variables), veri tabanı göçleri ve sunucu yönlendirmeleri canlı ortamda beklenmedik davranışlar sergileyebilir. Bu nedenle canlıya alım günü dakikası dakikasına planlanmış bir protokol üzerinden yönetilmelidir.

Yayın günü SEO ekibinin rolü, izleyici olmak değil; aktif olarak duman testlerini (smoke tests) yürütmek ve sistem stabilitesini teyit etmektir.

İlk 1 Saatte Yapılması Gereken "Smoke Test" (Duman Testi) Adımları

Yazılım canlı sunucuya aktarıldığı andan itibaren ilk 60 dakika içinde tamamlanması gereken kritik kontroller şunlardır:

1. robots.txt Dosyasının Doğrulanması (0-5. Dakika): /robots.txt adresine gidilerek dosyanın canlı versiyona geçtiği, test ortamındaki Disallow: / kuralının silindiği teyit edilir.

2. Örneklem Sayfa Kontrolleri (5-15. Dakika): Ana sayfa, en çok ciro getiren ilk 10 kategori, en popüler 10 ürün sayfası ve kritik landing page'ler manuel olarak açılır. Kaynak kod (View Source) üzerinden title, description, canonical ve robots etiketleri incelenir.

3. Hızlı Canlı Taraması (15-40. Dakika): Screaming Frog veya benzeri bir araçla sitenin en önemli 500-1000 URL'ini içeren bir liste taraması (List Mode) başlatılır. 404, 500 hataları ve yönlendirme zincirleri taranır.

4. CDN ve Önbellek (Cache Purge) Kontrolü (40-50. Dakika): Cloudflare, Fastly veya Akamai gibi CDN katmanlarının eski HTML sürümlerini önbellekten temizlediği (cache purge) doğrulanır.

5. Dönüşüm ve Analitik Etiketleri (50-60. Dakika): Google Tag Manager, GA4 ve dönüşüm izleme kodlarının yeni şablonda tetiklendiği kontrol edilir.

Google Search Console Üzerinden Hızlı İndeksleme ve Hata Takibi

Canlıya alım sonrasında Google'ın yeni sayfaları ve değişen mimariyi nasıl algıladığını anlamak için Search Console üzerinden şu adımlar işletilmelidir:

• URL Denetimi (URL Inspection): Değişen kritik sayfa şablonlarından birkaç URL "URL Denetimi" aracına girilir. "Canlı Testi Yap" (Test Live URL) butonuna basılarak Googlebot'un sayfayı sorunsuz render edip edemediği ve ekran görüntüsünde içeriğin tam yüklenip yüklenmediği teyit edilir.

• Dizine Ekleme İsteği: Kritik şablon değişikliklerinde URL Denetimi üzerinden "Dizine Eklenmesini İste" (Request Indexing) butonuna basılarak Googlebot öncelikli taramaya davet edilir.

• Site Haritalarının Yeniden Gönderimi: Yeni URL yapısını içeren güncel XML site haritası Search Console'a yeniden gönderilir.

• Dizin Kapsamı ve 404 Takibi: Sonraki 48-72 saat boyunca Search Console "Sayfalar" (Page Indexing) raporu izlenerek beklenmeyen 404, soft 404 veya noindex tarafından hariç bırakıldı uyarılarının sıklığı takip edilir.