AdSense 코드를 넣었다고 광고가 바로 보이는 것은 아닙니다. 새 사이트에서는 심사 지연, 반영 지연, 광고 송출 지연, 도메인 불일치, 광고 차단기 영향이 겹치면서 설정은 거의 맞는데도 모든 것이 고장 난 것처럼 느껴질 수 있습니다.
그래서 빈 광고 영역은 특히 답답합니다. 코드가 들어 있어도 사이트는 아직 심사 중일 수 있고, 송출 준비가 덜 되었을 수 있고, 라이브 도메인 쪽의 작은 불일치 하나가 전체 결과를 흔들 수 있습니다.
이 글은 실전 순서에 집중합니다.
Getting ready같은 상태가 보통 무엇을 뜻하는지- 정상적인 지연과 설정 문제를 어떻게 구분할지
- 광고가 안 보일 때 무엇부터 점검해야 하는지
짧게 말하면 AdSense 사이트 상태를 먼저 보고, 그다음 라이브 도메인, /ads.txt, 페이지 소스, 광고 차단기, 슬롯 매핑 순서로 확인한 뒤, 원인을 모른 채 코드를 계속 바꾸지 않는 것이 좋습니다.
먼저 사이트 상태부터 보기
AdSense의 Sites 메뉴에서 현재 도메인 상태를 먼저 확인합니다.
- 아직
Getting ready인지 - 이미 준비 완료인지
- 승인되었지만 송출이 느린 상태인지
이 상태는 지금 보고 있는 문제가 심사 지연에 가까운지, 구현 문제에 가까운지 가늠하는 데 가장 빠른 힌트를 줍니다.
사이트가 아직 준비 중이라면 빈 슬롯이 보인다고 해서 코드가 바로 틀렸다고 판단할 수는 없습니다. 심사와 송출이 아직 완전히 끝나지 않았을 수 있습니다.
코드가 맞아도 광고가 안 나오는 이유
가장 흔한 이유는 아래와 같습니다.
- 사이트 심사가 아직 끝나지 않음
- 광고 송출 반영이 아직 덜 됨
- 테스트 중 광고 차단기가 켜져 있음
- 공개 도메인에서
ads.txt가 열리지 않음 - AdSense가 심사한 도메인과 실제 운영 도메인이 정확히 같지 않음
- 슬롯이나 위치는 있지만 해당 페이지가 아직 안정적으로 송출되기 어려운 상태임
그래서 빈 공간이 보인다고 해서 곧바로 코드 오류라고 단정하면 안 됩니다.
가장 빠른 점검 순서
짧고 실용적인 순서로 보면 아래가 효율적입니다.
- AdSense
Sites상태 확인 - 지금 테스트 중인 라이브 도메인 확인
- 그 공개 도메인에서
/ads.txt열기 - 페이지 소스에서 게시자 스크립트 확인
- 광고 차단기나 브라우저 간섭 확인
- 슬롯 ID 매핑과 실제 배치 확인
이 순서는 라이브 사이트 기본 상태가 맞는지 보기 전에 낮은 확률의 코드 수정부터 시작하는 실수를 줄여줍니다.
라이브 사이트에서 꼭 확인할 것
놀랍게도 많은 AdSense 문제는 코드 문제보다 라이브 사이트 불일치 문제인 경우가 많습니다.
아래를 확인해 보세요.
- 실제 테스트하는 도메인이 AdSense가 검토한 도메인과 정확히 같은지
- 해당 도메인에서
/ads.txt가 공개적으로 열리는지 - 페이지 소스에 게시자 스크립트가 들어 있는지
- 의도한 광고 슬롯 위치가 현재 레이아웃에도 살아 있는지
- 데스크톱과 모바일에서 같은 증상이 재현되는지
로컬 빌드나 프리뷰에서만 정상으로 보여도 실제 운영 도메인이 다르면 AdSense 심사와 송출은 다르게 동작할 수 있습니다.
Getting ready는 보통 무엇을 뜻하나
많은 사이트에서 Getting ready는 보통 아래 둘 중 하나에 가깝습니다.
- 심사가 아직 진행 중인 상태
- 도메인과 설정이 아직 인식되고 매칭되는 중인 상태
이 상태가 보인다고 해서 무조건 바로 뭔가를 수정해야 하는 것은 아닙니다. 오히려 공개 설정이 안정적인지 확인한 뒤, 심사 중에는 코드를 계속 흔들지 않는 편이 더 나을 때가 많습니다.
이 시기에 스크립트, 슬롯, 도메인 설정을 계속 바꾸면 기준선이 사라져서 오히려 원인 파악이 더 어려워질 수 있습니다.
심사 중에 자주 하는 실수
1. 빈 공간이 보이면 코드가 틀렸다고 단정함
실제로는 심사 지연이나 송출 지연일 수 있습니다.
2. localhost나 preview만 확인함
AdSense가 본 실제 공개 도메인을 테스트해야 합니다. 로컬이나 스테이징만 봐서는 충분하지 않습니다.
3. 광고 차단기를 무시함
여전히 가장 흔한 오탐 원인 중 하나입니다.
4. 도메인 일치를 놓침
www, non-www, 대체 배포 URL, 리다이렉트가 섞이면 내가 보는 도메인과 AdSense가 인식한 도메인이 달라질 수 있습니다.
5. 너무 일찍 코드를 계속 바꿈
주원인이 아직 심사 지연인데도 스크립트나 슬롯 구성을 계속 바꾸면 오히려 신호가 더 헷갈릴 수 있습니다.
간단한 라이브 사이트 체크리스트
구현이 틀렸다고 보기 전에 아래를 확인하세요.
- AdSense 사이트 상태를 확인했다
- 테스트 중인 도메인이 심사 도메인과 정확히 일치한다
/ads.txt가 공개적으로 열린다- 페이지 소스에 게시자 스크립트가 있다
- 광고 차단기를 끄고 테스트했다
- 슬롯 ID와 배치가 현재 페이지 구조와 맞다
이 체크리스트만으로도 실제 빈 광고 문제의 상당수를 좁힐 수 있습니다.
이슈가 코드가 아닐 가능성이 큰 경우
아래 조건이면 주원인이 코드 버그가 아닐 가능성이 큽니다.
- 도메인 상태가 아직
Getting ready다 - 페이지 소스에는 스크립트가 있다
/ads.txt가 정상적으로 열린다- 여러 페이지에서 같은 빈 상태가 반복된다
- 최근 템플릿이나 슬롯 구조를 크게 바꾸지 않았다
이 경우에는 placement를 계속 수정하기보다 사이트를 안정적으로 유지하고, 도메인 정합성을 다시 확인하고, 송출이 자리를 잡을 시간을 주는 편이 보통 더 낫습니다.
FAQ
Q. 빈 흰 박스가 보이면 코드가 틀린 건가요?
아닙니다. 심사 중이거나, 송출 반영이 덜 되었거나, 광고 차단기 영향일 수도 있습니다.
Q. 승인 직후 바로 광고가 뜨나요?
항상 그렇지는 않습니다. 특히 새 사이트나 막 조정한 설정에서는 몇 시간 이상 지연될 수도 있습니다.
Q. 수동 광고 슬롯도 같은가요?
네. 수동 슬롯도 전체 심사 상태, 송출 준비 상태, 라이브 도메인 일관성의 영향을 받습니다.
Read Next
- 아직 승인 전이라면 기술 블로그 AdSense 승인 체크리스트로 돌아가세요.
- 다음 문제가
ads.txt라면 AdSense ads.txt 설정 가이드로 이어가세요.
Related Posts
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.