정적 블로그는 글 파일을 추가하고 push하면 끝나는 것처럼 보입니다. 하지만 실제 운영에서는 “파일을 만들었다”와 “공개 사이트에 반영됐다” 사이를 나눠서 봐야 합니다.

Daejin Lab을 Cloudflare Pages에 올리면서 배운 점은, 배포 성공 표시보다 공개 URL 확인이 더 중요하다는 것입니다. 특히 Search Console과 AdSense까지 생각하면 새 글이 sitemap과 canonical까지 정상으로 연결되는지 확인해야 합니다.

로컬에서 먼저 본 것

새 글을 추가하기 전후로 가장 먼저 보는 것은 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이 pages.dev 현재 주소인지
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. 공개 URL과 sitemap 확인
8. Search Console은 하루 요청량 안에서만 확인

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

이번 글의 결론

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

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