WordPress 검색 엔진 차단 설정이 바꾸는 것
WordPress의 '검색 엔진이 이 사이트를 검색하는 것을 차단' 옵션이 출력하는 내용과 외부 확인 방법, Google에서 복구되는 과정을 설명합니다.
WordPress의 "검색 엔진이 이 사이트를 검색하는 것을 차단"(Discourage search engines from indexing this site) 체크박스를 선택하면 사이트의 모든 공개 페이지에 noindex, nofollow가 담긴 robots 메타 태그가 삽입됩니다. Google은 이 태그를 따릅니다. 태그가 있는 상태로 다시 크롤링한 페이지는 검색 결과에서 하나씩 빠지고, 새 페이지는 추가되지 않습니다. 비공개 스테이징 사본이라면 의도한 결과입니다. 하지만 Google에 노출되어야 하는 운영 중인 사이트라면 지금 바로 해제하십시오. 방문자에게는 아무 변화도 보이지 않는 사이, 사이트 전체가 재크롤링될 때마다 한 페이지씩 Google에서 사라집니다.
현재 WordPress에서 이 설정이 출력하는 것
체크박스는 설정 → 읽기 화면의 "검색 엔진 가시성" 행에 있으며, WordPress 설치 프로그램의 설정 화면에서도 같은 체크박스가 제공됩니다. 이 설정은 데이터베이스에 값 하나만 저장합니다. 바로 blog_public 옵션으로, 체크하면 0, 해제하면 1입니다. 이 값이 무엇을 바꾸는지 2026년 10월, 최신 릴리스가 7.1.3이던 시점의 WordPress 코어 소스로 확인했습니다.
- 모든 프런트엔드 페이지에 robots 메타 태그가 붙습니다. 테마의 표준 head 출력에 다음 줄이 포함됩니다.
<meta name='robots' content='noindex, nofollow' />
- 내장 XML 사이트맵이 꺼집니다.
/wp-sitemap.xml의 코어 사이트맵은 404를 반환하고, WordPress가 생성하는 robots.txt에서Sitemap:줄이 사라집니다. - robots.txt에 새로운 차단이 추가되지 않습니다. 생성되는 파일은 관리자 영역에 대한 평소의
Disallow와admin-ajax.php에 대한Allow를 그대로 유지합니다. - HTTP 헤더는 추가되지 않습니다. 코어는 이 설정 때문에
X-Robots-Tag헤더를 보내지 않으므로, 신호는 HTML에만 존재합니다. - 사이트는 공개 상태로 남습니다. 체크박스 아래에는 "이 요청이 받아들여지는 것은 전적으로 검색 엔진에 좌우됩니다."라는 문구가 있습니다. 방문자와 robots 메타 태그를 무시하는 크롤러는 여전히 모든 페이지를 읽을 수 있습니다.
- 관리자에게 표시되는 알림은 하나뿐입니다. 체크박스가 선택된 동안 알림판의 "사이트 현황" 위젯에 "검색 엔진을 차단했습니다"라는 줄이 표시됩니다.
대시보드가 스페인어라면 문구는 로케일에 따라 다릅니다. 2026년 10월에 확인한 WordPress 번역 프로젝트 기준으로, 이 라벨은 멕시코, 아르헨티나, 콜롬비아 등 여러 라틴 아메리카 로케일에서는 "Disuade a los motores de búsqueda de indexar este sitio", 스페인에서 쓰는 스페인어에서는 "Pedir a los motores de búsqueda que no indexen este sitio"로 표시됩니다. 대부분의 스페인어 로케일에서 이 행은 "Ajustes de lectura" 화면의 "Visibilidad en los motores de búsqueda"이며, 모든 스페인어 로케일에서 대시보드 문구는 "Motores de búsqueda disuadidos"입니다.
WordPress 버전에 따라 설정 동작이 어떻게 바뀌었는가
예전 버전을 기준으로 쓴 조언이 아직 돌아다니는데, 그 조언은 다른 동작 방식을 설명합니다. 코어 소스를 보면 3단계로 나뉩니다.
| 5.2 이하 | noindex,follow | 모든 크롤러에 Disallow: / |
| 5.3–5.6, 2019년 11월 12일부터 | noindex,nofollow | 관리자 영역만 차단 |
| 5.7 이상, 2021년 3월 9일부터 | noindex, nofollow | 관리자 영역만 차단 |
가장 중요한 것은 5.3의 변경입니다. 그 이전에는 생성된 robots.txt가 모든 크롤러에게 사이트 전체에 접근하지 말라고 지시했기 때문에, Google은 페이지를 가져오지 못했고 noindex 태그도 보지 못했습니다. 다른 사이트에서 링크된 URL은 크롤링되지 않은 채 Google 색인에 남을 수 있었고, Search Console은 이를 "robots.txt로 인해 차단되었으나 색인이 생성됨"으로 보고합니다. 이 충돌은 해당 상태를 다룬 글에서 설명합니다. 5.3부터 체크박스는 robots.txt를 건드리지 않고 메타 태그만 사용합니다. 현재 사이트에서 Disallow: /가 보인다면 그것은 실제 robots.txt 파일, 플러그인 또는 호스팅 업체에서 온 것이며, 이 체크박스 때문이 아닙니다.
이 설정이 운영 사이트에 남는 이유
흔한 경로는 이렇습니다. 스테이징 사이트를 올바르게 숨겨 두었다가, 출시할 때 그 데이터베이스를 복사합니다. 마이그레이션 플러그인, 호스팅 업체의 "운영 환경으로 배포(push to live)" 도구, 수동 내보내기와 가져오기는 모두 옵션 테이블을 옮기며, blog_public도 함께 옮겨집니다. 눈에 띄는 변화는 방문자가 읽지 않는 페이지 head의 한 줄뿐입니다.
Diagram source
sequenceDiagram
participant S as 스테이징 사이트
participant P as 운영 사이트
participant G as Googlebot
S->>S: 체크박스 선택, blog_public은 0
S->>P: 출시 시 데이터베이스 복사
P->>P: blog_public은 여전히 0
G->>P: 홈페이지와 글을 재크롤링
P-->>G: noindex, nofollow가 담긴 HTML
G->>G: 재크롤링한 페이지를 하나씩 검색 결과에서 제외SEOReport가 2026년 5월부터 10월까지 감사한 외부 웹사이트 45개 중 홈페이지에 noindex 지시어를 담아 제공한 곳은 HTML과 X-Robots-Tag 헤더를 통틀어 한 곳도 없었습니다. 이 정도 표본으로는 이 실수가 얼마나 흔한지 말할 수 없고, 일상적인 일이 아니라는 것만 알 수 있습니다. 하지만 한 번 발생하면 모든 공개 페이지에 동시에 적용되므로, 모든 출시 체크리스트에 들어가야 합니다.
대시보드 밖에서 설정을 확인하는 방법
중요한 것은 로그아웃한 방문자가 페이지 캐시나 CDN을 거친 뒤 받는 HTML입니다. Google이 가져가는 것이 바로 그것이기 때문입니다. example.com을 귀하의 도메인으로 바꾸고, 처음 2개 명령은 홈페이지뿐 아니라 글 2~3개에도 실행하십시오. -L 옵션은 리디렉션을 따라가므로, www 없는 도메인에서 www로 또는 HTTPS로 이동하더라도 최종 페이지가 가려지지 않습니다.
# 1. The robots meta tag in the served HTMLcurl -sL https://example.com/ | grep -io "<meta[^>]*name=.robots[^>]*>"# 2. Any noindex sent as an HTTP header insteadcurl -sL -o /dev/null -D - https://example.com/ | grep -i "x-robots-tag"# 3. What robots.txt actually servescurl -sL https://example.com/robots.txt# 4. Whether the core sitemap is switched offcurl -sL -o /dev/null -w "%{http_code}\n" https://example.com/wp-sitemap.xml
첫 번째 결과에 noindex가 있고 네 번째 결과가 404라면 이 설정과 일치합니다. SEO 플러그인이 코어 사이트맵을 자체 사이트맵으로 대체할 수 있으므로, 404만으로는 아무것도 증명되지 않습니다. 두 번째 결과에 noindex가 있다면 서버, 호스팅 업체, CDN 또는 플러그인이 만든 헤더 규칙이며, 체크박스로는 제거할 수 없습니다.
WordPress 안에서 가장 빨리 확인하는 방법은 대시보드의 "검색 엔진을 차단했습니다" 문구입니다. 명령줄을 쓸 수 있다면 wp option get blog_public이 체크된 상태에서는 0을, 해제된 상태에서는 1을 출력합니다.
Diagram source
flowchart TD
A["라이브 HTML에 robots 메타 noindex가 있는가?"] -->|"예"| B["blog_public이 0인가?"]
A -->|"아니요"| C["X-Robots-Tag 헤더에 noindex가 있는가?"]
C -->|"예"| D["서버, 호스팅 업체 또는 CDN 규칙 제거"]
C -->|"아니요"| E["라이브 페이지는 색인 가능: 재크롤링 요청"]
B -->|"예"| F["체크박스 해제 후 캐시 비우기"]
B -->|"아니요"| G["플러그인이나 테마가 noindex 추가: 해당 설정 확인"]
F --> H["홈페이지와 글의 라이브 HTML이 깨끗한가?"]
G --> H
H -->|"아니요"| I["캐시가 아직 이전 HTML 제공: 캐시 비우기"]
I --> H
H -->|"예"| J["URL 검사 라이브 테스트, 그다음 수정 결과 확인"]Search Console에서 이 설정이 보이는 방식
Google이 페이지를 재크롤링하면서 태그를 발견하면, 해당 페이지는 페이지 색인 생성 보고서의 "색인이 생성되지 않음" 쪽으로 옮겨지고 "URL이 'NOINDEX'로 표시됨"(URL marked ‘noindex’) 사유 아래에 나타납니다. 2026년 10월에 확인한 Google의 페이지 색인 생성 보고서 문서에 따르면, 이는 Google이 페이지의 색인을 생성하려 할 때 noindex 지시어를 발견해 색인을 생성하지 않았다는 뜻입니다. Google이 페이지마다 다른 시점에 재크롤링하므로 이 이동은 점진적으로 일어납니다. 이 상태의 다른 원인과 의도된 경우는 "URL이 'NOINDEX'로 표시됨" 상태 가이드에서 다룹니다.
URL 검사는 양쪽을 모두 보여 줍니다. 기본 보기는 Google이 마지막으로 색인을 생성한 버전을 설명하며, "색인 생성 허용 여부" 항목이 그 버전에서 색인 생성이 금지되었는지 알려 줍니다. "라이브 URL 테스트"는 지금 시점의 페이지를 가져옵니다. 수정한 뒤에는 라이브 테스트를 믿으십시오. 색인된 버전의 보기는 Google이 재크롤링한 뒤에야 바뀝니다.
출시 1일차부터 체크박스가 선택되어 있던 사이트는 보고서에 URL이 거의 표시되지 않을 수 있습니다. 코어 사이트맵이 꺼져 있고 nofollow가 각 페이지의 링크를 따라가지 말라고 Google에 요청하므로, Google이 발견할 단서가 거의 없기 때문입니다.
상황을 바꾸는 플러그인과 서버 규칙
SEO 플러그인은 robots 태그를 직접 관리합니다. 2026년 10월에 널리 쓰이는 플러그인 2개, Yoast SEO와 Rank Math의 소스를 읽어 보았습니다. 둘 다 체크박스가 선택된 동안에는 여전히 noindex를 강제하고, 관리자 영역에 경고를 띄웁니다. 어느 플러그인을 쓰든 해결책은 체크박스를 해제하는 것입니다.
같은 플러그인이 체크박스를 해제한 뒤에도 개별 글, 글 유형 또는 아카이브에 대한 자체 설정으로 noindex를 유지할 수 있습니다. 다른 플러그인이나 테마도 같은 WordPress robots 필터를 통해 지시어를 추가할 수 있습니다. 출시 후에도 켜져 있는 '오픈 예정'(coming soon) 플러그인이나 유지보수 모드 플러그인이 그 예입니다. blog_public이 1인데도 라이브 HTML에 noindex가 보인다면 이런 설정을 확인하십시오.
스테이징에서 넘어오는 잔재가 2가지 더 있습니다. Disallow: /가 담긴 실제 robots.txt 파일은 WordPress가 생성하는 파일보다 우선하므로, 출시 후 라이브 파일을 다시 확인하십시오. 사이트를 숨겨 둔 동안 플러그인으로 robots.txt 규칙을 저장했다면 특히 그렇습니다. X-Robots-Tag: noindex를 추가하는 헤더 규칙은 메타 태그와 똑같이 작동하지만 페이지 소스에는 나타나지 않습니다. 외부 확인에서 둘 다 읽는 이유가 이것입니다. 파일을 한 줄씩 읽는 방법은 robots.txt와 크롤링 접근 가이드에서 설명합니다.
복구 방법과 소요 기간
- 체크박스를 해제하고 저장하거나
wp option update blog_public 1을 실행합니다. - 모든 캐시 계층을 비웁니다. 페이지 캐시 플러그인, 호스팅 업체의 캐시, CDN이 모두 해당합니다. 캐시된 페이지는 만료될 때까지 이전 head를 계속 제공합니다.
- 홈페이지와 몇몇 글에 외부 확인을 다시 실행하고,
/wp-sitemap.xml또는 플러그인의 사이트맵이 이제 200을 반환하는지 확인합니다. - Search Console의 Sitemaps 보고서에서 사이트맵을 제출해, Google이 재크롤링할 URL의 전체 목록을 갖도록 합니다. 깨끗한 사이트맵에 무엇이 들어가야 하는지는 XML 사이트맵 가이드에서 다룹니다.
- 홈페이지와 가장 중요한 페이지에 URL 검사의 라이브 테스트를 실행한 뒤, 그 몇 개 페이지에 "색인 생성 요청"을 사용합니다. 이 도구에는 개별 URL 요청 할당량이 있으며, Google 문서에 따르면 같은 URL을 반복해서 요청해도 크롤링이 빨라지지 않습니다.
- 페이지 색인 생성 보고서에서 "URL이 'NOINDEX'로 표시됨"을 열고 "수정 결과 확인"을 선택합니다.
그다음에는 기다려야 합니다. 2026년 10월에 확인한 Google의 재크롤링 문서에 따르면 크롤링에는 며칠에서 몇 주까지 걸릴 수 있고, noindex 문서는 일부 페이지의 경우 다시 방문하기까지 몇 달이 걸릴 수 있다고 설명합니다. 페이지 색인 생성 보고서 문서에 따르면 수정 결과 확인에는 일반적으로 최대 약 2주가 걸리며, 경우에 따라 훨씬 더 오래 걸립니다. 색인 생성 여부는 여전히 Google이 결정합니다. URL 검사 문서에는 요청이 페이지의 색인 등록을 보장하지 않는다고 명시되어 있습니다.
다음 출시 때 같은 일이 생기지 않게 하는 방법
체크박스에 의존하지 말고, 서버나 호스팅 업체에서 HTTP 인증을 걸어 스테이징을 비밀번호로 보호하십시오. 로그인은 모든 방문자와 크롤러를 막습니다. 비밀번호로 보호된 사본에서는 체크박스를 해제해 두십시오. Google은 로그인 뒤의 페이지를 읽을 수 없으므로 체크박스가 그곳에서 더하는 효과는 없고, 그래야 운영 환경으로 복사된 데이터베이스에 noindex가 딸려 가지 않습니다. 그리고 출시 체크리스트에 한 줄을 추가하십시오. 운영 개시 직후와 데이터베이스 마이그레이션 또는 복원 후마다 운영 도메인에서 외부 확인을 실행한다는 항목입니다.
SEOReport의 전체 진단은 홈페이지의 robots 메타 태그와 X-Robots-Tag 헤더, 그리고 사이트맵에 나열된 페이지의 robots 메타 태그를 읽고, 검색엔진에 색인하지 말라고 지시하는 페이지를 하나하나 지목합니다. 이 설정은 항상 홈페이지에 noindex를 만들고, 홈페이지의 noindex는 심각한 발견 사항으로 보고되므로, 이 설정이 사이트맵까지 꺼 버린 경우에도 잡아낼 수 있습니다. 소유자나 호스팅이 자주 바뀌는 사이트라면 REST API로 주간 모니터링을 설정하십시오. 사이트를 다시 감사하고 새로운 심각한 발견 사항이 나타나면 이메일로 알려 줍니다. 사이트가 자기 페이지를 스스로 숨기는 더 넓은 패턴은 색인 가능성 충돌 데이터와 페이지 색인 가능성 가이드에서 다룹니다.
자주 묻는 질문
AI 크롤러도 차단합니까?
아닙니다. 이 설정은 robots.txt 규칙을 추가하지 않으며, AI 크롤러의 접근은 보통 robots.txt에서 제어합니다. 다만 Google 자체의 AI 기능에는 영향을 줍니다. 2026년 10월에 확인한 Google의 AI 기능 문서에 따르면 페이지가 AI 개요나 AI 모드에서 참고 링크로 표시되려면 색인이 생성되어 있어야 하므로, noindex가 적용된 페이지는 그곳에서도 빠집니다. 체크박스는 AI 정책이 아니라 검색 색인 생성에 관한 요청으로 보십시오. AI 크롤러 정책을 의도적으로 설정하는 방법은 robots.txt의 AI 크롤러 결정표에서 다룹니다.
몇 주 전에 체크박스를 해제했는데 페이지가 여전히 "URL이 'NOINDEX'로 표시됨"으로 나옵니다. 왜 그렇습니까?
Search Console은 각 페이지를 마지막으로 크롤링했을 때 Google이 본 내용을 보고합니다. 먼저 "라이브 URL 테스트"를 실행하십시오. 라이브 테스트에서도 noindex가 발견된다면 캐시, 플러그인 또는 헤더 규칙이 이를 제공하고 있는 것입니다. 라이브 테스트가 깨끗하다면 페이지는 재크롤링을 기다리는 중이며, "수정 결과 확인"과 사이트맵 제출이 올바른 다음 단계입니다.
운영 중인 사이트를 리디자인하는 동안 체크박스를 켜 두어도 안전합니까?
아닙니다. 이 설정은 운영 중인 사이트에 적용되므로, 리디자인 기간에 Google이 재크롤링하는 모든 페이지가 검색 결과에서 빠집니다. 리디자인은 비밀번호로 보호된 스테이징 사본에서 진행하십시오.