SEO 전문가는 대규모 사이트의 기술 감사 작업을 시작합니다. 10분 후, Screaming Frog는 연속적으로 403 Forbidden 또는 429 Too Many Requests 오류를 발생시키기 시작합니다. 보안 서버는 크롤러를 공격 봇으로 인식하고 IP 주소를 차단했습니다. 결과적으로 감사는 다시 시작해야 하고, 고객에게 보고서 지연 이유를 설명해야 합니다. 크롤러를 위한 프록시를 올바르게 설정하면 이 문제를 해결할 수 있습니다. 어떻게 설정하는지 알아보겠습니다.
사이트가 감사 시 Screaming Frog를 차단하는 이유
Screaming Frog, Sitebulb, JetOctopus 및 Netpeak Spider는 기술적으로 검색 엔진 봇과 동일하게 작동합니다. 이들은 수천 개의 URL를 신속하게 탐색하고 HTML, CSS, JS 및 이미지를 다운로드하며 리디렉션 및 상태 코드를 확인합니다. 사이트 보호 측면(Cloudflare, Qrator, DDoS-Guard, 호스팅의 내장 WAF)에서는 이것이 의심스러운 활동으로 보입니다. 짧은 시간에 하나의 IP에서 너무 많은 요청이 발생하기 때문입니다.
특히 감사 시 차단이 자주 발생하는 경우는 다음과 같습니다:
- 자체 파싱 방어가 있는 Wildberries 유사 인프라의 대규모 온라인 쇼핑몰;
- "Under Attack" 모드가 활성화된 Cloudflare 뒤의 사이트 또는 높은 보안 수준;
- 각 요청이 서버에 부하를 주는 동적 콘텐츠 포털(검색, 필터, 상품 목록);
- 자신의 도메인이 아닌 경쟁자의 사이트를 분석할 때 — 그들은 귀하의 IP를 신뢰할 이유가 없습니다.
추가적인 복잡성: 에이전시가 하나의 정적 IP를 사용하고, 사이트 감사가 정기적으로 이루어지는 경우(하루에 여러 고객) 이 IP는 빠르게 보안 시스템의 블랙리스트에 올라갑니다. 그 후 현재 감사뿐만 아니라 같은 주소에서의 미래 감사도 차단됩니다. 이전에 문제 없이 열렸던 사이트도 포함됩니다.
응답 코드로 차단을 인식하는 방법
프록시 설정을 변경하기 전에 현재 발생하는 상황을 이해하는 것이 중요합니다. Screaming Frog는 상태 코드 열에 응답 코드를 표시합니다. 이를 통해 크롤링 중단의 원인을 쉽게 파악할 수 있습니다.
| 응답 코드 | 의미 | 조치 |
|---|---|---|
| 403 Forbidden | IP가 사이트 보호에 의해 차단됨 | IP 변경, 크롤링 속도 감소 |
| 429 Too Many Requests | 단위 시간당 요청 한도를 초과함 | 스레드 수 줄이기, 지연 추가 |
| 503 Service Unavailable | 서버 과부하 또는 봇 방어가 활성화됨 | User-Agent 변경, 거주지 IP 사용 |
| 응답 없음 / Timeout | IP가 블랙리스트에 올라 요청이 도달하지 않음 | 프록시 풀 전체 교체 |
보고서에서 수천 개의 URL에서 동일한 코드가 대량으로 나타나면 거의 항상 IP 차단 문제이며, 실제 사이트 문제는 아닙니다. 가설을 확인하는 것은 간단합니다. 동일한 IP에서 일반 브라우저로 문제 URL을 열어보세요. 페이지가 정상적으로 열리고 Screaming Frog가 403을 받는다면, 문제는 크롤러에 있는 것입니다.
SEO 크롤링에 적합한 프록시
프록시 유형 선택은 작업에 따라 다릅니다: 자신의 사이트에 대한 일회성 감사, 경쟁자에 대한 정기 모니터링 또는 보호된 마켓플레이스 스캔. 세 가지 주요 유형과 크롤러에 대한 적용 가능성을 살펴보겠습니다.
| 프록시 유형 | 속도 | 차단 위험 | 사용 시기 |
|---|---|---|---|
| 데이터 센터 프록시 | 높음 | 보호된 사이트에서 중간-높음 | 엄격한 보호가 없는 자신의 사이트 감사 |
| 거주지 프록시 | 중간 | 낮음 | 경쟁자 감사, Cloudflare 뒤의 사이트, 마켓플레이스 |
| 모바일 프록시 | 중간-낮음 | 최소 | 가장 공격적인 보호, 드문 점검 감사 |
대부분의 정기적인 기술 감사에서는 거주지 프록시가 최적의 균형을 제공합니다. 이들은 실제 ISP의 IP 주소를 사용하므로 사이트 보호는 크롤러의 요청을 일반 사용자 트래픽으로 인식합니다. 이는 귀하가 자신의 도메인이 아닌 경쟁자 사이트나 강력한 안티봇 시스템이 있는 마켓플레이스를 분석할 때 특히 중요합니다.
데이터 센터 프록시는 자신의 사이트를 감사하고 사전에 IP 범위를 WAF 또는 Cloudflare의 화이트리스트에 추가할 수 있는 경우 좋은 옵션으로 남아 있습니다. 이 경우 스캔 속도는 최대화되며 차단 위험이 없습니다.
Screaming Frog에서 프록시 단계별 설정
Screaming Frog는 기본적으로 프록시를 지원하며 설정은 몇 분이면 완료됩니다:
- 프로그램을 열고 Configuration → System → Proxy 메뉴로 이동합니다.
- 모든 트래픽에 대해 프록시 서버 사용 체크박스를 선택합니다.
- 제공자로부터 받은 프록시 서버의 주소와 포트를 입력합니다.
- 프록시가 로그인 및 비밀번호 인증을 요구하는 경우, 첫 요청 시 팝업 창에서 입력합니다.
- OK를 클릭하고 설정을 적용하기 위해 크롤링을 재시작합니다.
중요한 점: Screaming Frog의 무료 및 유료 버전은 내장 인터페이스를 통해 한 번에 하나의 프록시 서버와만 작동할 수 있습니다. IP 회전이 필요할 경우(50,000페이지 이상 스캔 시 유효), 제공자 측에서 자동으로 IP를 변경하는 프록시를 사용해야 합니다. 이는 크롤러가 아닌 프록시 서비스의 개인 계정에서 IP 변경 간격(예: 매 10분마다 또는 매 요청 시)을 설정합니다.
이러한 방식은 하나의 주소에 대한 부하를 줄입니다. 크롤러는 하나의 포트로 계속 작동하며, IP는 자동으로 변경되어 사이트는 특정 주소에서 비정상적으로 높은 요청 빈도를 인식하지 못합니다.
대규모 사이트를 위한 속도 및 스레드 설정
작동하는 프록시가 있더라도 너무 공격적인 크롤링 속도 설정은 차단을 유발할 수 있습니다. Screaming Frog에서는 Configuration → Speed 섹션에서 이를 조정합니다. 100,000페이지 이상의 사이트에 대한 권장 값은 다음과 같습니다:
- 최대 스레드: 보호된 사이트는 2–5, 엄격한 보호가 없는 사이트는 10–15;
- 최대 URI/s: 시작 시 2–3 요청으로 제한하고, 응답 코드를 관찰하며 점진적으로 증가시킵니다;
- 사용자 정의 User-Agent: Configuration → HTTP Header 섹션에서 사이트가 크롤러를 헤더로 차단하는 경우 실제 브라우저의 User-Agent를 사용합니다;
- robots.txt 준수 / crawl-delay: Crawl-delay 지시어가 명시된 경우 이를 고려합니다. 무시하면 서버 수준에서 차단될 수 있습니다.
공격적인 봇 방어가 있는 사이트의 경우, JavaScript Rendering 모드를 실제로 필요한 경우에만 활성화하는 것이 유용합니다(SPA 사이트에서 React/Vue 사용) — JS 렌더링은 서버에 대한 부하를 급격히 증가시키고 하나의 IP로 크롤링할 때 차단 위험을 높입니다.
100,000페이지 이상 스캔 시 IP 회전
사이트가 클수록 IP 주소 간의 부하를 적절히 분산하는 것이 중요합니다. 이러한 규모의 감사를 위해 두 가지 방식이 작동합니다:
시간에 따른 회전. IP는 요청 수와 관계없이 5–15분마다 자동으로 변경됩니다. 이는 여러 시간에 걸쳐 균일하게 크롤링할 때 적합합니다.
요청에 따른 회전. 각 새로운 HTTP 요청은 풀에서 새로운 IP로 전송됩니다. 이 모드는 차단으로부터 최대한 보호하지만, 쿠키 기반 인증이나 사이트의 세션 매개변수와의 정상적인 작업에 방해가 될 수 있습니다. 순수 기술 감사(상태 코드, 리디렉션, 메타 태그 수집)에는 비판적이지 않습니다.
여러 고객 사이트에 대한 병행 감사를 수행하는 에이전시의 경우, 프로젝트별로 IP 풀을 나누는 것이 합리적입니다. 이는 한 도메인에서의 차단이 "실수로" 다른 사이트 작업 시 IP의 평판에 영향을 미치는 상황을 방지합니다.
실무 팁: 대규모 감사 전에 현재 속도 및 프록시 설정으로 500–1000 URL에 대한 테스트 크롤링을 실행하세요. 이 시간 동안 403/429 오류가 발생하지 않으면, 전체 사이트에 대한 스캔을 안전하게 확장할 수 있습니다.
감사 시작 전 체크리스트
- ✅ 프록시가 연결되어 있고 접근 가능성 테스트 완료 (curl 또는 별도의 브라우저를 통해 확인);
- ✅ Max Threads 및 Max URI/s가 첫 실행을 위해 보수적으로 설정됨;
- ✅ User-Agent가 올바르게 설정되어 WAF에서 의심을 일으키지 않음;
- ✅ 사이트가 Crawl-delay 준수를 명시적으로 요청하는 경우 robots.txt 준수 활성화;
- ✅ JavaScript Rendering은 실제 필요 시에만 활성화;
- ✅ 사이트 규모가 20,000–30,000페이지 이상일 경우 IP 회전 설정;
- ✅ 세션 중단 시를 대비해 크롤링 진행 상황 저장 활성화 (Configuration → Save Crawl);
- ✅ 마켓플레이스 및 보호된 포털 감사 시 데이터 센터 대신 거주지 또는 모바일 프록시 선택.
프록시를 통한 크롤링 시 자주 발생하는 오류
시작 시 너무 높은 속도. 전문가들은 종종 감사를 가속화하려고 최대 스레드를 즉시 설정합니다. 결과적으로 사이트 보호는 즉각적으로 반응하며, 몇 분 내에 전체 프록시 풀이 블랙리스트에 올라갑니다.
모든 고객 프로젝트에 대한 하나의 정적 IP. 에이전시가 한 달에 수십 개의 감사에 대해 동일한 데이터 센터 프록시를 사용하는 경우, 이 IP의 평판은 빠르게 하락합니다. 다양한 사이트의 보안 시스템은 의심스러운 주소에 대한 데이터를 공유하는 공통 데이터베이스를 통해 정보를 교환합니다(예: Cloudflare IP Reputation).
지오 타겟팅 무시. 감사하는 사이트가 특정 지역(예: 해외 트래픽에 대한 지오 차단이 있는 러시아 온라인 쇼핑몰)에 맞춰 설정된 경우, 다른 국가의 IP를 사용하는 프록시는 접근 제한을 초래할 수 있습니다 — 공격적인 크롤링 없이도 말입니다.
과정 중 모니터링 부족. 몇 시간 동안 크롤링을 실행한 후, 전문가들은 종종 중간 응답 코드를 확인하지 않습니다. 결과적으로 감사가 완료된 후 차단 오류로 구성된 보고서의 절반을 발견하게 됩니다.
결론
Screaming Frog에서 기술 감사 시 차단 문제는 거의 항상 세 가지 요소의 조합으로 해결됩니다: 올바른 프록시 유형, 합리적인 크롤링 속도 및 적절한 IP 회전. 엄격한 보호가 없는 자신의 사이트에는 데이터 센터 프록시와 화이트리스트 추가만으로 충분합니다. 경쟁자, 마켓플레이스 및 Cloudflare 뒤의 사이트 감사에는 일반 사용자 트래픽처럼 보이는 IP가 필요합니다.
다른 도메인이나 보호된 플랫폼을 정기적으로 감사하는 경우, 거주지 프록시로 시작하는 것이 좋습니다. 이는 가장 공격적인 안티봇 시스템에서 차단 위험을 줄입니다. 최대한 보호된 리소스에 대한 특정 작업에는 모바일 프록시를 고려하고, 대규모 자체 인프라 감사에는 데이터 센터 프록시가 좋은 빠른 솔루션으로 남아 있습니다.