Web scraper - Jak skutecznie pobierać dane i unikać błędów?

Dobrze zaprojektowany web scraper potrafi zamienić ręczne przeklejanie danych w powtarzalny proces, ale tylko wtedy, gdy od początku rozumiesz strukturę strony, rodzaj ładowania treści i granice, których nie warto przekraczać. Najwięcej problemów nie robi sam kod, lecz złe założenia: że HTML zawsze jest stały, że każda strona działa tak samo i że po jednej udanej próbie wszystko już „będzie działać”. W tym tekście rozkładam temat na praktyczne decyzje, od HTML i selektorów po wybór narzędzia, ograniczenia techniczne i typowe błędy.

Czym taki scraper naprawdę jest i kiedy ma sens

Najprościej ujmując, scraper to program, który wyciąga konkretne dane ze stron WWW, zamiast tylko je wyświetlać. To ważne rozróżnienie, bo łatwo pomylić go z crawlerem: crawler szerzej przechodzi po linkach i mapuje witrynę, a scraper skupia się na polach, które chcesz zapisać, porównać albo przetworzyć dalej.

Ja zwykle zaczynam od jednego pytania: czy potrzebuję całej struktury serwisu, czy tylko kilku kolumn danych? Jeśli chodzi o ceny produktów, artykuły, ogłoszenia, katalogi firm albo archiwa wiadomości, taki mechanizm ma sens. Jeśli jednak serwis daje sensowne API, RSS albo eksport danych, to właśnie od tego zaczynam, bo jest stabilniej i taniej w utrzymaniu.

• Scraper zbiera dane z wybranych elementów strony.
• Crawler przechodzi po linkach i odkrywa kolejne podstrony.
• API daje dane w gotowej strukturze, bez zgadywania układu HTML.

W praktyce dobry projekt często łączy te role, ale jeśli od początku myślisz o jednym zadaniu, łatwiej dobrać właściwe narzędzie i nie przepłacić za złożoność. A skoro o strukturze mowa, warto zobaczyć, jak strona wygląda od środka, bo tam zaczyna się prawdziwa robota.

Jak czytać HTML zamiast patrzeć tylko na wygląd strony

HTML opisuje strukturę treści, a nie sam wygląd. To oznacza, że w scraperze nie szukam „ładnego układu”, tylko konkretnych znaczników, atrybutów i powtarzalnych wzorców. Przeglądarka po wczytaniu strony buduje też DOM, czyli drzewo obiektów reprezentujące dokument po renderowaniu. To właśnie na DOM-ie albo na surowym HTML-u najczęściej pracuje parser.

Na czym opieram selekcje

Najstabilniejsze są elementy, które mają stałe znaczniki lub sensowne atrybuty, na przykład data-id, data-product czy wyraźnie opisane sekcje. Dużo mniej lubię klasy generowane automatycznie przez frontend, bo potrafią zmienić się po drobnym deployu i psują cały proces.

W praktyce używam trzech podejść:

• Selektory CSS - dobre, gdy układ strony jest prosty i powtarzalny.
• XPath - przydatny, gdy trzeba dojść do danych przez strukturę drzewa albo pobrać tekst z bardziej zagnieżdżonych elementów.
• Atrybuty semantyczne - najlepsze, jeśli strona udostępnia stabilne znaczniki do identyfikacji treści.

Przeczytaj również: Znaczniki HTML - Jak poprawnie budować strukturę i unikać błędów?

Kiedy HTML źródłowy nie wystarcza

Jeśli widzę, że treść pojawia się dopiero po uruchomieniu JavaScriptu, sam HTTP i parser HTML mogą nie wystarczyć. Wtedy potrzebuję renderowania w przeglądarce albo innego sposobu odtworzenia tego, co widzi użytkownik. To kosztuje więcej zasobów, ale bywa konieczne przy nowoczesnych front-endach, nieskończonym scrollu czy treściach ładowanych dynamicznie.

Gdy już rozumiem strukturę strony, mogę zbudować pierwszy przepływ pobierania i sprawdzić, czy problem da się rozwiązać prostym parserem, czy trzeba wejść poziom wyżej.

Jak zbudować pierwszy działający przepływ pobierania danych

Ja zwykle rozbijam cały proces na małe kroki, bo wtedy od razu widać, gdzie coś się psuje. Nie zaczynam od wielkiego systemu, tylko od jednej strony, jednego rekordu i jednego zestawu pól. Dopiero gdy to działa, dokładam paginację, walidację i zapis do bazy.

1. Ustal zakres danych. Zapisz dokładnie, co chcesz pobierać: tytuł, cenę, datę publikacji, adres URL, autor, stan dostępności. Bez tego łatwo zbudować skrypt, który pobiera „coś”, ale nie to, czego naprawdę potrzebujesz.

2. Sprawdź strukturę strony. Otwórz HTML źródłowy, porównaj kilka podstron i zobacz, czy układ jest powtarzalny. W tym momencie wychodzi, czy wystarczy jedna reguła, czy trzeba przygotować kilka wariantów dla różnych typów kart albo sekcji.

3. Wybierz sposób pobierania. Przy prostych, statycznych stronach wystarczy zwykłe żądanie HTTP i parser HTML. Przy stronach z logowaniem, interakcją lub dynamicznym renderowaniem trzeba sięgnąć po automatyzację przeglądarki.

4. Parsuj i normalizuj. Nie zapisuję surowego tekstu bez obróbki. Usuwam zbędne spacje, zamieniam formaty dat, ujednolicam waluty i sprawdzam, czy wartości nie są puste albo błędnie ucięte.

5. Dodaj odporność na błędy. Timeout, 403, 429, brak elementu, zmiana kolejności pól - to nie wyjątki, tylko codzienność. Na start ustawiam też rozsądne przerwy między żądaniami, często rzędu 1-3 sekund, jeśli nie mam zgody na większy ruch.

6. Zapisz dane w przewidywalnym formacie. CSV nadaje się do prostych zestawień, JSON do wymiany między usługami, a baza danych do większych projektów, które będą rosły i wymagały filtrowania.

Jeśli coś ma się naprawdę utrzymać, od razu myślę też o logach i prostym monitoringu liczby pobranych rekordów. To zwykle ratuje projekt szybciej niż kolejna godzina walki z selektorem, który przestał działać po zmianie frontu. Na tym etapie najczęściej wychodzi też, czy wystarczy parser HTML, czy trzeba użyć cięższego narzędzia.

Jak wybrać narzędzie do konkretnego zadania

Dokumentacja Scrapy opisuje go jako szybki framework do crawlowania i ekstrakcji danych, więc dobrze sprawdza się przy większej liczbie podstron i wtedy, gdy chcesz mieć kolejki, eksport, retry oraz porządek w projekcie. Ja traktuję wybór narzędzia jak decyzję o zakresie odpowiedzialności: nie biorę przeglądarki wszędzie tam, gdzie wystarczy lżejsze rozwiązanie.

Jeśli ktoś pyta mnie, od czego zacząć, odpowiadam: od najtańszej metody, która wystarcza. Dopiero gdy treść siedzi za JavaScriptem albo wymaga interakcji, przenoszę się do automatyzacji przeglądarki. To oszczędza czas, zasoby i nerwy przy późniejszym utrzymaniu. Ale nawet najlepsze narzędzie nie daje prawa do ignorowania zasad serwisu.

Jak pracować zgodnie z zasadami witryny i nie psuć sobie projektu

Jak przypomina MDN, robots.txt zwykle leży w katalogu głównym domeny i wskazuje, do jakich zasobów crawler ma dostęp. Traktuję ten plik jako pierwszy sygnał, że właściciel serwisu chce ograniczyć ruch botów albo przynajmniej uporządkować sposób pobierania danych. To nie zastępuje zdrowego rozsądku, ale daje szybki obraz sytuacji.

W praktyce sprawdzam trzy rzeczy zanim puszczę większy ruch:

• Regulamin serwisu - szczególnie gdy dane mają trafić do produktu komercyjnego.
• Charakter danych - czy nie wchodzę w obszar danych osobowych albo treści, których ponowne użycie wymaga dodatkowej podstawy.
• Obciążenie techniczne - czy mój skrypt nie generuje niepotrzebnego ruchu, który wygląda jak atak albo zwykłe nadużycie.

Od strony technicznej staram się też nie przyspieszać na siłę. Ustawiam rozsądny limit żądań, cache, przerwy między pobraniami i jasny User-Agent. Jeśli widzę odpowiedzi 429 albo rosnącą liczbę błędów, to nie jest sygnał do walki, tylko do zwolnienia albo zmiany podejścia. Gdy te zasady są zignorowane, nawet poprawny technicznie scraper bywa bezużyteczny w dłuższym okresie.

Najczęstsze błędy, które psują dane szybciej niż sam kod

W projektach scrapingowych najdroższe nie są błędy składniowe. Najdroższe są błędy, których przez długi czas w ogóle nie widać. Poniżej są te, które spotykam najczęściej, razem z krótką korektą podejścia.

• Zbyt kruche selektory. Jeśli opierasz się na klasie generowanej automatycznie, jeden deploy potrafi wywrócić cały pipeline. Lepiej szukać stabilniejszych atrybutów albo układu semantycznego.
• Brak obsługi paginacji. Pierwsza strona zwykle wygląda dobrze, ale prawdziwe dane siedzą na kolejnych wynikach. Zanim uznam projekt za gotowy, sprawdzam, ile stron faktycznie istnieje i czy numeracja jest przewidywalna.
• Duplikaty i brak normalizacji. Ten sam rekord może pojawić się w kilku miejscach. Jeśli nie odfiltrujesz powtórzeń, statystyki i raporty szybko staną się fałszywe.
• Ignorowanie treści ładowanej asynchronicznie. Czasem HTML wygląda ubogo, bo właściwe dane przychodzą później przez skrypt. Wtedy sam parser widzi za mało i daje niepełny wynik.
• Brak walidacji pustych pól. Pusty tytuł, brak ceny albo niepoprawna data powinny trafiać do logów, a nie w ciszy do bazy.
• Zero testów regresji. Wystarczy zapisać przykładowy HTML i sprawdzać parser na tym samym materiale po zmianach. To prosty sposób, żeby wykryć pęknięcie selektora zanim zrobi to produkcja.

Jeśli te problemy wyeliminujesz, projekt przestaje być jednorazowym skryptem, a zaczyna działać jak sensowny element procesu danych. I właśnie wtedy pojawia się ostatnie, najważniejsze pytanie: co zrobić, żeby to rozwiązanie nie rozsypało się po tygodniu?

Najmniej kosztuje to rozwiązanie, które da się utrzymać bez ciągłych poprawek

Moja praktyczna zasada jest prosta: najpierw stabilność, potem skala. Jeśli scraper ma pracować raz na miesiąc, można go zbudować prościej. Jeśli ma zasilać raporty, produkt albo automatyzację biznesową, od razu potrzebujesz logów, testów selektorów, obsługi błędów i sensownego monitoringu jakości danych.

Najlepszy moment na uproszczenie projektu to nie później, tylko teraz. Jeśli serwis daje API, biorę API. Jeśli wystarczy HTML, nie dokładam przeglądarki. Jeśli strona zmienia się co tydzień, projektuję to tak, żeby szybciej wykryć zmianę niż walczyć z nią po fakcie. Właśnie takie decyzje odróżniają dobry scraper od skryptu, który działa tylko na zrzucie ekranu z testów.

Jeżeli miałbym zostawić jedną praktyczną wskazówkę, byłaby taka: zapisuj przykładowe strony, testuj parsery na znanych danych i nie zakładaj, że struktura HTML będzie trwała wiecznie. To podejście nie jest efektowne, ale właśnie dlatego działa.