Python ile web scraping yapmak birkaç satır HTTP isteği ve HTML seçicisiyle başlayabilir. Fakat güvenilir bir veri toplama sistemi; yalnız sayfayı indiren koddan değil, izin, kapsam, hız, hata yönetimi, veri kalitesi, güvenlik ve bakım kararlarından oluşur. Plansız bir bot hedef siteye gereksiz yük bindirebilir, kullanım şartlarını ihlal edebilir, kişisel verileri ölçüsüz toplayabilir veya ilk HTML değişikliğinde sessizce yanlış veri üretebilir.
Bu rehber, Python ile web scraping nasıl yapılır? sorusunu etik ve teknik sınırlarla ele alır. Amaç erişim kontrolünü aşmak değil; kamuya açık veya açıkça izin verilmiş veriyi, site sahibinin kurallarına ve makul trafik sınırlarına uyarak tekrarlanabilir biçimde toplamaktır.
Önce veriyi bir API, açık veri seti veya dışa aktarma özelliğiyle alıp alamayacağınızı kontrol edin. Scraping gerekiyorsa veri sahibinden izin alın, kullanım şartlarını ve robots.txt politikasını inceleyin. Yalnız ihtiyaç duyduğunuz URL ve alanları toplayın; düşük istek hızı, açık User-Agent, timeout, sınırlı retry ve önbellek kullanın. Ham yanıtı, ayrıştırılmış veriyi ve hata metriklerini ayrı tutun.
Crawling, bağlantıları izleyerek URL keşfetmeye odaklanır. Scraping, belirli sayfalardan yapılandırılmış alanlar çıkarmayı hedefler. Bot ise zamanlanmış kontrol, bildirim, entegrasyon veya form dışı otomasyon gibi daha geniş bir davranış sınıfıdır. Aynı yazılım bu görevlerin birkaçını yapabilir; yine de kapsamı adlandırmak riskleri görünür kılar.
Bir fiyat izleme projesi yalnız izinli ürün sayfalarındaki ad ve fiyat alanını okuyabilir. Arama motoru benzeri crawler ise milyonlarca URL keşfedebilir. İkinci sistemin trafik, robots.txt, tekrar ziyaret ve kaldırma talepleri açısından çok daha ağır sorumlulukları vardır.
Kod yazmadan önce şu soruları yanıtlayın:
Kamuya açık görünmek sınırsız kullanım izni anlamına gelmez. Telif, veri tabanı hakkı, sözleşme, gizlilik ve sektörel kurallar ülkeye ve kullanım biçimine göre değişebilir. Ticari veya yüksek riskli projede hukuk danışmanlığı alın.
Robots Exclusion Protocol, hizmet sahibinin crawler’ların hangi URI’lere erişmesini istediğini bildiren standart bir yöntemdir. RFC 9309, user-agent ve allow/disallow kurallarının yorumlanmasını, hata durumlarını ve önbellek davranışını tanımlar.
robots.txt dosyasına saygı duymak iyi bot davranışının temelidir; fakat bu dosya kimlik doğrulama veya hukuki lisans değildir. Bir yol robots.txt içinde yasaklanmamış olsa bile kullanım şartları, erişim yetkisi ve kişisel veri kuralları geçerliliğini korur. Yasaklanan alanı başka user-agent, IP veya tarayıcı otomasyonuyla aşmaya çalışmayın.
Python standart kütüphanesindeki robotparser benzeri araçlarla hedef URL’nin tanımlı user-agent için izinli olup olmadığını istek kuyruğuna girmeden önce kontrol edebilirsiniz. Politika sonucunu kısa süre önbelleğe alın; fakat site sahibinin güncellemesini makul aralıklarla yeniden okuyun.
Resmî API; alan adları, veri türleri, sayfalama, kimlik doğrulama, kota ve hata yanıtları için açık bir sözleşme sunar. HTML ise kullanıcı arayüzüdür ve haber verilmeden değişebilir. Aynı verinin API ile alınması genellikle daha düşük trafik, daha az ayrıştırma hatası ve daha açık kullanım hakkı sağlar.
API yoksa site sahibine veri dışa aktarma, ortaklık akışı veya periyodik dosya talep etmek uzun vadede daha ucuz olabilir. Sitemap ve RSS, sayfa keşfi ya da güncelleme takibi için tüm siteyi tekrar taramaktan daha verimlidir.
User-Agent alanında botun anlaşılır adı, sürümü ve site sahibinin ulaşabileceği bir iletişim sayfası veya e-posta bulunmalıdır. Genel tarayıcı gibi görünmeye çalışmak şeffaflığı azaltır. İletişim kanalında botun amacı, yaklaşık istek hızı ve durdurma talebinin nasıl iletileceği açıklanabilir.
Oturum açma gerekiyorsa yalnız açıkça yetkilendirilmiş hesap kullanın. Parola, çerez veya token değerlerini koda yazmayın; güvenli sır yönetimi kullanın. Başkasının oturumunu, ele geçirilmiş çerezi veya paylaşılması yasak kimlik bilgisini kullanmayın.
Hız sınırı, yalnız 429 yanıtı gelince düşünülmemelidir. Başlangıçta düşük eşzamanlılık ve istekler arasında gecikme kullanın. Aynı kaynağı tekrar indirmemek için önbellek, ETag ve Last-Modified başlıklarından yararlanın. Yoğun saatlerden kaçınma imkânı varsa site sahibiyle zaman penceresi belirleyin.
Sunucu 429 Too Many Requests veya 503 Service Unavailable döndürdüğünde saldırgan biçimde tekrar denemeyin. Retry-After başlığını uygulayın, üstel backoff ve rastgele jitter kullanın, maksimum deneme sayısı koyun. Hata oranı yükselirse devre kesiciyle işi durdurun.
Yüzlerce paralel istek teknik olarak mümkün olabilir; bu, izinli veya doğru olduğu anlamına gelmez. İş hacmini site sahibinin kapasitesine, anlaşmaya ve güncelleme sıklığına göre sınırlayın. Bir sayfa günde bir değişiyorsa dakikada kontrol etmek gereksizdir.
Python Requests kütüphanesinde varsayılan olarak açık bir timeout bulunmadığı için üretim kodu timeout değerini kendisi belirlemelidir. Resmî Requests gelişmiş kullanım belgesi, timeout verilmezse isteğin süresiz bekleyebileceğini belirtir.
Connect ve read timeout’u ayrı düşünün. DNS hatası, bağlantı reddi, timeout, HTTP hata kodu ve ayrıştırma hatasını aynı genel mesaj altında ezmeyin. Requests’in hata ve istisna rehberi, ConnectionError, Timeout, TooManyRedirects ve HTTPError ayrımını açıklar.
Yalnız güvenli ve idempotent işlemleri sınırlı biçimde tekrar deneyin. Sürekli hata veren URL’yi kuyruğun sonuna atmak yerine nedenini kaydedip gerektiğinde karantinaya alın.
HTML’i düzenli ifadeyle genel amaçlı ayrıştırmak kırılgandır. Beautiful Soup veya lxml gibi ayrıştırıcılar bozuk ve değişken işaretlemeyi daha kontrollü işler. Beautiful Soup belgeleri, seçilen parser’ın sonuçları etkileyebileceğini ve parser’ın açıkça belirtilmesinin yeniden üretilebilirliği artırdığını gösterir.
Seçici yazarken yalnız görsel konuma veya değişken CSS sınıfına bağlı kalmayın. data-* öznitelikleri, semantik yapı ve schema.org işaretlemesi daha kararlı olabilir. Yine de her alan için varlık, veri türü ve makul değer aralığı doğrulaması yapın.
Sayfa tasarımı değiştiğinde seçici None dönebilir. Bunu boş metin olarak kaydetmek, tüm veri setini sessizce bozabilir. Kritik alan eksikliğini hata sayın; örnek sayfayı karantinaya alın ve alarm üretin.
Önce sayfanın kullandığı resmî ve izinli bir API olup olmadığını kontrol edin. İçerik HTML içinde yoksa başsız tarayıcı kullanmak mümkündür; fakat kaynak, CPU ve bellek maliyeti HTTP istemcisinden çok daha yüksektir. Her sayfayı tarayıcıyla açmak yerine yalnız gerekli kapsamda kullanın.
CAPTCHA, giriş duvarı veya bot engeli gördüğünüzde bunu aşma problemi olarak ele almayın. İşlemi durdurun, site sahibinden API ya da erişim izni isteyin. Tarayıcı parmak izi gizleme, proxy rotasyonu ve insan davranışını taklit etme sürdürülebilir veri mühendisliği değildir.
Bir crawler bağlantıları izliyorsa aynı origin sınırı, izinli yol deseni ve maksimum derinlik belirleyin. Her URL’yi normalize edip tekrarları önleyin; fragment’leri kaldırın ve sonsuz takvim/sayfalama döngülerine karşı sınır koyun. Logout, delete, cart veya yönetim gibi durum değiştiren URL’leri kesinlikle kuyruğa almayın.
Dışarıdan gelen bir URL’yi sunucu tarafında doğrudan çağıran bot hizmetlerinde SSRF riski vardır. OWASP’ın SSRF Önleme Rehberi, hedef protokol ve alan adları için allowlist yaklaşımını önerir. Localhost, özel IP aralıkları, bulut metadata uç noktaları ve beklenmeyen yönlendirmeler engellenmelidir.
Toplanabiliyor olması, tutulması gerektiği anlamına gelmez. Projenin amacı için zorunlu olmayan ad, e-posta, profil, konum veya davranış bilgisini almayın. Kişisel veri gerekiyorsa hukuki dayanak, aydınlatma, erişim yetkisi, saklama süresi ve silme sürecini baştan belirleyin.
Ham HTML, ayrıştırılmış veri ve loglar farklı risk taşır. Ham sayfa gerekmiyorsa uzun süre saklamayın. Loglarda tam URL içindeki token’ları, çerezleri ve kişisel parametreleri maskeleyin. Yedeklerin de aynı saklama ve silme politikasına tabi olduğunu unutmayın.
Scraping sisteminin başarı metriği yalnız HTTP 200 sayısı değildir. Aşağıdaki ölçümleri izleyin:
Kaynak HTML’den ayrıştırılmış kayda kadar provenance tutun: kaynak URL, alınma zamanı, parser sürümü ve veri şeması sürümü. Böylece hatalı seçici fark edildiğinde hangi kayıtların yeniden işlenmesi gerektiği bulunabilir.
İzinli ve kişisel veri içermeyen küçük HTML örneklerini test fixture’ı olarak saklayın. Normal sayfa, eksik alan, boş sonuç, değişmiş sınıf ve hata sayfası örnekleriyle parser testleri yazın. Canlı siteye her testte istek göndermek hem yavaş hem de hedefe gereksiz yüktür.
Canlı smoke test az sayıda URL ile ve düşük sıklıkta çalışabilir. Şema alarmı geldiğinde tüm filoyu çalıştırmak yerine önce örnekleri inceleyin.
Bir iş yarıda kesildiğinde baştan başlamak yerine checkpoint kullanın. Her kayda kararlı bir kaynak kimliği verin ve upsert stratejisi belirleyin. Aynı URL’nin iki kez işlenmesi kopya kayıt veya iki kez bildirim üretmemelidir.
Planlayıcı; başlangıç zamanı, maksimum çalışma süresi, eşzamanlı iş sayısı ve kapanış davranışını yönetmelidir. İş durdurulduğunda açık bağlantıları kapatın, kuyruğu güvenli biçimde kaydedin ve yarım kayıtları tamamlanmış işaretlemeyin.
Her botta hızlı bir kill switch bulunmalıdır. Hata oranı, 429 yanıtı, alan eksikliği veya trafik bütçesi eşiği aşılırsa sistem otomatik durabilmelidir. Uyarılar yalnız “job failed” dememeli; hedef, hata sınıfı, ilk görülme zamanı ve etkilenen kayıt sayısını vermelidir.
Gösterge panelinde site başına istek oranı, gecikme, başarı, veri tazeliği ve parser sürümü izlenebilir. Site sahibinden durdurma talebi geldiğinde tüm zamanlanmış işler ve kuyruklar birlikte devre dışı bırakılmalıdır.
Hayır. robots.txt otomatik istemciler için erişim tercihidir; lisans, sözleşme veya kişisel veri izni değildir. Kullanım şartlarını ve geçerli hukuki yükümlülükleri ayrıca değerlendirin.
Statik HTML ve izinli API için Requests daha hafif ve öngörülebilirdir. Yalnız izinli içerik gerçekten JavaScript çalıştırmayı gerektiriyorsa tarayıcı otomasyonu düşünün. CAPTCHA veya erişim kontrolünü aşmak için kullanmayın.
Evrensel bir sayı yoktur. Site sahibinin politikası, anlaşması, sunucu kapasitesi ve verinin değişim sıklığı belirleyicidir. Düşük hızla başlayın, 429 ve gecikmeyi izleyin, gereksiz yeniden istekleri önbellekle azaltın.
Yalnız mutlu yolu test etmek. Timeout koymamak, sınırsız retry, boş alanı başarı saymak, HTML değişikliğini izlememek ve verinin kullanım hakkını baştan doğrulamamak en pahalı sorunlardandır.
Sürdürülebilir scraping; en fazla sayfayı en kısa sürede indirmek değildir. Doğru kaynaktan, açık kapsamla, en az trafik ve en az veriyle güvenilir sonuç üretmektir. İzin + robots.txt uyumu + şeffaf kimlik + hız sınırı + timeout + veri doğrulama + gizlilik + durdurma mekanizması bir araya geldiğinde bot hem hedef siteye hem veri kullanan ekibe daha az risk taşır.
İzinli scraping projenizde kullandığınız veri kaynağını, Python sürümünü, yaklaşık URL sayısını ve aldığınız hata sınıfını bu kategoride paylaşabilirsiniz. Oturum çerezi, token, kişisel veri veya hedef sitenin erişim kontrolünü aşmaya yönelik ayrıntı eklemeyin.
Bu rehber, Python ile web scraping nasıl yapılır? sorusunu etik ve teknik sınırlarla ele alır. Amaç erişim kontrolünü aşmak değil; kamuya açık veya açıkça izin verilmiş veriyi, site sahibinin kurallarına ve makul trafik sınırlarına uyarak tekrarlanabilir biçimde toplamaktır.
Kısa cevap: Güvenli web scraping akışı nedir?
Önce veriyi bir API, açık veri seti veya dışa aktarma özelliğiyle alıp alamayacağınızı kontrol edin. Scraping gerekiyorsa veri sahibinden izin alın, kullanım şartlarını ve robots.txt politikasını inceleyin. Yalnız ihtiyaç duyduğunuz URL ve alanları toplayın; düşük istek hızı, açık User-Agent, timeout, sınırlı retry ve önbellek kullanın. Ham yanıtı, ayrıştırılmış veriyi ve hata metriklerini ayrı tutun.
- Amaç, veri alanı ve saklama süresini yazılı tanımlayın.
- API, RSS, sitemap veya açık veri kaynağını önceleyin.
- İzin, lisans, kullanım şartları ve robots.txt dosyasını kontrol edin.
- Tek alan adı ve küçük URL örneğiyle pilot çalışma yapın.
- Timeout, hız sınırı, backoff ve maksimum retry belirleyin.
- Seçicileri gerçek örneklerle test edin ve boş veriyi hata sayın.
- Kişisel veriyi azaltın; sırları ve oturum bilgilerini kaydetmeyin.
- Kaynak değişince durabilen izleme ve kalite alarmı kurun.
Web scraping, crawling ve bot arasındaki fark nedir?
Crawling, bağlantıları izleyerek URL keşfetmeye odaklanır. Scraping, belirli sayfalardan yapılandırılmış alanlar çıkarmayı hedefler. Bot ise zamanlanmış kontrol, bildirim, entegrasyon veya form dışı otomasyon gibi daha geniş bir davranış sınıfıdır. Aynı yazılım bu görevlerin birkaçını yapabilir; yine de kapsamı adlandırmak riskleri görünür kılar.
Bir fiyat izleme projesi yalnız izinli ürün sayfalarındaki ad ve fiyat alanını okuyabilir. Arama motoru benzeri crawler ise milyonlarca URL keşfedebilir. İkinci sistemin trafik, robots.txt, tekrar ziyaret ve kaldırma talepleri açısından çok daha ağır sorumlulukları vardır.
Scraping yapmadan önce hangi sorular sorulmalı?
Kod yazmadan önce şu soruları yanıtlayın:
- Verinin sahibi ve yayıncısı kim?
- Bu kullanım için açık izin veya lisans var mı?
- Kullanım şartları otomatik erişim hakkında ne söylüyor?
- Aynı veri resmî API, RSS veya indirilebilir dosyada bulunuyor mu?
- Hangi alanlar gerçekten gerekli?
- Kişisel veri veya hassas bilgi işlenecek mi?
- Veri ne kadar süre tutulacak ve kim erişecek?
- Site sahibi iletişim kurmak isterse bot nasıl tanımlanacak?
Kamuya açık görünmek sınırsız kullanım izni anlamına gelmez. Telif, veri tabanı hakkı, sözleşme, gizlilik ve sektörel kurallar ülkeye ve kullanım biçimine göre değişebilir. Ticari veya yüksek riskli projede hukuk danışmanlığı alın.
robots.txt neyi belirler?
Robots Exclusion Protocol, hizmet sahibinin crawler’ların hangi URI’lere erişmesini istediğini bildiren standart bir yöntemdir. RFC 9309, user-agent ve allow/disallow kurallarının yorumlanmasını, hata durumlarını ve önbellek davranışını tanımlar.
robots.txt dosyasına saygı duymak iyi bot davranışının temelidir; fakat bu dosya kimlik doğrulama veya hukuki lisans değildir. Bir yol robots.txt içinde yasaklanmamış olsa bile kullanım şartları, erişim yetkisi ve kişisel veri kuralları geçerliliğini korur. Yasaklanan alanı başka user-agent, IP veya tarayıcı otomasyonuyla aşmaya çalışmayın.
robots.txt kontrolünü otomatikleştirin
Python standart kütüphanesindeki robotparser benzeri araçlarla hedef URL’nin tanımlı user-agent için izinli olup olmadığını istek kuyruğuna girmeden önce kontrol edebilirsiniz. Politika sonucunu kısa süre önbelleğe alın; fakat site sahibinin güncellemesini makul aralıklarla yeniden okuyun.
API neden scraping’den önce düşünülmeli?
Resmî API; alan adları, veri türleri, sayfalama, kimlik doğrulama, kota ve hata yanıtları için açık bir sözleşme sunar. HTML ise kullanıcı arayüzüdür ve haber verilmeden değişebilir. Aynı verinin API ile alınması genellikle daha düşük trafik, daha az ayrıştırma hatası ve daha açık kullanım hakkı sağlar.
API yoksa site sahibine veri dışa aktarma, ortaklık akışı veya periyodik dosya talep etmek uzun vadede daha ucuz olabilir. Sitemap ve RSS, sayfa keşfi ya da güncelleme takibi için tüm siteyi tekrar taramaktan daha verimlidir.
Bot kendini nasıl tanıtmalı?
User-Agent alanında botun anlaşılır adı, sürümü ve site sahibinin ulaşabileceği bir iletişim sayfası veya e-posta bulunmalıdır. Genel tarayıcı gibi görünmeye çalışmak şeffaflığı azaltır. İletişim kanalında botun amacı, yaklaşık istek hızı ve durdurma talebinin nasıl iletileceği açıklanabilir.
Oturum açma gerekiyorsa yalnız açıkça yetkilendirilmiş hesap kullanın. Parola, çerez veya token değerlerini koda yazmayın; güvenli sır yönetimi kullanın. Başkasının oturumunu, ele geçirilmiş çerezi veya paylaşılması yasak kimlik bilgisini kullanmayın.
İstek hızı ve sunucu yükü nasıl yönetilir?
Hız sınırı, yalnız 429 yanıtı gelince düşünülmemelidir. Başlangıçta düşük eşzamanlılık ve istekler arasında gecikme kullanın. Aynı kaynağı tekrar indirmemek için önbellek, ETag ve Last-Modified başlıklarından yararlanın. Yoğun saatlerden kaçınma imkânı varsa site sahibiyle zaman penceresi belirleyin.
Sunucu 429 Too Many Requests veya 503 Service Unavailable döndürdüğünde saldırgan biçimde tekrar denemeyin. Retry-After başlığını uygulayın, üstel backoff ve rastgele jitter kullanın, maksimum deneme sayısı koyun. Hata oranı yükselirse devre kesiciyle işi durdurun.
Eşzamanlılık hedef değil araçtır
Yüzlerce paralel istek teknik olarak mümkün olabilir; bu, izinli veya doğru olduğu anlamına gelmez. İş hacmini site sahibinin kapasitesine, anlaşmaya ve güncelleme sıklığına göre sınırlayın. Bir sayfa günde bir değişiyorsa dakikada kontrol etmek gereksizdir.
Timeout ve hata yönetimi nasıl kurulmalı?
Python Requests kütüphanesinde varsayılan olarak açık bir timeout bulunmadığı için üretim kodu timeout değerini kendisi belirlemelidir. Resmî Requests gelişmiş kullanım belgesi, timeout verilmezse isteğin süresiz bekleyebileceğini belirtir.
import requests
response = requests.get(
url,
headers={"User-Agent": "OrnekArastirmaBotu/1.0 (+iletisim-url)"},
timeout=(5, 20),
)
response.raise_for_status()
Connect ve read timeout’u ayrı düşünün. DNS hatası, bağlantı reddi, timeout, HTTP hata kodu ve ayrıştırma hatasını aynı genel mesaj altında ezmeyin. Requests’in hata ve istisna rehberi, ConnectionError, Timeout, TooManyRedirects ve HTTPError ayrımını açıklar.
Yalnız güvenli ve idempotent işlemleri sınırlı biçimde tekrar deneyin. Sürekli hata veren URL’yi kuyruğun sonuna atmak yerine nedenini kaydedip gerektiğinde karantinaya alın.
HTML ayrıştırma nasıl güvenilir yapılır?
HTML’i düzenli ifadeyle genel amaçlı ayrıştırmak kırılgandır. Beautiful Soup veya lxml gibi ayrıştırıcılar bozuk ve değişken işaretlemeyi daha kontrollü işler. Beautiful Soup belgeleri, seçilen parser’ın sonuçları etkileyebileceğini ve parser’ın açıkça belirtilmesinin yeniden üretilebilirliği artırdığını gösterir.
from bs4 import BeautifulSoup
soup = BeautifulSoup(response.text, "html.parser")
title = soup.select_one("main h1")
if title is None:
raise ValueError("Beklenen başlık bulunamadı")
value = title.get_text(" ", strip=True)
Seçici yazarken yalnız görsel konuma veya değişken CSS sınıfına bağlı kalmayın. data-* öznitelikleri, semantik yapı ve schema.org işaretlemesi daha kararlı olabilir. Yine de her alan için varlık, veri türü ve makul değer aralığı doğrulaması yapın.
Boş değer sessiz başarı değildir
Sayfa tasarımı değiştiğinde seçici None dönebilir. Bunu boş metin olarak kaydetmek, tüm veri setini sessizce bozabilir. Kritik alan eksikliğini hata sayın; örnek sayfayı karantinaya alın ve alarm üretin.
JavaScript ile oluşan içerik nasıl ele alınmalı?
Önce sayfanın kullandığı resmî ve izinli bir API olup olmadığını kontrol edin. İçerik HTML içinde yoksa başsız tarayıcı kullanmak mümkündür; fakat kaynak, CPU ve bellek maliyeti HTTP istemcisinden çok daha yüksektir. Her sayfayı tarayıcıyla açmak yerine yalnız gerekli kapsamda kullanın.
CAPTCHA, giriş duvarı veya bot engeli gördüğünüzde bunu aşma problemi olarak ele almayın. İşlemi durdurun, site sahibinden API ya da erişim izni isteyin. Tarayıcı parmak izi gizleme, proxy rotasyonu ve insan davranışını taklit etme sürdürülebilir veri mühendisliği değildir.
URL kuyruğu ve kapsam nasıl korunur?
Bir crawler bağlantıları izliyorsa aynı origin sınırı, izinli yol deseni ve maksimum derinlik belirleyin. Her URL’yi normalize edip tekrarları önleyin; fragment’leri kaldırın ve sonsuz takvim/sayfalama döngülerine karşı sınır koyun. Logout, delete, cart veya yönetim gibi durum değiştiren URL’leri kesinlikle kuyruğa almayın.
Dışarıdan gelen bir URL’yi sunucu tarafında doğrudan çağıran bot hizmetlerinde SSRF riski vardır. OWASP’ın SSRF Önleme Rehberi, hedef protokol ve alan adları için allowlist yaklaşımını önerir. Localhost, özel IP aralıkları, bulut metadata uç noktaları ve beklenmeyen yönlendirmeler engellenmelidir.
Veri minimizasyonu ve gizlilik
Toplanabiliyor olması, tutulması gerektiği anlamına gelmez. Projenin amacı için zorunlu olmayan ad, e-posta, profil, konum veya davranış bilgisini almayın. Kişisel veri gerekiyorsa hukuki dayanak, aydınlatma, erişim yetkisi, saklama süresi ve silme sürecini baştan belirleyin.
Ham HTML, ayrıştırılmış veri ve loglar farklı risk taşır. Ham sayfa gerekmiyorsa uzun süre saklamayın. Loglarda tam URL içindeki token’ları, çerezleri ve kişisel parametreleri maskeleyin. Yedeklerin de aynı saklama ve silme politikasına tabi olduğunu unutmayın.
Veri kalitesi nasıl ölçülür?
Scraping sisteminin başarı metriği yalnız HTTP 200 sayısı değildir. Aşağıdaki ölçümleri izleyin:
- İstenen ve başarılı URL sayısı.
- HTTP durum kodu ve hata sınıfı dağılımı.
- Kritik alan doluluk oranı.
- Tekrarlı kayıt oranı.
- Değer aralığı ve veri tipi ihlalleri.
- Şema değişikliği nedeniyle karantinaya alınan sayfa sayısı.
- Kaynak başına son başarılı güncelleme zamanı.
- Ortalama istek hızı ve 429 oranı.
Kaynak HTML’den ayrıştırılmış kayda kadar provenance tutun: kaynak URL, alınma zamanı, parser sürümü ve veri şeması sürümü. Böylece hatalı seçici fark edildiğinde hangi kayıtların yeniden işlenmesi gerektiği bulunabilir.
Değişen sayfa yapısına karşı test stratejisi
İzinli ve kişisel veri içermeyen küçük HTML örneklerini test fixture’ı olarak saklayın. Normal sayfa, eksik alan, boş sonuç, değişmiş sınıf ve hata sayfası örnekleriyle parser testleri yazın. Canlı siteye her testte istek göndermek hem yavaş hem de hedefe gereksiz yüktür.
def test_product_parser(sample_html):
item = parse_product(sample_html)
assert item.name
assert item.price >= 0
assert item.currency in {"TRY", "USD", "EUR"}
Canlı smoke test az sayıda URL ile ve düşük sıklıkta çalışabilir. Şema alarmı geldiğinde tüm filoyu çalıştırmak yerine önce örnekleri inceleyin.
Zamanlama, tekrar çalıştırma ve idempotency
Bir iş yarıda kesildiğinde baştan başlamak yerine checkpoint kullanın. Her kayda kararlı bir kaynak kimliği verin ve upsert stratejisi belirleyin. Aynı URL’nin iki kez işlenmesi kopya kayıt veya iki kez bildirim üretmemelidir.
Planlayıcı; başlangıç zamanı, maksimum çalışma süresi, eşzamanlı iş sayısı ve kapanış davranışını yönetmelidir. İş durdurulduğunda açık bağlantıları kapatın, kuyruğu güvenli biçimde kaydedin ve yarım kayıtları tamamlanmış işaretlemeyin.
Üretim gözlemlenebilirliği ve durdurma mekanizması
Her botta hızlı bir kill switch bulunmalıdır. Hata oranı, 429 yanıtı, alan eksikliği veya trafik bütçesi eşiği aşılırsa sistem otomatik durabilmelidir. Uyarılar yalnız “job failed” dememeli; hedef, hata sınıfı, ilk görülme zamanı ve etkilenen kayıt sayısını vermelidir.
Gösterge panelinde site başına istek oranı, gecikme, başarı, veri tazeliği ve parser sürümü izlenebilir. Site sahibinden durdurma talebi geldiğinde tüm zamanlanmış işler ve kuyruklar birlikte devre dışı bırakılmalıdır.
Yayın öncesi etik ve teknik kontrol listesi
- Veri kaynağı ve kullanım amacı belgeli mi?
- API veya açık veri alternatifi kontrol edildi mi?
- İzin, lisans, şartlar ve robots.txt incelendi mi?
- User-Agent botu ve iletişim kanalını açıkça tanımlıyor mu?
- Hız, eşzamanlılık ve tekrar deneme sınırı var mı?
- Timeout ve durum kodu yönetimi test edildi mi?
- Kritik alan eksikliği sessizce geçilmiyor mu?
- Kişisel veri en aza indirildi mi?
- SSRF ve yönlendirme sınırları uygulandı mı?
- Checkpoint, idempotency ve kill switch var mı?
Sık sorulan sorular
robots.txt izin veriyorsa her veri toplanabilir mi?
Hayır. robots.txt otomatik istemciler için erişim tercihidir; lisans, sözleşme veya kişisel veri izni değildir. Kullanım şartlarını ve geçerli hukuki yükümlülükleri ayrıca değerlendirin.
Scraping için Requests mi tarayıcı mı kullanılmalı?
Statik HTML ve izinli API için Requests daha hafif ve öngörülebilirdir. Yalnız izinli içerik gerçekten JavaScript çalıştırmayı gerektiriyorsa tarayıcı otomasyonu düşünün. CAPTCHA veya erişim kontrolünü aşmak için kullanmayın.
Bot ne kadar hızlı çalışmalı?
Evrensel bir sayı yoktur. Site sahibinin politikası, anlaşması, sunucu kapasitesi ve verinin değişim sıklığı belirleyicidir. Düşük hızla başlayın, 429 ve gecikmeyi izleyin, gereksiz yeniden istekleri önbellekle azaltın.
Web scraping projesinde en sık hata nedir?
Yalnız mutlu yolu test etmek. Timeout koymamak, sınırsız retry, boş alanı başarı saymak, HTML değişikliğini izlememek ve verinin kullanım hakkını baştan doğrulamamak en pahalı sorunlardandır.
Sonuç: İyi bot daha çok değil, doğru veri toplar
Sürdürülebilir scraping; en fazla sayfayı en kısa sürede indirmek değildir. Doğru kaynaktan, açık kapsamla, en az trafik ve en az veriyle güvenilir sonuç üretmektir. İzin + robots.txt uyumu + şeffaf kimlik + hız sınırı + timeout + veri doğrulama + gizlilik + durdurma mekanizması bir araya geldiğinde bot hem hedef siteye hem veri kullanan ekibe daha az risk taşır.
İzinli scraping projenizde kullandığınız veri kaynağını, Python sürümünü, yaklaşık URL sayısını ve aldığınız hata sınıfını bu kategoride paylaşabilirsiniz. Oturum çerezi, token, kişisel veri veya hedef sitenin erişim kontrolünü aşmaya yönelik ayrıntı eklemeyin.