사이트 접근성 확인
대표 도메인 `https://emfls.com`으로 접속했을 때 홈이 열리고, 주요 메뉴와 푸터 링크가 모두 작동해야 합니다. `pages.dev` 임시 주소가 아니라 실제 신청 도메인 기준으로 확인하는 것이 중요합니다.
HTTPS 인증서가 활성화되어 있고, 모바일 화면에서 메뉴와 본문이 겹치지 않아야 합니다. 심사자는 데스크톱만 보는 것이 아니므로 작은 화면에서도 글을 읽을 수 있어야 합니다.
필수 신뢰 페이지
소개, 문의, 개인정보처리방침, 이용약관, 면책 고지, 편집 정책, 콘텐츠 작성 기준은 사이트가 누가 어떤 기준으로 운영되는지 보여주는 장치입니다. 이 페이지들이 푸터나 사이트맵에서 접근 가능해야 합니다.
문의 이메일은 실제 수신 가능한 주소여야 하며, 개인정보처리방침은 문의 이메일, 광고 스크립트, 외부 서비스 사용 가능성을 실제 운영 방식에 맞게 설명해야 합니다.
콘텐츠 품질 확인
짧은 설명만 있는 글은 낮은 가치 콘텐츠로 보일 수 있습니다. 각 글에는 실제 예시, 흔한 실수, 점검표, FAQ, 공식 출처, 관련 글 링크가 포함되어야 합니다.
AI 생성 흔적을 줄이려면 일반론을 반복하기보다 실제 사이트 운영 중 겪는 상황을 구체적으로 설명해야 합니다. 예를 들어 Cloudflare 네임서버 변경, Search Console 사이트맵 오류, AdSense 확인 코드 배포 지연 같은 맥락이 도움이 됩니다.
정책 위험 제거
광고 클릭 유도 문구, 트래픽 구매, 자동 새로고침, 저작권 침해 자료, 불법 다운로드, 성인·도박·혐오 콘텐츠는 심사 전 반드시 제거해야 합니다.
광고가 들어갈 자리도 콘텐츠와 혼동되면 안 됩니다. 승인 전에는 광고 배치보다 콘텐츠와 신뢰 페이지를 먼저 완성하는 것이 안전합니다.
심사 직전 emfls.com에서 확인한 기준
이 사이트는 AdSense 확인 코드를 공통 head에 넣고, Cloudflare Pages 배포가 끝난 뒤 확인을 진행하는 흐름으로 구성했습니다. 코드가 저장소에 들어갔더라도 실제 배포가 끝나기 전에는 AdSense가 확인하지 못할 수 있습니다.
또한 소개, 문의, 개인정보처리방침, 편집 정책, 작성 기준, 면책 고지를 푸터와 사이트맵에서 접근 가능하게 배치했습니다. 심사자는 한 페이지가 아니라 사이트 전체 완성도를 볼 수 있기 때문입니다.
준비할 스크린샷
AdSense 확인 코드 화면, 실제 HTML head에 코드가 들어간 화면, Cloudflare Pages 최신 배포 성공 화면을 함께 보관합니다.
실전 점검표
- 대표 도메인 HTTPS 접속이 정상인지 확인한다.
- AdSense 코드가 최신 배포 HTML head에 들어갔는지 확인한다.
- 정책/신뢰 페이지가 푸터에서 접근 가능한지 확인한다.
- 글마다 고유한 예시, FAQ, 출처가 있는지 확인한다.
- Search Console에 XML 사이트맵을 제출한다.
흔한 실수
- 광고 코드만 넣고 콘텐츠와 정책 페이지를 보강하지 않는 것.
- 임시 배포 주소와 심사 도메인을 섞어 쓰는 것.
- 짧은 글을 많이 만들어 콘텐츠 수만 늘리는 것.
자주 묻는 질문
AdSense 신청 후에도 글을 수정해도 되나요?
가능합니다. 심사 중에는 사이트 안정성을 유지하면서 품질 보강, 오타 수정, 내부 링크 개선 위주로 수정하는 것이 좋습니다.
승인 전 광고 자리를 만들어야 하나요?
필수는 아닙니다. 승인 전에는 광고 배치보다 콘텐츠 품질과 사이트 신뢰도를 먼저 갖추는 것이 안전합니다.
Search Console 색인이 부족하면 무조건 거절되나요?
무조건은 아니지만, 주요 페이지 접근과 사이트맵 제출은 심사 전 기본 점검으로 처리하는 것이 좋습니다.