워드프레스 robots.txt 빈 화면·404 해결: 응답 코드·가상 파일·플러그인 진단

/robots.txt가 빈 화면이나 404로 보일 때는 파일 편집부터 하지 말고 HTTP 응답 코드와 본문 유형을 먼저 확인해야 합니다. 워드프레스는 물리적인 robots.txt 파일이 없어도 가상 응답을 만들 수 있으며, SEO 플러그인·웹서버·CDN이 서로 다른 계층에서 같은 경로를 처리할 수 있습니다.

잘못된 robots.txt는 검색엔진의 크롤링 범위를 바꿀 수 있습니다. 반대로 robots.txt가 없다고 해서 기존 페이지가 자동으로 검색 결과에서 삭제되는 것도 아닙니다. 문제를 해결할 때는 현재 응답을 저장하고, 변경 전후를 비교하며, Disallow 규칙을 추측으로 추가하지 않아야 합니다.

1단계: 화면이 아니라 HTTP 응답을 확인합니다

브라우저는 빈 본문, 다운로드 응답과 HTML 오류 페이지를 비슷하게 보여 줄 수 있습니다. 터미널이나 개발자 도구에서 헤더와 원문을 확인하세요.

curl -i https://example.com/robots.txt
curl -sS https://example.com/robots.txt | sed -n '1,80p'

결과	의미	다음 확인
200 + text/plain	정상 후보	본문 규칙과 Sitemap URL 확인
200 + 빈 본문	생성·캐시·출력 문제	원본 서버와 CDN 응답 비교
404	라우팅 또는 파일 부재	워드프레스 고유주소·웹서버 규칙 확인
200 + text/html	오류 페이지나 홈페이지가 반환됨	리라이트·캐시·보안 규칙 확인
301/302 반복	호스트·HTTPS 리디렉션 충돌	최종 URL과 프록시 설정 확인

curl -L로 최종 응답을 볼 수 있지만, 중간 리디렉션도 함께 기록하세요. www와 비www, HTTP와 HTTPS가 서로 다른 파일을 반환하면 검색엔진과 브라우저에서 결과가 달라질 수 있습니다.

2단계: 물리 파일과 워드프레스 가상 응답을 구분합니다

웹 루트에 실제 robots.txt가 있으면 보통 웹서버가 먼저 제공합니다. 파일이 없으면 워드프레스가 요청을 받아 가상 robots.txt를 생성할 수 있습니다.

1. 호스팅 파일 관리자나 SSH에서 문서 루트의 robots.txt 존재 여부를 확인합니다.
2. 물리 파일이 있다면 백업하고 권한·인코딩·줄바꿈을 확인합니다.
3. 파일이 없다면 워드프레스 고유주소와 프런트 컨트롤러가 /robots.txt를 처리하는지 확인합니다.
4. 스테이징 환경에서 물리 파일을 임시 이름으로 바꿔 가상 응답과 비교할 수 있습니다.

운영 서버에서 즉시 삭제하거나 이름을 바꾸기 전에 현재 파일을 내려받고 복구 경로를 확보하세요. 일부 호스팅은 배포 과정에서 파일을 다시 생성할 수 있습니다.

3단계: 워드프레스 설정을 확인합니다

설정 → 읽기의 ‘검색엔진이 이 사이트를 검색하지 못하도록 요청’ 옵션은 사이트가 색인되면 안 된다는 신호를 출력할 수 있습니다. 이 옵션이 켜져 있다고 robots.txt가 반드시 빈 화면이 되는 것은 아니지만, 공개 사이트라면 의도한 설정인지 확인해야 합니다.

SEO·보안·캐시 플러그인이 robots.txt를 편집하거나 가상 경로를 가로채는 경우도 있습니다. 플러그인을 모두 끄기보다 다음 순서로 범위를 줄입니다.

• 최근 변경·업데이트한 플러그인의 robots 기능 확인
• 스테이징에서 관련 기능만 비활성화
• 페이지 캐시·객체 캐시·CDN 캐시를 계층별로 삭제
• 원본 서버 주소와 공개 도메인의 응답 비교

4단계: 웹서버와 CDN 라우팅을 확인합니다

Nginx·Apache·Cloudflare 규칙이 /robots.txt를 다른 파일이나 애플리케이션으로 보낼 수 있습니다. 다음 항목을 찾습니다.

• Nginx의 location = /robots.txt 또는 정적 파일 규칙
• Apache .htaccess의 RewriteRule
• CDN Redirect Rule·Transform Rule·Worker
• 보안 솔루션의 봇 차단·챌린지 페이지
• 다중 사이트·다국어 플러그인의 호스트별 라우팅

설정 파일을 수정할 때는 백업하고 문법 검사 후 reload합니다. Nginx는 nginx -t, Apache는 배포 환경의 설정 검사 명령을 먼저 사용하세요. 현재 SSH 세션을 유지하고 별도 창에서 새 연결이 되는지 확인합니다.

최소 robots.txt 예시

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

이 예시는 모든 공개 경로 크롤링을 허용하는 단순 형태입니다. 관리자·검색·매개변수 경로를 차단할지 여부는 사이트 구조와 검색엔진 동작을 이해한 뒤 결정하세요. robots.txt는 접근 제어 장치가 아니므로 비밀 URL이나 개인정보를 보호하는 용도로 쓰면 안 됩니다.

수정 후 검증

1. 200 상태와 text/plain 응답을 확인합니다.
2. 대표 검색엔진 User-agent에 적용되는 규칙을 파싱합니다.
3. Sitemap URL이 200과 유효한 XML을 반환하는지 확인합니다.
4. 중요 페이지가 실수로 차단되지 않았는지 확인합니다.
5. Search Console의 robots.txt 보고와 URL 검사에서 실제 수집 결과를 봅니다.
6. CDN 캐시 만료 후에도 같은 응답이 유지되는지 재확인합니다.

자주 하는 실수

• 404를 해결하려고 루트 파일을 만들었지만 다른 배포에서 덮어씁니다.
• Disallow: /를 테스트 후 제거하지 않습니다.
• HTML 200 오류 페이지를 정상 robots.txt로 오해합니다.
• 캐시를 한 계층만 삭제해 원본과 외부 응답이 다릅니다.
• robots.txt로 URL 색인을 완전히 막을 수 있다고 생각합니다.

robots.txt 문제는 파일 하나의 문제가 아니라 요청 경로를 처리하는 계층의 문제입니다. 상태 코드 → 콘텐츠 유형 → 물리 파일 → 워드프레스 → 플러그인 → 웹서버·CDN 순으로 확인하면 위험한 추측을 줄일 수 있습니다.

공식 자료

• Google Search Central: robots.txt 소개
• WordPress.org: 검색엔진 가시성