robots.txt와 canonical을 점검하며 확인한 색인 기본 조건

검색 노출 문제를 보면 처음에는 Search Console 화면부터 보게 됩니다. 저도 그랬습니다. 빨간 문구나 실패 상태가 보이면 바로 뭔가 고쳐야 할 것 같습니다.

하지만 Daejin Lab에서는 먼저 기본 신호를 확인하는 쪽으로 바꿨습니다. robots.txt가 막고 있는지, canonical이 어디를 가리키는지, noindex가 들어갔는지부터 봐야 원인을 좁힐 수 있었습니다.

확인한 robots.txt

처음 확인 당시 robots.txt는 단순했습니다.

User-agent: *
Allow: /

Sitemap: https://daejinlab.com/sitemap-index.xml

이 설정은 모든 검색엔진에게 사이트 접근을 허용하고, sitemap 위치를 알려줍니다.

30개 글까지 채운 뒤에는 Search Console이 직접 제출한 /sitemap.xml과 Astro가 만든 /sitemap-index.xml을 모두 찾을 수 있도록 robots.txt를 더 명확하게 두었습니다.

User-agent: *
Allow: /

Sitemap: https://daejinlab.com/sitemap.xml
Sitemap: https://daejinlab.com/sitemap-index.xml

둘 중 하나만 있어도 보통은 충분하지만, Search Console에서 가져오기 상태가 늦게 바뀌는 동안에는 표준 XML sitemap을 직접 안내하는 편이 확인하기 쉬웠습니다.

canonical 확인

글 상세 페이지의 canonical은 현재 공개 URL을 가리켜야 합니다.

예를 들어 아래 글은:

https://daejinlab.com/blog/ai-agent-good-bad-tasks/

canonical도 같은 주소를 가리키는지 확인했습니다.

https://daejinlab.com/blog/ai-agent-good-bad-tasks/

이 값이 예전 도메인 후보나 다른 주소를 가리키면 검색엔진이 혼동할 수 있습니다.

noindex와 x-robots-tag

페이지 안에 noindex가 있으면 검색엔진이 색인하지 않을 수 있습니다. 서버 응답 헤더의 x-robots-tag도 마찬가지입니다.

점검 기준은 아래와 같습니다.

HTML 안에 noindex 없음
응답 헤더에 x-robots-tag 없음
HTTP 상태 200
content-type: text/html

Daejin Lab의 샘플 글에서는 이 조건이 정상으로 확인됐습니다.

sitemap과 함께 봐야 한다

색인 가능성은 robots.txt 하나만 보고 판단하기 어렵습니다. 아래를 같이 봐야 합니다.

robots.txt
sitemap-index.xml
sitemap-0.xml
canonical URL
noindex 여부
HTTP 상태 코드

처음 점검에서는 sitemap URL들이 정상적으로 확인됐고, 예전 daejinlab.com 주소도 남아 있지 않았습니다. 이후 글을 더 늘린 뒤에도 중요한 기준은 같았습니다. sitemap 안의 공개 URL이 같은 도메인을 가리키고, 각 URL이 200으로 응답하는지 확인했습니다.

sitemap.xml: 공개 URL 목록 확인
sitemap-0.xml: 공개 URL 목록 확인
각 URL 상태: 모두 200 OK
예전 도메인 문자열: 없음

2026-05-08 추가 확인

Search Console에는 여전히 가져올 수 없음이 보였지만, 사이트 쪽 확인 결과는 정상에 가까웠습니다.

/robots.txt: 200 OK
/sitemap.xml: 200 OK, application/xml, 공개 URL 포함
/sitemap-index.xml: 200 OK, sitemap index 포함
홈: 200 OK, noindex 없음, JSON-LD 있음

2026-05-21 재점검 메모

이후 공개 상태를 다시 정리하면서 로컬 빌드 기준 sitemap과 공개 글 목록이 같은 기준으로 맞는지 확인했습니다. 중요한 것은 URL 숫자 자체보다, sitemap과 공개 글 수가 같은 기준으로 설명되는지입니다.

공개 글 목록과 sitemap URL 기준 일치 확인
publish check: errors 0 / warnings 0

그래서 이 시점의 판단도 “sitemap 파일을 더 고친다”가 아니라 “Search Console 처리를 기다리면서 콘텐츠와 내부 링크를 보강한다”입니다. 색인 문제를 볼 때는 콘솔 화면 하나보다 공개 URL, 응답 헤더, XML 파싱, robots, canonical을 같이 보는 편이 안전합니다. 내부 링크 흐름은 정적 블로그 글 20개 이후 내부 링크를 다시 설계한 방법과 함께 다시 봅니다.

기술 점검 후 멈춘 지점

이번 점검에서 중요한 기준은 “정상 확인 후에는 멈춘다”였습니다. robots, sitemap, canonical, noindex를 모두 확인했는데도 Search Console 화면만 늦게 바뀐다면, 같은 파일을 계속 수정하는 것은 도움이 되지 않을 수 있습니다.

그래서 다음 변경은 색인 관련 파일이 아니라 콘텐츠 쪽으로 돌렸습니다. 대표 글에 실제 운영 기록을 추가하고, Daejin Lab 운영 원칙을 먼저 정했습니다와 소개·문의·개인정보처리방침 같은 기본 페이지 구성처럼 신뢰 페이지와 연결되는 글을 먼저 보강했습니다.

지금 남긴 색인 기준

정적 블로그에서 색인 문제가 생기면 글 내용보다 기술 설정을 먼저 확인해야 할 때가 있습니다.

Daejin Lab에서는 robots.txt, sitemap, canonical, noindex, 응답 헤더를 확인해 기본 색인 조건을 점검했습니다. Search Console 화면의 상태가 늦게 바뀌더라도, 사이트 쪽 기본 조건은 먼저 정상으로 맞춰두는 것이 중요합니다. 그리고 정상 확인 뒤에는 24~72시간 정도 파일을 동결하고, 콘텐츠 보강으로 넘어가는 편이 안전하다고 봅니다.

색인 문제를 볼 때의 순서

지금은 Search Console 메시지를 보기 전에 사이트가 보내는 신호를 먼저 봅니다. robots, canonical, noindex, sitemap이 서로 같은 방향을 가리키는지 확인합니다.

이 값들이 맞다면 바로 파일을 고치기보다 기다릴 수 있습니다. 반대로 이 값들이 섞여 있으면 Search Console을 탓하기 전에 제 설정부터 고쳐야 합니다.

빨간 화면보다 실제 응답을 먼저 봤다

Search Console에서 무언가 실패처럼 보이면 마음이 급해집니다. 하지만 그 화면만 보고 파일을 고치면 원인을 더 흐릴 수 있습니다. 그래서 robots.txt, canonical, noindex처럼 공개 페이지에서 직접 확인할 수 있는 값부터 보려고 했습니다.

2026-05-31에 다시 본 색인 점검 묶음

색인 문제를 볼 때 robots.txt만 보거나 canonical만 보면 판단이 자주 빗나갑니다. 이번 재점검에서는 검색엔진 설정 설명에 머물지 않고, 공개 URL을 확인할 때 어떤 파일을 함께 봐야 하는지 정리하는 쪽으로 다시 잡았습니다.

robots, canonical, sitemap, live URL을 함께 보는 색인 점검 지도

이 카드는 한 파일만 보지 않고 색인 표면을 묶어서 확인하는 기준입니다.

참고한 공식 문서

확인하지 않은 것

이 글은 Google이 특정 URL을 반드시 색인한다는 보장이 아닙니다. robots, canonical, sitemap, live URL 상태를 정리하는 점검 글입니다.

FAQ

robots.txt가 열리면 색인은 보장되나요?

아닙니다. robots.txt는 크롤링 허용 여부와 관련이 있고, 색인 여부는 별도 판단입니다.

canonical은 왜 같이 보나요?

대표 URL 신호가 엉키면 검색엔진이 어느 URL을 우선해야 할지 헷갈릴 수 있습니다.

sitemap만 제출하면 충분한가요?

충분하지 않습니다. 내부 링크, canonical, 실제 응답 상태도 함께 봐야 합니다.

이번 보강 뒤에는 이 글을 단순 설정 글로 보지 않기로 했습니다. 색인 문제는 보통 한 줄 설정이 아니라 여러 신호가 겹친 결과이기 때문입니다. 그래서 확인 순서 자체가 이 글의 핵심입니다.