[구글 샌드박스] 블로그스팟 + 도메인 + 클라우드플레어 샌드박스 기록

목적: 구글 샌드박스 기간의 기록

블로그 개설 후 ~ 샌드박스 탈출 기간의 기록을 남겨 나중에 확인하기 쉽게 하려는 목적으로 기록해요. 그래서 자세히 적기보다는 리스트 형태로 주르륵 나열하는 방식을 쓸 거예요.

조건은 다음과 같아요.

• 플랫폼: 블로그스팟
• 도메인: Yes (신생)
• 프록시: Yes (CF)
• 인증서: Let's Encrypt (CF)
• TLS: 1.3 (최소 1.2)
• 암호화: Full (Strict)
• 콘텐츠: 예전 글 최신화 + 새 글
• html 캐시: 사용 (기기별)

2026-05

• 2026-05-07: 구글 서치콘솔 등록. 사이트맵 제출.
• 2026-05-09: 색인 시작. SERP 정상 노출.
• 2026-05-29: Alley 카테고리 글 작성. 외부 미디어 서버 CORS 문제 글 작성 후. (6번째 글)

2026-06

• 2026-06-02: 색인 배제 시작. 홈페이지 외 모든 글 '크롤링됨 - 현재 색인이 생성되지 않음' 상태로 변경.
  

  

• 2026-06-12: 네이버, 다음, 빙에 블로그 등록 및 사이트맵 제출. 수집, 색인 시작.
• 2026-06-13: Alley 카테고리 글 비공개 및 삭제 요청.
• 2026-06-25: 홈페이지 색인 요청. (글 8 -> 7개)

2026-07

• 2026-07-04: 홈페이지 제외 모든 post가 '리디렉션 오류' 항목으로 이동. -> 유효성 검사 요청.
• 2026-07-06: 홈페이지 색인 요청. 사이트맵, RSS 다시 제출. (글 9개)
• 2026-07-11: Cloudflare 크롤러 힌트 활성 후 post 강제 업데이트. 리디렉션 유효성 검사 실패.
• 2026-07-12: 홈페이지 색인 요청. (글 11개)
• 2026-07-13: Cloudflare WAF 사용자 설정으로 악성 봇 차단. 샌드박스 기록 업로드. (글 12개)
• 2026-07-14: 아래의 이유로 블로그스팟 'HTTPS 리디렉션' 비활성.
  • CF 설정과 중복
  • GSC 리디렉션 오류 잦음
  • https 주소로 요청했지만 혹시나
• 2026-07-15: 크롤러 힌트 적용 후,
  • 예약글 공개 2분 후 구글 IP에서 이미지에 접근
  • 33초간 4개의 이미지에 62번의 요청
  • 그러나 이름없는 봇이며,
  • 글 자체인 html에는 접근하지 않아 수동 색인 요청
  • 글 공개 1시간 20분 후 GSC에서 URL검사 -> 크롤링 기록 없음
  • 수동 요청 두시간 후 URL 재 검사 시 '페이지 가져오기 - 실패: 리디렉션 오류' 표시
  • HTTPS 리디렉션 중복은 GSC '리디렉션 오류'의 원인이 아니었음
  • CF 에지 캐시 '장치 유형별 캐시' 비활성 후 수동 색인 요청.
• 2026-07-16: 본문 하단 저작권 문구 수정. 일부 글 PC 쿼리 강제 색인 요청 -> 리디렉션 오류 없음.
• 2026-07-17:
  • JavaScript 캐시 워머 적용. 유휴 시간에 1 접속당 3 캐시. method: HEAD
  • CF html 캐시 헤더 max-age: 600 -> 300 조정
  • CF '장치 유형별 캐시' 재 활성. OFF 시 캐시 오염 발생
  • 홈페이지 색인 요청 (글 14개)
  • 모바일 접속 302 리디렉션을 CF가 가로채도록 설정
    

    

    • CF 에지 캐시 bypass 상태에서 비교
    • CF 서버와 블로그스팟 서버의 응답시간 차이 존재
    • CF 400ms 이내, Blogspot 1.5s 이내
    • 블로그스팟도 반복 접속하면 빨라지나, CF에 비해서 느린 경향성
    • CF 역시 에지 서버가 외국으로 연결되면 다소 느려질 것으로 예상
• 2026-07-18: 캐시워머 변경
  • 인라인 JS -> Google Apps Script(GAS) 크론
  • 트리거 발동 시 목록의 기본, 모바일 주소 모두에 1바이트 GET 요청
  • 트리거 빈도 2 시간은 로그 파일 상, 출현 빈도 과다
  • -> 6시간으로 트리거 빈도 조정
  • GAS 콘솔 메시지 확인 결과, 블로그스팟 서버 요청 제한은 약 20Req/10s 정도로 추정
• 2026-07-19: 캐시워머 변경(추가)
  • Google Apps Script에서 UA 변경 불가 => 모바일 요청 불가능
    • 무작위 접속 위치라 원하는 CF 에지 서버에 캐시 요청 불가
    • 1 바이트 GET은 불완전 캐시 가능성 있다하여 일반적인 GET으로 변경
    • 문제는, GAS는 다운로드 중간 차단이 안되어 html 통짜로 받는 중
  • CF Workers로 User-Agent 변경하여 PC, 모바일 GET 요청하는 Cron 작업 등록
    • 그러나 클라우드플레어도 위치 지정하여 캐시 생성 불가
    • 현재 20 articles/batch, 3 batch/cycle로 적용. 총합 60 article 까지 캐시 워밍 가능
    • -> 미약하지만 트래픽 절감을 위해, body.cancel()로 html 본체 다운로드 차단
    • -> CF Workers Cron 작업 시 실제 실행 시간 제한 때문에 쪼개기 사용
    • -> waitUntil: 30초 제한은 fetch, scheduled는 최대 15분이나, 테스트 문제로 차후 적용
    • 요청은 더 제한됨. 50 subreq / req.
    • -> 글 14개 * 2 + 사이트맵 1개 = 29 subreq.
    • -> 현재 PC/Mobile 이중 요청 필요 상황에서 무료 요금제 제한이 더 크게 느껴짐
  • JS 캐시 워머 다시 추가
    • 수동 실행으로, 필요시에만 JS 캐시 워머 동작
    • 대신, 실행하면 1초 간격으로 모든 글을 요청
    • User-Agent는 데스크탑/모바일 변형 모두 사용
    • 최소한 한국에서만이라도 캐시 적중률 높일 수 있게 세팅
  • 구글 서치 콘솔 '리디렉션 오류' 유효성 검사 요청
• 2026-07-20: html 파일 stale-while-revalidate 기간 86400(1일) -> 604800(7일)로 변경. max-age는 유지
• 2026-07-22: 캐시워머 조정
  • Google Apps Script(GAS) + Cloudflare(CF) Workers + Cloudflare Queues의 세가지 방법 테스트 중
  • -> 캐시워머가 셋이나 되어 각 하루 1회로 트리거 빈도 조정
  • -> GAS: PC 페이지, Workers: PC + Mobile 페이지, Queues: Mobile 페이지
  • -> 모바일 기기가 일반 페이지 접속 시 302 응답 캐시해야하나, CF 리디렉션 룰로 대체
  • Queues 하루 제한량은 무료 플랜 기준 1만 작업. 그러나 메시지(요청) 1회에 쓰기 -> 읽기 -> 지우기 총 3회 작업 필요
  • -> 즉, 실제 발송 가능한 메시지(요청)은 대략적으로 하루 3333개 라고 볼 수 있으나, 전송 실패 및 재 전송 감안하면 3000개 이하로 생각. 보수적으로는 2천여개 정도로 가늠
  • -> 메시지 1개의 body에 64kB 까지 보낼 수 있으니 여러 url을 한번에 전송하면 제한 극복 가능
  • -> 그 정도로 글이 많이 쌓였다면 캐시 워머 불필요할 것으로 생각됨
  • 일반 Workers 작업 시 CPU Time 제한으로 작업 쪼개기 필요
  • -> 현재의 1 batch 당 20개 글, 40개 요청보다 더 많이 쪼개는 것이 안전. 아마 요청 수 기준으로 20개 이하 쯤?
  • -> 이 경우 과도한 sitemap 읽기 요청 발생. 까딱하면 셀프 디도스 공격
  • -> sitemap 미리 파싱하고 저장 필요. KV 네임스페이스, JSON 파일 혹은...... 워커 코드 내, 글 목록 하드 코딩
  • -> Worker 쪼개기는 나중에 필요시 다시 생각하고 현재 테스트를 지켜보다 한가지로 정착 할 예정
• 2026-07-25: 홈페이지 색인요청. (글 15개)
• 2026-07-26:
  • 사이트맵 다시 제출
  • 각 글에 대해 ?m=1 붙여서 요청 -> 페이지 가져오기 성공. 리디렉션 오류 없음
• 2026-07-28: 리디렉션 오류 유효성 검사 실패

2026-08

• 2026-08-06:
  • Cloudflare 캐시 정책 수정
    • Client: max-age=300, stale-while-revalidate=86400
    • Edge: max-age=300, stale-while-revalidate=604800
    • 캐시 수명과 재검증 대기 기간을 각각 응답 헤더 변환 규칙, 캐시 응답 규칙으로 분리
  • 사이트맵 다시 제출
  • 홈페이지 색인 요청 (글 17개)
  • 서치콘솔 미세 변화
    • URL 검사에서 일부 페이지 "색인 생성 허용 여부: 예"로 변경
    • 느리지만 하나씩 봇 방문 이뤄지는 중
    • 변화가 있는 모든 글의 마지막 크롤링 일자 7월 15일
      • cf로 302 리디렉션 가로채기 설정한 것은 7월 17일
      • 즉, 서버 반응 느려도 괜찮음. 일단은 기다림이 답이라고 볼 수 있음
    • 해당 게시물은 "페이지 색인이 생성되지 않음: 리디렉션 오류" -> "크롤링 됨 - 현재 색인이 생성되지 않음" 상태로 변경
    • 구글이 보기에 가치 없는 글이라고 가정할 수 있음
  • 구글에서 검색 결과에 미세한 변화 존재
    • site 명령으로 검색 시 여전히 공백
    • 그러나 site를 떼고 주소만 검색하면 AI 요약이 나옴
    • 정확한 시기 모르나, 7월 상순까지는 AI 요약 없었음
    • 7월 중~하순에 변화 생긴 것으로 추정
  • 260806 현재까지의 종합 판단
    • 수년 전이었다면 이 정도 퀄리티와 수량에서 구글 SERP에 색인되고 소수의 방문자 정도는 있었을 것
    • 아마도 AI로 인한 영구적 변화가 아닐지 추측 중
    • AI 답변도 영향 있을 것이고, 스팸 차단 정책도 영향 있을 것으로 생각
    • 특히 스팸 차단하면서 세세한 판단 보다는 크롤링 자원 절약 위해 "일단" 광역차단을 가하는 것이 아닌지 의심
    • 그래서 무고한 사이트도 도메인 권위가 낮다는 죄로 함께 쓸려나간다고 추측 중

메모

크롤러 힌트에 대하여 (IndexNow)

구글, 빙 양쪽 모두 크롤러 힌트 켜도 신규 글 발행 즉시 크롤러가 방문하지는 않았어요. 신규 도메인은 한계가 있는 듯 하네요.

네이버, 다음은 크롤러 힌트 적용되는지 모르겠으나 크롤러 자동 방문은 없었어요. 다만, 수동 요청 시 10분 이내에 색인 완료되었고요. (네이버는 230725부터 IndexNow 지원)

의심스러운 부분

'크롤링됨 - 현재 색인이 생성되지 않음'은 글의 품질이 낮아 색인 가치가 없다고 가정할 수 있어요.

그러나 어느 순간 '리디렉션 오류'쪽으로 옮겨갔다면, 신규 도메인이라 크롤링 예산이 부족한 상태에서 모바일 쿼리가 붙은 ?m=1으로 강제 리디렉션하니 더이상 크롤링을 진행하지 않고 멈춘 것이 아닌지 의심돼요.

위 스크린샷은 2026-07-15 기준 24시간 동안의 크롤러 기록인데요, 보시다시피 Googlebot이 요청한 6번 모두 성공했어요. 실패가 없죠. 그래서 신규 도메인의 크롤링 예산 문제를 의심하고 있어요. (우측의 차단 버튼은 자동이니 신경쓰지 마세요)

가져간 데이터 용량을 봐선 홈페이지, 게시물 등의 웹페이지는 안 가져가고 딱 사이트맵, robots 파일 여러번에 RSS 한 번만 요청한 것이 아닌지 의심되기도 해요. 만약 그렇다면, 애초에 게시물에 접근하는 시늉조차 안 했다는 뜻이겠죠. 신규 도메인은 글을 너무 잘 써도 의심한다더니...

2026-07-15 기준 네트워크 전송량은 sitemap + robots가 약 2kb, rss가 9kb인데 게시물은 최소로 잡아도 20kb를 넘어요. 그러니 6번 요청에 59kb면 웹페이지 방문은 안 했거나 거의 없다고 보는 게 타당하겠어요.

캐시 워머에 대하여

2026년 7월 중순부터 일주일 쯤 캐시 워머를 사용하고 있는데, '과연 이게 효과가 있는가?' 여기에 대해선 확신이 서지 않네요.

캐시 워머의 각 url 요청이 주로 미국에서 발생하기 때문에, 구글 봇이 주로 출발하는 지역과 같은 상위 tier를 공유하여 효과가 없지는 않겠지만...

원하는 지역을 고정해서 캐시 워밍을 할 수 없으니 실제 효과에 대해서는 좀 의문이 들어요.

오히려 빙봇이나 미국에서 활동하는 다른 잡다한 봇들이 블로그의 url을 찔러보느라 캐시가 구워지는 게 더 효과적인 것도 같고요...

어차피 workers나 gas의 봇에 사용자가 지역을 정할 수 없다면, 차라리 무차별 스캔 봇을 적당히 캐시 워밍 용도로 써먹다가 요청이 과하다 싶으면 차단하는 게 더 이득일지도 모르겠어요.

아무튼 기왕 만들어둔 봇을 버리기는 아까우니... 무료 제한 아슬아슬할 때까진 써먹어야 겠죠.

관련글

• 클라우드플레어 WAF 사용자 지정 규칙으로 봇 차단하기
• 블로그스팟 모바일 URL ?m=1 간단 제거 방법

참고 자료

• Google: Always Use HTTPS, 원본과 중복일 경우 리디렉션 루프 위험.
• Google: Apps Script 개요
• CF: Crawler Hints, IndexNow 프로토콜 지원함.
• CF: Wall time limits, Cron 호출 시 최대 15분
• CF: Workers Limits, 무급 노동자는 50개 하위 요청, CPU Time 10ms 제한.
• CF: Runtime APIs: waitUntil
• CF: Queues 가격, 무료 플랜 쓰기, 읽기, 지우기 합산하여 하루 1만 작업 허용.
• Naver: 네이버도 IndexNow 지원 (2023-07-25)