피드 최적화 상시 루틴: 검색 로봇이 차단되지 않도록 자사몰 서버의 User-Agent 허용 상태 검수 및 이미지 누락 정기 스캔 프로토콜

지금까지 다룬 모든 강의는 카탈로그 데이터와 캠페인 설계의 품질을 다뤘습니다. 하지만 이 모든 노력이 무의미해지는 경우가 하나 있습니다. 바로 메타가 그 데이터를 아예 가져가지 못하는 경우입니다. 이 강의는 데이터 품질이 아니라 데이터 전달 통로 자체가 막히지 않았는지를 확인하는, 인프라 관점의 마지막 점검을 다룹니다.

메타는 facebookexternalhit이라는 유저에이전트를 이용해 링크 미리보기 생성과 카탈로그 피드 수집 등 다양한 외부 데이터 수집 작업을 수행합니다. 이 크롤러는 링크 미리보기를 정상적으로 만들기 위해 사이트의 robots.txt 규칙을 우회하는 경우가 있는 것으로 알려져 있어, robots.txt 설정만으로는 이 크롤러의 접근을 완전히 통제하기 어렵습니다. 실질적인 차단·허용은 대개 서버나 방화벽(클라우드플레어 WAF, Nginx, .htaccess 등) 단의 규칙으로 이뤄집니다.

자사몰 서버의 보안을 강화하는 작업(봇 트래픽 차단, DDoS 방어 규칙 추가, CDN 설정 변경) 중에 알려지지 않은 유저에이전트를 광범위하게 차단하는 규칙을 걸 때, facebookexternalhit도 함께 차단 목록에 포함되는 사고가 실무에서 자주 발생합니다. 보안 담당자는 이 유저에이전트가 카탈로그 피드 수집에 쓰인다는 사실을 모르는 경우가 많아, 마케팅팀과 보안·인프라팀 사이에 소통이 없으면 이런 사고를 사전에 막기 어렵습니다.

유저에이전트 문자열은 쉽게 위조할 수 있기 때문에, 문자열만으로 진짜 메타 요청인지 판단하는 것은 불완전합니다. 더 신뢰할 수 있는 검증 방법은 요청이 들어온 IP 주소가 메타의 공식 네트워크 대역(AS32934, Facebook Inc.)에 속하는지 함께 확인하는 것입니다. 서버 방화벽 규칙을 설계할 때 유저에이전트 문자열 일치와 IP 대역 일치를 함께 요구하도록 설정하면, 이 유저에이전트를 사칭한 악성 크롤러와 실제 메타 요청을 구분할 수 있습니다.

상거래 관리자의 데이터 소스 화면에는 최근 피드 수집이 성공했는지 실패했는지가 표시됩니다. 이 화면에서 수집 실패 이력이 갑자기 발생했다면, 피드 파일 자체의 문제가 아니라 서버 접근성 문제(크롤러 차단)일 가능성을 먼저 의심해야 합니다. 특히 최근 서버·보안 설정 변경 이력과 수집 실패 시점이 겹친다면 이 인과관계를 우선적으로 확인하는 것이 효율적인 진단 순서입니다.

피드 수집 자체는 성공해도, 피드 안에 담긴 image_link URL이 실제로는 접근 불가능한 상태(이미지 삭제, 경로 변경, CDN 만료)인 경우가 있습니다. 이 문제는 피드 수집 실패와는 다른 층위의 문제라 상거래 관리자의 수집 상태 화면만으로는 발견되지 않을 수 있습니다. 정기적으로 카탈로그에 등록된 이미지 URL 샘플을 직접 접속해보거나, 상거래 관리자가 제공하는 상품별 진단 정보에서 이미지 관련 경고가 있는지 확인하는 별도의 스캔 루틴이 필요합니다.

크롤러 접근성, 피드 수집 성공 여부, 이미지 누락 여부는 서로 다른 원인에서 발생하지만, 결국 모두 "카탈로그 데이터가 메타에 온전히 전달되고 있는가"라는 같은 질문에 대한 답입니다. 이 세 가지를 주간 점검 체크리스트로 묶어 한 번에 확인하는 루틴을 만들어두면, 이 과목에서 다룬 다른 모든 최적화 작업(제품 세트, 크리에이티브, 리타게팅 조건식)이 온전한 데이터 위에서 작동하고 있다는 것을 지속적으로 보장할 수 있습니다.

이 강의에서 다룬 사고 대부분은 기술적으로 어려운 문제가 아니라, 서로 다른 팀이 서로의 작업이 상대 팀에 미치는 영향을 모른 채 진행하다 발생하는 소통 문제입니다. 인프라팀이 보안 규칙을 변경하기 전에 "카탈로그·픽셀 관련 크롤러·트래픽에 영향이 없는지" 마케팅팀에 확인받는 절차를 사전에 합의해두면, 이 강의에서 다룬 대부분의 사고를 사전에 예방할 수 있습니다. 이는 106강에서 다룬 서드파티 스크립트 릴리스 체크리스트와 같은 맥락의 조직 차원 해법입니다.