색인되지 않은 7건을 세 부류로 나눈 그림. 내가 일부러 막은 것, 구글이 알아서 정리한 것, 그리고 진짜 손댈 것 한 건으로 나뉘며 앞의 두 부류는 손댈 필요가 없다.

·7분 읽기·업데이트:

색인 안 됨 7건을 열어봤더니 고칠 건 하나였습니다


서치 콘솔에 사이트를 등록하고 며칠 뒤에 페이지 색인 리포트를 열었습니다.

색인 생성됨          18
색인 생성되지 않음    7

7이라는 숫자가 커 보였습니다. 글이 열몇 편인데 일곱 페이지가 검색에 안 잡힌다니.

결론부터 적으면, 일곱 건 중 실제로 손댈 건 한 건이었습니다. 그리고 그 한 건의 원인은 그 페이지에 없었습니다.

“색인 안 됨”은 오류 목록이 아닙니다

제가 잘못 읽고 있었습니다. 이 목록은 “실패한 페이지”가 아니라 “색인에 넣지 않은 페이지와 그 이유”입니다. 이유 중에는 제가 그렇게 시킨 것도 있고, 구글이 알아서 정리를 잘한 것도 있습니다.

7건이 다섯 가지 이유로 갈려 있었는데, 성격으로 묶으면 셋이었습니다.

내가 막은 것 — 색인하지 말라고 표시해둔 페이지입니다. 의도대로 동작하고 있다는 뜻이라 볼 것도 없습니다.

구글이 정리한 것 — 여기가 제일 헷갈렸습니다. “대체 페이지(적절한 표준 태그 있음)“라는 항목인데, 이름만 보면 뭔가 문제 같습니다. 구글 문서를 찾아보니 이렇게 적혀 있습니다.

This page correctly points to the canonical page, which is indexed, so there is nothing you need to do.

아무것도 할 필요 없다고 대놓고 적혀 있습니다. 같은 글에 주소가 여러 개 있을 때, 구글이 대표 주소 하나만 색인하고 나머지는 여기에 쌓아둡니다. 정상 동작을 보고하는 칸입니다.

진짜 손댈 것 — 하나 남았습니다.

남은 하나: rss.xml

“사용자가 선택한 표준 없는 중복 페이지”. 해당 주소는 rss.xml이었습니다.

중복이라는 건 같은 내용이 다른 주소에도 있다는 뜻입니다. 그런데 제 RSS는 하나뿐인데요. 게다가 RSS는 HTML이 아니라서 <link rel="canonical">을 넣을 자리가 없습니다. (HTTP 응답 헤더로 알려주는 방법이 있다는 건 나중에 알았습니다.) 어디가 중복이라는 건지 한참 못 찾았습니다.

리포트에 찍힌 주소를 다시 봤습니다.

http://ryumaspace.com/rss.xml

http였습니다.

사이트가 두 벌 있었습니다

주소창에 http://로 직접 쳐서 들어가 봤습니다. 그냥 열렸습니다. https로 안 넘어가고 200을 주고 있었습니다.

같은 사이트가 두 주소로 동시에 존재하고 있었던 겁니다.

주소 하나가 네 갈래로 갈라지는 구조. http와 https, 그리고 주소 끝 슬래시 유무가 곱해져서 같은 글에 주소가 네 개가 되고, 구글은 그중 하나만 색인하고 나머지를 색인 안 됨으로 보고한다. Always Use HTTPS 를 켜면 http 쪽 두 갈래가 정리된다.

그리고 이걸 알고 나니 앞의 “대체 페이지” 건수도 설명이 됐습니다. 주소가 http·https로 갈리고, 거기에 주소 끝 슬래시 유무까지 곱해지면 글 하나에 주소가 네 개가 됩니다. 슬래시 없는 쪽은 사이트가 알아서 슬래시 붙은 주소로 넘겨주니 “리디렉션이 포함된 페이지”로 따로 잡히고, 남는 건 http인데 그대로 열리는 주소입니다. 그게 “대체 페이지”로 보고됩니다.

고친 건 Cloudflare 설정 토글 하나였습니다.

SSL/TLS → 에지 인증서 → Always Use HTTPS

켜두면 http로 온 요청을 https로 넘겨줍니다. 이 한 칸이 꺼져 있어서 리포트 두 군데가 지저분했던 겁니다.

원인이 그 페이지에 없는 경우가 많습니다. 저는 RSS 생성 코드를 한참 들여다봤는데, 정작 문제는 사이트 전체 설정이었습니다.

그 김에 같이 손본 것 둘

리포트를 보다가 눈에 걸린 게 더 있었습니다.

링크마다 리다이렉트를 한 번씩 거치고 있었습니다

제 사이트는 주소 끝에 슬래시가 붙는 형태입니다. /blog/어떤-글/ 이렇게요. 그런데 제가 코드에 적어둔 내부 링크는 슬래시가 없었습니다.

<a href={`/blog/${post.id}`}>

이러면 방문자가 링크를 누를 때마다 슬래시 붙은 주소로 한 번 튕겼다가 갑니다. 사람 눈에는 티가 안 납니다. 그런데 크롤러 입장에서는 링크를 따라갈 때마다 리다이렉트를 한 번씩 더 겪는 거고, 리포트에는 “리디렉션이 포함된 페이지”가 쌓입니다.

링크에 슬래시를 붙였습니다.

<a href={`/blog/${post.id}/`}>

고작 한 글자인데, 이런 건 로컬에서 절대 안 걸립니다. 어차피 잘 열리니까요.

사이트맵의 3분의 2가 태그 페이지였습니다

사이트맵을 열어보고 놀랐습니다. 주소가 30개 들어 있는데 그중 19개가 태그 페이지였습니다. 글은 11편인데요.

태그를 자유롭게 달다 보니 글 한 편에만 붙은 태그가 잔뜩 생겼고, 태그마다 페이지가 하나씩 만들어져 있었습니다. 글 하나짜리 목록 페이지입니다. 내용은 제목 한 줄과 링크 하나가 전부입니다.

이걸 사이트맵에 넣어두면 크롤러에게 “여기 볼 게 30개 있다”고 말하는 셈인데, 실제로 볼 만한 건 11개입니다. 나머지를 훑는 동안 정작 글을 늦게 봅니다.

두 가지를 했습니다. 사이트맵에서 빼고,

sitemap({
  filter: (page) =>
    !page.includes('/tags/') && !page.includes('/404/'),
}),

페이지 자체에는 색인하지 말라고 붙였습니다.

<meta name="robots" content="noindex, follow" />

여기서 follow를 남긴 게 포인트입니다. “이 페이지는 검색결과에 넣지 마라. 다만 여기 있는 링크는 따라가라.” 태그 페이지는 그 자체로는 볼 게 없지만, 글로 가는 통로 역할은 합니다. nofollow까지 붙이면 통로를 막아버립니다.

사이트맵이 30개에서 11개로 줄었습니다.

색인 리포트 읽는 순서

이번 건으로 순서가 잡혔습니다.

숫자 말고 이유부터 봅니다. “색인 안 됨 7”은 그 자체로 아무 정보가 없습니다. 일곱이 전부 같은 이유일 수도, 일곱 가지 이유일 수도 있습니다.

“내가 시킨 것”과 “구글이 정리한 것”을 먼저 빼냅니다. 이 둘을 빼고 나면 대개 목록이 확 줄어듭니다. 저는 7건에서 1건이 됐습니다.

남은 것의 원인은 그 페이지 밖에 있을 수 있습니다. rss.xml이 중복이라는 보고를 받고 RSS 코드를 열었던 건 헛수고였습니다. 리포트에 찍힌 주소를 글자 그대로 읽었어야 했습니다. http인지 https인지, 끝에 슬래시가 있는지까지요.

고쳤으면 “수정 결과 확인”을 누릅니다. 안 누르면 구글이 다시 볼 때까지 그냥 기다려야 합니다. 누른 뒤에도 며칠에서 몇 주 걸립니다. 저도 지금 기다리는 중입니다.

마지막으로

처음에 7이라는 숫자를 보고 뭔가 크게 잘못된 줄 알았습니다. 실제로는 다섯 건이 정상이었고, 한 건은 제가 일부러 그렇게 만든 것이었고, 문제는 하나였습니다.

그 하나도 코드 문제가 아니라 설정 화면의 토글 하나였습니다. 켜는 데 3초 걸렸습니다. 찾는 데 오래 걸렸을 뿐입니다.

고친 곳

2026년 9월 29일, 글에 붙일 참고 문서를 하나씩 다시 열어보다가 본문과 어긋나는 곳을 찾아 고쳤습니다.

  • “주소 네 개 중 나머지가 전부 대체 페이지”라는 설명을 고쳤습니다. 슬래시 없는 주소는 리디렉션으로 따로 잡히고, 대체 페이지로 잡히는 건 http로 그대로 열리던 주소입니다.
  • RSS에도 HTTP 헤더로 대표 주소를 알릴 수 있다는 걸 덧붙였습니다.

참고한 문서


댓글

로그인도 이메일도 필요 없습니다. 이름만 적고 편하게 남겨주세요.