Cloudflare Pages는 GitHub와 연결하면 배포가 편합니다. 하지만 배포가 끝났다는 표시만 보고 바로 끝내면 안 됩니다.

Daejin Lab을 만들면서 느낀 것은, 배포 후 확인할 항목을 고정해두는 것이 중요하다는 점입니다.

기본 배포 설정

현재 Daejin Lab의 Cloudflare Pages 설정은 아래 기준입니다.

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

중요한 점은 Workers 배포가 아니라 Pages 배포라는 것입니다. Cloudflare 화면에서 Workers와 Pages가 가까이 있어 처음에는 헷갈리기 쉽습니다.

로컬에서 먼저 확인할 것

GitHub에 push하기 전에 먼저 로컬 빌드를 확인합니다.

npm run build

이 명령이 실패하면 Cloudflare에서도 실패할 가능성이 큽니다. 글만 추가했더라도 frontmatter 형식이 틀리면 빌드가 깨질 수 있습니다.

배포 후 확인할 URL

배포가 끝나면 아래 주소를 확인합니다.

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

글을 추가했다면 새 글 URL도 직접 열어봅니다.

/blog/새-글-slug/

Daejin Lab에서는 글을 15개까지 늘린 뒤 /blog/의 글 개수와 sitemap URL 개수를 함께 확인했습니다.

자주 놓치기 쉬운 것

배포 후에는 화면만 보는 것이 아니라 HTML head 쪽도 중요합니다.

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

특히 Search Console 인증 태그는 화면에 보이지 않기 때문에 HTML에서 직접 확인해야 합니다.

문제가 생겼을 때 보는 순서

Cloudflare Pages 배포가 기대와 다르면 아래 순서로 확인합니다.

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

이 순서를 정해두면 문제를 추측으로 보지 않아도 됩니다.

결론

Cloudflare Pages는 개인 정적 블로그 운영에 편하지만, 배포 후 검증 루틴이 있어야 안정적입니다.

Daejin Lab에서는 npm run build → git push → 공개 URL 확인 → sitemap 확인을 기본 루틴으로 잡았습니다. 이 흐름을 1호 블로그에서 안정화하면 나중에 다른 블로그에도 그대로 복제할 수 있습니다.