WordPress robots.txt 파일에는 무엇이 들어가야 하나요?

네 가지면 충분하고 그 이상은 필요 없습니다. 와일드카드 user-agent 줄, /wp-admin/에 대한 Disallow, /wp-admin/admin-ajax.php에 대한 Allow, 그리고 전체 사이트맵 URL을 가리키는 Sitemap 지시문입니다. 그 밖의 것은 모두 선택 사항이며, 인터넷에 떠도는 긴 차단 목록 대부분은 해결하는 문제보다 만드는 문제가 더 많습니다.

WordPress가 robots.txt 파일을 자동으로 만들어 주나요?

만들어 주지만 가상 파일일 뿐입니다. /robots.txt로 요청이 들어왔을 때 디스크에 실제 파일이 없으면 WordPress가 메모리에서 응답을 생성합니다. 여기에는 wp-admin 규칙이 들어가고, 5.5 버전부터는 wp-sitemap.xml을 가리키는 Sitemap 줄도 포함됩니다. 서버에 기록되는 것은 아무것도 없습니다.

제 robots.txt가 WordPress가 출력해야 할 내용과 다른 이유는 뭔가요?

거의 항상 웹 루트에 물리적인 robots.txt 파일이 존재하기 때문입니다. 웹 서버가 그 파일을 그대로 내보내고 WordPress는 아예 실행되지 않으므로, 가상 출력과 robots_txt 필터가 둘 다 조용히 무시됩니다. 다른 것을 살펴보기 전에 사이트 루트에 실제 파일이 있는지 확인하세요.

robots.txt에서 wp-content나 wp-includes를 막아야 하나요?

아니요. 그 디렉터리에는 페이지 렌더링에 필요한 CSS, JavaScript, 이미지가 들어 있습니다. 이를 막으면 Google이 해당 자원을 가져오지 못해 깨진 레이아웃을 기준으로 페이지를 평가합니다. 예전에는 흔한 조언이었지만 지금은 오히려 해롭습니다.

robots.txt로 페이지를 Google에서 빠지게 할 수 있나요?

아니요. robots.txt는 색인이 아니라 크롤링을 통제합니다. 차단된 URL이라도 다른 페이지가 링크하면 색인될 수 있고, 설명 없이 결과에 나타납니다. 페이지를 색인에서 빼려면 크롤링을 허용하고 noindex 메타 로봇 태그나 X-Robots-Tag 헤더를 내보내야 합니다.

robots.txt가 보안 수단이 되나요?

정반대입니다. 이 파일은 yoursite.com/robots.txt에서 누구나 볼 수 있는 공개 파일이라, 비공개 디렉터리를 적어 두면 그 위치를 광고하는 셈입니다. 예의 바른 크롤러만 자발적으로 지키고 악성 스캐너는 완전히 무시합니다. 민감한 경로는 인증이나 서버 규칙으로 보호하세요.

2026년 WordPress robots.txt 모범 사례 (실제로 넣어야 할 내용)

좋은 WordPress robots.txt는 다섯 줄 정도입니다. /wp-admin/을 막고, admin-ajax.php를 허용하고, 크롤러에게 사이트맵을 알려 주면 끝입니다. 포럼에서 보게 되는 40줄짜리 차단 목록은 대부분 렌더링을 망가뜨리거나 아무 일도 하지 않습니다. 파일 전체는 이렇습니다.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

도메인만 바꾸고, 사이트맵을 대신 관리하는 SEO 플러그인을 쓴다면 Sitemap 줄을 그 플러그인의 인덱스로 지정하세요. 그게 다입니다. 파일이 이보다 길다면 늘어난 줄들이 아마 무언가를 잃게 하고 있을 겁니다.

WordPress가 이미 하나 만들어 준다 — 실제 파일을 만들기 전까지는

WordPress에는 가상 robots.txt가 있습니다. /robots.txt 요청이 들어왔는데 웹 루트에 실제 파일이 없으면, WordPress가 요청을 가로채 메모리에서 응답을 출력합니다. 디스크에 기록되는 것은 없습니다. 기본 출력은 위의 wp-admin 차단 규칙과, WordPress 5.5부터 코어가 내보내는 wp-sitemap.xml용 Sitemap: 줄입니다.

이 출력을 바꾸는 요인은 두 가지입니다. 설정 → 읽기 → 검색 엔진이 이 사이트를 색인하지 않도록 요청 항목이 체크되어 있으면, WordPress는 전체 내용을 Disallow: /로 바꿔 모든 것을 차단합니다. 이 체크박스는 사이트를 오픈한 뒤 검색에서 사라지는 가장 흔한 원인입니다. 둘째로, 플러그인과 테마는 robots_txt 필터를 통해 가상 출력을 수정할 수 있는데, SEO 플러그인이 자체 사이트맵 줄과 규칙을 넣는 방식이 바로 이것입니다.

이제 사람들의 오후를 통째로 날려 먹는 부분입니다. 웹 루트에 있는 물리적 robots.txt 파일은 위의 모든 것을 조용히 덮어씁니다. 웹 서버가 디스크의 실제 파일을 찾아 그대로 내보내고, WordPress는 아예 로드되지 않습니다. 가상 생성기는 동작하지 않습니다. robots_txt 필터도 실행되지 않습니다. SEO 플러그인의 robots.txt 편집기는 여전히 올바른 규칙이 담긴 그럴듯한 화면을 보여 주겠지만, 그중 무엇도 크롤러에게 도달하지 않습니다.

규칙이 있는 곳	WordPress 관리자에서 수정 가능	실제 요청에서 우선
가상 (디스크에 파일 없음)	가능. `robots_txt` 필터나 플러그인으로	물리 파일이 없을 때만
웹 루트의 물리 파일	플러그인이 디스크에 쓰는 경우에만	항상

그러니 무엇을 살펴보기 전에 먼저, 브라우저에서 https://yoursite.com/robots.txt를 열어 보고, SFTP나 호스팅의 파일 관리자로 접속해 wp-config.php, .htaccess 옆에 실제 robots.txt가 있는지 확인하세요. 있다면 그 파일이 여러분의 robots.txt입니다. 거기서 수정하거나, 지우고 WordPress에 맡기세요. 다만 하나만 고르세요. 둘을 같이 굴리는 것이 아무도 찾을 수 없는 낡은 사이트맵 URL이 남는 이유입니다.

/wp-admin/은 막는데 admin-ajax.php는 허용하는 이유

/wp-admin/에는 대시보드가 있습니다. 그 URL들은 검색 결과에서 쓸모가 없고, 크롤링해 봐야 로그인 화면으로 리다이렉트되는 페이지에 크롤링 예산만 씁니다. 이 디렉터리를 막는 데는 이견이 없습니다.

admin-ajax.php는 같은 디렉터리 안에 있지만 관리자 페이지가 아닙니다. 더 보기 버튼, 필터가 적용된 상품 목록, 계산기, 폼 같은 프런트엔드 AJAX 요청을 플러그인과 테마가 처리할 때 쓰는 엔드포인트죠. 크롤러가 이걸 가져오지 못하면 그 기능들이 불러오는 콘텐츠를 볼 수 없고, Google은 해당 기능이 깨진 상태의 페이지를 방문자가 보는 그대로 렌더링하게 됩니다.

내 사이트에서 Google이 실제로 admin-ajax.php를 가져올 필요가 있는지는 프런트엔드가 그것을 쓰는지에 달려 있습니다. 솔직히 말하면 요즘 많은 사이트에서는 아무 상관이 없습니다. 테마가 /wp-json/의 REST API를 대신 쓰기 때문이죠. 이 Allow 줄은 순위 요소가 아니라 실제로 발생할 수 있는 고장에 대한 값싼 보험입니다. 비용이 들지 않으니 그냥 두세요.

/wp-content/나 /wp-includes/는 막지 마세요

아직까지 돌아다니는 robots.txt 조언 중 가장 나쁜 것이며, Google이 페이지를 렌더링하지 않던 시절의 유물입니다.

/wp-content/에는 테마, 플러그인, 업로드 파일, 즉 페이지를 페이지답게 만드는 스타일시트와 스크립트, 이미지가 들어 있습니다. /wp-includes/에는 플러그인이 의존하는 코어 JavaScript가 있습니다. Google은 페이지를 평가하기 전에 헤드리스 브라우저로 렌더링합니다. 이 디렉터리들을 막으면 렌더러는 CSS도 이미지도 없는 페이지를 받게 됩니다. Google이 평가하는 것은 레이아웃이 깨진 채 스타일 없는 텍스트 덩어리이고, 이는 콘텐츠 이해 방식과 모바일 사용성 점수에 영향을 줍니다.

이런 줄이 들어 있는 파일을 물려받았다면 지우세요.

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

피해는 Google Search Console의 URL 검사 도구로 직접 확인할 수 있습니다. 아무 페이지나 실시간 테스트를 돌리고 렌더링된 스크린샷을 본 뒤, 페이지 리소스 목록에서 차단된 항목을 확인하세요. CSS가 차단으로 표시된다면 그게 원인입니다.

Sitemap 지시문

한 줄, 절대 URL이며, 파일 어디에 있어도 됩니다. User-agent 그룹에 묶이지 않습니다.

Sitemap: https://example.com/wp-sitemap.xml

실제로 열리는 URL을 쓰세요. WordPress 코어는 wp-sitemap.xml을 제공합니다. 대부분의 SEO 플러그인은 코어 사이트맵을 끄고 보통 sitemap_index.xml 같은 다른 경로에 자체 인덱스를 내보냅니다. 확정하기 전에 브라우저에서 URL을 열어 보세요. 404를 가리키는 Sitemap 줄은 감사에서는 멀쩡해 보이기 때문에 아예 없는 것보다 나쁩니다.

여러 사이트맵을 한 줄에 하나씩 나열해도 괜찮습니다. Search Console에 사이트맵을 따로 제출하는 것도 여전히 할 만한 일입니다. robots.txt의 지시문은 내 Search Console 계정을 볼 일이 없는 크롤러가 사이트맵을 찾는 경로입니다.

robots.txt는 noindex가 아니고, 보안도 아니다

이 두 가지 오해가 robots.txt로 인한 피해의 대부분을 만듭니다.

URL을 차단해도 Google에서 사라지지 않습니다. robots.txt는 크롤링을 관장합니다. 다른 사이트가 차단된 URL로 링크하면 Google은 URL 자체를 색인할 수 있고, 그러면 주소만 덩그러니 나오고 정보를 제공할 수 없다는 안내가 붙은 결과가 나타납니다. 더 고약한 함정도 있습니다. 이미 noindex 메타 태그가 있는 페이지를 robots.txt에서 차단하면 Google은 그 페이지를 크롤링할 수 없어 noindex를 볼 수 없고, 페이지는 무기한 색인 상태로 남을 수 있습니다. 페이지를 빼려면 크롤링을 허용하고 페이지 head에 noindex 메타 로봇 태그를 넣거나 X-Robots-Tag HTTP 헤더를 내보내세요. Google은 2019년에 robots.txt 안의 noindex 지시문 지원을 중단했습니다.

경로를 차단한다고 그 경로가 보호되지는 않습니다. robots.txt는 정의상 공개 파일입니다. /private-client-files/를 적어 두면 모든 방문자와 모든 스캐너에게 어디를 봐야 하는지 정확히 알려 주는 셈이고, 준수 여부는 자발적입니다. Google은 지키지만 악성 봇은 지키지 않습니다. 보호가 필요한 것은 인증이나 IP 제한, .htaccess의 서버 단 규칙이 필요하지, 목표물을 광고하는 텍스트 파일 한 줄이 필요한 게 아닙니다.

추가할 만한 규칙과 넘겨도 되는 규칙

많은 사이트에서 정말 유용한 추가는 두 가지입니다. 검색 결과 경로를 막으면 크롤러가 내부 검색으로 가치 없는 URL을 끝없이 만들어 내는 것을 막을 수 있습니다. WooCommerce에서 장바구니나 결제 경로를 막으면 세션 파라미터가 붙은 URL이 크롤링 대상에서 빠집니다.

Disallow: /?s=
Disallow: /search/

다음은 건너뛰세요.

Crawl-delay — Google은 완전히 무시합니다. 실제로 서버 부하 문제가 있다면 Search Console의 크롤링 속도 설정을 쓰세요.
/feed/나 /trackback/ 차단 — 무해한 URL이고 피드는 쓸모가 있습니다.
개별 봇 이름을 길게 나열하기 — 사람들이 막으려는 봇 대부분은 애초에 정직하게 자신을 밝히지 않습니다.
/wp-json/ 차단 — 테마가 콘텐츠를 렌더링하는 데 쓰고 있을 수 있습니다.

WordPress robots.txt 생성기로 파일을 만들면 최소한의 올바른 버전을 얻고, 문법을 손으로 고치지 않고도 검색·커머스 규칙을 추가할 수 있습니다.

수정한 뒤에

https://yoursite.com/robots.txt를 직접 열어서, 플러그인 편집기가 보여 주는 내용이 아니라 실제로 전송되는 바이트가 기대한 대로인지 확인하세요. 그다음 Search Console에서 일반 페이지 하나에 실시간 URL 검사를 돌려 CSS나 JavaScript 리소스가 차단으로 돌아오지 않는지 확인하세요. Google은 robots.txt를 하루 정도 캐시하므로 수정이 즉시 반영되지 않고, 실수도 마찬가지입니다. 그 지연이야말로 실서비스에서 시험하고 기다리기보다 꼼꼼히 검증해야 하는 이유입니다.