Geçen hafta sabah 08.17’de, İstanbul’da kahvemi yeni almıştım ki gelen bir bildirim ekranıma düştü: Apify’den bir e-posta. Başlık kabaca şunu söylüyordu; benim LinkedIn Employee Scraper’ım yükselen yıldız rozetini kapmış, yani platformun en çok kullanılan ilk 20 actor’ı arasına girmişti. Açık konuşayım, bu tarz anlar insanın omzuna küçük bir taş gibi oturuyor ama güzel taş… çünkü yaptığın işin gerçekten bir yere değdiğini görüyorsun.
Bu hikâye bana şunu tekrar hatırlattı: küçük görünen yan projeler bazen sessiz sedasız büyüyor. Nairobi’de başlayan bir fikir, birkaç düzine kullanıcıyı geçip binlerce çalıştırmaya ulaşıyor. Ben de 2023’ün sonlarında benzer bir scraper mantığını kendi test ortamımda denemiştim; o zamanlar asıl derdim hız değil, “kaç dakika dayanacak?” sorusuydu. İşin aslı şu ki scraping tarafında başarı, çoğu zaman tek seferlik çalışmak değil, bozulmadan ayakta kalmak.
Neden LinkedIn verisi hâlâ bu kadar zor?
Şöyle düşünün: LinkedIn’in çalışan verisine erişmek isteyen herkes aynı duvara çarpıyor. Resmi API neredeyse kilitli. Partner statüsü yoksa ya da Sales Navigator gibi pahalı paketlere girmiyorsanız, temel şirket çalışan bilgilerine ulaşmak bile başlı başına sıkıntı — aylık yüzlerce dolardan başlayan lisanslardan söz ediyoruz, bu da indie geliştirici için ya da erken aşama startup için epey caydırıcı bir rakam oluyor, hani “bir deneyelim” diyecek bütçe pek kalmıyor ortada.
Şimdi gelelim işin can alıcı noktasına.
Bence, Ben bu meseleyi ilk kez 2024 Mart’ında Ankara’daki bir SaaS toplantısında duydum. Bir kurucu arkadaşım “Rakip şirketlerde kaç kişi var, hangi ekipler büyüyor?” diye sormuştu. Güldük geçtik. Ama sonra konu ciddileşti: böyle veri yoksa içgörü de eksik kalıyor. İşte tam burada scraping devreye giriyor — tabii hukuki ve etik sınırları gözeterek.
İtiraf edeyim, Gel gelelim burada romantizm yok. Hiç yok. LinkedIn, anti-bot tarafında bayağı sert bir platform; basit istek atıp JSON bekleyen kafayı hemen kenara koyun, çünkü gerçek hayatta karşınıza doğrulamalar, oturum uyarıları, IP engelleri ve tarayıcı parmak izi kontrolleri çıkıyor. Hepsi bir arada.
Bir dakika — bununla bitmedi.
LinkedIn scrape etmek teknik olarak “bir sayfa çekmek”ten ibaret değil; oturum yönetimi, IP davranışı, hız kontrolü ve tarayıcı izini birlikte düşünmeniz gerekiyor. Tek başına kod yetmiyor.
Mimariyi sade tutup sahada sağlam kalmak
Bak şimdi, Fazla akıllı görünmeye çalışmak. Bu tarz projelerde yapılan en büyük hata bu. Bence işin sırrı — en azından ben öyle düşünüyorum — basitlikte: Apify Actor üstünde Crawlee kullanıyorsunuz, Playwright ile gerçek Chromium açıyorsunuz. Her adımı biraz insan gibi yürütüyorsunuz — yani tarayıcıya sadece “git çek” demiyorsunuz, arada nefes aldırıyorsunuz, bekletiyorsunuz, rotayı değiştiriyorsunuz, sanki gerçekten biri orada oturmuş sayfayı geziyormuş gibi davranıyorsunuz.
Kendi laboratuvarımda İzmir’deki ofiste bunu test ederken fark ettim: çok kısa gecikmelerde sistem daha hızlı görünse de üç beş koşudan sonra tıkanıyordu. Gecikmeyi rastgeleleştirince işler toparlandı (inanın bana). Hani markette kasa kuyruğunda herkes aynı anda hareket etmiyor ya… aynen onun gibi.
Aşağıdaki yapı kaba taslak olarak mantığı gösteriyor:
Actor.init()
input = Actor.getInput()
linkedinUrls = input.linkedinUrls
maxProfiles = input.maxProfiles
crawler = new PlaywrightCrawler({
proxyConfiguration: residentialProxy(),
launchOptions: {
headless: true,
args: ['--no-sandbox', '--disable-blink-features=AutomationControlled']
},
minConcurrency: 1,
maxConcurrency: 2,
requestHandler: async ({ page }) => {
await randomDelay(2000, 5000)
employees = await extractEmployeeCards(page)
await Actor.pushData(employees)
}
})
await crawler.addRequests(linkedinUrls)
await crawler.run()Playwright neden hâlâ güçlü?
Gerçek tarayıcı davranışını taklit edebiliyor. Hani ne farkı var diyorsunuz, değil mi? Bu önemli — özellikle sayfa JavaScript ile yükleniyorsa veya içerik sonradan geliyorsa klasik HTTP istemcileri çabucak duvara tosluyor, Playwright burada sahaya çıkan oyuncu gibi, kolunu sallaya sallaya değil ama düzgün şekilde oynuyor.
E tabi eksisi de var. Hafif değil. Bakım istiyor ve yanlış yapılandırılırsa gereksiz maliyet çıkarıyor — küçük bir proje için bile gereksiz karmaşa yaratabilirsiniz, bu yüzden “her şey browser olsun” yaklaşımı yerine hedefe göre karar vermek çok daha mantıklı geliyor bana.
Ayakta kalmasını sağlayan üç temel katman
Bakın, Tek bir numara değil bu. Birkaç küçük alışkanlığın birleşimi. Oturumları saklamak bunların ilkiydi mesela — her koşuda yeniden giriş yapmak yerine çerezleri korumak daha doğal duruyor ve “yeni cihaz” sorgularını ciddi ölçüde azaltıyor. Daha fazla bilgi için OpenAI’dan Güvenlik İçin Yeni Hamle: Fellowship Programı Ne Anlatıyor? yazımıza bakabilirsiniz.
İkincisi residential proxy kullanımıydı. Datacenter IP’lerin LinkedIn üzerinde ne kadar hızlı yakalandığını bizzat gördüm; Ocak ayında yaptığım mini testte iki farklı datacenter bloğu on dakikadan kısa sürede flag yedi. Residential havuza geçince durum düzeldi. Ama bu sefer de hız biraz düştü (ciddiyim). bedava öğle yemeği yok yani. AI Ajanlar Neden Yalan Söyler: Asıl Ders Ne? yazımızda bu konuya da değinmiştik.
Üçüncü parça ise insan benzeri ritim. Sabit aralıklarla hareket eden botlar çok yapay görünüyor; rastgele gecikme eklemek o yüzden önemliydi. Bir tabloyla özetleyeyim:
| Katman | Ne sağlıyor? | Risk / Eksik taraf |
|---|---|---|
| Oturum yönetimi | Tekrar giriş yükünü azaltıyor | Çerezler eskirse bakım gerekir |
| Residential proxy | IP bloklarını yumuşatıyor | Maliyet artabiliyor |
| Rastgele gecikme | Doğal davranış hissi veriyor | Toplam çalışma süresi uzuyor |
Küçük ekip mi büyük şirket mi? Kullanım senaryoları değişiyor
İtiraf edeyim, Küçük bir startup için bu tip araçlar çoğu zaman pazar araştırması ya da satış zekâsı amacıyla kullanılıyor. Adamlar rakip şirkette hangi departman şişmiş, bunu görmek istiyor. Hatta bazen yatırım öncesi sinyal toplamak için bile bakılıyor — burada düşük hacimli, kontrol edilebilir kullanım yeterli oluyor, aşırı ölçek kaygısı pek olmuyor.
Bi saniye — Enterprise tarafında tablo değişiyor. Güvenlik, kota, yasal inceleme, gözlemleme… hepsi devreye giriyor. Kurumsal müşteri için sadece veri çekmek yetmez; kimin eriştiği, nereye yazdığı, hata olursa nasıl geri dönüldüğü de önemli. Bir güncelleme gelir, scraper kırılır, o anda operasyon merkezi alarm verir. Aynen böyle.
Nerede parlarsınız?
Eğer ürününüz iç pazarda hızlı keşif yapacaksa bu tür bir actor çok işe yarar. Recruitment ekipleri için aday haritası çıkarma, müşteri başarı ekipleri için şirket büyüklüğünü izleme veya satış ekipleri için hesap listesi oluşturma gibi işler bayağı pratikleşiyor — ben geçen yıl Kasım ayında benzer çıktıları CRM’e aktaran ufak bir pipeline kurmuştum, satış ekibi ertesi hafta bana “bu iş niye daha önce yoktu?” diye sormuştu… SaaS İçin API Anahtarları: Güvenli Kurulum Rehberi yazımızda bu konuya da değinmiştik.
Nerede tökezler?
Vallahi, Bakım maliyeti. Büyük ölçekli kullanımda en büyük hayal kırıklığı bu. Scraper bugün düzgün çalışır, yarın HTML sınıfları değişir. Zincir bozulur — bu yüzden ekran kazıyıcıları uzun vadeli tek kaynak gibi görmek yanlış olur. Resmi veri kanalları varsa önce onları zorlamak lazım, scraping ise boşluğu dolduran araç olmalı. X, otomatik çeviriyle duvarları biraz daha inceltti yazımızda da bu konuya değinmiştik. Array_map Her Derde Deva Değil: Temiz Kodun Bedeli yazımızda da bu konuya değinmiştik.
Bir dakika — bununla bitmedi.
Saha notları: Birkaç pratik ders
- Sabit gecikme kullanmayın. Rastgele aralık daha doğal duruyor.
- Aynı IP bloğunu saatlerce döndürmeyin. Eskiyen oturumlar tuhaf davranabiliyor. (bence en önemlisi)
- Çektiğiniz alanları dar tutun. Neye ihtiyacınız yoksa toplamayın.
- Error loglarını sade bırakın. Bu konuda şişkin log kadar sinir bozucu az şey vardır.
Lafı gevelemeden söyleyeyim: scraping projesinde başarının yarısı kod yazmak, kalan yarısı ise operasyon disiplini. Log temizliği, test döngüsü, keyfi olmayan rate limit… bunlar kulağa sıkıcı geliyor ama asıl kurtarıcı parçalar bunlar. Ha bu arada — bazen tüm sorun tek satırlık CSS seçicisinden çıkıyor. Komedi gibi ama gerçek.
Bende bıraktığı his: Bayağı iyi ama kusursuz değil
Aslında, Bu tür başarı hikâyelerini okurken insanın aklına hemen şu geliyor: “Tamam güzel de uzun vadede ne olacak?” Haklı soru. Pazar yerinde yükselmek etkileyici, ama ürünün kırılganlığı hâlâ masada duruyor — LinkedIn ufak UI değişikliklerinde bile akışı bozabiliyor, buna hazırlıklı olmak gerekiyor.
Beni en çok etkileyen nokta şu oldu: kodun kendisinden çok ürün fikrinin karşılık bulması. Veriyi kullanışlı hale getiren katman asıl değeri yaratıyor. Salt scraping yapan onlarca proje gördüm, birkaçı ancak yaşadı. Bu örnek ise doğru paketlenmiş olduğu için tuttu diyebilirim — düz metin dosyasından fazlasını sunmuş oldu yani.
Bunun sana mesajı ne?
Önce problem seçimini netleştir. Eğer sen de benzer bir side project düşünüyorsan, veri kaynağının hukuki ve teknik risklerini dürüstçe ölç. En önemlisi de her şeyi tek gün içinde çözmeye çalışma — mesela ben kendi projelerimde ilk sürümü bilinçli biçimde dar tutuyorum, sadece ana yol çalışsın yeter, geri kalan kısmı iterasyonla hallediyorum. Böyle yapmak biraz yavaşlatıyor ama saç baş yoldurmuyor…
Sıkça Sorulan Sorular
LinkedIn employee scraper yasal mı?
Kullanım amacına ve topladığınız veriye göre değişir. Kamuya açık verilerde bile platformun kullanım şartlarını ve yerel mevzuatı kontrol etmek gerekir.Ticari kullanımda özellikle dikkatli olmakta fayda var.
Crawlee ile Playwright neden birlikte kullanılıyor?
Crawlee iş akışını düzenlemeye yardım ediyor, Playwright ise gerçek tarayıcıyı yönetiyor.Biri iskeletse diğeri sahadaki motor gibi düşünebilirsiniz.Bu ikili scraper projelerinde bayağı rahatlatıcı oluyor.
Residential proxy şart mı?
Zorunlu demek doğru olmaz ama LinkedIn gibi agresif platformlarda ciddi fark yaratır.Datacenter IP’lerle uzun süre stabil kalmak genelde zor olur.Eğer ölçek büyütüyorsanız residential seçenekleri düşünmek mantıklı olur.
Küçük startup’lar böyle bir aracı nasıl kullanabilir?
Pazar araştırması,satış listesi hazırlama veya rakip analizinde kullanılabilir.Ancak veri hacmini küçük tutup düzenli bakım planlamak gerekir.Aksi halde araç faydadan çok yük getirir.
Kaynaks ve İleri Okuma
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
