Cloudflare Pages 배포 후 꼭 확인하는 체크리스트

처음 Cloudflare Pages 배포 화면을 봤을 때 제일 헷갈린 건 배포 성공 표시였습니다. 화면에는 성공처럼 보이는데, 실제 블로그 주소를 열어보면 제가 기대한 상태와 조금씩 달랐습니다.

Daejin Lab은 Astro로 만든 정적 블로그라 구조는 단순합니다. 그런데 단순한 사이트도 배포 뒤 확인을 대충 하면 Search Console, sitemap, canonical 쪽에서 나중에 다시 돌아오게 됩니다. 저도 그 과정을 한 번 겪고 나서야 배포 후 체크 순서를 따로 적어두기 시작했습니다.

처음에 헷갈린 부분

Cloudflare 안에서는 Workers와 Pages가 가까이 붙어 있습니다. 처음에는 둘 다 “배포”라는 말이 붙어 있어서, 제가 지금 어디에 올리고 있는지 한 번 더 확인해야 했습니다.

Daejin Lab 기준으로는 Workers가 아니라 Pages 배포입니다.

Framework preset: Astro
Build command: npm run build
Output directory: dist
Node version: 22 계열
Root directory: 비워두기

이 값은 한 번 맞춰두면 자주 바꾸지 않습니다. 특히 Root directory는 괜히 건드리면 Cloudflare가 엉뚱한 위치에서 빌드를 찾을 수 있습니다. 저는 이 부분을 고정값으로 두고, 문제가 생기면 먼저 글이나 설정 파일 쪽을 봅니다.

push 전에 로컬에서 먼저 본 것

배포 문제를 Cloudflare에서 바로 찾기 전에, 먼저 제 노트북에서 빌드가 되는지 봤습니다.

npm run build

글만 고쳤는데도 빌드가 깨질 수 있습니다. frontmatter에 따옴표가 빠졌거나, 이미지 경로가 틀렸거나, Markdown 안에 예상 못 한 문자가 들어가면 정적 사이트는 생각보다 쉽게 멈춥니다.

그래서 지금은 글을 고친 뒤 바로 push하지 않고, 로컬에서 한 번 빌드를 통과시킨 뒤에만 다음 단계로 갑니다. 귀찮아 보여도 이게 제일 덜 돌아가는 길이었습니다.

배포 후 바로 열어본 주소들

Cloudflare에서 성공 표시가 뜨면 끝이 아닙니다. 저는 최소한 아래 주소를 직접 열어봅니다.

/
/blog/
/categories/
/about/
/sitemap.xml
/sitemap-index.xml
/robots.txt

새 글을 추가했다면 새 글 URL도 따로 엽니다.

/blog/새-글-slug/

지금 Daejin Lab의 기준 도메인은 https://daejinlab.com입니다. 예전에는 pages.dev 주소를 기준으로 확인하던 시기도 있었지만, 커스텀 도메인을 붙인 뒤에는 최종 판단을 운영 도메인으로 맞췄습니다.

여기서 중요한 건 “페이지가 열린다”와 “검색엔진 기준도 맞다”가 다르다는 점입니다. 페이지는 열리는데 canonical이 예전 도메인을 가리키면 나중에 또 Search Console에서 찝찝한 상태가 됩니다.

sitemap 숫자는 외우지 않기로 했다

초반에는 글이 30개일 때 sitemap URL 수가 42개인지 확인했습니다. 그때는 숫자가 딱 맞아야 마음이 놓였습니다.

그런데 글을 계속 추가하고 필수 페이지도 늘리다 보니, 특정 숫자를 외우는 방식은 금방 낡았습니다. 지금은 숫자 자체보다 흐름을 봅니다.

글을 추가했다
→ sitemap URL 수가 자연스럽게 늘었다
→ 새 글 URL이 sitemap에 들어갔다
→ sitemap 안 URL이 200으로 열린다

이렇게 보는 편이 더 안전했습니다. 숫자를 외워두면 오히려 예전 기준에 끌려갈 수 있습니다.

화면보다 HTML head를 더 믿는다

배포 뒤 브라우저 화면만 보면 놓치는 값이 있습니다. 특히 블로그 수익화와 검색 노출을 생각하면 HTML head 쪽을 같이 봐야 합니다.

canonical URL
meta description
Search Console verification meta
noindex 여부
OG title과 description

Search Console 인증 태그는 화면에 보이지 않습니다. noindex도 마찬가지입니다. 그래서 대표 글 하나는 HTML을 직접 확인합니다. 사람이 보는 화면은 멀쩡한데, 검색엔진에게는 다른 신호를 주고 있을 수 있기 때문입니다.

문제가 생겼을 때 제가 보는 순서

예전에는 문제가 생기면 Cloudflare 캐시부터 의심했습니다. 그런데 몇 번 해보니 순서를 정해두는 편이 낫습니다.

1. GitHub에 최신 commit이 올라갔는가?
2. Cloudflare가 그 commit으로 배포했는가?
3. npm run build가 로컬에서 성공하는가?
4. dist 안에 원하는 파일이 생겼는가?
5. 공개 URL이 운영 도메인에서 열리는가?
6. sitemap에 새 글이 들어갔는가?
7. canonical이 운영 도메인을 가리키는가?

이 순서가 있으면 추측이 줄어듭니다. 특히 “방금 고친 게 반영이 안 됐다”는 느낌이 들 때, Cloudflare가 실제로 어느 commit을 배포했는지 먼저 보는 게 도움이 됐습니다.

배포 직후에는 조금 기다린다

Cloudflare Pages는 push 직후에 바로 최신 상태가 보이지 않을 때가 있습니다. sitemap도 마찬가지였습니다. 처음 확인했을 때는 이전 값처럼 보이다가, 조금 뒤 다시 보니 정상으로 바뀐 적이 있습니다.

그래서 배포 직후에는 한 번 보고 바로 실패로 판단하지 않습니다. 같은 URL을 몇 번 더 확인합니다.

curl -I https://daejinlab.com/sitemap.xml
curl https://daejinlab.com/sitemap.xml | grep -c '<url>'

Search Console 화면은 더 느립니다. 공개 파일이 정상이어도 Google 쪽 상태가 바로 바뀌지 않을 수 있습니다. 이때 파일을 계속 고치기 시작하면, 오히려 원인을 더 흐릴 수 있었습니다.

같이 열어두는 글

이 체크리스트만 따로 보면 배포 확인에 가깝습니다. 검색엔진까지 생각하면 아래 글을 같이 보는 편이 좋았습니다.

Cloudflare Pages 배포 후 공개 확인 기록은 실제 배포 뒤 공개 페이지를 다시 본 흐름입니다.
Search Console sitemap 가져올 수 없음 대응 기록은 파일은 정상인데 Google 화면만 늦는 상황을 다뤘습니다.
robots, canonical, index 상태 확인 기록은 검색 노출 관련 HTML head 값을 보는 기준입니다.

지금 제 운영 기준

지금은 배포를 이렇게 봅니다.

npm run build
→ git push
→ Cloudflare가 최신 commit을 배포했는지 확인
→ 운영 도메인 공개 URL 확인
→ sitemap과 robots 확인
→ 대표 글 canonical 확인

Daejin Lab은 아직 작은 블로그지만, 이 루틴을 만들어두니 글을 늘릴 때 덜 불안했습니다. 배포 성공 표시만 믿지 않고, 실제 공개 상태와 검색엔진이 보는 신호를 분리해서 보는 것. 지금은 그게 제 기준입니다.

PR이나 main push 뒤 framework, build, 검증 항목, 운영 도메인 URL 확인으로 이어지는 Cloudflare Pages 배포 게이트 시퀀스

이 카드는 검증 항목을 빌드 단계와 공개 확인 단계로 분리하는 배포 게이트 시퀀스입니다.

초록색 배포 표시만 믿지 않기로 했다

Cloudflare Pages에서 성공 표시가 떠도 마음이 바로 놓이지는 않았습니다. 실제 주소에서 예전 화면이 보이거나, sitemap은 늦게 바뀌거나, canonical이 예상과 다를 수 있었습니다. 그래서 지금은 배포 성공 화면보다 공개 URL을 직접 여는 쪽을 더 믿습니다.

2026-05-31에 다시 본 배포 체크리스트

Cloudflare Pages 배포 체크리스트는 처음에는 기술 확인 목록이었습니다. 하지만 AdSense 재검토 관점에서는 공개 사이트가 안정적으로 보이는지 확인하는 신뢰 장치이기도 합니다. 그래서 build 성공, 도메인, sitemap, RSS, 글 상세 페이지를 분리해서 보는 기준을 더 분명히 했습니다.

build, domain, sitemap, live 확인으로 이어지는 Cloudflare Pages 배포 체크리스트 카드

이 카드는 Cloudflare 화면보다 실제 공개 표면을 확인하는 배포 체크리스트입니다.

참고한 공식 문서

확인하지 않은 것

이 글은 Cloudflare 계정 화면의 모든 설정을 공개하지 않습니다. 계정 ID, 프로젝트 내부 설정, 빌링 정보는 공개하지 않고, 외부에서 확인 가능한 URL과 build 결과 중심으로 남깁니다.

FAQ

배포 체크리스트에서 가장 중요한 것은 무엇인가요?

로컬 build, 실제 URL, sitemap/RSS, 이미지 경로입니다. 하나만 보면 부족합니다.

Cloudflare 배포 성공이면 Search Console도 바로 정상인가요?

아닙니다. 배포와 색인은 다른 단계입니다. 배포 후 sitemap과 URL 상태를 따로 확인해야 합니다.

draft 노출, review 페이지, 깨진 이미지, staging domain, 얇은 글 목록처럼 보이는지를 함께 봅니다.