워드프레스 설치 사이트 GEO 측정은 캐시·실제 IP·봇 신원부터 맞춘다

워드프레스 설치 사이트에 서버사이드 GEO(생성형 엔진 최적화) 측정을 붙일 때는 세 가지를 먼저 맞춥니다. 첫째는 캐시 계층이 대신 응답해 기록에서 빠지는 요청이고, 둘째는 CDN 뒤에서 가려지는 실제 IP입니다. 셋째는 이름만 봇인 요청을 걸러 내는 신원 대조입니다.

여기에 robots.txt 실제 응답과 고유주소 기준까지 맞춰야 페이지 단위 기록을 기간끼리 비교할 수 있습니다.

기록 지점은 어느 계층에 두어야 하나요?

워드프레스로 가는 요청은 여러 계층을 지납니다. 앞 계층이 저장한 응답을 돌려주면 뒤 계층에는 기록이 남지 않습니다.

WordPress 고급 관리 문서에 따르면 캐시 플러그인은 글과 페이지를 정적 파일로 저장해 내보냅니다. 이 문서는 웹서버 앞에 두는 리버스 프록시(웹서버 앞에서 요청을 대신 받는 서버) 캐시도 소개합니다.

기본 기록 지점은 웹서버 접근 로그로 둡니다. 플러그인 방식 기록은 캐시가 응답한 요청을 놓칠 수 있어 보조로만 씁니다. CDN이 HTML을 캐시한다면 CDN 쪽 기록도 함께 받습니다.

Apache 문서의 결합 로그 형식(Combined Log Format)은 한 줄에 아홉 항목을 남깁니다. 요청 IP, identd 정보, 인증 사용자, 시각, 요청 줄, 상태 코드, 전송 크기, Referer, User-Agent 순서입니다.

identd 정보는 접속한 클라이언트 쪽에서 알려 주는 식별값입니다. Apache는 별도 설정을 켜지 않으면 이 값을 구하지 않으므로 보통 하이픈(-)으로 남습니다. 인증 사용자 칸도 정보가 없으면 하이픈입니다.

User-Agent는 사용자 에이전트, 곧 요청을 보낸 프로그램 이름입니다. 로그를 나눌 때 칸 위치를 이 순서대로 잡아야 봇 이름을 정확히 읽을 수 있습니다.

Apache 문서는 어느 정도 요청이 있는 서버에서도 접근 로그가 요청 1만 건마다 보통 1MB 이상 늘어난다고 설명합니다. 그래서 순환(rotation, 일정 주기로 새 파일에 기록하는 방식)을 설정하라고 권합니다.

이 문서에 따르면 내장 rotatelogs를 파이프로 연결하면 재시작 없이 파일이 바뀝니다. 외부 도구로 옛 파일을 옮기는 방식이라면 서버가 로그 파일을 다시 열도록 알려야 합니다. 문서가 제시하는 표준 방법은 접속을 끊지 않는 재시작(graceful restart)입니다.

보관 기간은 비교 기간보다 길게 잡습니다. 예를 들어 가상의 ○○ 기업이 월 단위로 비교한다면 적어도 두 달치가 있어야 전월과 비교할 수 있습니다.

완료 기준: 기본 기록 지점 한 곳과 로그 형식·순환 방식·보관 기간이 문서로 정해져 있습니다.

캐시와 CDN 뒤에서 빠지는 요청과 실제 IP는 어떻게 확인하나요?

CDN 캐시가 바꾸는 요청 수

CDN마다 기본 캐시 대상이 다르므로 사용하는 서비스의 문서를 먼저 확인합니다. Cloudflare를 예로 들면, 이 회사 문서는 기본 설정에서 HTML과 JSON을 캐시하지 않는다고 설명합니다. 이 경우 페이지 요청은 원 서버까지 옵니다.

같은 문서는 모든 항목을 캐시하는 규칙을 만들 수 있다고 안내합니다. 이 규칙을 쓰면 HTML도 CDN에서 바로 응답할 수 있습니다.

또 이 문서는 Cloudflare가 기본 설정에서 사이트의 robots.txt를 캐시한다고 적고 있습니다. 원 서버 로그에 robots.txt 요청이 적게 보여도 수집이 줄었다고 단정할 수 없습니다.

로그에 남는 IP와 실제 요청 IP

Cloudflare 문서에 따르면 별도 설정이 없으면 원 서버 로그에 Cloudflare IP가 남습니다. 원래 방문자 IP는 CF-Connecting-IP 헤더에 따로 실려 옵니다. 다른 CDN도 실제 IP를 별도 헤더로 넘기는 경우가 있으므로 그 서비스의 헤더 이름을 확인합니다.

Cloudflare 안내서는 이 헤더를 Apache의 mod_remoteip나 Nginx의 realip 모듈로 읽는 방법을 제시합니다. Apache에서는 신뢰할 프록시 주소로 Cloudflare IP 대역을 지정하도록 안내합니다. Nginx의 대역 목록은 정기적으로 갱신해야 한다고 덧붙입니다.

이 안내서는 Cloudflare IP에서 온 트래픽만 받지 않으면 헤더가 위조될 수 있다고 권고합니다. 헤더가 위조되면 로그의 IP 자체를 믿을 수 없습니다. 실무에서는 이 설정을 봇 신원 대조의 전제로 보는 방법을 권합니다.

캐시 플러그인이 가리는 요청 시험

캐시 때문에 빠지는 요청은 아래 순서로 확인합니다.

1. 측정할 글을 하나 고릅니다.
2. 평소 트래픽과 섞이지 않는 시험용 사용자 에이전트(예: GEO-TEST-1020)를 정합니다.
3. 그 사용자 에이전트로 같은 주소를 두 번 요청합니다.
4. 기본 기록 지점에 두 줄이 모두 남았는지 확인합니다.
5. 플러그인 방식 기록도 쓴다면 그쪽에도 두 번 남았는지 비교합니다.
6. 한쪽에만 남았다면 캐시 계층을 원인으로 보고 기본 기록 지점을 다시 정합니다.

완료 기준: 시험 요청 두 건이 기본 기록 지점에 실제 요청 IP와 함께 남아 있습니다.

워드프레스 robots.txt의 실제 응답은 어떻게 확인하나요?

WordPress 개발자 문서에 따르면 do_robots 함수가 기본 robots.txt 내용을 출력합니다. 기본 내용은 모든 크롤러에 적용되며, 관리자 영역은 막고 admin-ajax.php는 허용합니다.

출력은 robots_txt 필터를 거치므로 이 필터를 쓰는 플러그인이 내용을 바꿀 수 있습니다. 관리 화면 설정과 실제 응답이 다를 수 있으므로, 브라우저나 명령줄로 실제 주소를 요청해 받은 내용을 기준으로 기록합니다.

이 함수 문서는 5.3 버전부터 검색 엔진 노출 차단 설정을 켜도 robots.txt에 전체 차단 줄이 들어가지 않는다고 적고 있습니다. 이 역할은 페이지의 robots 메타 태그가 맡습니다. 이 설정을 robots.txt 차단으로 기록하면 해석이 틀어집니다.

Google 문서는 robots.txt를 보통 최대 24시간 캐시한다고 설명합니다. 429를 뺀 4xx 응답은 파일이 없는 것으로 봅니다. 5xx 응답이 오면 처음 12시간은 크롤링을 멈춥니다.

OpenAI 문서도 검색 관련 robots.txt 변경이 반영되는 데 24시간 정도 걸릴 수 있다고 안내합니다. 그래서 robots.txt를 바꿀 때마다 변경 시각과 응답 상태를 기록합니다. 변경 뒤 하루는 비교 구간에서 따로 표시합니다.

완료 기준: 실제 응답 내용과 상태 코드(5xx가 아닌 값), 확인 시각이 기록되어 있습니다.

워드프레스 주소는 페이지 단위로 어떻게 맞추나요?

WordPress 고유주소(퍼머링크, 글마다 고정된 주소) 설정 안내서는 여러 구조를 제시합니다. 기본형(?p=123), 날짜와 이름, 월과 이름, 숫자형, 글 이름, 사용자 정의 구조입니다. 구조를 바꾸면 같은 글이 다른 주소로 로그에 남습니다.

이 안내서에 따르면 .htaccess에 쓰기 권한이 없을 때는 화면에 나온 재작성 규칙을 직접 넣어야 새 고유주소가 작동합니다. 구조를 바꾼 직후에는 새 주소의 상태 코드부터 확인합니다.

실무에서는 페이지 단위로 묶기 전에 아래 네 가지 정규화 규칙을 문서로 정하는 방법을 권합니다.

1. 쿼리 문자열은 원래 주소와 함께 보관하되 집계 키에서는 뺍니다. 기본형 고유주소를 쓰는 사이트라면 글을 가리키는 p 값만 남깁니다.
2. 끝 슬래시는 사이트가 실제로 쓰는 형태 하나로 통일합니다.
3. 한글 주소가 퍼센트 인코딩 형태로 기록되는지 먼저 로그에서 확인하고, 디코딩한 한 형태로 맞춥니다.
4. 고유주소를 바꿨다면 글 ID, 옛 주소, 새 주소를 한 행에 적은 대응표를 만듭니다. 이 표로 두 주소를 같은 글로 묶습니다.

관리자 영역과 admin-ajax.php 요청은 콘텐츠 페이지가 아니므로 따로 집계합니다. 아래는 그대로 옮겨 쓸 수 있는 측정 환경 기록표입니다.

완료 기준: 기록표가 모두 채워져 있습니다.

봇 신원 확인은 어느 단계에서 하나요?

Google 문서는 로그 IP를 확인하는 방법으로 DNS 조회와 공개 IP 목록 대조를 제시합니다. DNS 조회는 host 명령으로 아래 순서를 따릅니다.

1. 로그의 IP로 역방향 DNS(IP로 호스트 이름을 찾는 조회)를 실행합니다.
2. 나온 호스트 이름이 사용자 에이전트에 맞는 도메인으로 끝나는지 봅니다.
3. 그 호스트 이름으로 정방향 조회를 다시 실행합니다.
4. 결과 IP가 로그의 원래 IP와 같은지 확인합니다.

2번의 도메인은 크롤러 유형마다 다릅니다. 이 문서에 따르면 Googlebot 같은 일반 크롤러는 googlebot.com으로 끝납니다. 특수 크롤러는 google.com, 사용자 요청 가져오기는 gae.googleusercontent.com 또는 google.com으로 끝납니다.

따라서 Googlebot 이름을 단 요청은 googlebot.com으로 끝나야 통과로 봅니다. google.com이나 googleusercontent.com으로 끝나면 사용자 에이전트와 함께 어느 유형인지 판정합니다.

Google의 공개 IP 목록도 일반 크롤러(common-crawlers.json), 특수 크롤러(special-crawlers.json), 사용자 요청 가져오기 파일로 나뉩니다. OpenAI 역시 봇마다 IP 목록 파일을 따로 공개합니다. 문서가 밝힌 용도가 봇마다 다르므로 대조 기준도 봇별로 나눕니다.

OpenAI 문서에 따르면 ChatGPT-User는 사용자 요청으로 움직여 robots.txt 규칙이 적용되지 않을 수 있습니다. 용도가 다른 봇은 한 칸에 묶지 않고 따로 집계합니다. OAI-SearchBot 수집은 ChatGPT 검색 답변에 쓰일 수 있다는 선행 신호로만 기록하며, 인용을 보장하는 근거로 쓰지 않습니다.

Apache 문서는 HostnameLookups를 켜면 서버가 크게 느려질 수 있다고 설명합니다. 대신 logresolve 같은 사후 처리 도구로 이름을 찾으라고 안내합니다. 실무에서는 요청마다 조회하지 않고 쌓인 로그를 하루 단위로 대조하는 방법을 권합니다.

대조할 때마다 IP 목록 파일을 새로 받습니다. 목록이 바뀌면 같은 IP라도 판정이 달라질 수 있기 때문입니다. 하루치 결과는 표 위에 「대조일 2026-10-21, 목록 받은 날 2026-10-21」처럼 한 줄을 적고 아래 양식으로 남깁니다.

완료 기준: 신원이 확인된 요청과 이름만 봇인 요청이 봇별로 다른 칸에 집계되어 있습니다.

정리

1. 요청 경로 표를 채우고 웹서버 접근 로그를 기본 기록 지점으로 정합니다. 결합 로그 형식·순환·보관 기간도 설정합니다.
2. CDN 뒤에 있다면 CDN 공개 IP 대역에서 온 요청만 실제 IP 헤더를 믿도록 설정합니다. 이어서 시험 요청 두 건으로 기록을 확인합니다.
3. robots.txt 실제 응답과 상태 코드를 기록하고, 변경 뒤 하루를 비교 구간에서 따로 표시합니다.
4. 주소 정규화 규칙과 고유주소 대응표를 만들고, 구조를 바꾼 날짜를 비교 구간 경계로 표시합니다.
5. 하루치 로그로 봇 신원을 봇별로 대조하고, 신원이 확인된 요청부터 페이지 단위 집계를 시작합니다.

참고 자료

• Cache (WordPress Advanced Administration Handbook, WordPress.org, 확인일 2026-10-20)
• do_robots() 함수 레퍼런스 (WordPress Developer Resources, 확인일 2026-10-20)
• Settings Permalinks screen (WordPress.org Documentation, 확인일 2026-10-20)
• Restoring original visitor IPs (Cloudflare Docs, 확인일 2026-10-22)
• Default cache behavior (Cloudflare Docs, 확인일 2026-10-22)
• Log Files (Apache HTTP Server 2.4 Documentation, 확인일 2026-10-22)
• Verifying Googlebot and other Google crawlers (Google Search Central, 확인일 2026-10-22)
• How Google interprets the robots.txt specification (Google Search Central, 확인일 2026-10-20)
• Overview of OpenAI Crawlers (OpenAI, 확인일 2026-10-20)