robots.txt란? 검색엔진 크롤링 제어 쉽게 정리

robots.txt는 검색엔진 로봇에게 "이 경로는 살펴봐도 되고, 저 경로는 살펴보지 말라"고 알려주는 아주 짧은 안내문이다. 사이트 루트 주소 뒤에 /robots.txt만 붙이면 누구나 열어 볼 수 있는 평범한 텍스트 파일이며, 복잡한 코드가 아니라 몇 줄짜리 규칙 모음일 뿐이다.

결론부터 말하면 이렇다. robots.txt는 검색 순위를 올려주는 도구가 아니라, 검색엔진 로봇의 방문 동선을 정리해 주는 안내판이다. 관리자 페이지나 장바구니처럼 검색에 나올 필요가 없는 경로를 크롤링(검색엔진 로봇이 웹페이지를 읽어가는 행위) 단계에서부터 제외해, 로봇이 정말 중요한 페이지에 시간을 쓰도록 돕는다.

이 파일 하나를 잘못 써서 홈페이지 전체가 검색에서 사라지는 사고도 실제로 자주 일어난다. 그만큼 규칙은 짧지만, 한 줄의 실수가 미치는 영향은 결코 작지 않다.

새 홈페이지를 오픈했는데 몇 주가 지나도 검색에 전혀 뜨지 않는다는 문의를 받으면, 열에 서너 번은 원인이 이 파일 한 곳에 있다. 개발 단계에서 걸어 둔 차단 규칙을 실제 서비스로 옮기면서 함께 딸려 온 경우가 대부분이다. 반대로 규칙을 정확히 이해하고 나면, 이만큼 적은 노력으로 큰 사고를 예방할 수 있는 파일도 드물다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• robots.txt는 크롤링(수집) 여부를 정하는 파일이고, 검색 노출(색인) 자체를 막는 도구가 아니다
• 파일은 반드시 도메인 루트(example.com/robots.txt)에 있어야 하며, 위치가 틀리면 무시된다
• Disallow: / 한 줄이 사이트 전체를 차단할 수 있는 가장 흔하고 위험한 실수다
• 구글은 crawl-delay와 robots.txt 안의 noindex 규칙을 지원하지 않는다(2019년부터 공식적으로 무시)
• 2026년 현재는 GPTBot, Google-Extended 같은 AI 학습용 크롤러도 robots.txt로 별도 제어할 수 있다

robots.txt는 어렵게 느껴질 이유가 전혀 없는 파일이다. 문법은 몇 개뿐이고, 대부분의 사이트에는 다섯 줄 안팎이면 충분하다. 다만 이 짧은 파일이 사이트 전체의 검색 노출과 맞닿아 있다 보니, 정확히 모르고 손대면 위험하다.

이 글은 SEO를 처음 접하는 사업가와 실무자를 기준으로, robots.txt의 정의부터 문법, 실전 예시, 흔한 실수, 그리고 2026년 기준 AI 크롤러 대응까지 예시 중심으로 쉽게 정리한다. 어려운 용어가 나오면 그 자리에서 바로 풀어 쓴다.

robots.txt란 정확히 무엇인가?

robots.txt는 검색엔진 로봇에게 사이트의 어느 경로를 크롤링해도 되는지 알려주는 텍스트 파일이다. 회사로 치면 건물 입구에 붙은 "이 층은 방문객 출입 가능, 저 층은 관계자 외 출입금지"라는 안내판과 같다.

안내판이 있다고 문이 물리적으로 잠기는 것은 아니다. robots.txt도 강제로 문을 잠그는 장치가 아니라 정직한 로봇에게 보내는 부탁이다. 구글봇(Googlebot)이나 빙봇(Bingbot)처럼 이름 있는 검색엔진 로봇은 이 안내를 대체로 성실히 따르지만, 이 규칙을 무시하는 악성 봇도 존재한다는 점은 알아 두어야 한다.

이 파일은 반드시 사이트의 루트 주소에 있어야 한다. https://iruweb.com/robots.txt처럼 도메인 바로 뒤에 파일 이름이 오는 구조다. https://iruweb.com/blog/robots.txt처럼 하위 폴더에 넣으면 검색엔진은 그 파일을 아예 찾지 못하고, 파일이 없는 것과 똑같이 취급한다.

지금 당장 아무 사이트나 브라우저 주소창에 사이트주소/robots.txt를 쳐 보면 바로 확인할 수 있다. 예를 들어 iruweb.com/robots.txt라고 입력하면 그 사이트의 robots.txt 내용이 그대로 화면에 뜬다. 로그인도, 특별한 도구도 필요 없이 누구나 열람 가능한 공개 파일이다.

가장 단순한 robots.txt는 이런 모습이다.

User-agent: *
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml

세 줄이 하는 일은 이렇다. 첫째 줄은 "모든 로봇에게"라는 대상 지정이고, 둘째 줄은 "관리자 폴더는 크롤링하지 말라"는 차단 지시이며, 셋째 줄은 "사이트맵은 여기 있다"는 안내다. robots.txt의 거의 모든 실전 활용은 이 세 요소의 조합으로 이루어진다.

여기서 크롤링이라는 말을 한 번 더 짚어 두자. 크롤링이란 검색엔진의 수집 로봇이 웹페이지를 차례로 찾아가 내용을 읽어 가는 과정을 말한다. 크롤링 이후에 그 내용을 검색 목록에 등록하는 과정을 색인(인덱싱)이라고 부르는데, robots.txt는 이 둘 중 앞 단계인 크롤링만 다루는 파일이라는 점이 이 글 전체에서 가장 중요한 전제다.

이 규칙은 1994년 한 개발자가 자신의 사이트가 로봇 때문에 서버 부담을 겪은 뒤 제안하면서 시작되었고, 오랫동안 업계의 관행으로만 지켜지다가 2022년에 이르러 국제 인터넷 표준화 기구(IETF)가 정식 인터넷 표준(RFC 9309)으로 채택했다. 30년 가까이 관행으로만 통용되던 규칙이 뒤늦게 공식 표준이 된 셈인데, 그만큼 이 짧은 텍스트 파일이 웹 생태계 전반에서 오랫동안 신뢰받아 온 약속이라는 뜻이기도 하다.

지금도 전 세계 대부분의 대형 사이트가 이 파일을 두고 있으며, 신규로 홈페이지를 만드는 개발사나 플랫폼 대부분이 기본값으로라도 robots.txt를 자동 생성해 준다. 그만큼 이 파일은 "있으면 좋은 선택 사항"이 아니라, 현대 웹사이트라면 갖추어 두는 것이 기본값에 가까운 요소로 자리 잡았다.

아래 그림에 robots.txt 한 줄 한 줄이 각각 무슨 역할을 하는지 정리해 두었다. 처음 robots.txt를 여는 사람이라면 이 구조부터 눈에 익혀 두면 이후 내용이 훨씬 쉬워진다.

robots.txt는 문을 잠그는 자물쇠가 아니라, 성실한 손님에게만 통하는 안내판이다. 정말 민감한 정보는 비밀번호나 로그인으로 별도 보호해야 한다.

robots.txt는 서버가 평범한 텍스트 문서를 응답으로 돌려주는 방식으로 작동한다. 브라우저나 로봇이 그 주소로 요청을 보내면 서버가 200(정상) 응답과 함께 내용을 전달하는 구조이며, 특별한 프로그램이나 데이터베이스가 필요하지 않다. 그래서 아주 작은 홈페이지도 메모장으로 파일 하나만 만들어 올리면 그것으로 끝이다.

여기서 실무자가 놓치기 쉬운 부분이 하나 더 있다. robots.txt는 누구나 열람할 수 있는 공개 파일이므로, 이 파일 자체를 보안 수단으로 쓰면 안 된다는 점이다. Disallow: /backup/이나 Disallow: /internal-docs/처럼 민감해 보이는 폴더 이름을 그대로 적어 두면, 오히려 "여기에 무언가 중요한 것이 있다"는 지도를 세상에 공개하는 셈이 된다. 정말 보호해야 할 자료는 robots.txt로 안내하는 대신, 로그인이나 접근 권한 설정으로 막아야 한다.

robots.txt는 왜 필요한가?

robots.txt가 필요한 가장 큰 이유는 크롤링 예산(crawl budget)을 낭비하지 않기 위해서다. 크롤링 예산이란 검색엔진 로봇이 한 사이트를 방문할 때 쓸 수 있는 시간과 자원의 한도를 뜻한다. 특히 페이지 수가 많은 쇼핑몰이나 대형 사이트일수록 이 예산은 한정적이다.

로봇이 장바구니, 검색 결과 페이지, 관리자 화면처럼 손님에게 보여줄 필요가 없는 페이지를 도느라 시간을 다 쓰면, 정작 중요한 상품 페이지나 블로그 글은 늦게 발견되거나 자주 갱신되지 못한다. robots.txt로 불필요한 경로를 미리 차단해 두면, 로봇이 진짜 중요한 페이지에 더 자주, 더 깊이 방문한다.

두 번째 이유는 서버 부담을 줄이는 것이다. 검색엔진 로봇은 하루에도 여러 번 사이트를 방문하는데, 방문 페이지 수가 지나치게 많으면 서버에 부하가 걸릴 수 있다. 로그인 페이지, 내부 검색 결과, 필터가 잔뜩 붙은 URL처럼 사실상 같은 내용을 변주만 한 페이지들을 차단하면 서버도, 로봇도 한결 가벼워진다.

세 번째 이유는 중복 콘텐츠 관리다. 하나의 쇼핑몰 상품이 색상·사이즈 옵션에 따라 URL이 수십 개로 갈라지는 경우가 흔하다. 이런 파생 URL을 모두 크롤링하게 두면 검색엔진 눈에는 "비슷한 페이지가 너무 많다"는 신호로 비칠 수 있다. robots.txt로 불필요한 파생 경로를 정리하면 이런 혼란을 줄일 수 있다.

이런 이유들 때문에 사업 규모와 무관하게 홈페이지, 블로그, 쇼핑몰 모두 robots.txt 하나쯤은 갖추어 두는 것이 기본이다. 페이지가 몇 개 안 되는 소규모 사이트라도, 관리자 경로나 결제 진행 화면처럼 검색에 나올 이유가 없는 곳은 어디에나 있기 마련이다.

실제 숫자로 감을 잡아 보면 이해가 쉽다. 원두를 파는 쇼핑몰이 원두 종류 20개에 색상·용량·배송 옵션을 조합하면, 상품 1개가 URL로는 수십 개까지 갈라지기도 한다. 여기에 정렬 방식과 필터까지 더해지면 실제 눈에 보이는 상품은 20개뿐인데 검색엔진이 마주치는 주소는 수천 개로 불어난다.

로봇이 이런 파생 주소를 전부 도느라 시간을 쓰면, 정작 새로 올린 신상품 페이지는 발견이 늦어질 수 있다.

이런 상황에서 정렬·필터 옵션이 붙은 주소만 골라 Disallow로 정리해 두면, 로봇의 방문 동선이 훨씬 효율적으로 바뀐다. 페이지 수가 적은 사이트에서는 체감이 크지 않을 수 있지만, 페이지가 수백·수천 개로 늘어나는 시점부터는 이 정리 작업의 효과가 뚜렷하게 나타난다.

다만 오해하지 말아야 할 점이 있다. robots.txt는 검색 순위를 직접 올려주는 파일이 아니다. "robots.txt를 잘 쓰면 상위노출된다"는 말은 사실이 아니며, 이 파일의 역할은 어디까지나 로봇의 동선 정리에 한정된다.

비유하자면 robots.txt는 집을 짓기 전에 마당의 잡초를 정리하는 작업과 비슷하다. 잡초를 치웠다고 집이 저절로 예뻐지지는 않지만, 잡초가 무성한 채로는 아무리 좋은 집을 지어도 마당까지 눈에 들어오지 않는다. 실제로 순위를 좌우하는 것은 페이지 속도, 콘텐츠 품질, 구조화 데이터, 신뢰할 만한 백링크처럼 훨씬 넓은 요소들이며, robots.txt는 그 요소들이 제 역할을 하도록 길을 터 주는 기초 작업에 가깝다. 순위를 좌우하는 더 넓은 요소는 홈페이지 제작 전 SEO 체크리스트에서 함께 확인할 수 있다.

robots.txt 문법은 어떻게 쓰나?

robots.txt의 문법은 몇 개의 지시어만 알면 충분하다. 아래 표에 핵심 지시어를 정리했다.

지시어	역할	예시
User-agent	규칙을 적용할 로봇을 지정	User-agent: * (모든 로봇)
Disallow	크롤링을 막을 경로	Disallow: /admin/
Allow	차단된 상위 경로 안에서 예외로 허용할 경로	Allow: /admin/public/
Sitemap	사이트맵 파일의 전체 주소 안내	Sitemap: https://example.com/sitemap.xml
#	주석(로봇은 무시하고 사람만 읽음)	# 관리자 영역 차단

User-agent는 어떤 로봇에게 규칙을 적용할지 지정하는 줄이다. 별표(*)를 쓰면 "모든 로봇"을 의미하고, User-agent: Googlebot처럼 이름을 명시하면 그 로봇에게만 해당 규칙이 적용된다. 로봇 이름을 여러 번 반복해 각기 다른 규칙을 줄 수도 있다.

Disallow는 가장 자주 쓰이는 지시어로, 뒤에 오는 경로를 크롤링하지 말라는 뜻이다. Disallow: /admin/은 /admin/으로 시작하는 모든 하위 경로를 차단한다. 아무것도 쓰지 않고 Disallow:만 남겨 두면 "차단할 것이 없다"는 뜻이 되어 오히려 전체 허용으로 해석된다.

Allow는 Disallow로 막은 영역 안에서 일부만 다시 열어 줄 때 쓴다. 예를 들어 관리자 폴더 전체는 막되, 그 안의 이미지 폴더만 로봇이 볼 수 있게 하고 싶다면 Disallow: /admin/ 다음 줄에 Allow: /admin/images/를 추가하면 된다.

Sitemap은 사이트맵 파일이 어디 있는지 알려주는 안내다. robots.txt 어느 위치에 적어도 상관없고, 반드시 https://로 시작하는 전체 주소(절대경로)로 적어야 한다. 사이트맵이 여러 개라면 Sitemap 줄을 여러 번 추가하면 된다. 사이트맵 자체가 무엇이고 어떻게 만드는지는 사이트맵(sitemap.xml) 만드는 법에서 자세히 다룬다.

여기서 실무자가 자주 놓치는 세부 규칙 두 가지를 짚어 둔다.

• 경로는 대소문자를 구분한다. /Admin/과 /admin/은 로봇 눈에 서로 다른 경로다. 실제 폴더 이름과 정확히 똑같이 적어야 한다.
• 와일드카드 두 가지를 쓸 수 있다. 별표(*)는 아무 문자열이나 대신할 수 있는 기호이고, 달러 기호($)는 "여기서 주소가 끝난다"는 표시다. 예를 들어 Disallow: /*.pdf$는 .pdf로 끝나는 모든 주소를 차단한다.

실전에서 바로 쓸 수 있는 예시 세 가지를 든다. 아래 예시들은 각 업종의 사정에 맞게 경로만 바꾸면 그대로 쓸 수 있다.

블로그·정보성 사이트

User-agent: *
Disallow: /wp-admin/
Disallow: /search/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xml

관리자 화면과 내부 검색 결과 페이지만 막고, 나머지 글은 모두 열어 둔 구성이다. admin-ajax.php처럼 사이트 작동에 필요한 파일 하나만 예외로 다시 허용해 둔 점도 눈여겨볼 부분이다.

쇼핑몰

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /*?*sort=
Disallow: /*?*filter=
Sitemap: https://example.com/sitemap.xml

장바구니와 결제 화면, 그리고 정렬·필터 옵션이 붙어 사실상 같은 상품을 반복 노출하는 주소를 차단했다. 상품 페이지 자체는 건드리지 않아 검색 노출에 영향이 없다.

기업·서비스 소개 사이트

User-agent: *
Disallow: /internal/
Disallow: /thank-you/
Sitemap: https://example.com/sitemap.xml

내부 직원용 페이지와 문의 완료 후 뜨는 감사 페이지처럼, 검색에 나올 필요가 없는 두어 개 경로만 정리한 구성이다. 대부분의 소규모 홈페이지는 이 정도 수준이면 충분하다.

개인 포트폴리오·프리랜서 사이트

# 이력서 PDF는 링크로만 공유하고 검색 노출은 원치 않아 차단
User-agent: *
Disallow: /*.pdf$
Sitemap: https://example.com/sitemap.xml

주석(#)을 활용해 이 규칙을 왜 넣었는지 기록해 둔 예시다. 로봇은 #로 시작하는 줄을 그냥 건너뛰지만, 나중에 이 파일을 다시 열어 볼 사람에게는 훌륭한 메모가 된다. 와일드카드 $를 활용해 .pdf로 끝나는 모든 주소를 한 줄로 정리한 점도 참고할 만하다.

규칙이 여러 줄 겹칠 때는 가장 구체적인(긴) 경로가 우선 적용된다는 점도 알아 두면 좋다. 예를 들어 Disallow: /docs/로 폴더 전체를 막아 두었더라도, 바로 아래에 Allow: /docs/public-guide.pdf를 추가하면 그 파일 하나만 다시 열린다. 규칙의 순서보다 경로 문자열이 얼마나 구체적인지가 우선순위를 정한다.

이제 실제로 흔히 발견되는 나쁜 robots.txt 하나를 단계별로 고쳐 보자. 이해를 굳히는 데는 정답을 외우는 것보다 고치는 과정을 눈으로 따라가는 편이 훨씬 오래 남는다. 예로 든 것은 신규 오픈한 온라인 쇼핑몰의 robots.txt다.

처음 파일은 이랬다.

User-agent: *
Disallow: /

개발 서버에서 검색 노출을 막으려고 걸어 둔 설정을 실제 서비스 주소로 그대로 옮기면서 지우지 않은 경우다. 문제가 한눈에 보인다.

1. 슬래시 하나가 사이트 전체를 막고 있다. 상품 페이지, 블로그, 홈 화면까지 전부 크롤링이 금지된 상태다.
2. 사이트맵 안내가 없다. 로봇이 새 페이지를 스스로 찾아야 하는 상황이라 발견 속도가 느려진다.
3. 정말 막아야 할 장바구니·결제 페이지는 정작 지정되어 있지 않다.

이제 순서대로 고쳐 본다.

1. 전체 차단부터 푼다. Disallow: / 줄을 지우거나, 정말 막을 경로만 남긴 새 규칙으로 바꾼다.
2. 진짜 막아야 할 경로만 하나씩 추가한다. 장바구니와 결제 화면, 필터 조합 주소를 지정한다.
3. 사이트맵 위치를 알려 준다. Sitemap: 줄을 추가해 로봇이 상품·블로그 목록을 빠르게 찾도록 돕는다.

최종 결과는 이렇게 바뀐다.

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /*?*sort=
Sitemap: https://example.com/sitemap.xml

처음의 "전체 차단" 상태와 비교하면, 검색에 나와야 할 상품과 콘텐츠는 모두 열려 있고 정말 불필요한 경로만 정확히 막힌 것을 확인할 수 있다. 이 과정을 한 문장으로 요약하면 이렇다.

"지금 이 규칙이 무엇을 막고 있는지"를 한 줄씩 눈으로 확인한 뒤, 꼭 필요한 차단만 남기고 나머지는 모두 연다.

어떤 업종이든 이 순서로 점검하면 위험한 robots.txt를 안전한 상태로 되돌릴 수 있다.

구글이 robots.txt를 어디까지 지원하는지도 알아 두면 실수를 줄일 수 있다. 아래 그림은 구글이 실제로 지키는 규칙과, 문법에는 있어도 구글이 무시하는 규칙을 나란히 비교한 것이다.

구글은 crawl-delay 지시어를 지원하지 않는다. crawl-delay는 "몇 초에 한 번씩만 방문해 달라"고 요청하는 지시어로, 빙(Bing)이나 야후 같은 일부 검색엔진은 참고하지만 구글봇은 이 줄을 그냥 지나친다. 구글에서 크롤링 속도를 조절하고 싶다면 robots.txt가 아니라 구글 서치 콘솔의 크롤링 속도 관련 설정을 활용해야 한다.

robots.txt 안에 noindex를 적는 방식도 구글은 2019년부터 공식적으로 지원하지 않는다. 예전에는 일부 사이트가 Disallow 옆에 비공식적으로 noindex: 줄을 추가해 색인 제외를 시도하기도 했지만, 구글은 이를 문서화되지 않은 규칙으로 규정하고 더 이상 반영하지 않는다고 공식적으로 밝혔다. 페이지를 색인에서 빼고 싶다면 뒤에서 설명할 meta robots의 noindex 태그를 써야 한다.

robots.txt에서 흔히 저지르는 실수는 무엇인가?

robots.txt는 짧은 만큼 실수의 대가도 크다. 실무에서 반복적으로 나타나는 실수를 좋은 예·나쁜 예로 비교한다.

첫 번째, 사이트 전체를 차단하는 한 줄 실수. 가장 흔하고 가장 치명적인 사고다.

구분	예시
나쁜 예	User-agent: * / Disallow: /
좋은 예	User-agent: * / Disallow: /admin/

나쁜 예의 Disallow: /는 슬래시 하나로 사이트 전체를 크롤링 금지 상태로 만든다. 이 실수는 대개 개발·테스트 서버(스테이징 환경)에서는 검색 노출을 막으려고 일부러 넣어 둔 설정인데, 실제 서비스 사이트로 그대로 복사하면서 함께 옮겨 오는 경우에 발생한다. 새 사이트를 오픈하거나 서버를 옮긴 뒤에는 반드시 robots.txt 내용부터 확인하는 습관이 필요하다.

두 번째, robots.txt로 이미 검색에 나온 페이지를 지우려는 오해다.

robots.txt로 막았다고 해서 그 페이지가 검색 결과에서 즉시 사라지는 것은 아니다.

이미 다른 사이트에서 그 주소로 링크를 걸어 두었다면, 구글은 그 페이지 내용을 읽지 못하더라도 주소 자체는 검색 결과에 "설명 없음" 형태로 남겨 둘 수 있다. 크롤링 차단과 색인 제외는 서로 다른 개념이기 때문이다. 이미 노출된 페이지를 확실히 빼고 싶다면 해당 페이지에 접근을 허용한 상태에서 noindex 메타 태그를 넣거나, 구글 서치 콘솔의 삭제 요청 기능을 쓰는 것이 정확한 방법이다.

세 번째, 서브도메인과 프로토콜마다 별도의 robots.txt가 필요하다는 점을 모르는 경우다. robots.txt는 그 파일이 놓인 정확히 그 호스트와 프로토콜에만 적용된다. 즉 www.example.com용 robots.txt가 있어도 blog.example.com이나 shop.example.com처럼 서브도메인이 다르면 해당 서브도메인에 별도의 robots.txt를 따로 두어야 한다. http://와 https://도 원칙적으로는 별개의 주소로 취급되므로, 리다이렉트가 제대로 되어 있지 않다면 이 부분도 함께 점검해야 한다.

네 번째, 파일 위치나 이름 오타다. Robots.txt, ROBOTS.TXT처럼 대소문자를 다르게 쓰거나, 루트가 아닌 하위 폴더(/blog/robots.txt 등)에 넣으면 검색엔진은 이 파일을 찾지 못하고 아예 없는 것으로 취급한다. 파일명은 정확히 소문자 robots.txt여야 하고, 위치는 반드시 도메인 바로 아래여야 한다.

다섯 번째, 파일 용량 초과다. 구글의 robots.txt 파서는 파일 크기를 약 500KB(51만 2,000바이트)까지만 읽는다. 이 한도를 넘어가는 부분은 아예 읽지 않고 무시해 버린다. 실제로 이 한도를 넘기는 사이트는 매우 드물지만, 자동 생성 스크립트로 규칙을 무한히 쌓는 경우라면 이 한도를 염두에 두어야 한다.

여섯 번째, 사이트맵 주소를 상대경로로 적는 실수다. Sitemap: /sitemap.xml처럼 도메인 없이 짧게 적으면 규칙이 무시될 수 있다. Sitemap 지시어는 반드시 https://example.com/sitemap.xml처럼 처음부터 끝까지 완전한 주소(절대경로)로 적어야 정상적으로 인식된다. 다른 지시어들은 상대경로로 써도 되지만, Sitemap만큼은 예외라는 점을 기억해 두자.

아래 그림은 이 중에서 가장 흔한 "전체 차단" 실수를 나쁜 예와 좋은 예로 나란히 비교한 것이다.

이 다섯 가지 실수의 공통점은 "내가 지금 무엇을 차단하고 있는지 정확히 모르고 손을 댔다"는 것이다. robots.txt를 수정한 뒤에는 항상 사이트주소/robots.txt를 직접 열어 내용을 눈으로 다시 확인하는 습관을 들이면 대부분의 사고를 예방할 수 있다.

robots.txt 파일이 아직 없다면 어떻게 만드나?

robots.txt를 처음부터 만드는 절차는 어렵지 않다. 일반 텍스트 편집기 하나만 있으면 충분하고, 특별한 프로그램이 필요 없다.

1. 메모장이나 코드 편집기를 연다. 워드 프로그램처럼 서식이 붙는 도구는 피한다. 서식이 섞이면 로봇이 규칙을 제대로 읽지 못할 수 있다.
2. 필요한 규칙을 이 글의 예시를 참고해 작성한다. 자기 사이트의 관리자 경로, 결제 페이지, 검색 결과 페이지 등 실제로 존재하는 경로로 바꿔 적는다.
3. 파일 이름을 정확히 robots.txt로 저장한다. 대문자나 다른 이름으로 저장하면 인식되지 않는다. 저장 형식은 UTF-8 인코딩을 선택하는 것이 안전하다. 다른 인코딩으로 저장하면 한글 주석이 깨져 보일 수 있다.
4. 호스팅 관리자 화면이나 FTP로 사이트 루트 폴더에 업로드한다. 카페24, 아임웹처럼 국내에서 널리 쓰이는 홈페이지 빌더는 대개 관리자 화면 안에 robots.txt를 직접 입력하는 메뉴를 별도로 제공한다. 워드프레스라면 대부분의 SEO 플러그인에서 이 파일을 화면에서 바로 수정할 수 있다.
5. 브라우저에서 내도메인.com/robots.txt로 열어 내용이 정확히 뜨는지 확인한다. 이 마지막 확인 한 단계를 건너뛰지 않는 것이 중요하다.

플랫폼마다 접근 방식이 조금씩 다르다는 점도 알아 두면 좋다. 자체 서버나 워드프레스처럼 파일 시스템에 직접 접근할 수 있는 환경이라면 위 절차 그대로 따르면 되고, 카페24·아임웹·윅스 같은 종합 홈페이지 빌더를 쓴다면 대개 "SEO 설정" 또는 "검색엔진 최적화" 메뉴 안에 robots.txt 편집 기능이 마련되어 있어 파일을 직접 다루지 않고도 내용을 수정할 수 있다.

만약 사용 중인 플랫폼에 robots.txt를 직접 수정하는 메뉴가 보이지 않는다면, 플랫폼이 자동으로 기본 규칙을 생성해 주는 경우일 수 있다. 이런 경우에도 앞서 안내한 것처럼 브라우저에서 직접 열어 현재 어떤 내용이 적용되고 있는지부터 확인하는 것이 첫 단계다.

업종별로 robots.txt에서 놓치기 쉬운 부분은 무엇인가?

같은 문법이라도 업종에 따라 "무엇을 막아야 하는지"는 서로 다르다. 사업 형태별로 실제로 자주 발견되는 경로와 그에 맞는 처리 방향을 정리한다.

카페·식당

예약·웨이팅 시스템을 외부 업체와 연동해 쓰는 경우가 많은데, 이 연동 과정에서 /booking/confirm/이나 /waiting/status/처럼 예약 상태를 보여주는 임시 페이지가 함께 생성된다. 이런 페이지는 사람마다 다른 내용이 뜨는 "일회성 화면"이라 검색에 노출될 이유가 없다.

구분	처리
나쁜 예	예약 확인 페이지까지 그대로 크롤링 허용
좋은 예	Disallow: /booking/confirm/으로 예약 확인 화면만 차단

메뉴판이나 매장 소개 페이지는 그대로 열어 두어야 검색 노출에 도움이 된다는 점도 함께 기억해야 한다.

병원·치과

예약 폼과 개인정보 입력 화면이 핵심 차단 대상이다. /reservation/form/, /mypage/처럼 환자 개인정보가 오가는 화면은 검색에 노출될 필요가 전혀 없을 뿐 아니라, 노출되면 신뢰 문제로 이어질 수도 있다.

구분	처리
나쁜 예	예약 폼·마이페이지까지 전체 공개 상태
좋은 예	Disallow: /mypage/, Disallow: /reservation/form/로 개인정보 관련 화면만 정확히 차단

반면 진료 항목 소개, 의료진 소개, 오시는 길 페이지는 검색 노출이 매출과 직결되므로 절대 실수로 함께 차단되지 않도록 주의해야 한다.

학원·교육기관

수강 신청 폼과 학부모 전용 로그인 영역이 대표적인 차단 대상이다. /apply/, /parent-login/처럼 개인 계정과 연결된 경로는 차단하되, 커리큘럼 소개나 강사진 소개, 후기 페이지는 검색에서 매우 중요한 콘텐츠이므로 열어 두어야 한다.

부동산 중개

매물 상세 페이지는 검색 노출의 핵심이지만, 지도 API를 불러오는 스크립트 경로나 필터 조합으로 끝없이 갈라지는 검색 결과 페이지(/search/?minPrice=...)는 정리 대상이다.

구분	처리
나쁜 예	필터 조합 주소까지 전부 크롤링 허용 → 중복 페이지 폭증
좋은 예	Disallow: /*?minPrice=처럼 필터 파라미터가 포함된 주소만 선별 차단

매물 자체의 상세 페이지 주소는 절대 이 규칙에 함께 걸리지 않도록, 필터 파라미터가 붙은 패턴만 정확히 지정하는 것이 중요하다.

인테리어·시공업체

시공 갤러리는 검색 유입의 핵심 콘텐츠이므로 그대로 열어 두고, 대신 견적 신청 폼 제출 후 뜨는 완료 페이지(/quote/thanks/)나 내부 관리용 갤러리 편집 화면만 차단 대상으로 삼는다. 시공 사례 하나하나가 잠재 고객을 데려오는 콘텐츠라는 점을 감안하면, 이 업종에서는 "무엇을 여느냐"가 "무엇을 막느냐"보다 더 중요하다고 볼 수 있다.

이렇게 업종별로 살펴보면 공통된 원칙이 보인다. 매출과 직결되는 콘텐츠(소개, 상품, 시공 사례, 블로그 글)는 최대한 열어 두고, 개인정보·결제·내부 관리 화면만 정확히 골라 막는다는 것이다. 이 원칙 하나만 기억해도 업종이 달라져도 흔들리지 않는 기준을 세울 수 있다.

robots.txt, noindex, 사이트맵은 서로 어떻게 다른가?

세 파일과 태그의 역할이 헷갈린다는 질문을 자주 받는다. 결론부터 말하면 셋은 서로 대체재가 아니라 각자 다른 층위의 역할을 맡은 협력 관계다.

구분	역할	위치
robots.txt	크롤링(수집) 허용 여부	도메인 루트의 텍스트 파일
noindex(메타 로봇 태그)	색인(검색 등록) 허용 여부	각 페이지의 <head> 안
sitemap.xml	크롤링해야 할 페이지 목록 안내	별도 XML 파일

robots.txt는 "여기 오지 마라"는 출입 안내이고, noindex는 "들어와서 봐도 되지만 명부에는 올리지 마라"는 지시이며, 사이트맵은 "여기부터 여기까지 둘러보면 좋다"는 초대장이다. 이 셋의 역할을 헷갈리면 원하는 결과를 얻지 못한다.

가장 흔한 혼동은 "차단하고 싶은 페이지에 robots.txt와 noindex를 동시에 걸어 두는 것"이다. 이렇게 하면 오히려 역효과가 난다. robots.txt로 크롤링 자체를 막아 버리면, 구글은 애초에 그 페이지에 들어가서 noindex 태그를 읽을 기회조차 얻지 못한다. noindex로 색인에서 빼고 싶은 페이지라면, 크롤링은 허용한 채로 noindex 태그만 넣어야 확실하게 작동한다.

정리하면 이렇다.

• 검색엔진이 아예 방문하지 않기를 바란다면 → robots.txt의 Disallow
• 방문은 해도 되지만 검색 결과에는 올리지 않기를 바란다면 → noindex(크롤링은 허용 상태 유지)
• 중요한 페이지를 더 잘, 더 빨리 발견하기를 바란다면 → sitemap.xml과 Sitemap 지시어

실제 사례로 이 셋의 차이를 확인해 보자. 한 회사가 여름 한정 이벤트 페이지를 운영하다가 행사가 끝나 그 페이지를 검색에서 없애고 싶다고 가정한다.

나쁜 대응: 이벤트 페이지 주소를 robots.txt의 Disallow에 추가하고 안심한다.

이 방법의 문제는 이렇다. 이미 여러 사람이 그 페이지를 공유하거나 다른 사이트가 링크를 걸어 두었다면, 구글은 페이지 내용을 다시 확인하지 못한 채로도 그 주소를 "행사 관련 페이지"로 계속 검색 결과에 남겨 둘 수 있다. 심지어 내용이 이미 바뀌었는데도 오래된 정보로 인식된 상태 그대로 노출될 위험도 있다.

좋은 대응: robots.txt는 건드리지 않고 크롤링은 그대로 허용한 채, 페이지에 noindex 태그를 추가하거나 페이지를 완전히 종료했다면 410(사라짐) 상태 코드로 응답하도록 설정한다.

이렇게 하면 구글이 다시 방문했을 때 "이 페이지는 이제 색인에서 빼야 한다"는 신호를 정확히 읽고 검색 결과에서 자연스럽게 제외한다. 크롤링을 열어 둔 채로 신호를 정확히 주는 쪽이, 크롤링부터 막아 버리는 쪽보다 오히려 더 확실하게 작동한다는 것이 이 사례의 핵심이다.

AI 크롤러도 robots.txt로 제어할 수 있나?

2026년 현재는 검색엔진 로봇뿐 아니라 AI 모델 학습이나 AI 검색 서비스를 위해 콘텐츠를 수집하는 크롤러도 여럿 활동하고 있다. robots.txt는 이런 AI 크롤러도 이름(User-agent)만 지정하면 개별적으로 허용하거나 차단할 수 있다.

대표적인 AI 관련 크롤러는 다음과 같다.

크롤러 이름	운영사	주로 하는 일
GPTBot	OpenAI	AI 모델 학습용 데이터 수집
OAI-SearchBot	OpenAI	ChatGPT 검색 기능용 수집
Google-Extended	구글	제미나이 등 생성형 AI 모델 학습 여부 제어
ClaudeBot	Anthropic	AI 모델 학습용 데이터 수집
CCBot	Common Crawl	공개 데이터셋 수집(여러 AI 회사가 재활용)
Applebot-Extended	애플	애플 AI 기능 학습 여부 제어(일반 애플봇과 별개)
PerplexityBot	퍼플렉시티	AI 검색·답변 생성을 위한 콘텐츠 수집

여기서 반드시 짚고 넘어갈 부분이 있다. Google-Extended는 구글 검색 노출을 담당하는 일반 구글봇(Googlebot)과는 별개의 크롤러다. Google-Extended를 차단해도 일반 검색 결과나 AI 오버뷰 같은 구글 검색 기능 노출에는 영향을 주지 않으며, 오직 제미나이 같은 생성형 AI 모델의 학습 데이터로 콘텐츠가 쓰이는지 여부만 제어한다. 이 둘을 혼동해 Google-Extended를 막았다가 검색 노출까지 줄었다고 오해하는 경우가 있는데, 이는 사실과 다르다.

AI 크롤러를 다루는 robots.txt 예시는 이렇다.

User-agent: *
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

이 예시는 일반 검색엔진에는 평소처럼 사이트를 열어 두면서, GPTBot과 Google-Extended에게는 별도로 "이 사이트 콘텐츠는 AI 학습에 쓰지 말아 달라"고 요청하는 구성이다. 반대로 콘텐츠가 AI 검색 결과에 인용되고 언급되기를 원하는 사업자라면, 이런 크롤러를 굳이 차단하지 않고 열어 두는 편을 선택할 수도 있다. 무엇이 우리 사업에 유리한지는 정답이 하나로 정해져 있지 않으며, AI 검색 시대의 노출 전략은 GEO 생성형엔진최적화에서 더 넓게 다룬다.

AI 크롤러 차단 여부는 검색 순위와 무관한 별도의 선택이다. 다만 어떤 크롤러를 막았는지는 반드시 robots.txt에 명확히 기록해 두어야 나중에 헷갈리지 않는다.

그렇다면 우리 사이트는 어떤 기준으로 정해야 할까. 판단 기준은 크게 두 가지 질문으로 좁혀진다.

• 우리 콘텐츠가 AI 검색·챗봇 답변에 인용되어 신규 방문으로 이어지길 원하는가? 그렇다면 관련 크롤러를 열어 두는 편이 유리할 수 있다.
• 우리 콘텐츠가 다른 AI 서비스의 학습 재료로 그대로 쓰이는 것은 원하지 않는가? 그렇다면 학습 전용 크롤러만 골라 차단하는 절충안도 가능하다.

두 질문의 답이 서로 다른 경우가 흔하다는 점도 알아 두면 좋다. 예를 들어 "검색·답변에는 인용되고 싶지만, 통째로 학습에는 쓰이길 원하지 않는다"면 챗봇 답변용 크롤러는 열어 두고 학습 전용 크롤러만 차단하는 식으로 세분화할 수 있다. 정답은 하나로 정해져 있지 않으므로, 자기 콘텐츠의 성격과 사업 방향에 맞추어 선택하면 된다.

한 가지 더 알아 둘 점은, robots.txt에 이름을 적어 특정 크롤러를 차단해도 그 이름을 사칭한 가짜 수집 프로그램까지 걸러내지는 못한다는 것이다. robots.txt는 정직하게 자기 이름을 밝히는 로봇에게만 통하는 부탁이라, 이름을 속이고 접근하는 프로그램은 이 규칙과 무관하게 콘텐츠를 가져갈 수 있다. 방문자가 정말 해당 회사의 크롤러가 맞는지까지 엄격하게 확인하고 싶다면, 서버 로그에서 접속 IP를 역추적하는 방식(리버스 DNS 확인)을 함께 활용하는 방법이 있다. 다만 이 정도까지는 대부분의 일반 사이트에는 필요하지 않으며, robots.txt로 의사를 명확히 밝혀 두는 것만으로 충분한 경우가 대부분이다.

네이버·빙 같은 다른 검색엔진에서도 규칙이 똑같이 통하나?

robots.txt의 기본 문법은 검색엔진과 무관하게 공통으로 통하는 국제 표준이지만, 각 검색엔진이 이 규칙을 얼마나 세밀하게 참고하는지는 조금씩 다르다.

네이버는 예티(Yeti)라는 이름의 수집 로봇을 운영하며, User-agent와 Disallow 규칙을 기본적으로 참고한다. 다만 네이버 검색은 구글보다 자체 서비스(블로그, 카페, 지식iN, 플레이스)의 비중이 크기 때문에, 워드프레스나 자체 도메인으로 만든 홈페이지라면 robots.txt 설정과 별개로 네이버 서치어드바이저에 사이트를 등록해 두어야 원활한 수집과 노출을 기대할 수 있다. 반대로 앞서 언급했듯 네이버 블로그(blog.naver.com)는 네이버가 알아서 수집·색인하므로 이 등록 절차 자체가 필요 없다.

빙(Bing)은 구글과 마찬가지로 User-agent, Disallow, Sitemap을 지원하며, 여기에 더해 crawl-delay 지시어도 실제로 참고한다는 점이 구글과 다르다. 빙 웹마스터 도구에 사이트를 등록해 두면 빙봇(Bingbot)의 방문 현황을 별도로 확인할 수 있다.

정리하면, robots.txt 파일 자체는 검색엔진마다 새로 만들 필요 없이 하나로 공용으로 쓰되, 검색엔진마다 제공하는 등록 도구(구글 서치 콘솔, 네이버 서치어드바이저, 빙 웹마스터 도구)에는 각각 따로 등록해 두어야 한다는 것이 실무에서 가장 자주 놓치는 부분이다. robots.txt는 공통 언어이지만, 등록과 확인은 검색엔진마다 따로 해야 한다.

robots.txt는 어떻게 확인하고 테스트하나?

가장 간단한 확인법은 브라우저 주소창에 내도메인.com/robots.txt를 직접 입력해 보는 것이다. 내용이 눈에 보이는 텍스트로 그대로 뜨면 정상 위치에 파일이 있다는 뜻이다.

구글이 이 파일을 실제로 어떻게 읽고 있는지 확인하려면 구글 서치 콘솔의 설정 메뉴 안 크롤링 통계 보고서를 살펴보면 된다. 이 보고서에서 구글봇이 robots.txt 요청 자체에 성공했는지, 최근에 언제 다시 읽어 갔는지를 확인할 수 있다. 구글 서치 콘솔을 아직 등록하지 않았다면 구글 서치 콘솔 사용법부터 참고하면 좋다.

과거에는 구글이 별도의 "robots.txt 테스터" 도구를 서치 콘솔 안에 제공했지만, 이 전용 테스트 도구는 이후 정리되었다. 지금은 서드파티 검증 도구나, robots.txt 문법을 그대로 해석해 주는 오픈소스 라이브러리를 활용해 특정 주소가 차단되는지 미리 점검하는 방식이 일반적이다. 급하게 확인해야 한다면 규칙을 하나씩 적용해 보며 Disallow 대상 주소가 실제로 그 규칙에 걸리는지 눈으로 대조하는 것만으로도 대부분의 실수는 걸러낼 수 있다.

robots.txt가 아예 존재하지 않을 때는 어떻게 될까. 파일이 없으면 구글은 "차단할 것이 없다"고 간주하고 사이트 전체를 평소처럼 크롤링한다. 즉 robots.txt가 없다고 사이트가 검색에서 빠지는 일은 없다. 다만 관리자 페이지처럼 굳이 노출시키고 싶지 않은 경로가 있다면, 파일을 만들어 두는 편이 안전하다.

반대로 robots.txt 서버에 일시적인 오류가 나서 파일을 아예 불러오지 못하는 경우도 있다. 구글 공식 문서에 따르면 이런 오류가 약 30일 넘게 이어지면 구글은 마지막으로 확인된 정상 버전을 기준으로 삼거나, 그마저 없으면 제한이 없는 것으로 간주한다고 밝히고 있다. 서버 점검이나 이전 작업 중에는 이 파일이 일시적으로 열리지 않을 수 있으니, 큰 변경 작업 전후로는 이 파일이 정상적으로 열리는지 함께 점검해 두는 것이 좋다.

한 가지 더 알아 둘 점은 구글이 robots.txt를 매번 새로 읽는 것이 아니라 최대 24시간 정도 캐시(임시 저장)해 두고 재사용한다는 것이다. 즉 방금 파일을 수정했다고 그 즉시 구글의 판단이 바뀌지는 않으며, 다음 방문 때 반영된다. 급하게 반영이 필요하다면 서치 콘솔에서 다시 가져오기를 요청할 수 있다.

클라우드플레어(Cloudflare) 같은 CDN(콘텐츠 전송 네트워크, 방문자에게 더 가까운 서버에서 콘텐츠를 빠르게 전달해 주는 서비스)을 함께 쓰는 사이트라면 확인할 부분이 하나 더 있다. 방화벽이나 봇 차단 규칙이 지나치게 강하게 설정되어 있으면, robots.txt 요청 자체가 검색엔진 로봇 앞에서 차단되어 파일 내용과 무관하게 접근이 막힐 수 있다. robots.txt 문법에는 문제가 없는데도 서치 콘솔에서 계속 오류가 뜬다면, 이런 보안·방화벽 설정도 함께 점검해 보는 것이 좋다.

또한 실무에서는 실제 배포 전에 로컬이나 스테이징 환경에서 규칙을 미리 적어 보고, Disallow로 지정한 경로 각각을 눈으로 대조하는 습관이 유용하다. "이 규칙에 어떤 실제 주소들이 걸리는가"를 하나씩 짚어 보면, 의도치 않게 너무 넓은 범위를 막아 버리는 실수를 배포 전에 걸러낼 수 있다.

아래 체크리스트로 발행 전 마지막 점검을 해 보자.

robots.txt는 얼마나 자주 점검해야 하나?

robots.txt는 한 번 만들어 두고 잊어버려도 되는 파일이 아니다. 사이트 구조가 바뀌는 시점마다 함께 점검해야 하는 파일이라고 생각하는 편이 안전하다.

특히 아래 네 가지 상황에서는 반드시 다시 확인해야 한다.

1. 홈페이지를 새로 만들거나 플랫폼을 옮길 때. 개발사가 작업 중이던 테스트 서버의 설정이 실제 서비스 주소로 그대로 넘어오는 사고가 가장 흔하게 발생하는 시점이다.
2. 쇼핑몰에 새로운 필터·정렬 기능을 추가할 때. 새 URL 패턴이 생기면서 미처 정리하지 못한 파생 주소가 늘어난다.
3. 예약·상담 시스템을 새로 연동할 때. 외부 서비스와 연결되며 새로운 임시 페이지 경로가 함께 생겨난다.
4. 도메인이나 서브도메인 구조를 바꿀 때. 앞서 설명했듯 robots.txt는 정확히 그 호스트에만 적용되므로, 주소 체계가 바뀌면 파일도 새로 점검해야 한다.

담당자를 명확히 정해 두는 것도 중요하다. 개발팀이 새 기능을 배포할 때마다 robots.txt에 영향이 있는지 함께 검토하는 절차를 정해 두면, 마케팅팀이나 대표가 뒤늦게 "왜 검색에 안 나오지"라고 놀라는 상황을 줄일 수 있다. 큰 개편이 없더라도 분기에 한 번 정도는 파일을 열어 눈으로 다시 훑어보는 루틴을 권한다.

변경 이력을 남겨 두는 것도 좋은 습관이다. 언제, 왜 이 규칙을 추가했는지 파일 안에 주석으로 짧게 남겨 두면, 몇 달 뒤 다른 담당자가 이 파일을 다시 열었을 때 "이 줄을 지워도 되는지"를 훨씬 쉽게 판단할 수 있다.

코드로 사이트를 관리하는 팀이라면, robots.txt도 다른 소스 코드와 함께 버전 관리 시스템(예: 깃)에 올려 두는 것을 권한다. 그러면 누가 언제 어떤 줄을 바꿨는지 기록이 남고, 실수로 전체 차단 규칙이 들어갔을 때도 이전 버전으로 손쉽게 되돌릴 수 있다. 이 작은 습관 하나가, 뒤늦게 "왜 갑자기 검색 유입이 끊겼지"라며 원인을 추적하는 시간을 크게 줄여 준다.

자주 묻는 질문

robots.txt가 없으면 사이트에 문제가 생기나요?

문제가 생기지 않는다. robots.txt가 없으면 검색엔진은 제한이 없다고 판단하고 사이트 전체를 평소처럼 크롤링한다. 다만 관리자 화면이나 결제 진행 화면처럼 굳이 검색에 나올 필요가 없는 경로가 있다면, 짧게라도 파일을 만들어 두는 편이 정리에 도움이 된다.

robots.txt를 수정하면 바로 반영되나요?

아니다. 구글은 이 파일을 최대 24시간 정도 캐시해 두고 재사용한다. 급하게 반영해야 한다면 구글 서치 콘솔에서 다시 가져오기를 요청할 수 있지만, 일반적인 경우라면 하루 안팎을 기다리면 자연스럽게 새 규칙이 적용된다.

robots.txt로 이미 검색에 나온 페이지를 지울 수 있나요?

확실하게 지우는 방법은 아니다. robots.txt는 크롤링만 막을 뿐이라, 이미 다른 곳에서 링크가 걸려 있다면 설명 없는 형태로 검색 결과에 남을 수 있다. 확실히 빼고 싶다면 해당 페이지에 접근은 허용한 채로 noindex 메타 태그를 넣거나, 구글 서치 콘솔의 삭제 요청 기능을 사용해야 한다.

crawl-delay를 넣으면 구글봇 방문 속도가 느려지나요?

아니다. 구글은 crawl-delay 지시어를 아예 지원하지 않는다. 이 줄을 넣어도 구글봇은 그냥 지나친다. 구글의 크롤링 속도를 조절하고 싶다면 서치 콘솔의 관련 설정을 활용해야 하며, 빙이나 야후처럼 crawl-delay를 실제로 참고하는 검색엔진에만 이 지시어가 의미가 있다.

워드프레스는 robots.txt를 어떻게 관리하나요?

워드프레스는 기본적으로 가상의 robots.txt를 자동 생성한다. 별도 파일을 만들지 않아도 워드프레스가 기본 규칙을 알아서 내보내며, 직접 파일을 업로드하면 그 파일이 우선 적용된다. 대부분의 SEO 플러그인에서 robots.txt 내용을 화면에서 바로 수정할 수 있는 기능을 제공한다.

사이트맵을 robots.txt에 여러 개 적어도 되나요?

된다. Sitemap 지시어는 한 줄로 제한되지 않으며, 사이트맵이 여러 개라면 Sitemap: 줄을 필요한 만큼 추가하면 된다. 상품용, 블로그용, 이미지용 사이트맵이 따로 있는 대형 사이트에서 흔히 쓰는 방식이다.

robots.txt 문법에 오류가 있으면 사이트 전체가 위험해지나요?

규칙 하나의 오타가 사이트 전체에 영향을 줄 수 있으니 주의가 필요하다. 특히 Disallow: /처럼 슬래시 하나로 전체를 막는 실수가 가장 흔하고 파급력이 크다. 반면 존재하지 않는 지시어를 잘못 적었을 때는 대개 그 줄만 무시되고 나머지 정상 규칙은 그대로 작동한다. 그래도 수정 후에는 반드시 파일을 다시 열어 확인하는 습관이 중요하다.

하위 폴더에도 robots.txt를 넣었는데 왜 적용이 안 되나요?

검색엔진은 도메인 루트에 있는 robots.txt 하나만 인식한다. example.com/blog/robots.txt처럼 하위 폴더에 파일을 추가로 넣어도, 검색엔진은 이 파일의 존재 자체를 알지 못하고 그냥 지나친다. 블로그 영역만 따로 규칙을 주고 싶다면 루트의 robots.txt 안에 /blog/ 경로를 지정하는 방식으로 규칙을 추가해야 하며, 별도 파일을 여러 개 만드는 방식으로는 해결되지 않는다.

네이버에서도 robots.txt가 똑같이 적용되나요?

기본 원리는 같다. 네이버의 수집 로봇(예: 예티, Yeti)도 robots.txt의 User-agent와 Disallow 규칙을 참고한다. 다만 네이버 블로그(blog.naver.com)처럼 네이버 플랫폼 안에 개설한 블로그는 네이버가 자체적으로 수집·색인하므로 이 robots.txt 개념이 해당되지 않으며, 워드프레스나 자체 도메인으로 만든 홈페이지에만 이 파일이 의미를 가진다.

폴더 전체가 아니라 페이지 하나만 콕 집어 막을 수 있나요?

가능하다. Disallow 뒤에 폴더 경로 대신 정확한 파일 경로를 적으면 그 페이지 하나만 차단된다. 예를 들어 Disallow: /event/2025-summer-sale/는 그 이벤트 페이지 하나만 막고, 나머지 이벤트 페이지들은 그대로 검색에 노출된 상태를 유지한다. 다만 페이지 수가 많아질수록 이렇게 하나씩 나열하는 방식은 관리가 번거로워지므로, 공통된 주소 패턴이 있다면 와일드카드로 한 번에 정리하는 편이 유지보수에 유리하다.

이미지나 PDF 파일도 robots.txt로 막을 수 있나요?

가능하다. 확장자를 기준으로 와일드카드를 활용하면 특정 형식의 파일 전체를 한 번에 막을 수 있다. 예를 들어 Disallow: /*.pdf$는 사이트 안의 모든 PDF 파일을, Disallow: /images/private/는 특정 이미지 폴더만 차단한다. 다만 이미 다른 곳에 공개적으로 링크된 파일이라면, 앞서 설명한 것처럼 크롤링 차단만으로 완전히 숨겨지지 않을 수 있다는 점은 동일하게 적용된다.

User-agent 블록을 여러 개 만들면 어떻게 되나요?

로봇마다 서로 다른 규칙을 줄 수 있다. User-agent: * 블록으로 공통 규칙을 두고, 그 아래에 User-agent: 특정봇이름 블록을 따로 추가하면 그 로봇에게는 별도 규칙이 우선 적용된다. 특정 로봇을 지정한 블록이 있으면, 그 로봇은 공통 블록(*)이 아니라 자신에게 지정된 블록만 따른다는 점을 기억해야 한다. 그래서 특정 로봇 하나만 다르게 다루고 싶을 때는 그 블록 안에 필요한 규칙을 빠짐없이 다시 적어 주어야 한다.

robots.txt 규칙이 서로 충돌하면 어떤 것이 우선되나요?

가장 구체적인(가장 긴) 경로를 지정한 규칙이 우선한다. 앞서 문법 설명에서 다룬 것처럼, Disallow: /docs/와 Allow: /docs/guide.html이 함께 있다면 더 구체적인 Allow 규칙이 이겨서 그 파일 하나만 열린다. 규칙을 적은 순서는 우선순위에 영향을 주지 않으므로, "위에 적은 규칙이 무조건 이긴다"고 오해하지 않도록 주의해야 한다.

robots.txt와 .htaccess는 어떻게 다른가요?

둘은 목적 자체가 다르다. robots.txt는 검색엔진 로봇에게 크롤링 여부를 "부탁"하는 안내문이고, .htaccess는 서버 설정 파일로 특정 방문자나 요청을 실제로 "차단하거나 리다이렉트"하는 강제력을 가진다. 정말 접근 자체를 막고 싶다면 .htaccess나 서버 설정, 로그인 인증 같은 실질적인 장치를 함께 써야 하며, robots.txt만으로는 부탁 이상의 효력을 기대하기 어렵다.

모바일 전용 사이트는 robots.txt를 따로 만들어야 하나요?

모바일과 데스크톱이 같은 주소를 쓰는 반응형 사이트라면 robots.txt도 하나만 있으면 된다. 다만 m.example.com처럼 모바일 전용 서브도메인을 별도로 운영하는 구조라면, 앞서 설명했듯 서브도메인마다 별도의 robots.txt가 필요하므로 모바일 주소에도 똑같은 파일을 별도로 올려 두어야 한다.

아직 사이트가 완성되지 않았는데 robots.txt로 전체를 미리 막아 둬도 되나요?

개발 중인 사이트라면 임시로 전체를 막아 두는 것 자체는 합리적인 선택이다. 다만 이 글에서 계속 강조했듯, 이 설정을 걸어 둔 채 실제 서비스로 오픈하면서 지우는 것을 잊는 사고가 가장 흔하게 발생한다. 개발 단계에서 Disallow: /를 걸어 두었다면, 오픈 당일 체크리스트에 "robots.txt 전체 차단 해제 확인"을 반드시 포함시켜 두는 것을 권한다.

robots.txt 대신 메타 로봇 태그만 써도 충분하지 않나요?

둘은 역할이 달라 서로를 완전히 대체하지 못한다. 메타 로봇 태그(noindex 등)는 각 페이지 안에 넣는 방식이라 페이지 수가 많으면 하나하나 적용해야 하고, robots.txt는 폴더 단위로 한 번에 규칙을 걸 수 있어 훨씬 효율적이다. 반대로 색인에서 페이지를 확실히 빼고 싶다면 앞서 설명했듯 메타 로봇 태그 쪽이 더 정확하게 작동한다. 두 도구를 각자의 역할에 맞게 함께 쓰는 것이 정답이다.

robots.txt를 공개해도 보안상 문제가 없나요?

파일 자체는 공개되어도 괜찮지만, 내용 구성에는 주의가 필요하다. 이미 설명했듯 robots.txt는 누구나 열람할 수 있는 파일이므로, 여기에 적힌 폴더 이름은 사실상 공개된 정보다. 관리자 화면이나 백업 폴더처럼 민감한 경로는 robots.txt로 안내하는 대신 로그인·비밀번호·서버 접근 권한 같은 실질적인 보안 장치로 보호하고, robots.txt에는 크롤링 효율을 위한 최소한의 정보만 남기는 것이 안전하다.

마무리: 안내판부터 정확히 걸어 두자

robots.txt는 짧지만, 사이트 전체의 검색 노출과 맞닿아 있는 파일이다. 모든 로봇을 대상으로 하는 User-agent: *, 정말 불필요한 경로만 골라 막는 Disallow, 그리고 사이트맵 위치를 알려주는 Sitemap 세 가지만 정확히 갖추어도 대부분의 사이트에서는 충분하다.

오늘 배운 내용을 정리하면 이렇다.

• robots.txt는 크롤링 여부를 정하는 파일이지, 색인 여부를 정하는 파일이 아니다
• 파일은 반드시 도메인 루트에 정확한 소문자 이름으로 있어야 한다
• Disallow: / 한 줄이 사이트 전체를 차단할 수 있으니 발행 전 반드시 다시 확인한다
• 구글은 crawl-delay와 robots.txt 안의 noindex를 지원하지 않는다
• 2026년에는 AI 학습용 크롤러까지 이 파일로 개별 제어할 수 있다

지금 바로 자기 사이트 주소 뒤에 /robots.txt를 붙여 열어 보고, 이 글의 체크리스트와 대조해 보는 것으로 충분한 첫걸음이 된다.

무인도에 아무리 예쁜 호텔을 지어도 손님이 존재를 모르면 소용없다는 말이 있다. robots.txt는 반대로, 손님(검색엔진 로봇)이 호텔 안에서 길을 잃지 않도록 정리해 주는 안내판에 가깝다. 로비와 객실은 활짝 열어 두고, 직원 전용 통로나 보일러실 같은 곳만 정확히 표시해 두면, 손님은 꼭 봐야 할 곳을 더 빠르고 편하게 둘러볼 수 있다.

robots.txt처럼 작지만 중요한 설정 하나하나가 모여 검색에 강한 사이트를 만듭니다. 이루웹은 이런 기술적인 SEO 세팅부터 사이트 구조, 콘텐츠 전략까지 처음 설계 단계부터 함께 챙기는 웹 에이전시입니다. 우리 사이트의 robots.txt가 제대로 되어 있는지, 혹시 놓친 부분은 없는지 궁금하시다면 SEO 홈페이지 제작 서비스를 살펴보시고, 무료 상담으로 현재 사이트 상태를 진단받아 보시길 권해 드립니다. 작은 파일 하나까지 놓치지 않고 함께 챙겨 드리겠습니다.