HTML 메타 태그나 robots.txt를 올바르게 수정했음에도 특정 PDF 문서가 구글 검색 결과에 계속 노출되거나, 반대로 API 응답 데이터가 검색엔진에 무단 수집되는 경험을 해봤을 것이다. 다만 대부분의 개발자들은 서버 응답 헤더 수준에서 동작하는 X-Robots-Tag의 존재를 모른 채 HTML meta 태그만 고치다가 시간을 허비한다. 이번에는 X-Robots-Tag가 정확히 무엇인지, 왜 필요하며, Nginx와 Apache 및 PHP 환경에서 어떻게 완벽하게 설정하는지 정리해서 소개하겠다.
검색엔진 크롤러에 수집 및 색인 여부를 전달하는 방법은 크게 세 가지가 있다. 가장 흔히 쓰이는 HTML 메타 태그(<meta name="robots" content="...">)와 웹서버 루트의 robots.txt, 그리고 HTTP 응답 헤더로 전달하는 X-Robots-Tag다.
HTML 메타 태그는 HTML 문서 내부의 <head> 영역에 포함되어야 동작한다. 따라서 PDF 파일, 이미지는 물론이고 JSON이나 XML 형태의 API 응답 데이터에는 메타 태그를 삽입할 수 없다. robots.txt는 크롤러의 접근 자체를 막아주지만, 외부에서 해당 파일로 직접 링크를 걸어둔 경우 검색엔진이 '내용은 읽지 않은 채 URL만 색인'해버리는 문제가 발생한다.
X-Robots-Tag는 웹서버나 백엔드 애플리케이션이 HTTP 응답 헤더로 직접 전달하는 지침이다. 파일 형식을 가리지 않고 적용할 수 있으며, 색인 차단(noindex), 링크 추적 금지(nofollow), 캐시 저장 금지(noarchive) 등 기존 메타 태그의 모든 지시어를 동일하게 사용할 수 있다.
| 구분 | robots.txt | HTML Meta 태그 | X-Robots-Tag |
|---|---|---|---|
| 적용 위치 | 웹서버 루트 파일 | HTML <head> 내부 | HTTP 응답 헤더 |
| 적용 대상 | 전체 경로 및 파일 | HTML 문서 전용 | 모든 파일 (PDF, 이미지, API 등) |
| 크롤링 차단 | 가능 | 불가능 (크롤링 후 색인 판단) | 불가능 (크롤링 후 색인 판단) |
| 색인 완전 제외 | 불가 (URL만 등록될 수 있음) | 가능 | 가능 |
웹 서버 설정 또는 백엔드 코드 작성으로 특정 디렉터리나 파일 확장자에 X-Robots-Tag를 손쉽게 추가할 수 있다.
Nginx에서는 http, server, location 블록 내에서 add_header 지시어를 사용한다.
# 특정 확장자(PDF, DOCX) 파일의 검색 색인 및 캐시 차단
location ~* \.(pdf|docx)$ {
add_header X-Robots-Tag "noindex, noarchive, nosnippet" always;
}
Apache에서는 mod_headers 모듈이 활성화된 상태에서 .htaccess 또는 VirtualHost 설정 파일에 Header 지시어를 추가한다.
# uploads 디렉터리 내의 모든 파일 색인 차단
<Directory "/var/www/html/uploads">
Header set X-Robots-Tag "noindex, nofollow"
</Directory>
백엔드 로직에 따라 동적으로 색인 여부를 결정할 때는 header() 함수를 사용한다. Output이 출력되기 전에 실행해야 한다.
<?php
// 비회원 전용 동적 데이터 응답 시 색인 차단 헤더 전송
header("X-Robots-Tag: noindex, nofollow", true);
header("Content-Type: application/json;");
echo json_encode(["status" => "success", "data" => $privateData]);
?>
서비스 운영 중 개인정보가 포함된 PDF 서식 파일과 백엔드 REST API 경로가 구글 검색 노출로 유출되는 문제를 해결하는 실전 사례다.
robots.txt에만 경로를 등록하거나 Nginx 설정 시 always 옵션을 누락하여 4xx/5xx 에러 페이지 응답 시 헤더가 유실되는 경우다.
# ✗ 잘못된 예: always 구문이 없어 에러 응답 시 헤더가 누락됨
location /api/ {
add_header X-Robots-Tag "noindex";
proxy_pass http://backend_cluster;
}
Nginx location 블록에 always 키워드를 추가하고 curl 명령어로 응답 헤더를 검증한다.
# ✓ 올바른 예: 모든 상태 코드에서 헤더 전송 보장
location /api/ {
add_header X-Robots-Tag "noindex, nofollow" always;
proxy_pass http://backend_cluster;
}
터미널에서 curl -I 명령어로 해당 URL의 헤더를 호출하여 X-Robots-Tag가 정상 출력되는지 확인한다.
$ curl -I https://example.com/api/v1/users
HTTP/2 200
server: nginx
date: Mon, 15 Oct 2024 10:00:00 GMT
content-type: application/json
x-robots-tag: noindex, nofollow
✗ robots.txt에서 Disallow 처리를 해두고 X-Robots-Tag: noindex를 적용하는 것은 가장 흔한 실수다. robots.txt에 의해 크롤러의 접근이 차단되면 크롤러는 해당 문서의 HTTP 응답 헤더를 읽지 못한다. 결과적으로 검색엔진은 X-Robots-Tag 지시어를 확인하지 못해 기존의 색인을 삭제하지 않고 그대로 유지한다.
✓ 이미 색인된 문서나 API 주소를 구글 결과에서 완전히 지우려면, 먼저 robots.txt의 Disallow 구문을 제거해야 한다. 검색엔진 크롤러가 사이트에 방문해 HTTP 응답 헤더의 X-Robots-Tag: noindex를 읽어가도록 허용한 다음 색인이 삭제되었을 때 robots.txt를 다시 재설정하는 것이 올바른 순서다.
X-Robots-Tag 설정은 non-HTML 파일과 백엔드 API의 검색 노출을 정밀하게 제어하기 위한 핵심 기술이다. 서버 응답 헤더 레벨에서의 작은 설정 하나가 의도치 않은 보안 문서 유출을 막고 크롤링 예산을 효율적으로 관리하는 큰 효과를 만든다는 점을 잊지 말자. 이 글의 Nginx 및 Apache 서버 설정 부분을 참고해 웹 서버 응답 헤더를 점검하면, 검색엔진 수집 정책을 완벽하게 제어하는 결과를 얻을 수 있을 것이다.