robots.txt 로 막으면 검색에서 사라진다, 사실은 색인은 남을 수 있습니다
robots.txt 는 수집을 막는 장치지 색인을 지우는 장치가 아닙니다. 차단했는데 검색에 남는 이유와, 목적별로 어떤 장치를 써야 하는지 정리했습니다.
거래처 단가표가 걸린 페이지를 robots.txt 로 막아 놓고 안심하는 경우를 종종 봅니다. 막았으니 검색에서 사라졌겠지, 하고요. 몇 달 뒤에 거래처가 그 단가표를 구글에서 찾아냅니다.
robots.txt 와 색인은 다른 층의 이야기라서 생기는 일입니다.
차단과 색인은 별개입니다
robots.txt 는 "우리 집에 들어오지 마세요"라는 문패에 가깝습니다. 로봇이 페이지를 읽으러 오는 것, 즉 수집을 막습니다.
그런데 구글이 어떤 페이지를 색인하는 데 방문이 꼭 필요한 건 아닙니다. 다른 사이트 어딘가에 그 주소로 걸린 링크가 있으면, 구글은 들어가 보지 못한 채로도 "이 주소에 뭔가 있다"는 사실을 색인에 올릴 수 있습니다. 서치콘솔에 뜨는 "차단되었지만 색인됨"이 정확히 이 상태입니다.
이렇게 색인된 페이지는 검색 결과에 설명문 없이 주소와 제목 비슷한 것만 덜렁 나옵니다. 안 나오는 것도, 제대로 나오는 것도 아닌 어정쩡한 상태로요.
목적에 맞는 장치가 따로 있습니다
먼저 말 하나만 풀고 가겠습니다. noindex 는 페이지 안에 붙이는 "이 페이지는 검색 결과에 올리지 마세요"라는 표시입니다. robots.txt 가 문 앞의 안내문이라면 noindex 는 페이지 자신의 의사 표시고요.
| 하려는 것 | 맞는 장치 | 흔한 실수 |
|---|---|---|
| 검색 결과에서 빼기 | 페이지에 noindex | robots.txt 로 막음 |
| 로봇 방문 자체를 줄이기 | robots.txt | noindex 만 넣음 |
| 급하게 가리기 | 서치콘솔 삭제 요청 | 페이지만 삭제하고 방치 |
| 아예 없애기 | 페이지 삭제 + 404/410 | robots.txt 로 막고 끝 |
가장 자주 꼬이는 조합이 "noindex 를 넣고 robots.txt 로도 막기"입니다. 성실해 보이지만 서로를 죽이는 조합입니다. noindex 는 로봇이 페이지에 들어와서 읽어야 작동하는데, robots.txt 가 입구를 막고 있으니 영영 읽히지 않습니다. 검색에서 빼고 싶은 페이지일수록 문은 열어 둬야 합니다.
지금 어느 상태인지 어떻게 확인하나요
화면만 봐서는 차단인지 색인 누락인지 구분되지 않습니다. 네 곳을 순서대로 봅니다.
- 주소창에 도메인 뒤 /robots.txt 를 붙여 직접 엽니다. 어떤 경로가 막혀 있는지 여기서 드러납니다
- 서치콘솔 URL 검사 도구에 문제의 주소를 넣습니다. 차단 때문인지 다른 사유인지 한 줄로 나옵니다
- 색인 생성 보고서에서 사이트 전체의 사유별 건수를 봅니다. 한 페이지의 문제인지 규칙 한 줄의 문제인지가 갈립니다
- 구글 검색창에 site: 를 붙여 그 경로를 검색합니다. 설명문 없이 주소만 뜨면 막힌 채로 색인된 상태입니다
3번까지 갔는데도 사유가 "차단되었지만 색인됨"이라면, 그 페이지는 막힌 것이 아니라 반쯤 열려 있는 셈입니다.
차단을 풀어야 하는 경우는 어떻게 가려내나요
기준은 하나입니다. 검색 결과에서 빼는 것이 목적이면 문을 열고, 수집량을 줄이는 것이 목적이면 문을 닫습니다.
| 페이지 성격 | robots.txt | noindex | 그렇게 하는 이유 |
|---|---|---|---|
| 단가표처럼 노출되면 곤란한 문서 | 차단을 풉니다 | 넣습니다 | 읽혀야 색인에서 빠집니다 |
| 이미 주소만 뜬 상태인 페이지 | 차단을 풉니다 | 넣습니다 | 막은 채로는 표시가 전달되지 않습니다 |
| 로그인, 장바구니 같은 기능 화면 | 차단 유지 | 필요 없음 | 검색 가치가 없고 방문만 소모합니다 |
| 파라미터가 붙어 끝없이 늘어나는 주소 | 차단 유지 | 필요 없음 | 수집량을 줄이는 것이 목적입니다 |
| 공개 자체가 문제인 내부 자료 | 무관 | 무관 | 서버에서 비밀번호로 막는 문제입니다 |
| 오픈 전 개발용 사이트 | 차단 유지 | 필요 없음 | 오픈일에 두 설정을 함께 확인합니다 |
위 두 줄은 이미 검색에 들어간 것을 꺼내는 작업이고, 아래 네 줄은 애초에 들어갈 이유가 없는 것을 덜어내는 작업입니다.
반대 방향의 사고도 있습니다
막으려다 못 막는 사고의 반대편에, 막을 생각이 없었는데 막혀 있는 사고가 있습니다. 사이트를 만들 때 개발사가 테스트용으로 걸어 둔 전체 차단이 오픈 뒤에도 남아 있는 경우인데, 생각보다 흔합니다. 색인이 안 되는 사유들을 정리할 때도 이 항목이 상위에 있었습니다.
주소창에 도메인 뒤에 /robots.txt 를 붙여서 직접 열어 보세요. Disallow: / 한 줄이 보인다면 사이트 전체가 막혀 있는 겁니다. 이 상태로는 사이트맵을 아무리 제출해도 소용이 없습니다.
순서를 지키지 않으면 어떤 일이 생기나요
페이지를 검색에서 빼는 작업에는 순서가 있습니다. 순서를 바꾸면 같은 일을 두 번 하게 됩니다.
- robots.txt 에서 해당 경로의 차단을 먼저 풉니다
- 페이지 머리에 noindex 를 넣습니다
- 로봇이 다시 들어와 그 표시를 읽을 때까지 기다립니다
- 검색 결과에서 빠진 것을 확인한 뒤에 차단을 다시 걸지 결정합니다
3번에서 조급해져 차단을 도로 거는 일이 잦은데, 그러면 처음으로 돌아갑니다. 재방문 주기는 사이트마다 다르고, 페이지가 많은 사이트일수록 수집 자원 배분의 영향을 받아 늦어집니다. 당장 가려야 한다면 삭제 요청으로 먼저 덮어 두고 1번부터 진행하세요.
여기까지로 해결되지 않는 경우는 무엇인가요
차단과 색인을 정리해도 남는 문제가 있습니다. 색인에서 빼는 것과 접근을 막는 것은 다른 일이라는 점입니다. 검색 결과에서 사라져도 주소를 아는 사람은 그대로 열 수 있습니다. 계약서나 결제 내역처럼 공개 자체가 문제인 파일은 로그인 뒤로 옮기거나 서버에서 접근을 제한해야 끝납니다.
지우기로 정한 페이지라면 404 나 410 으로 응답하게 두고, 그 주소를 robots.txt 로 덮지 마세요. 막아 두면 사라졌다는 사실조차 확인하러 오지 못하니까요. 정리 작업의 순서를 한 줄로 줄이면 이렇게 됩니다. 읽히게 두고, 표시로 알리고, 반영을 확인한 다음에 문을 닫습니다.
사장님들께 가장 자주 받는 질문부터 다룹니다. 답이 갈리는 자리는 추측으로 넘기지 않고, 직접 확인한 만큼만 적습니다.