Cloudflare Pages 배포 후 새 글이 실제로 반영됐는지 확인한 방법

Cloudflare Pages에서 배포가 끝났다고 떠도 바로 안심하기는 어려웠습니다. 실제 주소를 열었을 때 예전 글이 보이거나, sitemap 숫자가 바로 바뀌지 않는 순간이 있었기 때문입니다.

Daejin Lab을 운영하면서 배운 건 배포 성공과 공개 확인을 나눠서 봐야 한다는 점이었습니다. Cloudflare 화면은 한 단계고, 실제 독자와 검색엔진이 보는 화면은 또 다른 단계였습니다.

로컬에서 먼저 본 것

새 글을 추가하기 전후로 가장 먼저 보는 것은 git 상태와 빌드입니다.

git status --short
npm run build

Astro 블로그에서는 markdown frontmatter가 조금만 틀려도 빌드가 실패할 수 있습니다. 예를 들어 category 값은 정해진 목록 안에 있어야 하고, 이미지 경로도 실제 파일을 가리켜야 합니다.

Daejin Lab의 카테고리는 현재 아래 다섯 개만 사용합니다.

AI 도구
개발 자동화
로컬 LLM
블로그 운영
실전 기록

그래서 새 글을 추가할 때도 제목과 본문만 보지 않고, category와 tags가 기존 구조에 맞는지 먼저 확인합니다.

push 후 바로 믿지 않기

GitHub에 push했다고 해서 공개 사이트가 즉시 바뀌는 것은 아닙니다. Cloudflare Pages가 새 commit으로 빌드하고 배포하는 시간이 필요합니다.

그래서 push 후에는 아래를 순서대로 봅니다.

1. GitHub main의 commit SHA
2. 로컬 HEAD와 remote main 일치 여부
3. Cloudflare Pages 배포 완료 여부
4. 새 글 URL의 HTTP 200 여부
5. /blog/ 목록에 새 글 노출 여부
6. sitemap URL 수 변화

이 순서가 없으면 문제가 생겼을 때 어디서 막혔는지 구분하기 어렵습니다. 로컬에만 있는 글인지, GitHub에는 있지만 Cloudflare가 아직 배포하지 않았는지, 배포는 됐지만 sitemap 생성에서 빠졌는지 판단해야 합니다.

공개 URL에서 확인하는 항목

브라우저로 화면만 보는 것도 필요하지만, SEO 관점에서는 HTML 안쪽도 같이 봅니다.

Daejin Lab에서는 대표 글을 공개 URL로 열어 아래 항목을 봅니다.

HTTP status 200
canonical이 현재 production 도메인(`daejinlab.com`) 기준인지
meta robots가 index,follow인지
본문에 새 문구가 실제로 들어갔는지
OG title과 description이 과하게 비어 있지 않은지

특히 canonical은 중요합니다. 예전에 임시 도메인이나 다른 주소가 남아 있으면 Search Console에서 판단이 꼬일 수 있습니다. 그래서 robots.txt와 canonical을 점검하며 확인한 색인 기본 조건을 따로 정리해두었습니다.

sitemap은 숫자만 보지 않기

sitemap URL 수가 늘어나는 것은 좋은 신호지만, 숫자만으로는 부족합니다. XML이 실제로 파싱되는지, Googlebot User-Agent로도 접근되는지 함께 확인해야 합니다.

이번 블로그에서는 배포 후 sitemap을 볼 때 아래 기준을 사용했습니다.

/sitemap.xml 200 OK
Content-Type application/xml
XML 파싱 가능
Googlebot User-Agent 접근 가능
robots.txt에서 sitemap 선언

Search Console이 늦게 반영되더라도 공개 URL이 이 조건을 통과하면, 당장 sitemap 생성 방식을 더 바꾸지 않습니다. 이 기준은 Search Console에서 sitemap 가져올 수 없음이 뜰 때 확인한 것에서 더 자세히 정리했습니다.

새 글 발행 후 남기는 기록

운영 기록형 블로그에서는 배포 확인 자체도 콘텐츠가 될 수 있습니다. 단순히 “배포했다”가 아니라 아래처럼 남기면 나중에 같은 문제를 줄일 수 있습니다.

언제 새 글을 추가했는가
몇 개 글을 추가했는가
빌드가 성공했는가
sitemap URL 수가 어떻게 바뀌었는가
Search Console에서 어떤 상태였는가
추가로 수정하지 않기로 한 파일은 무엇인가

이런 기록은 AdSense 준비에도 도움이 된다고 봅니다. 사이트가 운영자 목소리 없는 글 묶음이 아니라, 실제로 점검하며 운영되는 블로그라는 신호가 되기 때문입니다.

Daejin Lab에서 정한 루틴

지금은 아래 루틴을 기본으로 삼고 있습니다.

1. markdown 글 작성
2. 내부 링크 2개 이상 확인
3. npm run build
4. git diff --check
5. 로컬 commit
6. push 직전 발행 게이트 확인
7. Cloudflare 배포 완료 후 공개 URL과 sitemap 확인
8. Search Console은 하루 요청량 안에서만 확인

git push와 Search Console 조작은 외부 반영이 걸리는 작업이라 자동으로 넘기지 않고, 사람이 한 번 더 확인하는 단계로 둡니다. 이 구분이 있어야 자동화가 편해지면서도 운영 사고를 줄일 수 있습니다.

이번 글의 결론

Cloudflare Pages는 개인 정적 블로그에 잘 맞지만, 발행 후 검증 루틴이 없으면 작은 오류를 놓치기 쉽습니다.

Daejin Lab에서는 새 글을 추가할 때마다 로컬 빌드, 공개 URL, canonical, sitemap을 함께 확인하기로 했습니다. 글을 많이 쓰는 것보다 중요한 것은 “새 글이 실제로 검색엔진이 읽을 수 있는 상태로 발행됐는지”를 확인하는 일입니다.

배포 뒤에 꼭 남기는 확인

지금은 새 글을 올린 뒤 공개 URL을 직접 열어보고, sitemap에 들어갔는지 확인합니다. 가능하면 대표 글의 canonical도 같이 봅니다.

이 확인을 하지 않으면 배포가 됐다고 생각하고 다음 작업으로 넘어가게 됩니다. 나중에 Search Console에서 이상한 상태를 보면 다시 돌아와야 합니다. 그래서 몇 분 더 쓰더라도, 배포 직후 확인은 루틴으로 남겨두기로 했습니다.

배포 후에 손이 한 번 더 간다

새 글을 올리고 나면 끝난 것 같지만, 제 기준에서는 그때부터 확인이 시작됩니다. 글 URL이 열리는지, 목록에 보이는지, sitemap에 들어갔는지까지 봐야 마음이 놓입니다. 이 확인이 귀찮아도, 나중에 Search Console에서 이상한 상태를 봤을 때 덜 흔들립니다.

2026-05-31에 다시 보강한 배포 확인선

새 글이 실제로 보이는지는 “push가 됐다”와 다릅니다. 이번 AdSense 보강을 하면서도 첫 라이브 확인에서 이미지가 늦게 올라오거나 CDN 반영이 지연될 수 있다는 점을 다시 봤습니다. 그래서 이 글은 Cloudflare Pages 사용법보다, 공개 반영을 어디까지 확인해야 하는지에 초점을 맞춥니다.

로컬 build, GitHub push, Cloudflare deploy, 라이브 URL과 RSS 확인으로 이어지는 배포 후 확인 루틴

이 카드는 배포 성공과 공개 확인을 분리한 흐름입니다. 실제 독자와 검색엔진이 보는 표면은 마지막 라이브 확인에서 봅니다.

Daejin Lab에서는 새 글을 올린 뒤 article URL만 보지 않습니다. /blog/ 목록, /sitemap.xml, /rss.xml, 이미지 경로, 브라우저 콘솔까지 같이 봅니다. 특히 AdSense 재검토 전에는 공개 글 수와 sitemap URL 수가 맞는지, draft나 review 페이지가 새어 나오지 않는지 확인하는 쪽이 더 중요했습니다.

참고한 공식 문서

Cloudflare 문서는 배포 전제, Google 문서는 sitemap의 역할, Astro 문서는 콘텐츠 빌드 구조를 확인하는 용도입니다. 이 글의 핵심은 도구 설명보다 “배포 뒤 무엇을 실제로 열어봤는가”입니다.

확인하지 않은 것

Cloudflare 내부 대시보드의 모든 상태를 자동으로 조작하거나 캡처하지는 않습니다. 계정 정보와 프로젝트 식별값이 들어갈 수 있기 때문입니다. 공개 글에는 실제 URL에서 확인 가능한 항목만 남깁니다.

FAQ

Cloudflare Pages에서 성공이면 끝 아닌가요?

아닙니다. 배포 성공은 한 단계입니다. 실제 URL, sitemap, RSS, 이미지 파일이 모두 반영됐는지 따로 봐야 합니다.

sitemap URL 수가 중요한 이유는 무엇인가요?

예상보다 많거나 적으면 draft, review, 누락 글이 섞였을 수 있습니다. AdSense 재검토 전에는 이 표면을 특히 조심해서 봅니다.

라이브 반영이 늦으면 어떻게 하나요?

처음부터 실패로 단정하지 않고 일정 간격으로 다시 확인합니다. 다만 끝까지 이미지나 글이 404면 배포 산출물과 경로를 다시 봅니다.