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 개수를 함께 확인했습니다. 이후 30개 글까지 확장한 뒤에는 sitemap URL 수가 42개로 늘었는지도 다시 봤습니다.

글 수: 30개
sitemap URL 수: 42개
대표 새 글 URL: 200 OK
카테고리 페이지: 200 OK

자주 놓치기 쉬운 것

배포 후에는 화면만 보는 것이 아니라 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는 push 직후에 바로 최신 파일이 보이지 않을 때가 있습니다. 이번에도 배포 직후 sitemap URL 수가 이전 값처럼 보이다가, 몇 번 더 확인하니 42개로 바뀌었습니다.

그래서 배포 직후에는 한 번만 보고 실패로 판단하지 않고, 아래처럼 같은 URL을 몇 차례 다시 확인하는 편이 안전했습니다.

curl -I https://daejin-lab-blog.pages.dev/sitemap.xml
curl https://daejin-lab-blog.pages.dev/sitemap.xml | grep -c '<url>'

Search Console 화면도 마찬가지입니다. 공개 URL이 정상이어도 Google 쪽 상태 표시는 몇 분에서 더 길게 늦을 수 있습니다.

결론

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

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