대부분의 파싱 초보자들은 사이트를 완전히 탐색하는 것부터 시작합니다: 메인 페이지에 들어가 모든 링크를 수집하고, 각 링크를 클릭하고, 다시 링크를 수집하는 과정을 수천 번 반복합니다. 이는 프록시와 시간을 소모하며, 종종 차단으로 이어집니다. 더 쉽고 저렴한 방법이 있습니다: Wildberries, Ozon 및 Avito를 포함한 거의 모든 대형 사이트는 이미 모든 페이지의 준비된 맵인 sitemap.xml을 가지고 있습니다. 이를 찾고 읽고 수천 개의 불필요한 요청 대신 사용하는 방법을 알아보겠습니다.
sitemap.xml이란 무엇이며 파서에게 왜 필요한가
sitemap.xml은 사이트가 Google 및 Yandex와 같은 검색 엔진을 위해 스스로 생성하는 파일입니다. 이 파일에는 사이트 소유자가 인덱싱되기를 원하는 모든 페이지가 나열되어 있습니다: 상품 카드, 카테고리, 블로그 기사. 본질적으로, 이는 사이트가 스스로 제공하는 URL의 준비된 목록입니다. 수동으로 링크를 클릭하거나 페이지네이션을 클릭하거나 탐색 논리를 추측할 필요가 없습니다.
Wildberries 또는 Ozon에서 경쟁자의 가격을 모니터링하는 판매자에게는 이것이 의미하는 바가 있습니다: 수천 개의 카테고리와 페이지를 탐색하는 대신, sitemap에 대한 한 번의 요청으로 모든 상품 카드의 목록을 즉시 받을 수 있습니다. 경쟁자의 콘텐츠 분석을 위해 URL 데이터베이스를 수집하는 마케터에게는 수작업으로 소요되는 시간을 절약할 수 있습니다. 경쟁자의 랜딩 페이지를 파싱하여 크리에이티브를 분석하는 중재자에게는 sitemap이 사이트의 모든 페이지를 한 번에 보여줍니다.
중요한 점: 모든 페이지가 sitemap에 포함되는 것은 아닙니다. 때때로 필터가 있는 페이지, 임시 프로모션 또는 URL에 매개변수가 있는 페이지는 포함되지 않습니다. 따라서 sitemap은 항상 사이트의 100%를 커버하지는 않지만, 일반적으로 카탈로그나 모니터링에 필요한 유용한 페이지의 80-95%를 포함합니다.
전체 탐색 vs sitemap 우선: 비용 비교
접근 방식의 차이는 추상적인 "시도"가 아니라 실제 자원, 즉 요청 수, 프록시 트래픽 소비 및 결과까지 걸리는 시간으로 계산할 때 뚜렷합니다. 아래는 50,000개의 상품 카드로부터 카탈로그를 수집하는 예를 통한 비교입니다.
| 매개변수 | 사이트 전체 탐색 | sitemap을 통한 파싱 |
|---|---|---|
| URL 수집 요청 수 | 15,000–20,000 (카테고리, 페이지네이션, 필터) | 50–300 (sitemap 파일만) |
| URL 목록 수집 시간 | 4–8시간 | 15–30분 |
| IP 차단 위험 | 탐색 요청의 양으로 인해 높음 | 요청 수가 훨씬 적어 낮음 |
| 프록시 트래픽 부하 | 높음, 대량의 IP 풀 필요 | 최소, 적은 풀로도 가능 |
| 파서의 논리 복잡성 | 높음, 탐색 논리 분석 필요 | 낮음, XML 구조 분석 |
제목의 "10배 저렴하다"는 과장이 아닙니다. 전체 탐색이 페이지 목록을 작성하기 위해 15,000-20,000개의 요청을 요구하는 반면, sitemap은 같은 목록을 50-300개의 요청으로 제공합니다. 이는 프록시 트래픽과 시간에서 수십 배의 절약을 가능하게 합니다. 상품 카드는 여전히 별도로 다운로드해야 하지만, 어떤 URL을 다운로드해야 할지 확실히 알 수 있으며, 빈 페이지, 중복 및 쓰레기 링크에 자원을 낭비하지 않습니다.
어떤 사이트에서든 sitemap.xml 찾는 방법
첫 번째이자 가장 간단한 방법은 사이트 도메인에 /sitemap.xml을 추가하는 것입니다. 예를 들어, 브라우저에서 https://example.com/sitemap.xml 주소를 열어보세요. 이는 대부분의 사이트에서 작동하며, 인기 있는 CMS를 사용하는 많은 온라인 상점에서도 마찬가지입니다.
이 주소에서 아무것도 없다면, robots.txt 파일을 확인하세요. 이 파일은 거의 항상 /robots.txt 주소에 위치하며, 대부분의 경우 Sitemap: https://example.com/sitemap_index.xml라는 줄을 포함합니다. 이는 사이트가 검색 엔진에 맵을 찾는 위치를 알리는 공식적인 방법입니다. Wildberries 및 Ozon과 같은 대형 마켓플레이스의 경우, 사이트 맵이 종종 수십 개의 파일로 나뉘어 있으며, robots.txt를 통해 명시됩니다.
세 번째 방법은 Google Search Console과 같은 시스템에서 언급을 검색하거나, 모든 sitemap 파일을 자동으로 찾는 전문 스캐너를 사용하는 것입니다. 경쟁자의 사이트에 대해서는 일반적으로 첫 번째 두 가지 방법으로 충분합니다. robots.txt는 거의 항상 외부의 눈으로부터 차단되지 않으며, 이는 공개 파일입니다.
조언:
sitemap 파일 이름은 항상 표준화되어 있지 않습니다. sitemap_index.xml, sitemap-products.xml, product-sitemap.xml와 같은 다양한 변형이 있을 수 있습니다. 항상 robots.txt에서 시작하세요. 정확한 경로를 알려줄 것입니다.
마켓플레이스의 sitemap 구조: 인덱스 및 중첩된 맵
작은 사이트는 일반적으로 모든 URL이 포함된 하나의 sitemap.xml 파일을 가지고 있습니다. 그러나 Wildberries, Ozon 또는 Avito와 같은 대형 카탈로그는 수백만 개의 페이지를 가지고 있으며, 이렇게 많은 양을 포함하는 하나의 XML 파일은 불편합니다. 따라서 이들은 소위 sitemap 인덱스라는 파일을 사용합니다. 이는 카테고리, 날짜 또는 10,000-50,000개의 URL 묶음으로 나뉜 수십 또는 수백 개의 개별 sitemap 파일을 참조하는 목차 파일입니다.
구조는 대략 다음과 같습니다: 먼저 주요 인덱스 파일을 열고, 그 안에서 자식 sitemap에 대한 링크 목록을 찾습니다. 예를 들어 sitemap-products-1.xml, sitemap-products-2.xml 등이 있습니다. 그런 다음 이러한 파일 각각을 다운로드하고 그로부터 최종 상품 카드의 URL을 추출해야 합니다. 이는 두 단계의 과정이지만, 여전히 사이트 탐색을 수동으로 하는 것보다 훨씬 빠릅니다.
때때로 자식 sitemap 파일은 gzip 형식으로 압축되어 있습니다 (.xml.gz 확장자) — 이는 서버 공간을 절약하기 위한 표준 관행입니다. 스크립트가 파일을 다운로드하고 XML 대신 읽을 수 없는 문자를 발견하면, 아마도 파싱 전에 내용을 먼저 압축 해제해야 할 것입니다.
sitemap에서 URL을 단계별로 추출하기
준비된 no-code 파싱 도구를 사용하는 사람들을 위해, 대부분의 현대 마켓플레이스 카탈로그 파서들은 이미 sitemap을 자동으로 읽을 수 있습니다. 사이트의 루트 URL만 지정하면 도구가 robots.txt를 찾고 sitemap 인덱스를 찾아 모든 카드를 수집합니다. 하지만 개발자와 함께 작업하거나 작은 스크립트를 직접 작성하는 경우, 작업 논리는 간단하며, 다음은 Python의 예입니다:
import requests
import gzip
from io import BytesIO
from lxml import etree
def get_sitemap_urls(sitemap_url, proxies=None):
response = requests.get(sitemap_url, proxies=proxies, timeout=15)
content = response.content
# gzip 압축 해제, 파일이 압축된 경우
if sitemap_url.endswith('.gz'):
content = gzip.decompress(content)
root = etree.fromstring(content)
namespace = {'ns': 'http://www.sitemaps.org/schemas/sitemap/0.9'}
# 이것이 sitemap 인덱스인 경우 — 자식 맵에 대한 링크 수집
sub_sitemaps = root.findall('.//ns:sitemap/ns:loc', namespace)
if sub_sitemaps:
all_urls = []
for sub in sub_sitemaps:
all_urls.extend(get_sitemap_urls(sub.text, proxies))
return all_urls
# 일반 sitemap인 경우 — 최종 URL 수집
urls = root.findall('.//ns:url/ns:loc', namespace)
return [url.text for url in urls]
proxy = {
"http": "http://user:pass@proxy_host:port",
"https": "http://user:pass@proxy_host:port"
}
urls = get_sitemap_urls("https://example.com/sitemap_index.xml", proxies=proxy)
print(f"발견된 URL: {len(urls)}")이 스크립트는 인덱스 파일을 재귀적으로 탐색하고, 각 자식 맵을 다운로드하여 모든 최종 링크를 하나의 목록으로 수집합니다. 결과적으로, 사이트 탐색을 통해 불필요한 이동 없이 상품 카드의 전체 URL 목록을 얻을 수 있습니다.
URL 패턴에 따라 필요한 페이지 필터링하기
sitemap에서 전체 URL 목록을 받은 후, 거의 항상 필터링이 필요합니다. 하나의 sitemap 파일에는 상품 카드, 카테고리 페이지, 블로그 기사, 브랜드 페이지 및 서비스 페이지가 함께 있을 수 있습니다. 아마도 특정 카테고리의 상품 카드만 필요할 것입니다.
필터링을 위해 일반적으로 URL 패턴을 사용합니다. 예를 들어, 사이트의 상품 카드가 /catalog/product/12345 형식이고, 카테고리가 /catalog/category/electronics 형식이라면, 경로 세그먼트를 간단히 비교하여 서로를 구분할 수 있습니다. URL 구조가 그렇게 명확하지 않은 경우에는 정규 표현식을 사용하여 패턴을 한 번 설정하고 수십만 개의 링크를 즉시 필터링할 수 있습니다.
sitemap 내의 <lastmod> 태그를 살펴보는 것도 유용합니다. 이는 페이지의 마지막 수정 날짜를 보여줍니다. 전체 카탈로그가 아니라 최근 일주일 동안 업데이트된 상품만 필요하다면 (예: 경쟁자의 새로운 포지션 모니터링을 위해), 이 날짜에 따라 URL을 필터링하고 몇 달 동안 변경되지 않은 페이지는 건드리지 않을 수 있습니다.
사이트 맵 대량 다운로드를 위한 프록시 설정
sitemap에 대한 요청 수가 전체 탐색보다 훨씬 적지만, Wildberries 및 Ozon과 같은 사이트는 여전히 의심스러운 활동을 모니터링합니다 — 하나의 IP에서 너무 잦은 요청, 비정상적인 User-Agent, 브라우저 헤더의 부재. 따라서 sitemap 파일을 다운로드할 때조차도 프록시를 사용하는 것이 좋습니다. 특히 정기적인 모니터링을 계획하고 있다면 더욱 그렇습니다.
XML 파일을 다운로드하는 데는 일반적으로 데이터 센터 프록시가 충분합니다 — 이들은 빠르고 저렴하며, sitemap에 대한 요청 수가 적어 사이트가 일반 카탈로그 페이지보다 강력한 보호를 적용할 가능성이 낮습니다. 그러나 수집된 URL에 대한 상품 카드 다운로드 단계에서는 요청 수가 훨씬 많고 보호가 더 강력하므로 주거용 프록시로 전환하는 것이 좋습니다 — 이들은 일반 사용자의 실제 IP를 사용하며 마켓플레이스의 안티봇 시스템에 의해 차단될 가능성이 적습니다.
모바일 사이트의 카탈로그를 모니터링하거나 모바일 트래픽에서만 데이터를 제공하는 API를 사용하는 경우, 모바일 프록시를 고려하는 것이 좋습니다 — 이들은 모바일 운영자의 IP를 사용하며 대부분의 안티프로드 시스템에서 가장 신뢰받는 것으로 간주됩니다.
스크립트나 파서에서의 실제 설정은 간단합니다: 요청의 해당 필드에 프록시의 호스트, 포트, 로그인 및 비밀번호를 지정하세요 (위 코드 예제의 proxies 매개변수에서 보여준 것처럼), 또는 준비된 no-code 파서나 Dolphin Anty 또는 AdsPower와 같은 안티디텍트 브라우저를 사용하여 자동 수집 설정 전에 사이트 구조를 수동으로 확인할 경우, 프로필 설정에서 프록시 데이터를 입력하세요: "프록시" 탭을 열고 → HTTP 또는 SOCKS5 유형 선택 → 호스트, 포트, 로그인, 비밀번호 입력 → 프로필 저장.
sitemap 작업 시 자주 발생하는 오류
첫 번째이자 가장 흔한 오류는 robots.txt를 무시하고 sitemap 주소를 무작위로 추측하는 것입니다. 이는 시간을 낭비하는 일이며, 인덱싱 규칙 파일을 확인하면 쉽게 피할 수 있습니다.
두 번째 오류는 sitemap이 불완전할 수 있다는 점을 간과하는 것입니다. 일부 사이트는 SEO에 낮은 가치를 가진 페이지를 sitemap에서 의도적으로 제외하지만, 가격 모니터링에는 여전히 중요한 페이지가 있을 수 있습니다 — 예를 들어, 재고가 없는 상품 페이지. sitemap을 통해 수집된 카드 수가 예상보다 현저히 적다면, 사이트가 카테고리에서 보여주는 상품 수와 비교하고 필요시 누락된 섹션을 점검하여 수집을 보완해야 합니다.
세 번째 오류는 이미 다운로드한 sitemap 파일을 캐시하지 않는 것입니다. 매일 모니터링을 실행하는 경우, 매번 인덱스 파일과 모든 자식 맵을 다시 다운로드할 필요가 없습니다 — 대부분은 매일 변경되지 않습니다. URL 목록을 로컬에 저장하고 lastmod 날짜에 따라 실제로 변경된 것만 업데이트하세요.
네 번째 오류는 요청 헤더를 잊는 것입니다. 간단한 XML 파일 다운로드조차도 요청이 봇처럼 보이면 차단될 수 있습니다: User-Agent 없이, Accept-Language 없이, 요청 라이브러리가 기본적으로 설정하는 비정상적인 헤더와 함께. 현실적인 브라우저 헤더를 프록시와 결합하여 추가하면 이 단계에서 차단될 가능성이 급격히 줄어듭니다.
sitemap을 통한 파싱 시작 체크리스트
전체 카탈로그 수집을 시작하기 전에, 오류로 시간을 낭비하지 않도록 짧은 단계 목록을 확인하세요:
- 사이트의 robots.txt를 확인하고 sitemap 또는 sitemap 인덱스의 정확한 주소를 찾았습니다.
- sitemap 구조가 두 단계(인덱스 + 자식 맵) 또는 한 단계인지 확인했습니다.
- 자식 파일이 gzip으로 압축되어 있는지 확인했습니다.
- 필요한 페이지의 URL 패턴을 정의했습니다 (상품 카드, 카테고리 등).
- 신선한 포지션만 필요할 경우 패턴 또는 lastmod 날짜에 따른 필터링을 설정했습니다.
- sitemap 파일 다운로드 및 상품 카드 다운로드를 위해 프록시를 연결했습니다.
- 현실적인 요청 헤더를 추가했습니다 (User-Agent, Accept-Language).
- 재실행 시 모니터링을 위한 캐싱 및 날짜 비교를 설정했습니다.
- 최종 URL 수를 사이트에서 예상되는 상품 수와 비교했습니다.
결론
sitemap 우선 접근 방식은 해킹이나 보호 우회를 위한 것이 아니라, 사이트가 검색 엔진을 위해 스스로 게시하는 정보를 활용하는 것입니다. 수천 개의 탐색 요청 대신, XML 파일에 대한 수십 개의 요청으로 필요한 페이지의 준비된 목록을 얻습니다. 이는 파싱 시작 시간을 절약하고 프록시 트래픽 소모를 줄이며, 전체 탐색보다 사이트에 대한 부하가 훨씬 적기 때문에 IP 차단 위험을 현저히 줄입니다.
Wildberries, Ozon 또는 다른 대형 사이트의 카탈로그 모니터링을 시작하는 경우, sitemap에서 시작하세요 — 첫 실행에서 이미 몇 시간의 작업을 절약할 수 있습니다. sitemap 파일 다운로드에는 저렴한 데이터 센터 프록시가 충분하며, 이후 상품 카드 데이터의 정기적인 수집을 위해 차단 위험이 높은 경우 주거용 프록시를 고려하는 것이 좋습니다 — 이는 장기적으로 빈번한 차단 없이 파서의 안정적인 작동을 보장합니다.