Web Sitesi Teslim Kabul Testi: SEO ve GEO Kontrolü
Yapay zeka destekli taslak; yayından önce baştan sona okunur ve iddialar birincil kaynaklara karşı kontrol edilir. İçerik üretim sürecimiz

Teslim toplantısında ekrana açılan site her zaman kusursuz görünür: menü açılıyor, görseller yerinde, iletişim formu gönderiliyor. Ama arama motorlarının ve yapay zeka tarayıcılarının siteyi nasıl gördüğü o ekranda görünmez. Bu yazı, siteyi bir ajansa ya da serbest çalışan bir geliştiriciye yaptırmış ve teslim almak üzere olan işletme sahibi için hazırlandı. On bir kontrolün her biri bir tarayıcı, bir terminal satırı ya da ücretsiz bir doğrulayıcıyla, teknik bilgi gerektirmeden yapılabilir; sonunda da test geçmediğinde teslimi nasıl şartlı kabul edeceğinizi anlatıyoruz.
Satın almadan önce ajansa sorulacak soruları KOBİ sitesi altyapı rehberi bir araya getiriyor. Oradaki sorular söz almak içindi; buradaki kontroller o sözün tutulup tutulmadığını teslim gününde ölçmek için.
Teslim toplantısında "site yayında" cümlesi neyi kanıtlamaz?
"Site yayında" yalnızca bir insanın tarayıcıda sayfayı açabildiğini söyler. Aynı anda şu durumların hepsi mümkündür: sayfa metni tarayıcıda JavaScript çalıştıktan sonra oluşuyor ve kaynak dosyada yok; test sunucusundan kalan bir etiket arama motorlarına "bu sayfayı dizine ekleme" diyor; güvenlik katmanı yapay zeka tarayıcısını kapıda çeviriyor; olmayan bir adres "bulunamadı" yazdığı hâlde başarılı yanıt dönüyor.
Bu hataların hiçbiri ekranda uyarı çıkarmaz. Etkileri haftalar sonra "Google'da çıkmıyoruz" şikâyeti olarak döner; o noktada proje kapanmış, son ödeme yapılmış olur. Kabul testi hataları, ajans hâlâ projenin içindeyken bulmak içindir. Sonucu bir görüş değil, tekrar edilebilen bir ölçümdür: iki taraf aynı komutu çalıştırıp aynı çıktıyı görür.
Teste başlamadan önce hazırlanacak üç şey
Örnek adres listesi. Beş adres yeterli: ana sayfa, en önemli hizmet sayfanız, bir blog yazısı, iletişim sayfası ve sitede var olmayan uydurma bir adres.
Canlı alan adı. Siteler sık sık önce test.siteniz.com gibi bir alt adreste kurulur. Testi canlı alan adında yapın; test adresinde geçen bir kontrol canlıda geçmeyebilir.
Bir terminal. Windows 10 ve sonrasında curl hazır gelir; Komut İstemi'ni ("cmd") açmanız yeterli. PowerShell'de curl başka bir komutu çalıştırdığı için orada curl.exe yazın. Mac'te Terminal uygulaması kullanılır. Her sonucu tarih ve saatle not edin; bu notlar kabul tutanağının ham maddesi olacak.
Kontrol 1 ve 2: JavaScript kapalıyken sayfa ve kaynaktaki metin
İlk iki kontrol aynı soruyu iki yoldan sorar: sayfanın metni, tarayıcı hiçbir kod çalıştırmadan önce sunucudan gelen dosyada var mı?
Kontrol 1, JavaScript'i kapatmak. Chrome'da adres çubuğuna chrome://settings/content/javascript yazın ve "Sitelerin JavaScript kullanmasına izin verme" seçeneğini işaretleyin. Ardından adreslerinizi açın. Başlıklar, paragraflar ve iletişim bilgileri görünüyorsa kontrol geçer; ekran bembeyaz kalıyorsa ya da yalnızca bir yükleme simgesi dönüyorsa geçmez. Testten sonra ayarı geri açın.
Kontrol 2, kaynağı görüntülemek. Sayfada sağ tıklayıp "Sayfa kaynağını görüntüle" deyin (ya da Ctrl+U). Açılan metinde Ctrl+F ile hizmet sayfanızdaki özgün bir cümleyi arayın. Cümle bulunuyorsa geçer; kaynakta yalnızca kısa bir kabuk ve uzun betik dosyası adları varsa geçmez.
Google sayfaları sonradan işleyip JavaScript'i çalıştırabiliyor (JavaScript SEO temelleri bunu, kaynaklar elverdiğinde başsız bir Chromium'un sayfayı işlemesi olarak anlatıyor); yapay zeka tarayıcılarının aynı şeyi yaptığına güvenmek için ise elimizde bir dayanak yok. Bu kontrol geçmezse sonraki dokuz kontrolün iyi sonucu pek bir şey ifade etmez.
Kontrol 3: Siteye bir yapay zeka botunun kimliğiyle istek atmak
Kaynakta metnin bulunması, her ziyaretçiye o metnin gönderildiği anlamına gelmez; güvenlik duvarları ve CDN bot korumaları bazı tarayıcıları kimliklerine bakarak geri çevirir. Aynı adrese önce sıradan bir tarayıcı, sonra bir bot kimliğiyle istek atıp iki yanıtı karşılaştırın:
curl.exe -s -o NUL -w "%{http_code} %{size_download}\n" -A "Mozilla/5.0 Chrome/120.0" https://siteniz.com/hizmetler/ornek
curl.exe -s -o NUL -w "%{http_code} %{size_download}\n" -A "GPTBot/1.2" https://siteniz.com/hizmetler/ornek
Mac'te curl.exe yerine curl, NUL yerine /dev/null yazın. Her satır iki sayı döndürür: durum kodu ve indirilen bayt. İkisinde de 200 ve birbirine yakın boyut görüyorsanız kontrol geçer. Bot satırında 403, 429 ya da 200 ile birlikte çok küçük bir boyut görüyorsanız bota gerçek sayfa değil bir engel ekranı gidiyor demektir.
Terminal kullanmak istemiyorsanız aynı karşılaştırmayı tarayıcıdan yapan bir AI bot erişim testi aracı var. Erişim kayıtlarında gerçek botun nasıl ayırt edileceğini ve hosting sağlayıcısına ne yazılacağını AI botlarının erişim doğrulaması üzerine yazdığımız rehberde anlattık.
Kontrol 4 ve 5: Tek h1 ve her sayfanın kendi canonical adresi
Kontrol 4, başlık sayısı. Her sayfada sayfanın ana konusunu söyleyen tek bir h1 etiketi olmalı. Tasarımda büyük görünen her yazı h1 değildir. Kaynak görünümünde Ctrl+F ile <h1 arayın; tarayıcı eşleşme sayısını gösterir. Ekrandaki son hâl için F12 ile geliştirici araçlarını açıp Console sekmesine document.querySelectorAll('h1').length yazın. İki sayı da 1 ise geçer.
Kontrol 5, canonical etiketi. Canonical, "bu içeriğin asıl adresi budur" bilgisidir. Kaynakta canonical kelimesini arayın ve yanındaki adresi okuyun. Doğru sonuç: adres sayfanın kendi canlı adresi, https ile ve alan adınızla. Terminalden de bakabilirsiniz:
curl.exe -s https://siteniz.com/hizmetler/ornek | findstr /i "canonical"
Mac'te findstr /i yerine grep -i yazılır. Üç hatalı sonuca dikkat edin: her sayfada ana sayfayı gösteren canonical, test sunucusunu gösteren canonical ve hiç canonical olmaması. İlk ikisi engelleyici hatadır, üçüncüsü düzeltilecek bir eksik.
Test ortamından kalanlar: noindex, robots.txt ve açık bırakılmış test adresi
Geliştirme sırasında siteyi arama motorlarından gizlemek doğru bir uygulamadır; sorun, yayına geçerken bu gizlemenin unutulmasıdır.
Kontrol 6, noindex. Kaynakta noindex kelimesini arayın; hiç bulunmamalı. Aynı talimat sunucu yanıtının başlığında da gelebilir:
curl.exe -sI https://siteniz.com/ | findstr /i "x-robots-tag"
Çıktı boşsa sorun yok. İçinde noindex geçen bir satır dönüyorsa site arama motorlarına kendini dizine eklememesini söylüyor.
Kontrol 7, robots.txt. Tarayıcıda siteniz.com/robots.txt adresini açın. User-agent: * satırının altında tek başına Disallow: / varsa bütün site taramaya kapalıdır. Yapay zeka tarayıcılarının adlarının (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot gibi) altında Disallow görüyorsanız, bunun bilinçli bir karar olup olmadığını ajansa sorun.
Test adresinin kendisi de bir kalıntıdır. test.siteniz.com parolasız açık kalırsa aynı içerik iki adreste yayında olur; teslimde bu adresin kapatılmasını ya da parolayla korunmasını isteyin. Canlı sitenin bağlantılarının ve görsel yollarının test adresini göstermediğini, kaynakta test alan adını arayarak doğrulayın.
Kontrol 8: Olmayan bir adres gerçekten 404 döndürüyor mu?
Olmayan bir adreste ekranda "sayfa bulunamadı" yazması yetmez; sunucunun 404 durum kodu göndermesi gerekir. Mesaj "yok" derken kod "başarılı" diyorsa buna yumuşak 404 denir. Uydurma adresinizle ölçün:
curl.exe -s -o NUL -w "%{http_code}\n" https://siteniz.com/boyle-bir-sayfa-yok-12345
Çıktı 404 (ya da kalıcı kaldırma için 410) ise geçer; 200 ise geçmez. Denemeyi /hizmetler/boyle-bir-hizmet-yok gibi bir alt klasör adresiyle tekrarlayın; bazı kurulumlar kökte doğru, alt klasörde yanlış yanıt verir.
Bu hatayı kendi sitemizde de yaşadık. 19 Eylül 2026'ya kadar /hizmetler/olmayan-sayfa gibi adresler bizde de 200 dönüyordu; sebep, karşılığı olmayan her isteği ana sayfa dosyasına gönderen bir yönlendirme kuralıydı. Kuralı kaldırıp gerçek bir hata sayfası ürettik; o gün barındırma ortamının yerel kopyasında denediğimiz sekiz geçersiz adresin sekizi 404 döndü. Artık yayın öncesinde çalışan bir kontrol betiği, site haritasındaki bir adresin dosyası eksikse ya da hata sayfası üretilmemişse yayını durduruyor.
Kontrol 9 ve 10: Site haritası ve yapılandırılmış veri doğrulaması
Kontrol 9, sitemap. siteniz.com/sitemap.xml adresini açın. Adres sayısı proje planındaki sayfa sayısına yakın mı, hepsi canlı alan adıyla mı başlıyor? Birkaç adresi rastgele seçip kontrol 8'deki komutla ölçün; site haritasındaki her adres 200 dönmeli. Site yeni bir adres yapısına taşındıysa eski adreslerin yönlendirilmesi ayrı bir iştir; bu eşlemeyi yenilemede 301 haritası yazısında anlattık.
Kontrol 10, şema. Yapılandırılmış veri, işletmenizin adını, adresini ve hizmetlerini makinenin okuyacağı biçimde bildirir. Hizmet sayfanızın adresini validator.schema.org doğrulayıcısına ve Google'ın Zengin Sonuç Testi'ne girin; hata çıkmamalı. Ardından şemadaki telefon, adres ve hizmet adlarının sayfada görünen bilgilerle aynı olup olmadığını okuyun. Sayfada görünmeyen ya da eski bilgiyi bildiren şema düzeltilmelidir. Şema sıralama garantisi vermez; yaptığı iş belirsizliği azaltmaktır.
Kontrol 11: Mobil görünüm ve hız, teslimde hangi değer yazılır
Tek bir skoru kabul ölçütü saymayın. PageSpeed Insights'ta "Mobil" sekmesine bakın. Yeni bir sitede "gerçek kullanıcı deneyimi" bölümü genellikle boş gelir, çünkü yeterli ziyaretçi verisi birikmemiştir; teslim anındaki tek veri, her çalıştırmada biraz oynayan laboratuvar ölçümüdür. Testi üç kez çalıştırıp ortadaki değeri not edin. En anlamlı iki metrik LCP (ana içeriğin ekrana gelme süresi) ve CLS'tir (yüklenirken içeriğin kayması); Google'ın Core Web Vitals eşikleri LCP için 2,5 saniye ve altını "iyi" sayıyor. Hedef ancak brief'te yazıldıysa bağlayıcıdır.
Siteyi gerçek bir telefonda da açın: sayfa yana kaymamalı, düğmelere rahat basılabilmeli, telefon numarasına dokununca arama başlamalı ve form mobil klavyeyle doldurulabilmeli.
Test geçmezse teslimi şartlı kabul etmek
Kontrollerin hepsinin ilk seferde geçmesi beklenmez. Önemli olan, geçmeyenin ne olacağının yazılı hâle gelmesidir. Bulguları üç sınıfa ayırın.
| Sınıf | Örnek bulgular | Teslim kararı |
|---|---|---|
| Engelleyici | JavaScript kapalıyken boş sayfa, noindex kalıntısı, Disallow: /, bota 403, test adresini gösteren canonical, yumuşak 404 | Kabul edilmez; düzeltme ve yeniden test sonrası kabul |
| Düzeltilecek | Birden fazla ya da hiç h1, canonical eksikliği, şema hatası, site haritasında açılmayan adres | Şartlı kabul; düzeltme için yazılı bir süre ve yeniden test tarihi |
| Sonraki iş | Brief'te hedef yazılmamış hız değeri, sonradan istenen yeni şema türü | Kabul; ayrı bir iş kalemi olarak kayda geçer |
Şartlı kabulü işler kılan iki şey var. Birincisi, her bulgunun kanıtıyla yazılması: hangi adres, hangi komut, dönen çıktı, beklenen sonuç. "Site yavaş" bir bulgu değildir; "hizmet sayfasında mobil LCP üç ölçümün ortancasında şu değer, brief'teki hedef şu" bir bulgudur. İkincisi, yeniden test tarihinin baştan konması; düzeltme bitince aynı komutlar aynı adreslerde çalıştırılır.
Ödeme aşamalara bölündüyse son dilimi yeniden testin geçmesine bağlamak iki taraf için de açık bir kuraldır. Sözleşmede kabul testi tanımlanmadıysa bulgu listesini yine de yazılı gönderin; engelleyici hataların çoğu bir etiketin ya da satırın kaldırılmasıyla kapanan küçük işlerdir. Bir sonraki projede ölçütleri baştan yazmak için web sitesi brief'i üzerine hazırladığımız şablonu kullanabilirsiniz.
Kabul tutanağında hangi satırlar bulunmalı?
Tutanak uzun bir belge olmak zorunda değil. Aşağıdaki tablo her kontrole tek satır ayırıyor; kendi ölçümünüz için sağına bir "Sonuç" sütunu ekleyin.
| No | Kontrol | Nasıl ölçülür | Beklenen |
|---|---|---|---|
| 1 | JavaScript kapalı görünüm | Tarayıcıda JavaScript kapatılıp sayfa açılır | Metin ve iletişim bilgisi görünüyor |
| 2 | Kaynakta metin | Ctrl+U, özgün bir cümle aranır | Cümle bulunuyor |
| 3 | Bot kimliğiyle istek | İki curl satırı karşılaştırılır | İkisi de 200, boyut yakın |
| 4 | Tek h1 | Kaynakta ve konsolda h1 sayısı | Her sayfada 1 |
| 5 | Canonical | Kaynakta canonical aranır | Sayfanın kendi canlı adresi |
| 6 | noindex | Kaynakta ve yanıt başlığında aranır | Bulunmuyor |
| 7 | robots.txt | /robots.txt açılır | Genel Disallow: / yok |
| 8 | Gerçek 404 | Uydurma adrese curl | 404 ya da 410 |
| 9 | Site haritası | /sitemap.xml açılır, örnek adresler ölçülür | Canlı alan adı, hepsi 200 |
| 10 | Yapılandırılmış veri | İki doğrulayıcı ve sayfayla karşılaştırma | Hata yok, bilgiler sayfayla aynı |
| 11 | Mobil ve hız | PageSpeed mobil, üç ölçüm; gerçek telefon | Brief'teki hedef ya da not edilen değer |
Tutanağın altına üç şey eklenir: testi kimin, hangi tarihte yaptığı; engelleyici ve düzeltilecek bulguların listesi; yeniden test tarihi. Yayından sonra neyin hangi sırayla izleneceğini yayından sonraki ilk 30 gün planında ayrıca ele aldık; kabul testi o planın ilk gününe devredilen bir başlangıç çizgisidir.
Kendi kurulumlarımızda sayfaların tarayıcıya dolu HTML olarak gelmesini ve teslimde site haritası, robots dosyası ve analitik kurulumunun tamamlanmış olmasını iş kalemi olarak tanımlıyoruz; kapsamın tamamı kurumsal web sitesi kurulumu sayfasında. Başka bir ekibin teslim ettiği sitede bir çıktıyı yorumlayamadıysanız ücretsiz iş analizi bir ön görüşmedir: işletmenizi ve ölçtüğünüz sonuçları konuşur, sonraki adımı birlikte belirleriz. Görüşme talebi için iletişim bilgilerimiz hazır. Sıralama ya da trafik garantisi vermiyoruz; verdiğimiz şey, her kontrolün nasıl ölçüldüğünün açık olması.
Sıkça Sorulan Sorular
Yaptırdığım sitenin SEO uyumlu olup olmadığını teknik bilgi olmadan nasıl anlarım?
Dört kontrol çoğu sorunu ortaya çıkarır ve hiçbiri teknik bilgi gerektirmez. Tarayıcıda JavaScript'i kapatıp sayfanın metninin görünüp görünmediğine bakın, sayfa kaynağında hizmet açıklamanızdan bir cümle arayın, kaynakta noindex kelimesinin geçmediğini doğrulayın ve robots.txt dosyasında tüm siteyi kapatan bir Disallow satırı olmadığını kontrol edin. Bu dördü geçiyorsa site en azından arama motorlarına ve yapay zeka tarayıcılarına kapalı değildir; ayrıntılı değerlendirme için canonical, 404 kodu ve şema kontrolleri de eklenir.
Web sitesi JavaScript kapalıyken boş görünüyorsa ne anlama gelir?
Sayfanın metni sunucudan gelen dosyada bulunmuyor, ancak tarayıcı JavaScript kodunu çalıştırdıktan sonra oluşuyor demektir. Google bu tür sayfaları sonradan işleyebiliyor, ancak yapay zeka tarayıcılarının aynı işlemi yaptığına güvenmek için bir dayanak yok; bu tarayıcılar sayfayı boş bir kabuk olarak görebilir. Çözüm, sayfaların sunucu tarafında ya da yayın öncesinde hazır HTML olarak üretilmesidir ve bu, teslimden önce ajanstan istenmesi gereken bir altyapı düzeltmesidir.
Canonical etiketi yanlışsa site nasıl etkilenir?
Canonical etiketi arama motoruna bir sayfanın asıl adresini bildirir. Bütün iç sayfalar ana sayfayı asıl adres olarak gösteriyorsa arama motoru bu sayfaları ana sayfanın kopyası sayabilir ve ayrı ayrı göstermeyebilir. Etiket test sunucusunun adresini gösteriyorsa sinyal yanlış alan adına gider. Bu yüzden her sayfanın canonical etiketinin kendi canlı adresini, https ile ve doğru alan adıyla göstermesi teslimde doğrulanmalıdır.
Kabul testinde hata çıkarsa ödemeyi durdurabilir miyim?
Bu, sözleşmenizde yazanlara bağlıdır ve hukuki bir değerlendirme yerine geçecek genel bir cevap verilemez. Uygulamada en açık yol, sözleşmede kabul testini ve ödeme aşamalarını baştan tanımlamak ve son ödeme dilimini yeniden testin geçmesine bağlamaktır. Böyle bir madde yoksa bulguları kanıtlarıyla birlikte yazılı olarak iletmek ve düzeltme için bir tarih üzerinde anlaşmak, tartışmayı ölçülebilir bir zemine taşır.
Kabul testini kaç kez yapmak gerekir?
En az iki kez yapılır: ilk teslimde ve düzeltmeler bittikten sonra aynı adreslerde, aynı komutlarla. Sonuçlar karşılaştırılabilsin diye her ölçüm tarih ve saatle kaydedilir. Yayından sonra da tekrar etmekte fayda var, çünkü eklenti güncellemeleri, hosting değişiklikleri ya da güvenlik ayarları daha önce geçen bir kontrolü bozabilir; bot erişimi ve noindex kontrolünü ayda bir tekrarlamak bu tür sessiz geri dönüşleri erken yakalar.