대량 웹사이트 검사기를 사용하면 Website Status, HTTP Status Code, Final URL, Page Title, Error Message를 확인해 기업 URL을 검토할 수 있습니다. Datablist에서 CSV 또는 Excel 목록에 **Website Status & Parked Domain Checker**를 실행하고, 샘플을 테스트한 뒤 불확실한 결과를 조사한 후 CRM 레코드를 변경하세요.
웹사이트 접속 가능 여부는 URL에 관한 근거일 뿐, 기업의 영업 지속이나 폐업을 입증하지는 않습니다. 정상적으로 열리는 페이지가 휴업 중인 기업의 것일 수도 있습니다. 요청 실패 역시 일시적인 장애, 오래된 URL 또는 접근 제한 때문일 수 있습니다.
검사 결과와 기업 상태에 대한 판단은 별도로 관리하는 것이 좋습니다. 그래야 기술적 오류를 근거로 계정을 잘못 삭제하지 않으면서 팀이 검토 대기열을 운영할 수 있습니다.
이 도구로 확인할 수 있는 항목
이 enrichment는 입력된 웹사이트 URL을 가져와 응답을 분류합니다. 해당 옵션을 비활성화하지 않으면 캐시된 페이지 콘텐츠를 재사용할 수 있습니다.
- Online: 페이지 콘텐츠를 성공적으로 가져왔으며 파킹 검사 조건에 해당하지 않았습니다. 기업의 실제 영업 여부나 이메일 전달 가능성을 검증하는 결과는 아닙니다.
- Redirected: 요청이 다른 도메인에서 완료되었습니다. 프로토콜 변경이나 경로 변경만으로는 기업 도메인이 바뀐 것으로 분류하지 않습니다.
- Parked: 페이지 제목, 콘텐츠 또는 URL 패턴이 도구의 파킹 휴리스틱과 일치했습니다. 페이지를 직접 검토하세요. 임시 안내나 유지보수 문구는 사람이 맥락을 판단해야 할 수 있습니다.
- Unreachable: 요청 오류 또는 비정상 응답으로 인해 사용할 수 있는 페이지 결과를 얻지 못했습니다. 도메인이 사라졌다고 단정하지 말고 HTTP 코드와 오류를 확인하세요.
파킹 페이지로 판정된 경우 CRM 레코드를 보관 처리하기 전에 대량 파킹 도메인 검토 워크플로를 따르세요. 웹사이트 상태만으로는 기업의 폐업 여부를 판단할 수 없습니다.
기업명만 있는 목록이라면 먼저 웹사이트를 식별해야 합니다. 이런 데이터로 시작한다면 기업명으로 회사 웹사이트 찾기를 읽고, 도메인 매칭 결과를 검토한 후 검사하세요.
웹사이트 상태 확인 단계별 가이드
1단계: 데이터 불러오기
CSV 또는 Excel 파일을 collection으로 가져옵니다. Company Name, Original Website와 변경되지 않는 CRM 또는 소스 ID를 유지하세요. 불확실한 매칭 결과가 원본 웹사이트를 덮어쓰지 않도록 검사 결과는 새 property에 저장합니다.
예시로 계정 001에는 https://acme.example이, 계정 002에는 이전 도메인이 들어 있을 수 있습니다. 샘플에는 일반 URL, 이미 알고 있는 리디렉션, 검토가 필요한 레코드를 골고루 포함하세요. 이는 입력 형식을 설명하기 위한 예시이며 실제 웹사이트를 실시간으로 검사한 결과가 아닙니다.
2단계: Status Checker 열기
enrichment 카탈로그를 열고 Website Status & Parked Domain Checker를 선택합니다. 이 도구는 기존 각 행의 웹사이트 URL을 처리하며, 내 웹사이트를 방문한 익명의 사용자가 어느 기업 소속인지 식별하는 도구가 아닙니다.
“내 웹사이트를 방문한 기업”을 찾고 있었다면 이 차이를 알아두어야 합니다. 이 워크플로는 사용자가 입력한 기업 URL을 검사합니다. 방문자 식별이나 웹사이트 분석 제품이 아닙니다.
3단계: 설정 구성 및 웹사이트 입력 매핑
Website Url을 기업의 원본 URL이 들어 있는 property에 매핑합니다. 값이 없거나 유효하지 않은 입력은 의미 있는 접속 가능 여부를 검사하기 전에 수정해야 합니다.
Proxy Policy에서 Use proxy on error (default), Always use proxy 또는 No proxy를 선택하세요. 기본 정책은 실패한 요청을 프록시를 통해 다시 시도할 수 있습니다. 그렇다고 요청 성공을 보장하거나 사이트가 첫 요청을 거부한 이유까지 밝혀 주는 것은 아닙니다.
이 enrichment는 7일 동안 캐시된 페이지 콘텐츠를 재사용할 수 있습니다. 최근 변경 사항을 조사하기 위해 새로 요청해야 한다면 Disable cached data를 활성화하세요. collection에는 별도의 검사 날짜를 기록해야 합니다. 캐시된 데이터를 검사한 실행 시점과 실제 페이지를 가져온 시점은 다를 수 있습니다.
비용을 산정할 때는 enrichment 설정에 표시된 비용과 실행 후 보고된 사용량을 기준으로 삼으세요. 프록시 및 캐시 사용 여부에 따라 사용량이 달라질 수 있으므로 모든 결과를 동일한 신규 요청으로 계산해서는 안 됩니다.
4단계: 출력 항목 선택하기
목록 검토가 목적이라면 Website Status, HTTP Status Code, Final URL, Page Title, Error Message 등 5개 출력 항목을 모두 매핑하세요. 각 항목은 서로 다른 질문에 답합니다.
Website Status는 요약 결과입니다. Final URL은 도메인 변경을 조사하는 데 유용합니다. Page Title과 Error Message는 파킹 또는 요청 실패의 원인을 파악하는 데 도움이 됩니다. HTTP 코드는 해당 요청의 맥락 정보일 뿐, 기업 상태를 독립적으로 판정하는 기준이 아닙니다.
Keep, Verify domain, Retry, Investigate business status처럼 팀에서 관리할 별도의 검토 property를 추가하세요. 검사기가 이러한 비즈니스 판단까지 대신 생성하지는 않습니다.
5단계: Instant Run 열기
입력과 출력을 설정한 후 Continue with Instant Run을 선택합니다. 나머지 collection을 처리하기 전에 소규모 샘플부터 테스트하세요.
전체 데이터를 대표하는 샘플을 구성하세요. 현재 정상적으로 운영되는 홈페이지처럼 확인하기 쉬운 URL만 넣으면 오래된 도메인이나 접근이 제한된 사이트의 동작을 파악할 수 없습니다.
6단계: 샘플 테스트하기
설정된 실행 범위를 확인하고 몇 개의 행만 처리합니다. 원본 URL, Final URL, 페이지 제목을 기업 레코드와 비교하세요. 오류는 성공한 결과와 분리해 살펴봅니다.
해당 batch에 애플리케이션이 제공하는 실행 모드를 사용하세요. Run in Async는 작업 실행 방식에 관한 설정입니다. 웹사이트 요청 실패를 기업의 폐업 근거로 바꾸는 기능이 아닙니다.
새 요청의 결과와 비교해야 한다면 캐시 설정을 명시적으로 활성화하세요. 같은 캐시 요청을 반복 실행한 뒤 이를 독립적인 확인 결과로 간주해서는 안 됩니다.
7단계: 결과 검토 후 전체 실행
나머지 데이터를 실행하기 전에 샘플을 확인하세요. 잘못된 입력 property가 매핑되었거나 리디렉션이 무관한 기업을 가리킨다면 설정 또는 원본 데이터를 먼저 수정합니다.
샘플 결과가 유용하다면 처리하려던 나머지 행에도 실행하세요. CRM으로 다시 내보낼 수 있도록 원본 소스 ID와 검토 결정을 유지합니다.
웹디자인 영업용 prospect 목록에서는 접속 가능한 사이트가 출발점일 뿐입니다. 리디자인을 제안하기 전에 오래된 웹사이트 검토 체크리스트를 따라 모바일 탐색, 문의 경로, 콘텐츠를 확인하세요.
웹사이트 검사 결과 해석하기
다음의 판단 예시를 참고해 기술적 결과와 비즈니스 결론을 분리하세요.
| 결과 | 검토할 항목 | 피해야 할 판단 |
|---|---|---|
| Online, 콘텐츠 응답 성공 | 페이지가 확인하려던 기업을 나타내는가? | 모든 연락처나 이메일이 최신이라고 단정하기 |
| 다른 도메인으로 Redirected | 원래 기업, 도착 페이지의 기업 정체성, 변경 이유 | 변경을 자동으로 인수로 분류하기 |
| Parked, coming-soon 제목 | 임시 페이지인지, 재출시 예정인지, 무관한 도메인인지 | 기업 계정을 즉시 삭제하기 |
| Unreachable, 요청 오류 | 오류 세부 정보와 원본 URL, 필요한 경우 나중에 새로 요청한 결과 | 한 번의 검사 실패만으로 기업을 폐업 처리하기 |
리디렉션 처리 방법
도착 페이지의 이름과 사업 활동을 계정 정보와 비교하세요. 도메인 리디렉션은 리브랜딩, 인수, 호스팅 변경 또는 무관한 페이지로의 이동을 의미할 수 있습니다. 어떤 상황에 해당하는지 확인한 후에만 CRM을 업데이트하세요.
웹사이트가 리디렉션된다는 이유만으로 이메일 도메인을 변경해서는 안 됩니다. 웹과 이메일의 라우팅은 서로 별개이므로 연락처 주소를 변경하기 전에 적절한 이메일 검증 워크플로를 사용하세요.
파킹 도메인 식별 방법
분류기는 가져온 콘텐츠와 제목, URL의 패턴을 활용합니다. “coming soon”을 비롯한 임시 콘텐츠를 감지할 수 있습니다. 이는 사이트를 직접 살펴봐야 한다는 신호이지, 기업 등록부 조회 결과나 검증된 폐업 공지는 아닙니다.
결과를 검토 대기열에 두고 기존 고객 관계 정보도 보존하세요. 기업이 계속 영업 중인지 판단하려면 보조 출처나 해당 계정 담당자의 확인이 필요할 수 있습니다.
접속할 수 없는 사이트 처리
오류와 HTTP 코드를 확인하세요. 존재하지 않는 페이지 경로, 서버 문제, 차단된 요청은 기업 정체성이 바뀐 것으로 확인된 경우와 의미가 다릅니다.
입력한 URL이 여전히 정확한지, 캐시가 사용되었는지 확인하세요. 일시적인 문제로 보이면 계획적으로 다시 시도합니다. 해결되지 않은 레코드는 검토 대상으로 남겨 두고, 불확실성을 부정적인 사실로 바꾸지 마세요.
결론
웹사이트 검사를 활용해 기업 목록의 작업 우선순위를 정하세요. 새 응답 또는 캐시된 응답을 검토하고, 리디렉션과 오류를 조사한 뒤 승인된 판단을 원본 레코드 ID와 함께 내보냅니다. 기술적 상태와 기업 상태는 서로 다른 필드에서 관리하세요.
주요 활용 사례
CRM 데이터 정리
정기적으로 검사해 웹사이트를 확인해야 하는 계정을 찾으세요. 일괄 삭제하는 대신 검토 대기열로 보냅니다. 수정 이력을 추적할 수 있도록 원본 URL과 계정 ID를 보존하세요.
Prospect 목록 정제
enrichment를 실행하기 전에 불확실한 웹사이트 매칭을 검사하세요. 잘못된 도메인이나 오래된 소스 레코드를 발견하는 데 도움이 되지만, 모든 이메일을 검증하거나 Outbound 적합성을 판단해 주지는 않습니다. 데이터 클리닝 및 다음 워크플로에 필요한 검사와 함께 사용하세요.
리브랜딩 감지
변경된 Final URL은 후보 신호로 활용할 수 있습니다. 메시지에서 리브랜딩이나 인수를 언급하기 전에 기업의 정체성과 변경 이유를 확인하세요. 검토한 레코드에는 판단을 뒷받침하는 근거를 함께 보관합니다.
FAQ
실제로 웹사이트에 접속하나요?
페이지 콘텐츠를 가져오지만 캐시된 응답을 재사용할 수도 있습니다. 새 요청인지 여부가 중요하다면 Disable cached data를 활성화하세요.
파킹 도메인을 감지할 수 있나요?
파킹 또는 임시 페이지와 관련된 패턴을 감지합니다. 휴리스틱 결과는 수정이 필요할 수 있으므로 페이지와 맥락을 직접 확인하세요. 이 검사만으로 기업의 폐업 여부가 확정되지는 않습니다.
웹사이트가 봇을 차단하면 어떻게 하나요?
Proxy Policy와 표시된 오류를 확인하세요. 프록시로 다시 시도하면 콘텐츠를 가져올 수도 있지만 여전히 실패할 수 있습니다. 접근 제한 때문에 신뢰할 만한 검사가 불가능하다면 미확인 결과로 처리하세요.
Online이면 기업이 영업 중이라는 뜻인가요?
Online은 웹사이트 검사 규칙에 따라 사용할 수 있는 페이지 콘텐츠를 찾았다는 의미입니다. CRM의 계정 상태를 변경하거나 레코드를 삭제하기 전에 적절한 근거를 통해 기업 상태를 확인하세요.