글을 공개했다고 검색에 보이는 것은 아니다

글을 공개하고 홈페이지에서 제목과 본문이 보이면, 발행은 끝난 것처럼 느껴집니다. 저도 그렇게 생각했습니다. 관리 화면에서 공개 버튼을 누르고, 새 글이 홈의 최신 기록에 나타나고, 주소를 열어 본문까지 확인했으니 말입니다.

그런데 며칠 뒤 sitemap.xml을 다시 열어 보니 새 글이 없었습니다. 홈페이지에는 분명히 보이는 글이었지만, 검색엔진에 "이 글도 읽어 달라"고 전달하는 목록에는 들어가지 않은 상태였습니다.

글을 쓰는 이유는 내가 실행 했던 것을 기록하는 의미도 있지만, 결국 남들이 읽고 인사이트를 얻어가거나 정보를 알아갔으면 좋겠다는 이유, 그리고 유입을 통해 얻을 수 있는 이득 등을 고려한 것이기 때문에 노출이 되지 않는 글은 다소 당황스럽죠.

이 글은 검색 순위를 올리는 방법을 정리한 글이 아닙니다. Supabase 기반의 글 편집 및 발행과 Vercel 배포 환경에서 글을 직접 공개하고 운영하며, '발행 완료'로 끝나면 되는 것이 아니라 정확히 세팅을 해야 한다는 것을 공유하는 포스팅 입니다.

글이 보이면 끝이라고 생각한 이유

블로그를 만들 때 가장 큰 고려사항은 어떻게 하면 잘 노출이 될까였어요. 이전 구조는 브라우저에서 자바스크립트가 실행된 뒤에야 글을 불러오는 방식이었습니다. 사람이 직접 접속하면 자연스럽게 보이지만, 자바스크립트를 실행하지 않거나 비동기 응답을 기다리지 않는 크롤러는 빈 껍데기에 가까운 페이지를 받을 수 있었습니다.

그래서 공개 사이트를 Next.js의 서버 렌더링 구조로 바꿨습니다. 글의 제목, 설명, canonical, 본문이 처음 전달되는 HTML에 들어가도록 바꾸고, 관리자 화면만 검색 대상에서 제외했습니다. 이 작업은 'AI기획자' 홈페이지를 만들기까지에서 남긴 것처럼, 글을 쓰기 위한 도구를 만드는 일의 연장이었습니다.

전환 뒤에는 실제 게시글 주소를 자바스크립트 없이 확인했습니다. 제목과 본문, 개별 메타데이터가 초기 HTML에 보였고, robots.txt, sitemap, RSS도 응답했습니다. 당시에는 "검색을 위한 기본 구조를 갖췄다"고 판단했습니다.

그 판단은 절반만 맞았습니다. 구조가 준비되어 있어도, 새 글이 그 구조 안으로 실제로 들어가는지는 발행할 때마다 별도로 확인해야 했습니다. 너무 번거로웠죠.

블로그와 sitemap의 최신 글이 다르다?

어제 작성한 AI 앱 기획, 기능을 줄여야 할 때 묻는 5가지는 홈페이지에 최신 글로 표시되고, 개별 주소에서도 정상적으로 읽혔습니다. 하지만 같은 시점의 sitemap에는 이전 두 글만 들어 있었습니다.

여기서 먼저 Fact만 짚어보죠.

첫째, 새 글이 사라진 것은 아닙니다. 홈페이지와 개별 주소에서 읽을 수 있었습니다.

둘째, 그렇다고 검색엔진이 그 글을 가장 쉽게 발견할 경로까지 정상이라는 뜻도 아닙니다. sitemap은 검색엔진에 모든 색인을 보장하는 문서가 아니지만, 사이트 운영자가 공개한 URL을 일관되게 알려 주는 기본 목록입니다. 글이 홈에는 있고 sitemap에는 없다면, 발행 흐름의 서로 다른 단계가 같은 결과를 보고 있지 않다는 신호로 봐야 합니다.

이런 현상을 발견한 뒤에야 글을 발행하기 위해서는 단지 '공개 상태 변경'이 아니라 여러 설정을 만져줘야 한다는 것을 알았습니다.

"발행"을 위한 네 가지

작은 블로그라도 글을 공개로 바꾼 후 확인할 것은 생각보다 여러 개입니다. 다만 모든 화면을 매번 점검하는 것은 지속하기 어렵습니다. 그래서 저는 다음 네 가지가 같은 글을 가리키는지만 보려고 합니다.

1. 독자가 여는 주소

새 글 주소가 실제로 열리고, 제목과 본문이 정상적으로 보이는지 확인합니다. 로그인 상태의 관리자 화면이 아니라 일반 브라우저에서 확인하는 것이 중요합니다.

2. 초기 HTML의 정보

검색·소셜 서비스는 사람처럼 화면을 기다려 주지 않을 수 있습니다. 제목, 설명, canonical, 본문 일부가 처음 전달되는 HTML에 있는지 확인해야 합니다. 이 점 때문에 저는 Vite 기반 클라이언트 렌더링 구조에서 서버 렌더링 구조로 옮겼습니다.

3. sitemap의 URL

새 공개 글이 sitemap에 포함됐는지 확인합니다. sitemap을 제출했다고 해서 이후의 모든 글이 자동으로 제대로 반영된다는 뜻은 아니었습니다. 실제 공개 데이터와 sitemap 생성 기준이 같은지 따로 검증해야 했습니다.

4. 사람이 이해할 수 있는 연결

홈의 최신 글, 카테고리, 관련 글 링크 중 적어도 하나에서 새 글로 자연스럽게 이동할 수 있어야 합니다. 검색엔진 이전에 독자가 사이트 안에서 '다음 글을 발견할 수 있는가'의 문제이기도 합니다.

이 중 하나라도 빠졌다고 해서 문제될 것은 전혀 없긴 합니다. 다만 무엇이 빠졌는지 모른 채 "발행했다"고 인지하고 있는 것은 반쪽짜리 포스팅이라고 생각합니다.

자동화를 해도 확인은 해야합니다

AI와 자동화 도구를 쓰면 글쓰기와 배포의 속도는 빨라집니다. 제목 후보를 만들고, 초안을 다듬고, 이미지를 처리하고, Draft를 생성하고 공개로 바꾸는 일까지 많은 단계가 짧아집니다.

하지만 AI가 인지하고 시스템이 인지하는 서로 다른 시스템이 같은 의미인지는 한 번 되돌아 볼 필요가 있습니다. 겉으로는 전혀 문제가 없거든요.

CMS는 글이 공개됐다고 말할 수 있습니다. 블로그는 최신 글이 보인다고 말할 수 있습니다. 배포 서비스는 빌드가 성공했다고 말할 수 있습니다. 그러나 sitemap 생성 경로가 다른 데이터를 보고 있거나, 캐시가 오래된 목록을 전달하고 있다면 독자가 보는 사이트와 검색엔진에 전달되는 사이트는 달라질 수 있습니다.

헤르메스 에이전트를 셋업한 날, 일하는 방식이 바뀌었다에서 자동화의 경계를 정하는 일이 중요하다고 썼습니다. 이 경험은 그 원칙을 콘텐츠 운영에도 적용하게 했습니다. 자동으로 공개할 수 있는가보다, '공개 결과를 누가 어떤 기준으로 확인할 것인가'가 더 중요했습니다.

지금은 '원인'보다 '현상'을 먼저 기록

현재 sitemap 누락의 정확한 원인은 아직 잘 모르겠습니다. 새 글의 공개 데이터, sitemap 생성 경로, 캐시 무효화 조건을 차례로 확인해야 하는데요. 원인을 모르는 상태에서 "검색엔진 반영이 늦어서 그렇다"고 단정하고 싶지 않습니다.

대신 이미 확인된 사실은요. 새 글은 홈페이지와 개별 URL에서는 읽혔고, 같은 시점 sitemap에서는 누락되어 있었습니다. 그래서 해야할 것은, 먼저 공개 데이터와 sitemap의 입력값이 같은지 확인하고, 다음으로 발행 뒤 갱신·캐시 무효화가 실제로 일어나는지 검증해야 합니다.

작은 운영 기록에서 이런 미완의 결론을 남기는 이유가 있습니다. 당장 해결책을 멋지게 말하는 것보다, 무엇을 아직 모르는지 정확히 남겨야 다음 수정이 추측이 아니라 검증이 되기 때문입니다.

필자가 다음에 확인할 것

다음 공개 글을 발행하기 전과 후에 아래만 확인하려 합니다.

• 새 글의 공개 URL이 비로그인 상태에서도 정상적으로 열리는지
• 페이지의 제목·canonical·본문이 초기 HTML에 포함되는지
• sitemap에 같은 URL이 포함되는지
• 홈과 카테고리에서 새 글로 이동할 수 있는지
• 빠진 항목이 있다면, CMS 데이터·생성 경로·캐시 중 어느 단계의 문제인지

글을 썼다는 사실과 글이 발견될 수 있다는 사실은 다릅니다. 개인 블로그를 운영하며 제가 만들고 싶은 것은 공개 버튼을 누르기 쉬운 도구만이 아닙니다. 그 버튼 뒤에서 실제로 어떤 일이 벌어졌는지 확인하고, 다음 판단을 더 나아지게 하는 기록의 흐름입니다.

FAQ

Q. 글을 공개했는데 sitemap에 보이지 않으면 어떻게 하나요?
공개 URL이 정상적으로 열리는지, 초기 HTML에 메타데이터가 포함되는지부터 확인합니다. 그다음 sitemap 생성 로직이 실제 공개 데이터를 참조하는지, 캐시가 최신 상태로 갱신되는지 점검하는 순서가 필요합니다.

Q. sitemap 누락이 검색 노출에 실제로 얼마나 영향을 주나요?
sitemap은 색인을 보장하는 문서는 아니지만, 검색엔진이 URL을 발견하는 통로 중 하나입니다. 내부 링크나 RSS 같은 다른 발견 경로가 있어도, sitemap 누락은 운영자가 반드시 확인해야 할 신호입니다.

Q. CMS에서 공개하면 sitemap에 자동으로 반영되지 않나요?
반영 여부는 sitemap을 생성하는 방식에 따라 다릅니다. 정적으로 미리 생성하는 구조라면 새 글이 다음 빌드나 재생성 시점까지 반영되지 않을 수 있습니다.

Q. 서버 렌더링(SSR)으로 바꾸면 이 문제가 해결되나요?
SSR은 검색엔진이 초기 HTML에서 콘텐츠를 바로 읽게 해주지만, sitemap 생성이나 캐시 무효화까지 자동으로 해결해주지는 않습니다. 두 가지는 별도로 확인해야 하는 항목입니다.

Q. 개인 블로그 운영자가 매번 이 모든 걸 점검해야 하나요?
매번 정밀 점검하기는 어렵지만, 공개 URL·초기 HTML·sitemap·내부 링크 네 가지만 짧게 확인하는 루틴을 두면 큰 부담 없이 지속할 수 있습니다.