ADSENSE 연결 오류 점검 가이드
애드센스 ‘사이트를 찾을 수 없음’ 해결 가이드: 코드·robots.txt·접속 상태 순서대로 점검
사이트가 브라우저에서 열리는데도 애드센스가 찾지 못한다면, 단순히 코드를 다시 붙이는 것보다 실제 공개 HTML → 크롤러 허용 → 최종 HTTP 응답 → CDN·리디렉션 순서로 확인해야 원인을 빠르게 좁힐 수 있습니다.
핵심 요약
- 애드센스에 등록한 도메인과 실제 최종 접속 도메인이 일치하는지 먼저 확인합니다.
- 연결용 애드센스 코드 또는 메타 태그가 공개 페이지의
<head>영역에 실제로 출력되는지 확인합니다. robots.txt, 로그인, 점검 페이지, 봇 차단, 국가 차단이 애드센스 크롤러를 막지 않아야 합니다.- 홈페이지와
/robots.txt의 최종 응답을 확인하고, 403·404·5xx·리디렉션 루프를 해결합니다. - ‘사이트를 찾을 수 없음’과 ‘ads.txt 찾을 수 없음’은 별도 상태이므로 혼동하지 않습니다.
1. ‘사이트를 찾을 수 없음’은 정확히 어떤 문제인가요?
이 메시지는 대체로 애드센스가 등록된 사이트에 접근하지 못했거나, 사이트 소유권을 확인할 코드·메타 태그·ads.txt를 공개 페이지에서 확인하지 못했을 때 나타납니다. Google은 사이트 URL이 정확한지, 사이트가 실제로 게시되어 있는지, 비밀번호 없이 접근 가능한지, 애드센스 크롤러가 robots.txt에 의해 차단되지 않는지 확인하도록 안내합니다.
여기서 가장 중요한 구분은 사이트 연결 오류와 ads.txt 상태 오류입니다. 애드센스 ‘사이트’ 메뉴에는 승인 상태와 ads.txt 상태가 따로 표시되므로, 같은 ‘찾을 수 없음’이라는 표현이 보여도 점검 대상이 다를 수 있습니다.
| 표시 상태 | 주요 의미 | 우선 점검 |
|---|---|---|
| 사이트를 찾을 수 없음·접속 불가 | 사이트 페이지 또는 확인 수단에 접근하지 못함 | 등록 URL, 코드, 공개 접속, robots.txt, 방화벽 |
| ads.txt 찾을 수 없음 | 루트 도메인의 ads.txt 파일을 마지막 크롤링에서 찾지 못함 | /ads.txt 위치, 200 응답, 게시자 ID, HTTP·HTTPS 리디렉션 |
| 준비 중 | 사이트 검토가 진행 중이거나 다른 계정 설정 작업이 남아 있음 | 애드센스 홈의 필수 작업과 사이트 상태 |
바로 확인할 위치
애드센스 계정의 사이트 메뉴에서 해당 도메인을 열고, 승인 상태와 ads.txt 상태를 각각 확인하세요. Google의 애드센스 사이트 상태 설명과 화면 문구를 대조하면 점검 범위를 줄일 수 있습니다.
2. 가장 빠른 해결 순서는 어떻게 되나요?
원인을 한꺼번에 추측하기보다, 외부에서 확인 가능한 항목부터 안쪽 설정으로 이동하는 것이 효율적입니다. 아래 순서는 코드 문제, 서버 문제, 크롤러 차단을 서로 분리해 확인하도록 구성했습니다.
1단계 · 등록 주소와 최종 주소 비교
애드센스에 추가한 도메인, 브라우저 주소창의 최종 도메인, 사이트의 대표 주소가 같은지 확인합니다. 오타, 예전 도메인, 잘못된 하위 도메인이면 잘못된 사이트를 삭제하고 올바른 주소를 추가해야 합니다.
2단계 · 시크릿 창과 외부 네트워크에서 접속
로그아웃·시크릿 창에서 홈페이지와 주요 글이 열리는지 확인합니다. 관리자 로그인 상태에서만 정상으로 보이거나, 특정 국가·통신사·봇에만 403이 발생하면 애드센스도 접근하지 못할 수 있습니다.
3단계 · 공개 원본 소스에서 코드 확인
페이지에서 ‘소스 보기’를 열어 게시자 ID와 연결 코드가 실제 HTML에 출력되는지 확인합니다. 테마 편집기에 저장했더라도 캐시·조건부 출력 때문에 공개 페이지에는 빠질 수 있습니다.
4단계 · robots.txt와 보안 장비 확인
Mediapartners-Google, Google-Display-Ads-Bot 또는 전체 크롤러가 차단되지 않았는지 확인하고, CDN·WAF의 봇 차단 로그도 함께 봅니다.
5단계 · 최종 HTTP 응답과 리디렉션 확인
최종 페이지가 200으로 끝나는지, 리디렉션이 반복되지 않는지, SSL·DNS·서버 오류가 없는지 확인합니다. 모든 수정이 공개 환경에 반영된 뒤 검토를 다시 요청합니다.
실무 팁
한 번에 여러 설정을 바꾸지 말고, 각 단계마다 ‘공개 페이지에서 확인 가능한 증거’를 남기세요. 예를 들어 코드 확인 화면, robots.txt 원문, 최종 상태 코드, CDN 방화벽 로그를 순서대로 저장하면 같은 오류가 반복될 때 원인을 비교하기 쉽습니다.
3. 애드센스 코드는 어디를 어떻게 확인해야 하나요?
사이트 연결용 애드센스 코드 스니펫은 페이지의 <head>와 </head> 사이에 들어가야 합니다. Google은 콘텐츠가 있고 실제로 방문되는 페이지에 코드를 배치하고, 사이트 확인에 실패하면 변경 사항이 게시되었는지와 애드센스 크롤러가 접근 가능한지를 확인하도록 안내합니다.
코드 편집기보다 ‘공개 원본 소스’를 기준으로 보세요
테마 편집기, 플러그인 설정, CMS 관리 화면에 코드가 저장된 것과 실제 방문자에게 전달되는 HTML은 다를 수 있습니다. 홈페이지에서 마우스 오른쪽 버튼의 ‘페이지 소스 보기’를 열고 ca-pub- 또는 google-adsense-account를 검색해 확인하세요.
<head>
<script async
src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-본인게시자ID"
crossorigin="anonymous"></script>
</head>주의사항
예시의 게시자 ID를 그대로 사용하면 안 됩니다. 애드센스 계정에서 복사한 본인 코드를 사용하고, 코드가 두 번 이상 중복 삽입되거나 동의 관리 도구가 승인 전까지 스크립트를 완전히 제거하는지도 확인해야 합니다.
| 점검 항목 | 정상 기준 | 자주 생기는 오류 |
|---|---|---|
| 코드 위치 | 공개 HTML의 head 영역 | 본문 위젯·푸터에만 삽입 |
| 게시자 ID | 애드센스 계정의 ca-pub 값과 일치 | 예시 ID, 다른 계정 ID, 일부 잘림 |
| 배포 상태 | 로그아웃·시크릿 창에서도 확인 | 관리자 미리보기에서만 출력 |
| 캐시 | 서버·플러그인·CDN 캐시 모두 갱신 | 이전 HTML이 계속 제공됨 |
Google 공식 애드센스 사이트 연결 절차 확인
정보 확인하기 →
4. robots.txt에서 무엇을 확인해야 하나요?
robots.txt는 크롤러가 어떤 URL에 접근할 수 있는지 알려주는 파일입니다. 사이트 루트의 https://도메인/robots.txt에서 열려야 하며, 사이트 전체 또는 애드센스 관련 크롤러를 막는 규칙이 있으면 연결·검토가 실패할 수 있습니다.
가장 먼저 찾을 차단 규칙
User-agent: * Disallow: / User-agent: Mediapartners-Google Disallow: / User-agent: Google-Display-Ads-Bot Disallow: /
위와 같은 사이트 전체 차단이 있다면 공개 콘텐츠를 검토할 수 없습니다. 단, robots.txt 전체를 무조건 비우기보다 관리자·검색 결과·개인 경로처럼 원래 차단해야 할 영역은 유지하고, 공개 글과 애드센스 확인 경로만 접근 가능하도록 조정하세요.
애드센스 크롤러 허용 예시
User-agent: Mediapartners-Google Disallow: User-agent: Google-Display-Ads-Bot Disallow:
빈 Disallow:는 해당 그룹에서 차단 경로가 없다는 뜻입니다. 다만 CMS·호스팅 환경마다 기본 robots.txt가 자동 생성될 수 있으므로, 저장 후 실제 루트 URL에서 새 내용이 보이는지 반드시 확인해야 합니다.
혼동하기 쉬운 점
noindex와 robots.txt는 역할이 다릅니다. robots.txt는 크롤링 접근을 제어하고, noindex는 접근한 페이지를 검색 색인에서 제외하도록 지시합니다. 애드센스 접속 문제를 해결하려고 무조건 noindex를 제거하기보다, 먼저 실제 크롤러 차단과 접속 상태를 확인하세요.
Google의 애드센스 크롤러 문제 해결 문서와 robots.txt 기본 안내를 함께 보면 광고 크롤러 문제와 검색 크롤링 설정을 구분하는 데 도움이 됩니다.
5. 사이트 접속 상태와 HTTP 응답은 어떻게 점검하나요?
사용자 브라우저에서 한 번 열린다는 사실만으로 항상 정상이라고 볼 수는 없습니다. 서버가 특정 사용자 에이전트, 국가, 요청 빈도에 따라 다른 응답을 내리거나, 홈페이지가 200처럼 보이지만 실제로는 긴 리디렉션 체인·간헐적 5xx·보안 챌린지를 거칠 수 있기 때문입니다.
최종 페이지가 정상 200으로 끝나는지 확인
curl -I https://example.com/
curl -L -o /dev/null -s -w "%{http_code} %{url_effective}\n" https://example.com/
curl -I https://example.com/robots.txt첫 요청이 301 또는 302여도 최종적으로 대표 HTTPS 주소의 200 응답으로 안정적으로 끝나면 일반적으로 정상적인 리디렉션입니다. 반대로 403은 방화벽·권한 차단, 404는 주소·파일 없음, 429는 과도한 요청 제한, 5xx는 서버·프록시 오류 가능성을 우선 의심할 수 있습니다.
| 신호 | 가능한 원인 | 확인할 곳 |
|---|---|---|
| 403 | WAF, 봇 차단, 국가 제한, 파일 권한 | CDN 보안 이벤트·서버 접근 로그 |
| 404 | 잘못된 등록 URL, 루트 파일 누락 | 도메인·경로·배포 파일 |
| 429 | 과도한 속도 제한 또는 봇 관리 | Rate Limit·Bot Fight 설정 |
| 5xx | 호스팅 장애, 애플리케이션 오류, 프록시 타임아웃 | 서버 오류 로그·호스팅 상태 |
| 리디렉션 반복 | HTTP/HTTPS·www 규칙 충돌 | 서버·CMS·CDN 리디렉션 규칙 |
Search Console 활용법
URL 검사에서 홈페이지와 대표 글을 ‘실제 URL 테스트’해 크롤링 가능 여부와 페이지 리소스 문제를 확인하세요. 다만 이 결과는 Google 검색 기준의 진단이므로 애드센스 전용 크롤러 접근을 보장하지는 않습니다.
Search Console 실제 URL 테스트 사용법
정보 확인하기 →
6. CDN·방화벽·리디렉션·CMS에서 자주 막히는 지점은 무엇인가요?
코드와 robots.txt가 정상인데도 오류가 반복되면, 사이트 앞단의 CDN·WAF·호스팅 보안 기능을 확인해야 합니다. 특히 자동 봇 차단, 자바스크립트 챌린지, 국가별 접속 제한, 과도한 속도 제한은 일반 사용자는 통과하지만 크롤러에는 403 또는 429를 반환할 수 있습니다.
| 환경 | 자주 발생하는 원인 | 해결 방향 |
|---|---|---|
| CDN·WAF | Bot challenge, 국가 차단, Rate Limit | 보안 이벤트에서 차단 요청을 확인하고 공개 페이지의 과도한 규칙을 완화 |
| WordPress | 유지보수 모드, 캐시, 보안 플러그인, 테마 head 훅 누락 | 미리보기 대신 공개 소스 확인, 캐시 전체 삭제, 보안 로그 확인 |
| 티스토리·호스팅형 CMS | 스킨 저장 미반영, 개인 도메인 전환, 플랫폼 관리 robots.txt | 대표 도메인과 공개 HTML 확인, 플랫폼 공식 연결 방식 사용 |
| 리디렉션 | www·non-www, HTTP·HTTPS 규칙 충돌 | 대표 URL 하나로 단순하게 통합하고 최종 200 확인 |
| 도메인·DNS | 만료, 잘못된 레코드, IPv6 경로 오류, 전파 지연 | A·AAAA·CNAME과 인증서, 외부 지역 접속을 함께 검사 |
로그에서 확인할 핵심 항목
- 애드센스 검토를 요청한 시점 전후에 403·429·5xx가 증가했는지
- 홈페이지, 대표 글, robots.txt가 서로 다른 보안 규칙을 적용받는지
- 로그인 쿠키가 없는 요청에만 유지보수 페이지 또는 빈 화면이 제공되는지
- IPv4에서는 정상인데 IPv6 경로에서만 실패하는지
- 자바스크립트를 실행해야만 본문이 나타나고 초기 HTML에는 콘텐츠가 거의 없는지
보안 설정을 전부 끄지는 마세요
문제 해결을 위해 사이트 전체 보안을 장기간 해제하는 방식은 권장하기 어렵습니다. 먼저 차단 로그로 원인을 확인한 뒤, 공개 콘텐츠와 필요한 Google 크롤러에 한해 최소 범위로 예외를 적용하고 다시 테스트하세요.
7. 수정 후 재검토 전 무엇을 최종 확인해야 하나요?
재검토는 ‘설정을 바꿨다’가 아니라 ‘외부에서 정상 결과를 확인했다’는 상태에서 요청해야 합니다. 캐시가 남아 있거나 DNS·리디렉션 변경이 일부 지역에만 반영된 상태라면 같은 문제가 다시 감지될 수 있습니다.
재검토 전 체크리스트
- □ 애드센스 사이트 목록의 도메인 철자와 실제 대표 도메인이 일치한다.
- □ 로그인하지 않은 시크릿 창에서 홈페이지와 대표 글이 열린다.
- □ 공개 원본 소스에 올바른 ca-pub 코드 또는 확인 메타 태그가 있다.
- □ robots.txt가 루트에서 열리고 애드센스 크롤러를 차단하지 않는다.
- □ 홈페이지의 최종 응답이 200이며 리디렉션 루프가 없다.
- □ CDN·WAF 로그에서 403·429 차단이 발견되지 않는다.
- □ 서버·플러그인·CDN 캐시를 삭제한 뒤 다시 확인했다.
- □ ads.txt 오류가 별도로 있다면 /ads.txt의 위치·200 응답·게시자 ID를 따로 확인했다.
Google은 사이트 검토가 일반적으로 며칠 내에 끝나지만 경우에 따라 2~4주가 걸릴 수 있다고 안내합니다. 또한 사이트를 삭제했다가 다시 제출하면 처리가 지연될 수 있으므로, 등록 URL 자체가 틀린 경우가 아니라면 불필요한 삭제·재추가보다 원인 수정과 정상 접속 확인을 우선하세요.
마무리 요약
애드센스 ‘사이트를 찾을 수 없음’은 코드 한 줄만의 문제가 아니라, 등록 주소·공개 HTML·크롤러 권한·서버 응답·보안 설정이 연결된 문제입니다. 가장 빠른 해결법은 공개 페이지에서 코드가 보이는지 확인한 뒤 robots.txt와 403·404·5xx·리디렉션을 순서대로 점검하는 것입니다.
모든 항목을 실제 외부 환경에서 확인한 다음 재검토를 요청하고, ads.txt 상태는 사이트 연결 오류와 분리해 관리하세요. 공식 도움말의 문구나 크롤러 정책은 바뀔 수 있으므로 마지막 단계에서 최신 안내를 다시 확인하는 것이 안전합니다.
8. 애드센스 사이트 연결 오류 FAQ
Q. 애드센스 코드가 보이는데도 사이트를 찾을 수 없다고 나오는 이유는 무엇인가요?
브라우저 화면에 코드가 보이는 것만으로는 충분하지 않습니다. 실제 공개 페이지의 원본 소스에 올바른 게시자 ID가 포함되어야 하고, 애드센스 크롤러가 로그인·방화벽·robots.txt 차단 없이 그 페이지에 접근할 수 있어야 합니다. 캐시된 이전 HTML이나 관리자 미리보기에서만 코드가 보이는 경우도 함께 확인해야 합니다.
Q. robots.txt 파일이 없으면 애드센스 연결에 문제가 되나요?
robots.txt가 반드시 있어야 애드센스 연결이 되는 것은 아닙니다. 다만 파일이 있다면 Mediapartners-Google, Google-Display-Ads-Bot 또는 전체 사용자 에이전트에 대해 사이트 전체를 차단하는 규칙이 없는지 확인해야 합니다. 잘못된 규칙을 추가하는 것보다 필요한 공개 경로만 허용하는 편이 안전합니다.
Q. Search Console 실시간 URL 테스트가 성공하면 애드센스도 반드시 접속할 수 있나요?
반드시 그렇지는 않습니다. Search Console 실시간 테스트는 Google 검색 크롤링 가능성을 확인하는 데 유용하지만, 애드센스 검토 크롤러와 네트워크 조건을 완전히 재현하지는 않습니다. 따라서 테스트 성공 후에도 애드센스 코드, 전용 크롤러 차단, CDN 보안 규칙을 별도로 확인해야 합니다.
Q. 사이트 수정 후 바로 다시 검토를 요청해도 되나요?
코드와 접속 문제를 실제 공개 환경에서 확인한 뒤 다시 검토를 요청하는 것이 좋습니다. 수정이 배포되지 않았거나 캐시가 남은 상태에서 반복 제출하면 같은 문제가 다시 감지될 수 있습니다. 사이트를 삭제하고 다시 추가하는 행동은 처리 지연 요인이 될 수 있으므로 URL 자체가 틀린 경우가 아니라면 신중해야 합니다.
Q. ‘사이트를 찾을 수 없음’과 ‘ads.txt 찾을 수 없음’은 같은 오류인가요?
서로 다른 상태입니다. ‘사이트를 찾을 수 없음’은 사이트 연결·검토 단계에서 페이지 또는 확인 수단에 접근하지 못하는 문제에 가깝고, ‘ads.txt 찾을 수 없음’은 루트 도메인의 ads.txt 파일을 찾지 못했다는 의미입니다. 두 상태가 함께 나타날 수는 있지만 코드와 사이트 접속부터 확인한 뒤 ads.txt를 별도로 점검해야 합니다.
참고 자료·업데이트 확인처
