[AdSense][수익화] Requires review 상태에서 WAF, redirect, robots allow 경로가 crawler 접근을 막을 때 어떤 응답 헤더부터 다시 보나
IT 리서치 노트
[AdSense][수익화] Requires review 상태에서 WAF, redirect, robots allow 경로가 crawler 접근을 막을 때 어떤 응답 헤더부터 다시 보나
AdSense의 `Requires review` 상태가 길어질 때 ownership과 payments는 이미 맞는데도 crawler 접근이 막혀 있을 수 있다. 2026년 7월 21일 기준 Google 공식 도움말을 다시 보면 이때는 단순히 robots.txt만 보는 것이 아니라 SSL, HTTP→HTTPS redirect, login protection, 그리고 crawler 전용 차단을 같이 봐야 한다. 이 글은 WAF, redirect, robots allow 경로가 crawler 접근을 막을 때 어떤 응답 헤더부터 다시 보는 편이 빠른지 정리한 것이다.
1. 개요
결론부터 말하면 AdSense crawler 접근 문제를 다시 볼 때는 robots.txt보다 먼저 URL별 응답 헤더를 저장하는 편이 빠르다. 홈, 대표 글, robots.txt 각각에 대해 HTTP 상태, redirect location, 로그인 흔적, challenge HTML 여부를 먼저 나누면 WAF인지 redirect인지 금방 갈린다.
그다음에 Mediapartners-Google 차단 규칙을 본다. robots 설정이 맞더라도 redirect loop나 TLS 문제, 로그인 리다이렉트, bot challenge가 있으면 review는 계속 멈출 수 있다.
2. 어디서 실제로 막히는가
이 상황에서 흔한 오해는 세 가지다. 첫째, Search Console이 괜찮으면 AdSense crawler도 같을 것이라고 본다. 둘째, robots.txt만 열리면 접근성 문제는 끝났다고 생각한다. 셋째, 브라우저에서 정상 렌더링되면 redirect와 WAF 문제도 없다고 가정한다.
하지만 Google 도움말은 crawler access를 password, robots.txt, SSL, redirect 같은 별도 질문으로 나눈다. 즉 같은 사이트라도 사람 브라우저와 crawler가 같은 결과를 받는다는 보장은 없다. WAF나 CDN bot protection, country rule, session redirect가 들어가면 특히 그렇다.
- 증상: ownership과 payments는 끝났는데 review가 오래 남는다.
- 실패: robots.txt 한 장만 보고 crawler 접근성 전체를 판단한다.
- 막힘: HTTP→HTTPS redirect, login redirect, WAF challenge를 로그로 안 남긴다.
- 누락: Mediapartners-Google과 Search Console bot을 같은 crawler로 취급한다.
| 질문 | 먼저 볼 것 | 판단 기준 |
|---|---|---|
| robots 문제인가 | robots.txt와 Mediapartners 규칙 | Disallow:/가 있으면 즉시 수정 대상이다 |
| redirect 문제인가 | Location과 final status | loop 또는 긴 체인이 있으면 crawler 접근성이 떨어진다 |
| WAF/login 문제인가 | 401/403, challenge HTML, auth header | 사람과 bot의 응답이 다르면 의심한다 |
3. 실무에서 적용하는 순서
가장 짧은 순서는 다섯 단계다. 첫째, 홈과 대표 콘텐츠 URL의 헤더를 각각 저장한다. 둘째, robots.txt에서 Mediapartners-Google 차단 여부를 본다. 셋째, HTTP→HTTPS redirect가 한 번에 끝나는지 확인한다. 넷째, login redirect나 basic auth가 숨어 있지 않은지 확인한다. 다섯째, CDN/WAF가 bot challenge를 내보내는지 본다.
- 홈, 대표 글, robots.txt의 HTTP 상태를 남긴다.
- Mediapartners-Google 차단 규칙을 확인한다.
- redirect location과 hop count를 기록한다.
- login redirect, 401/403, WWW-Authenticate를 확인한다.
- WAF challenge HTML이나 vendor header를 확인한다.
핵심은 사람 브라우저 기준이 아니라 crawler 기준의 재현 로그를 남기는 것이다. review가 오래 남아도 ownership과 payments가 끝났다면 더 이상 계정 설정을 흔들지 말고 접근성 로그를 먼저 고정하는 편이 낫다.
home_status=200
content_status=200
robots_status=200
redirect_chain=http->https
mediapartners_allow=true
login_redirect_seen=false
waf_challenge_seen=false이미 payments와 review queue 글에서 계정 쪽 분기를 닫았다면, 이번 글은 남은 crawler 접근 축을 더 구체적으로 좁히는 후속편이다.
4. 공식 문서와 예시 화면으로 확인하기
첫 화면은 Google이 crawler 접근 문제에서 SSL과 HTTP→HTTPS redirect를 별도 체크 항목으로 둔다는 점을 보여 준다. 브라우저에서 열리는 것만으로는 충분하지 않다.
즉 Requires review가 오래 남아 있을 때 redirect chain이나 TLS 오류가 있으면 ownership과 payments가 맞아도 review는 진행되지 않을 수 있다.
두 번째 자료는 Google이 connection issues에서 직접 묻는 질문 목록이다. password protection과 crawler access는 review 지연의 핵심 분기다.
여기서 중요한 점은 '사람은 열 수 있다'와 'crawler가 같은 경로를 따라갈 수 있다'가 다르다는 것이다. WAF, basic auth, country block이 있으면 둘이 쉽게 갈라진다.
세 번째 자료는 robots.txt에서 어떤 줄이 바로 문제를 만드는지 보여 준다. Mediapartners-Google 전체 차단은 AdSense crawler가 콘텐츠를 읽지 못하게 만든다.
Search Console에서 다른 Google bot이 잘 도는 것처럼 보여도 Mediapartners-Google 규칙이 별도로 막혀 있으면 AdSense review 쪽은 계속 멈출 수 있다.
운영에서는 crawler 차단 원인을 넷으로 나눠 두는 편이 빠르다. robots, redirect chain, login, WAF를 한 표로 나누면 어떤 헤더를 먼저 저장할지가 바로 정해진다.
이미 crawler 헤더와 robots 경로 글이 큰 분기를 열었다면, 이번 표는 그 안에서 WAF와 redirect를 더 좁게 갈라 주는 후속편이다.
마지막 자료는 실제로 저장할 헤더 예시다. 화면 캡처보다 먼저 HTTP 상태와 redirect, challenge 흔적을 텍스트로 남겨 두는 편이 재현성이 높다.
이 정도 로그만 있어도 policy 대기와 crawler 차단을 섞지 않게 된다. 또 ownership과 crawler 접근 분기 글을 실제 운영 점검표로 바꾸기 쉬워진다.
5. 주의사항과 리스크
첫 번째 리스크는 site를 삭제했다 다시 등록해 review 시간을 늘리는 것이다. 두 번째는 Search Console 검증 통과를 crawler 접근 통과와 같은 신호로 보는 것이다. 세 번째는 robots.txt만 손보고 redirect와 WAF 차단은 그대로 두는 것이다.
실무 기록에는 URL별 상태, redirect 최종 목적지, auth 흔적, challenge 흔적을 같이 남기는 편이 좋다. 그래야 robots 경로 글과 이번 header 글이 서로 다른 층이라는 점이 분명해진다.
6. 결론
AdSense Requires review 상태에서 crawler 접근을 의심할 때는 robots.txt만 볼 일이 아니다. 응답 헤더 기준으로 redirect, login, WAF, Mediapartners 허용 규칙을 먼저 분리해야 review 지연의 실제 원인을 빠르게 좁힐 수 있다.
같은 가지의 선행 글로는 ownership과 crawler 접근 분기 글, payments와 review queue 글, crawler header와 robots 경로 글을 이어서 보면 좋다.
오늘 기준 후속편으로는 crawler login이 비활성화돼 보일 때 review 단계 공개 경로를 다시 여는 글을 같이 보면 좋다. 이번 글이 응답 헤더와 redirect, WAF를 먼저 좁히는 축이라면, 그 글은 review 단계에서 login wall을 언제 내려야 하는지와 승인 뒤 crawler login을 언제 설계해야 하는지를 따로 정리한다.