reCAPTCHA çerezleri: hangileri ayarlanır ve çözümü nasıl etkiler?

Aynı sitede reCAPTCHA'nın kimine tek tıkla geçilen bir onay kutusu, kimine üst üste görsel bulmacalar çıkarmasının başlıca nedeni tarayıcıdaki çerezlerdir. Google, riski ölçerken tarayıcının Google çerezlerine ve localStorage geçmişine bakar: köklü bir profil "normal kullanıcı" sinyali verir, tertemiz bir profil ise şüphe uyandırır. Bu yazı, reCAPTCHA'nın hangi çerezleri okuyup yazdığını, bunların doğrulama zorluğunu nasıl belirlediğini ve otomasyon oturumlarınızda çözüm oranını korumak için neleri saklamanız gerektiğini ortaya koyar.

Aynı reCAPTCHA neden bazen kolay bazen zor?

Google, çerezleri risk değerlendirmesindeki tek sinyal olarak değil ama ağırlığı yüksek bir sinyal olarak kullanır. Tarayıcının çerez durumu ile karşılaşacağınız zorluk arasındaki ilişki genellikle şöyle işler:

Pratikte bu üç uca iniyor. Oturum açılmış bir Google hesabından gelen SID, HSID ve NID çerezleri varsa doğrulama çoğunlukla tek onay kutusu tıklamasıyla geçer. Normal taramadan biriken NID ve 1P_JAR çerezleri varsa daha kolay görsel doğrulamalar ya da doğrudan onay kutusu görürsünüz. Hiç Google çerezi olmayan tertemiz bir oturumda ise çok turlu görsel bulmacalar beklemelisiniz.

reCAPTCHA hangi çerezleri okur ve yazar?

Çerez tarafını üç gruba ayırmak, hangisini saklamanın gerçekten işe yaradığını görmeyi kolaylaştırır: Google alan adı çerezleri, reCAPTCHA'nın kendi oturum durumu ve doğrulamayı barındıran sitenin çerezleri.

Google alan adı çerezleri

Bunlar .google.com üzerinde ayarlanır ve reCAPTCHA iframe'i tarafından okunur. Risk skorunuza en çok bunlar etki eder:

reCAPTCHA'nın kendi oturum durumu

reCAPTCHA kendi oturum verisini hem bir çerezde hem de localStorage'da tutar. rc:: ön ekli anahtarlar, üçüncü taraf çerezleri engellense bile durumun korunmasını sağlar:

Hedef sitenin çerezleri

reCAPTCHA'yı barındıran site de oturum ve CSRF takibi için çerez kullanabilir. Bunlar zorluğu doğrudan belirlemez ama form gönderiminin çalışması için gereklidir:

• Oturum kimliği (PHPSESSID, session_id) — CAPTCHA çözümünü kullanıcı oturumuna bağlar.
• CSRF token'ı (csrf_token, _token) — form gönderimi için gereklidir.
• Siteye özel izleme çerezleri — CAPTCHA'nın ne zaman tetiklendiğini etkileyebilir.

Tarayıcı ve API tarafında çerezleri saklamak

Çerezleri nasıl sakladığınız, tarayıcı mı kullandığınıza yoksa doğrudan API ile mi çözüm aldığınıza göre değişir.

Tarayıcı otomasyonunda (Playwright/Puppeteer)

Tarayıcı otomasyonu çerezleri doğal olarak yönetir. Oturumlar arasında korumak için kaydedip geri yüklemeniz yeterli:

# Save cookies after session
cookies = page.context.cookies()
import json
with open("cookies.json", "w") as f:
    json.dump(cookies, f)

# Restore cookies in next session
with open("cookies.json") as f:
    cookies = json.load(f)
page.context.add_cookies(cookies)

CaptchaAI ile (yalnızca API çözümü)

CaptchaAI'yi tarayıcı olmadan kullandığınızda çerezler çözümü doğrudan etkilemez — CaptchaAI kendi çözüm ortamını yönetir. Yine de hedef site oturum sürekliliği için çerez bekliyorsa, çerez bağlamını istekle birlikte iletebilirsiniz:

POST https://ocr.captchaai.com/in.php

key=YOUR_API_KEY
&method=userrecaptcha
&googlekey=SITE_KEY
&pageurl=https://staging.example.com/qa-login
&cookies=NID=12345;1P_JAR=2026-04-04-12

cookies parametresi isteğe bağlıdır ve çerez bağlamını çözüm için CaptchaAI'ye gönderir.

Yerel senaryo: staging ödeme akışı testi

Bir e-ticaret ekibindeki otomasyon geliştiricisini düşünün: her CI koşusunda sıfırdan bir Europe/Istanbul profiliyle açtığı staging ödeme akışında reCAPTCHA sürekli zor bulmacalar çıkarıyor, testler kararsızlaşıyordu. Çözüm, profili her koşuda sıfırlamak yerine sabit bir tarayıcı profilini saklamak oldu; Google çerezleri ve rc:: girişleri birikince doğrulama çoğunlukla onay kutusuna düştü. API tarafında ise hedef sitenin PHPSESSID çerezi korunarak oturum uyuşmazlığı önlendi. Not: bu veriler gerçek kullanıcı verisi içeriyorsa KVKK kapsamına girer; testleri yalnızca yetkili staging ortamlarında yürütün.

localStorage neden ayrı bir katman?

reCAPTCHA, risk değerlendirme verisini localStorage'da rc:: ön ekli anahtarlarda saklar:

• rc::a — kodlanmış risk analizi yükü
• rc::b — son doğrulamanın zaman damgası
• rc::c — mevcut doğrulama oturumu verisi
• rc::d-<hash> — widget başına örnek verisi

Bu girişler, üçüncü taraf çerezlere ihtiyaç duymadan sayfa yüklemeleri arasında durumu korur. Otomasyonda localStorage'ı saklamak, doğrulama zorluğunu belirgin biçimde azaltabilir:

# Save localStorage
storage = page.evaluate("() => JSON.stringify(localStorage)")
with open("localstorage.json", "w") as f:
    f.write(storage)

# Restore localStorage
with open("localstorage.json") as f:
    storage = f.read()
page.evaluate(f"Object.entries(JSON.parse('{storage}')).forEach(([k,v]) => localStorage.setItem(k,v))")

Alan adları arası çerez kısıtlamaları

reCAPTCHA, google.com üzerinden bir iframe içine yüklenir. Modern tarayıcıların katı çerez politikaları bu iframe'i doğrudan etkiler:

• SameSite=Lax (varsayılan): Google çerezleri varsayılan olarak reCAPTCHA iframe'ine gönderilmez.
• Üçüncü taraf çerez engelleme: reCAPTCHA recaptcha.net'e veya birinci taraf moduna geçer.
• ITP (Safari): Google çerezlerinin süresi daha hızlı dolar, zor doğrulamalar sıklaşır.

Google bu kısıtlamaları birkaç yolla telafi eder: alternatif alan adı olarak recaptcha.net kullanmak, istemci tarafı durumu için localStorage'daki rc::* girişlerine yaslanmak ve kurumsal müşterilere birinci taraf komut dosyası yükleme seçeneği sunmak.

Çözüm oranını koruyan pratikler

Çözüm oranını yüksek tutmak için otomasyon akışınızda şu alışkanlıkları oturtun:

• Kalıcı tarayıcı profilleri kullanın: çalıştırmalar arasında tarama geçmişi birikir, doğrulamalar kolaylaşır.
• Görevler arasında çerezleri silmeyin: Google'ın risk değerlendirmesinin sürekliliğini korur.
• google.com engelliyse recaptcha.net'i kullanın: aynı hizmet, farklı alan adı.
• localStorage'daki rc:: girişlerini saklayın: reCAPTCHA oturum durumunu korur.
• Ara sıra Google hizmetlerini ziyaret edin: çerez geçerliliğini tazeler.

Sorun giderme

Sık sorulan sorular

reCAPTCHA neden bazen tek onay kutusu, bazen üst üste görsel çıkarıyor?

Fark büyük ölçüde çerez ve localStorage geçmişindedir. Köklü Google çerezleri olan bir profil düşük riskli sayılır ve çoğunlukla onay kutusuyla geçer; geçmişi olmayan yeni profil ise yüksek riskli görülür ve çok turlu görsel doğrulama alır.

API ile çözerken isteğe cookies parametresini eklemek zorunda mıyım?

Hayır. cookies parametresi isteğe bağlıdır. CaptchaAI, reCAPTCHA'yı kendi altyapısıyla bağımsız olarak çözer; çerezi yalnızca hedef site oturum sürekliliği için gerekiyorsa iletmeniz yeterlidir.

SameSite=Lax politikası reCAPTCHA'yı bozar mı?

Bozmaz. SameSite=Lax yüzünden Google çerezleri iframe'e gönderilmese bile reCAPTCHA recaptcha.net veya birinci taraf moduyla ve localStorage durumuyla çalışmaya devam eder; yalnızca risk sinyali zayıflar.

Çerezleri ve localStorage'ı ne sıklıkla yenilemeliyim?

Google'ın NID çerezi yaklaşık 6 ay, 1P_JAR ise yaklaşık 1 ay geçerlidir. Profili düzenli kullanmak çerezleri ve rc:: girişlerini taze tutar; uzun süre kullanılmayan profillerde zorluğun arttığını görebilirsiniz.

İlgili makaleler

• reCAPTCHA v2 callback sorununu API ile çözme
• Aynı sayfada reCAPTCHA v2 ve Turnstile'ı birlikte yönetme
• reCAPTCHA v2 callback mekanizması

Sonraki adımlar

reCAPTCHA çözüm oranlarınızı yükseltin — CaptchaAI API anahtarınızı alın ve otomasyon iş akışlarınızda çerezleri doğru yönetin.