답변
설정 방법을 말씀드리기 전에 되돌리기 어려운 결과부터 짚겠습니다. 사이트 전체를 검색에서 빼면 검색을 통해 들어오던 방문자가 0이 됩니다. 그리고 나중에 마음이 바뀌어 차단을 풀어도 그날 바로 복구되지 않습니다. 검색 노출은 크롤링(로봇이 페이지를 발견해 내려받는 단계), 인덱싱(그 내용을 분석해 데이터베이스에 저장하는 단계), 랭킹(저장된 것 중에서 순서를 매기는 단계) 순서로 진행되는데, 차단을 풀면 이 세 단계를 처음부터 다시 밟아야 하고 크롤링된 페이지가 전부 인덱싱되는 것도 아닙니다. 그래서 '일단 막아두고 나중에 열지'라는 계획은 생각보다 비쌉니다. 그다음 왜 막으려 하시는지부터 정하십시오. 목적에 따라 처방이 완전히 다릅니다. 첫째, 개발 중인 스테이징·테스트 서버를 감추려는 경우. 둘째, 내부용 페이지나 특정 고객에게만 공개하는 페이지를 감추려는 경우. 셋째, 사이트는 정상 노출시키되 장바구니·주문완료·사이트 내 검색결과·관리자 경로 같은 특정 페이지만 빼려는 경우. 넷째, 이미 검색결과에 떠버린 것을 지우려는 경우입니다. 이 넷을 구분하지 않고 robots.txt부터 손대는 것이 가장 흔한 실수입니다. 핵심부터 말씀드리면 robots.txt는 색인을 지우는 도구가 아닙니다. robots.txt는 검색 크롤러가 사이트의 어떤 페이지나 파일을 요청할 수 있고 없는지를 알려주는 텍스트 파일이고, 크롤러에게 보내는 제안(hint)일 뿐이라 모든 크롤러가 이를 준수한다는 보장이 없습니다. 규칙을 무시하는 봇은 여전히 접근합니다. 게다가 robots.txt로 막는 것은 '가져가지 말라'는 크롤링 거부이지 '검색결과에서 빼라'는 요청이 아닙니다. 그래서 이미 색인된 페이지를 robots.txt로 막으면 지워지기는커녕 그대로 남는 경우가 생깁니다. 검색결과에서 빼는 것이 목적이라면 써야 할 것은 noindex입니다. noindex는 페이지를 색인에서 빼라는 규칙으로 meta 태그 또는 X-Robots-Tag HTTP 헤더로 지정합니다. 여기에 반드시 지켜야 할 조건이 하나 있습니다. 구글은 noindex 규칙이 효력을 가지려면 그 페이지가 robots.txt로 차단돼 있지 않아야 하고 크롤러가 접근할 수 있어야 한다고 명시합니다. 둘을 동시에 걸면 크롤러가 페이지를 가져올 수 없어 noindex를 읽지 못하고, 다른 사이트가 링크를 걸어둔 경우 오히려 색인에 남습니다. 실무에서 가장 자주 나는 사고가 정확히 이 조합입니다. 기준은 목적입니다. 검색결과에서 빼는 것이 목적이면 noindex를 걸고 robots.txt는 열어둡니다. 크롤 자원 낭비를 막는 것이 목적이면 robots.txt로 막되 그 URL은 색인에 남아도 상관없는 경로여야 합니다. 이미 검색결과에 나와 있는 것을 지우는 경우는 한 단계가 더 붙습니다. noindex를 걸어두면 크롤러가 그 페이지를 다시 방문해 규칙을 읽은 뒤에야 색인에서 빠지므로 시차가 생깁니다. 급하다면 각 검색엔진이 제공하는 삭제·수집 제외 요청 창구를 함께 쓰는 것이 순서입니다. 여기서 중요한 것은 창구가 따로 있다는 점입니다. 구글은 서치콘솔, 네이버는 서치어드바이저입니다. 네이버는 서치어드바이저에 사이트를 등록하고 소유 확인(HTML 태그 또는 파일 업로드)을 거친 뒤 수집 요청·사이트맵 제출을 별도로 해야 하는 구조라 구글 서치콘솔과 절차·기준이 다릅니다. 즉 한쪽에서 조치했다고 다른 쪽에서도 사라지지 않으니 두 도구 모두에서 각각 처리하셔야 합니다. 다만 각 도구의 삭제 요청 메뉴 명칭과 화면 경로는 이번에 확인하지 못했으므로, 실제 조치는 각 도구에 로그인해 현재 화면에서 직접 확인하고 진행하십시오. 개발 중인 스테이징 서버라면 robots.txt나 noindex보다 확실한 방법이 따로 있습니다. 서버 단에서 비밀번호(HTTP 인증)를 걸거나 접속 IP를 제한하는 것입니다. robots.txt는 규칙을 무시하는 봇에게는 무력하고, 정말 민감한 콘텐츠를 보호하려면 비밀번호 보호 같은 다른 수단을 함께 써야 한다는 것이 원칙입니다. 내부용 페이지도 같습니다. 검색에서 안 보이게 하는 것과 아무나 못 들어오게 하는 것은 다른 문제이고, 후자가 필요하면 로그인 벽이 답입니다. 반대 방향의 사고도 함께 기억해두십시오. robots.txt로 가장 흔히 나는 사고가 개발 서버에서 쓰던 Disallow: / 설정을 실제 운영 사이트에 그대로 옮겨 사이트 전체 크롤링을 막아버리는 경우입니다. 이 실수는 배포 직후에 바로 드러나지 않고 며칠 뒤 검색 트래픽이 서서히 줄어드는 형태로 나타나 발견이 늦습니다. 지금 의도적으로 차단을 거신다면, 나중에 그 설정이 어디에 남아 있는지 기록해두고 배포 체크리스트에 '운영 도메인의 robots.txt와 meta 태그 확인' 항목을 넣어두십시오. 몇 달 뒤 '왜 검색에 안 나오지'로 되돌아오는 문의의 상당수가 이때 걸어둔 설정을 잊어버린 경우입니다. 마지막으로 이번에 확인하지 못한 것을 남겨두겠습니다. 첫째, 구글 서치콘솔과 네이버 서치어드바이저의 색인 삭제·수집 제외 요청 메뉴의 정확한 명칭과 경로입니다. 둘째, 삭제 요청 후 실제로 검색결과에서 사라지기까지 걸리는 시간과 그 조치의 유효 기간입니다. 셋째, X-Robots-Tag 헤더를 웹서버나 각 쇼핑몰 솔루션 관리자에서 설정하는 구체적인 문법과 메뉴 경로입니다. 넷째, 네이버가 robots.txt와 noindex를 구글과 동일한 규칙으로 해석하는지에 대한 공식 문서입니다. 이 네 가지는 화면 문구를 지어내는 대신 각 검색엔진의 웹마스터 도구와 사용 중인 솔루션의 고객센터에서 직접 확인하시길 권합니다. 위에서 정리한 목적별 구분과 robots.txt·noindex를 같이 걸면 안 된다는 원칙은 그 확인과 무관하게 그대로 적용되는 부분입니다.