AI ajanları artık her yerde, tamam. Ama tarayıcı işine gelince çoğu modelin eli gerçekten kolu bağlanıyor. Hani metni okuyor, özet çıkarıyor, bazen kod bile yazıyor — fakat canlı bir siteye girip butona basması, form doldurması, oturum açması ya da dinamik içeriği kendi gözüyle doğrulaması gerektiğinde işler bir anda dağılıyor. İşte tam bu noktada Chrome CDP devreye giriyor ve açık konuşayım: bu yaklaşım baya iş görüyor (bizzat test ettim)
Geçen ay, 2026 Ocak başında İstanbul’daki küçük bir SaaS ekibi için benzer bir akışı incelerken bunu çok net gördüm. Ekibin kullandığı araç yalnızca statik istek atabiliyordu; React tabanlı panelde veriler hiç görünmüyor, login ekranı takılıyor, raporlar eksik kalıyordu. Dur bir saniye — aslında şunu söyleyeyim önce: sorun modelin “zekası” değildi. Sorun gerçek tarayıcıyla konuşamamasıydı. Sadece bu.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Survivor’ın anlattığı web-access fikri tam da bu boşluğu kapatıyor. AI ajanına yalnızca veri değil, etkileşim de veriyorsun — (inanın bana). Sayfayı açıyor, render bekliyor, tıklıyor, yazıyor, sekme değiştiriyor, kısacası insanın yaptığı şeyleri daha kontrollü biçimde yapabiliyor. Bu kulağa basit geliyor. Pratikte fark ise çok büyük.
Neden Klasik Scraping Yetmiyor?
Lafı gevelemeden söyleyeyim. fetch ya da axios gibi araçlar hâlâ lazım, evet, ama tek başlarına yetmiyorlar artık. Çünkü modern sitelerin önemli bir kısmı JavaScript ile çalışıyor. HTML kaynağında göremediğin içerikler sonradan yükleniyor; statik istek attığında eline çoğu zaman yarım yamalak, işe yaramaz bir sayfa düşüyor.
Bir de kullanıcı etkileşimi meselesi var. Login formu mu var? Captcha mı çıktı? Bir menü açılmadan veri mi görünmüyor? Bunların hepsi klasik scraping’i boğuyor (ciddiyim). Geçen yıl Eylül 2025’te Ankara’da bir e-ticaret projesinde aynı duvara tosladık; ürün listesi API’dan geliyordu ama filtreler tamamen front-end tarafındaydı ve normal scraper o filtreyi hiç anlayamıyordu. Hiç.
Burada mesele sadece “veri çekmek” değil aslında… veriyi doğrulamak da gerekiyor. Bazen sistem sana içerik dönduruyor gibi görünüyor ama ekranda bambaşka bir şey oluyor. Tarayıcı penceresini görmeden buna güvenmek — hmm, nasıl desem — pek akıllıca sayılmaz.
Statik Sayfa ile Dinamik Sayfa Arasındaki Fark
Açık konuşayım, Statik sayfa biraz gazete kupürü gibi. Ne varsa önünde duruyor, hepsi bu. Dinamik sayfa ise mutfakta pişen yemek gibi — ilk baktığında boş tencere görebilirsin, ama birkaç saniye bekleyince asıl içerik gelir. Aradaki fark basit ama sonuçları ciddi.
| Kriter | Klasik Scraping | CDP Tabanlı Otomasyon |
|---|---|---|
| JS-render edilen içerik | Zayıf | Güçlü |
| Tıklama / form doldurma | Sınırlı | Tam destekli |
| Hız | Daha hızlı olabilir | Daha ağır olabilir |
| Doğrulama kabiliyeti | Düşük | Yüksek |
| Karmaşıklık yönetimi | Daha basit görünür | Daha esnek ama uğraştırır |
Chrome CDP ile Web-Access Skill Mantığı Nasıl Çalışıyor?
Bunun kalbinde Chrome DevTools Protocol var. Adından korkmayın — aslında tarayıcıyla uzaktan konuşmanın resmi yolu gibi düşünün. AI ajanı burada doğrudan Chrome’un içine uzanıp sekme açabiliyor, DOM’u okuyabiliyor, click event tetikleyebiliyor ve sonucu kontrol edebiliyor. Gayet temiz bir yapı. Daha fazla bilgi için Bybit API Python Rehberi: Emirler ve Pozisyonlar yazımıza bakabilirsiniz.
Bana göre en güzel tarafı şu: aynı altyapıyla farklı iş akışlarını tekrar kullanabiliyorsun. Mesela haber araştırmasında arama sonuçlarını toplarken ayrı davranıyor, CRM panelinde form doldururken bambaşka bir şekilde çalışıyor. İkisi de aynı tarayıcı omurgasını kullanıyor. Şaşırdım açıkçası ilk gördüğümde. Browser’da Doktor Değil, Danışman: WebLLM ile Gizli Yapay Zekâ yazımızda bu konuya da değinmiştik.
// Basitleştirilmiş mantık
1) Uygun erişim yolunu seç:
— search = keşif
— fetch = statik içerik
— CDP = dinamik veya etkileşimli görev
2) Sekmeyi aç
3) Sayfanın yüklenmesini bekle
4) Tıkla / yaz / kaydır / doğrula
5) Sonucu kontrol et
6) Gerekirse aynı akışı yeniden kullan
Bu yapı aklıma 2024 Kasım’ında Berlin’deki bir danışmanlık projesini getirdi. Orada ekip her şeyi API üzerinden çözmeye çalışıyordu — ama dashboard’daki bazı kritik metrikler yalnızca kullanıcı arayüzünde oluşuyordu (evet, kötü tasarım, biliyorum). CDP ile işi çözdük; çünkü sistemin tam olarak ne gördüğünü görmek gerekiyordu. Başka çare yoktu.
Neden “skill” yaklaşımı önemli?
Size bir şey söyleyeyim, Çünkü tek seferlik script yerine tekrar kullanılabilir bir yetenek katmanı kuruyorsun. Bugün SEO araştırması için kullanırsın, yarın rapor toplarsın, ertesi gün login sonrası veri çekerken yine aynı yapıdan faydalanırsın. Bu kadar basit — ve bu kadar değerli.
Şimdi gelelim işin can alıcı noktasına.
Kurulumda Üç Temel Adım Var Ama İnce Noktalar Çok Önemli
Kılavuzdaki kurulum üç adım gibi görünüyor. Kağıt üzerinde haklılar: remote debugging’i açmak, skill’i kurmak ve bağımlılıkları kontrol etmek. Bitti sanıyorsun. Ama asıl olay orada başlıyor! Çünkü en ufak bir sürüm uyumsuzluğu bütün zinciri yerle bir edebiliyor. Ciddi söylüyorum. Gin ile Trafiği Sıraya Dizmek: Room Paketi Ne Sunuyor? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
1) Chrome Remote Debugging’i Açmak
Burası kritik. chrome://inspect/#remote-debugging ekranından ilgili izinleri açmadan bu iş yürümez — kapısı kilitli eve anahtarsız girmeye çalışmak gibi, olmuyor işte. Basit ama atlanınca her şey duraksıyor. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
2) Skill Paketini Kurmak
eze-is/web-access deposunu klonlamak ya da kendi ajan platformunun plugin sistemiyle eklemek mümkün olabiliyor. Burada güzel olan şu ki yerel tarayıcını kullanıyorsun. Oturum bilgilerini dışarı taşıma derdin ciddi ölçüde azalıyor. Küçük ama önemli bir fark.
3) Bağımlılık Kontrolü Yapmak!
Bence, Bunu atlayan çok kişi görüyorum. Sonra “neden çalışmadı?” diye saatlerce oyalanıyorlar… Node.js sürümü düşükse zaten geçmiş olsun noktasına geliyor; özellikle 22+ şartına dikkat etmek şart. Şart.
Tarayıcı otomasyonu yaparken en büyük hata “bir kere çalıştıysa tamamdır” demek oluyor. Hayır; oturum süresi biter, UI değişir, selector kırılır… sistem canlıysa bakım ister.
Peki Pratikte Nerelerde İşe Yarıyor?
Bi saniye — Neyse, gelelim gerçek kullanım senaryolarına — burası en eğlenceli bölüm bence. Çok kaynaklı araştırma yaparken paralel sekmeler gerçekten hayat kurtarıyor; biri haberi okurken diğeri karşılaştırma yapabiliyor, ikisi aynı anda ilerliyor. Bir startup için bu — kendi adıma konuşayım — durum ciddi maliyet avantajı yaratıyor çünkü manuel operasyona ayrılan süre azalıyor. Kurumsal tarafta ise olay ölçekten vuruyor.
Bir ekip düşünün. Her gün yüzlerce form, binlerce kayıt ve sürekli değişen web arayüzleri (ki bu çoğu kişinin gözünden kaçıyor)
- Müşteri portalından veri toplama ve doğrulama — ciddi fark yaratıyor
- SPA uygulamalarda sonsuz scroll içeriği okuma
- Password gerektiren iç akışlarda yerel oturumla çalışma — ciddi fark yaratıyor
- Süreç bazlı form doldurma ve gönderme
Zayıf Yanları Da Var mı? Tabii Ki Var!
Evet, var. Hatta bazen can sıkıcı seviyelere çıkabiliyor (inanın bana). CDP tabanlı yaklaşım klasik scraping yöntemine göre daha ağır çalışabiliyor — bilgisayar kaynağı tüketiyor, kurulumda ufak bir hata tüm sistemi çökertiyor, üstelik güvenlik tarafını hafife alırsan başın gerçekten ağrıyor. Biraz ham diyebilirim. Pişmesi lazım. Ama potansiyeli yüksek, bunu söyleyebilirim rahatlıkla.
Bir diğer mesele de debug portu konusu. Bunu yanlış yere açarsan ciddi risk doğuyor — o yüzden yerel makinede tutmak şart; üretim ortamında rastgele açık bırakılmaz, bırakılmamalı zaten. Bu konuda esneklik yok.
Küçük ekiplerde bu yöntem hemen değer üretiyor çünkü esneklik sağlıyor. Enterprise seviyede ise izleme, loglama, yetkilendirme ve sandbox katmanları olmadan ilerlemek giderek zorlaşıyor. Açık konuşayım: kağıt üzerinde kolay görünen şey sahada insanı bir güzel terletiyor.
Sıkça Sorulan Sorular
<
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.



