글을 발행하면 Google이 바로 찾을까? Astro 블로그의 색인 준비 상태를 확인한 과정
Astro 새 글이 내부 링크, 사이트맵, robots.txt, canonical과 RSS에 반영되고 운영 URL에서 정상 응답하는지 확인하는 실제 점검 과정입니다.
새 글을 작성하고 운영 사이트에서 페이지가 열리는 것까지 확인하면 발행이 끝났다고 생각하기 쉽습니다. 저도 처음에는 글 주소가 정상적으로 보이면 Google도 곧바로 발견하고 검색 결과에 보여줄 것이라고 막연하게 생각했습니다.
하지만 페이지 공개, URL 발견, 크롤링과 색인은 서로 다른 단계였습니다.
Google은 검색 과정을 크게 크롤링, 색인 생성과 검색 결과 제공으로 설명합니다. 사이트맵은 검색엔진이 URL을 발견하도록 도울 수 있지만, 사이트맵에 주소가 들어갔다고 모든 페이지의 크롤링이나 색인이 보장되지는 않습니다.
그래서 minml에서는 “Google에 색인됐다”는 결과 대신, 제가 직접 검증할 수 있는 질문으로 범위를 바꿨습니다.
새 글이 검색엔진에 발견될 수 있는 기술적인 상태로 공개됐는가?
이번에는 바로 전에 발행한 AI 기술 글의 사실 검증 과정을 사례로 삼아 Markdown 파일에서 운영 URL까지 따라가 봤습니다. 실제 Search Console의 색인 상태를 대신 추측하지 않고, 사이트 안에서 확인할 수 있는 내부 링크, 사이트맵, canonical, robots 설정, RSS와 HTTP 응답을 하나씩 점검했습니다.
페이지가 열리는 것과 색인되는 것은 달랐습니다
새 글의 운영 주소가 200 응답을 반환한다면 방문자가 페이지를 열 수 있다는 뜻입니다. 이것은 중요한 첫 단계지만 다음 내용을 모두 증명하지는 않습니다.
- Google이 이 URL을 이미 발견했다
- Googlebot이 페이지를 크롤링했다
- Google이 페이지를 색인에 저장했다
- 검색어에 맞춰 결과에 노출한다
- 특정 날짜 안에 검색 결과에 나타난다
Google 공식 문서도 검색 필수사항을 따르는 페이지라 하더라도 크롤링, 색인이나 검색 결과 노출을 보장하지 않는다고 설명합니다. 따라서 배포 직후 할 수 있는 검사는 색인 완료 확인이 아니라 색인을 막을 만한 기술적 문제를 줄이는 작업에 가깝습니다.
제가 구분한 단계는 다음과 같습니다.
| 단계 | 의미 | 사이트에서 확인한 항목 |
|---|---|---|
| 공개 | 방문자가 URL에 접근할 수 있음 | 운영 주소의 200 응답 |
| 발견 준비 | 다른 페이지나 목록에서 URL을 찾을 수 있음 | 내부 링크와 사이트맵 |
| 크롤링 허용 | robots 규칙이 페이지를 막지 않음 | robots.txt |
| 대표 주소 제안 | 같은 콘텐츠의 선호 URL을 알림 | canonical과 리다이렉트 |
| 색인 | Google이 페이지를 분석해 색인에 저장 | Search Console 등 외부 확인 필요 |
| 검색 노출 | 검색어에 맞춰 결과로 제공 | 실제 검색·성과 데이터 필요 |
이 구분 덕분에 “페이지가 정상이다”와 “Google에 노출됐다”를 같은 문장으로 쓰지 않게 됐습니다.
새 글 한 편이 연결되는 경로를 따라갔습니다
Astro에서 Markdown 파일 하나를 추가하면 해당 글의 HTML만 생기는 것이 아닙니다. minml 구조에서는 새 글의 공개 여부와 주제 분류에 따라 여러 페이지와 피드가 함께 바뀝니다.
이번 글을 쓰기 전 최신 글이었던 팩트체크 글을 기준으로 다음 경로를 확인했습니다.
- 글의 고유 HTML 페이지가 생성됐습니다.
- 홈페이지의 최신 글 영역에서 해당 글로 연결됐습니다.
- 전체 글 목록에 포함됐습니다.
- AI 활용 주제 페이지에 포함됐습니다.
- XML 사이트맵에 공개 URL이 들어갔습니다.
- RSS의 최신 항목에 제목과 주소가 들어갔습니다.
- 글의 canonical이 자기 공개 주소를 가리켰습니다.
- 배포 뒤 실제 운영 URL이 200을 반환했습니다.
이 중 어느 하나만 통과했다고 전체가 정상이라고 판단하지 않았습니다. 글 페이지는 생성됐지만 목록에서 빠질 수 있고, 목록 링크는 있지만 사이트맵이 이전 결과일 수 있습니다. 로컬 빌드는 정상이어도 운영 배포에서 파일이 빠질 가능성도 따로 봐야 합니다.
CMS 없이 Astro 글을 발행하는 과정이 작성부터 배포까지의 전체 흐름을 설명했다면, 이번 글은 그 결과물이 검색엔진에 발견될 준비를 갖췄는지에 집중합니다.
첫 번째 확인은 내부 링크였습니다
Google은 링크를 따라 새로운 페이지를 발견할 수 있습니다. 특히 중요한 페이지가 메뉴나 다른 글의 링크를 통해 도달 가능한 구조인지 확인하는 것이 기본입니다.
minml의 새 글은 다음 공개 목록에서 연결됩니다.
- 홈페이지 최신 글
- 전체 글 목록
- 해당 주제 목록
- 같은 주제의 관련 글 영역
- 작성자 페이지
최근 글 23편을 세 주제로 나누고 메뉴를 다시 정리한 이유도 여기에 있었습니다. 모든 글을 한 목록에만 두는 것보다 독자가 주제별로 이동할 수 있게 만들면서, 검색엔진도 일반적인 링크를 통해 글 사이를 따라갈 수 있는 구조가 됐습니다.
내부 링크를 확인할 때는 링크 문구만 보지 않습니다.
- 실제 a 요소와 href 속성으로 연결되는가
- 링크 대상이 공개 페이지로 생성됐는가
- 주소의 슬래시 규칙이 사이트 전체에서 일관적인가
- 관련 없는 글로 잘못 연결되지 않았는가
- 초안이나 삭제된 주소를 가리키지 않는가
Astro 빌드가 링크 대상의 존재까지 자동으로 보장하지는 않습니다. minml에서 깨진 링크를 넣어도 빌드가 성공했던 경험이 있었기 때문에, 생성된 HTML 안의 내부 경로를 별도 검사합니다.
사이트맵에는 공개할 주소만 포함했습니다
minml은 Astro의 공식 sitemap 통합을 사용합니다. 사이트의 기본 공개 주소를 설정하고 통합을 추가하면 빌드할 때 정적으로 생성된 경로를 바탕으로 XML 사이트맵이 만들어집니다.
설명의 구조만 단순화하면 다음과 같습니다.
export default defineConfig({
site: "https://example.com",
integrations: [sitemap()]
});실제 빌드 결과의 사이트맵에서 팩트체크 글의 공개 URL을 찾을 수 있었습니다. 초안으로 남긴 글은 페이지 자체가 생성되지 않으므로 사이트맵에도 들어가지 않았습니다.
Google은 사이트맵에 검색 결과에서 보고 싶은 대표 URL을 포함하라고 안내합니다. 같은 콘텐츠가 여러 주소로 열릴 수 있다면 모든 변형을 넣는 대신 선호하는 URL을 선택해야 합니다.
다만 사이트맵은 명령서가 아니라 힌트에 가깝습니다. URL 발견을 돕지만 Google이 해당 파일을 내려받거나 모든 URL을 크롤링하고 색인한다는 보장은 없습니다. 그래서 사이트맵에 주소가 있다는 결과를 “색인 완료”라고 기록하지 않습니다.
robots.txt는 사이트맵 위치와 차단 여부를 확인했습니다
minml의 robots.txt에는 모든 크롤러가 공개 영역을 방문할 수 있는 기본 규칙과 사이트맵 주소가 있습니다. 공개 예시로 바꾸면 다음과 같은 형태입니다.
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap-index.xml이 파일에서 확인하려는 것은 두 가지입니다.
- 새 글의 경로를 막는 Disallow 규칙이 없는가
- 사이트맵의 공개 주소가 정확한가
robots.txt에서 허용한다고 Google이 반드시 크롤링하는 것은 아닙니다. 반대로 robots.txt는 개인정보나 비공개 문서를 보호하는 접근 제어 장치도 아닙니다. 공개하면 안 되는 내용은 애초에 배포하지 않거나 인증으로 보호해야 합니다.
이번 글에서는 검색엔진이 글을 찾을 수 있는지만 다루지만, 초안과 운영 정보의 공개 범위는 별도의 문제입니다. minml은 frontmatter의 draft 값이 참인 글을 공개 페이지 생성, 목록과 RSS에서 제외합니다.
canonical은 현재 글의 대표 주소를 가리켰습니다
같은 내용이 여러 URL로 보일 수 있을 때 canonical은 어떤 주소를 대표로 선호하는지 검색엔진에 알리는 신호입니다. Google은 리다이렉트와 canonical 링크를 강한 신호로, 사이트맵 포함을 상대적으로 약한 신호로 설명합니다. 어떤 방법도 Google의 최종 선택을 강제하지는 않습니다.
minml의 글 페이지는 별도의 주소를 지정하지 않으면 글의 slug를 이용해 자기 자신을 가리키는 canonical을 생성합니다. 팩트체크 글의 빌드 HTML에서도 canonical이 실제 공개 주소와 일치하는지 확인했습니다.
검사할 때는 다음 세 값이 같은 방향을 가리키는지 봅니다.
- 브라우저에서 여는 최종 URL
- HTML head의 canonical URL
- 사이트맵에 포함된 URL
내부 링크도 가능하면 같은 대표 주소를 사용합니다. 슬래시 유무나 과거 주소가 섞이면 방문자는 정상적으로 이동하더라도 검색엔진에는 불필요하게 여러 신호를 줄 수 있기 때문입니다.
과거 주소는 관련 있는 새 주소로 연결했습니다
Ghost에서 Astro로 이전하거나 비슷한 글을 합치면 예전 주소가 남습니다. minml은 내용이 합쳐진 과거 URL을 관련 있는 현재 글로 301 리다이렉트합니다.
Google은 영구 리다이렉트를 기존 페이지가 새 위치로 옮겨졌다는 신호로 사용합니다. 이때 모든 오래된 글을 홈페이지 하나로 보내기보다, 실제로 내용을 이어받은 관련 페이지로 연결하는 것이 사용자에게도 자연스럽습니다.
배포 뒤에는 설정 파일만 보고 끝내지 않고 과거 주소가 실제로 301을 반환하며 올바른 목적지로 향하는지 확인합니다. 새 글 발행이 기존 리다이렉트를 우연히 깨뜨리지 않았는지도 함께 검사합니다.
RSS 반영은 별도 피드의 완전성을 확인하는 일이었습니다
RSS는 사이트맵과 목적이 다릅니다. 구독 도구와 독자가 새 글을 받아볼 수 있는 공개 피드이며, minml에서는 공개 글을 발행일순으로 정렬해 제목, 설명과 링크를 생성합니다.
팩트체크 글을 배포하기 전 RSS를 확인했을 때 해당 글이 첫 항목에 있었고 링크도 공개 URL과 일치했습니다. draft 상태의 글은 RSS 수집 단계에서 제외됩니다.
RSS에 글이 들어갔다고 Google 색인이 보장되는 것은 아닙니다. 이번 검사에서는 새 글이 사이트의 공개 피드에서 빠지지 않았고, 피드가 존재하지 않는 주소를 가리키지 않는다는 사실만 확인했습니다.
로컬 빌드와 운영 확인을 나눴습니다
배포 전에는 로컬 빌드 결과에서 다음 항목을 확인합니다.
| 로컬 검사 | 확인하는 내용 |
|---|---|
| 콘텐츠 스키마 | 제목, 날짜와 필수 필드의 형식 |
| 정적 페이지 생성 | 새 slug의 HTML 존재 |
| 내부 링크 검사 | 링크 대상 경로 존재 |
| 이미지 검사 | 대표 이미지 파일 존재 |
| 사이트맵 검사 | 새 공개 URL 포함 |
| RSS 검사 | 새 공개 글 포함 |
| HTML 확인 | canonical과 메타데이터 |
배포 뒤에는 운영 환경에서 다시 확인합니다.
| 운영 검사 | 확인하는 내용 |
|---|---|
| 홈페이지 | 정상 응답과 기본 탐색 |
| 새 글 | 공개 URL의 200 응답 |
| 대표 이미지 | 이미지 URL의 200 응답 |
| 사이트맵 | 운영 주소에서 접근 가능 |
| 없는 시험 주소 | 실제 404 응답 |
| 과거 주소 | 의도한 301 응답과 목적지 |
| 공유 서버의 다른 사이트 | 배포 영향이 없었는지 확인 |
이 검사는 완성된 새 릴리스로 한 번에 교체하는 배포 방식 안에 포함돼 있습니다. 로컬에서 정상인 파일을 운영 폴더에 일부만 복사해 HTML과 사이트맵의 시점이 달라지는 문제를 피하기 위해서입니다.
운영 URL의 상태 코드와 공개 도메인은 독자가 확인할 수 있는 정보라 글에 남길 수 있습니다. 반면 실제 서버 IP, 접속 계정, 내부 경로와 원본 명령 출력은 색인 준비 상태를 설명하는 데 필요하지 않아 공개하지 않습니다.
이번에 확인한 것과 확인하지 못한 것을 나눴습니다
새 글 한 편을 기준으로 확인한 결과는 다음과 같습니다.
- 글 페이지가 정적 HTML로 생성됨
- 홈, 전체 글, AI 주제와 작성자 페이지에서 연결됨
- 사이트맵과 RSS에 공개 URL이 포함됨
- canonical이 같은 공개 URL을 가리킴
- robots.txt가 글 경로를 차단하지 않음
- 배포 뒤 글과 이미지가 200을 반환함
- 실제 없는 주소는 404를 반환함
- 기존 통합 주소는 301을 유지함
여기까지 확인해도 알 수 없는 내용이 있습니다.
- Google이 정확히 언제 URL을 발견했는가
- Googlebot이 언제 다시 방문하는가
- 해당 페이지가 색인 대상으로 선택됐는가
- 어떤 검색어에서 어느 위치에 노출되는가
- 이번 기술 설정이 애드센스 심사에 영향을 줬는가
이 정보는 사이트 파일만으로 확인할 수 없습니다. 필요한 경우 Search Console의 URL 검사와 사이트맵 보고서에서 Google이 확인한 상태를 봐야 합니다. 그 결과도 색인과 순위를 보장하는 약속이 아니라 현재 관찰할 수 있는 데이터로 해석해야 합니다.
새 글 발행 후 사용하는 색인 준비 체크리스트
페이지와 내부 연결
- 새 글의 공개 URL이 생성됐는가
- 홈이나 주제 목록에서 일반 링크로 들어갈 수 있는가
- 전체 글과 작성자 페이지에 포함됐는가
- 관련 글 링크가 올바른 공개 주소를 가리키는가
- 초안과 삭제된 경로가 목록에 섞이지 않았는가
검색엔진에 전달하는 신호
- 사이트맵에 새 대표 URL이 포함됐는가
- robots.txt가 해당 경로를 막지 않는가
- robots.txt의 사이트맵 주소가 정확한가
- canonical이 현재 공개 URL과 일치하는가
- 사이트맵, canonical과 내부 링크의 주소 형식이 일관적인가
- 과거 주소가 있다면 관련 페이지로 영구 리다이렉트되는가
피드와 운영 배포
- RSS에 새 공개 글이 포함됐는가
- 글과 대표 이미지가 운영 환경에서 200을 반환하는가
- 사이트맵을 운영 주소에서 열 수 있는가
- 없는 주소가 홈페이지 대신 실제 404를 반환하는가
- 기존 리다이렉트와 다른 사이트에 영향이 없는가
표현과 공개 범위
- 색인 준비와 색인 완료를 구분해 설명했는가
- 검색 노출이나 승인 시점을 보장하지 않았는가
- 실제 서버 IP, 계정과 내부 경로를 제거했는가
- 최종 HTML과 이미지까지 개인정보 검사를 마쳤는가
검색엔진이 찾을 수 있는 상태까지가 제가 확인할 수 있는 범위였습니다
Astro의 사이트맵 통합과 공통 레이아웃을 한 번 설정하면 새 글마다 XML과 canonical을 손으로 작성할 필요는 없습니다. 그렇다고 자동 생성이라는 이유만으로 결과를 확인하지 않아도 되는 것은 아니었습니다.
새 글이 실제 페이지로 생성되고, 다른 공개 페이지에서 링크되며, 사이트맵과 RSS에 포함되고, 같은 대표 주소를 가리키고, 운영 환경에서 정상 응답하는지까지 확인해야 하나의 발행 결과로 볼 수 있었습니다.
이 모든 검사를 통과해도 Google의 크롤링과 색인은 Google이 결정합니다. 제가 확실하게 말할 수 있는 것은 새 글이 검색엔진에 발견될 수 있도록 사이트 안의 경로와 신호를 일관되게 준비했다는 것까지입니다.
색인을 보장하는 비법을 찾기보다, 새 글을 발행할 때마다 발견을 방해하는 기술적 실수를 반복하지 않는 구조를 만드는 편이 현실적이었습니다.