워드프레스 구글 서치콘솔 robots.txt 오류는 블로그 초보자에게 꽤 당황스러운 문제다.
워드프레스 구글 서치콘솔 robots.txt 오류는 단순히 robots.txt 파일 하나만 확인해서 끝나는 문제가 아니다.
계정, 속성, 사이트맵, 캐시, DNS, 서버 방화벽까지 함께 확인해야 정확한 원인을 찾을 수 있다.
나도 오늘 실제로 이 문제를 겪었다. 처음에는 구글 서치콘솔 실적 그래프가 갑자기 떨어져서 단순히 검색 노출이 줄어든 줄 알았다. 그런데 하나씩 확인해보니 단순한 실적 하락이 아니었다.
워프로 글을 작성해보신 분이라면 누구나 한번쯤 겪게되는 증상이다. 바로 구슬서치콘솔 robots.txt 오류로 색인할수 없음이 계속 반복된다는것.
나 역시 이 오류를 바로 잡기위해 꼬박 하루를 지새웠다가 겨우 해결할수 있었는데 덕분에 이것 저것 다 해보느라 도메인과 워프에 대한 지식이 급격히 늘어나는 신기한 경험을 할수 있었다.
결론부터 말하면, 워드프레스에서 구글 서치콘솔 robots.txt 오류가 발생하면 단순히 robots.txt 파일 하나만 보면 안 된다.
계정, 속성, 사이트맵, 캐시, DNS, 서버 방화벽까지 함께 확인해야 한다.
오늘 실제로 이 문제를 풀어가면서 처음에는 구글 서치콘솔 실적 그래프가 갑자기 떨어져서 단순히 검색 노출이 줄어든 줄 알았다. 그런데 하나씩 확인해보니 단순한 실적 하락이 아니었다.
서치콘솔 계정이 서로 다르게 연결되어 있었고, 도메인 속성과 URL 접두어 속성도 섞여 있었다. 여기에 robots.txt 접근 오류와 캐시 문제까지 겹치면서 색인 생성 요청까지 막히는 상황이었다.
다행히 하나씩 확인한 끝에 메인 주소와 최근 발행 글 3개까지 색인 생성 요청에 성공했다.
오늘 겪은 과정을 정리해두면 나처럼 워드프레스 초보 운영자에게 도움이 될 것 같아 기록으로 남긴다.
갑자기 구글 서치콘솔 실적이 급감했다
처음 이상함을 느낀 건 구글 서치콘솔 실적 그래프였다.
워드프레스 블로그를 시작한 뒤 4월 말부터 조금씩 검색 노출과 클릭이 잡히기 시작했다. 그런데 어느 순간부터 실적 그래프가 아래로 크게 꺾이는 것처럼 보였다.
처음에는 새 블로그라서 구글이 테스트 노출을 줬다가 다시 줄인 것이라고 생각했다. 실제로 초기 블로그는 노출과 클릭이 안정적이지 않기 때문에 하루 이틀 수치가 크게 흔들릴 수 있다.
하지만 자세히 보니 이상한 점이 있었다.
노트북에서 보는 서치콘솔 데이터와 데스크탑에서 보는 서치콘솔 데이터가 달랐다.
한 계정에서는 4월부터 데이터가 보였고, 다른 계정에서는 최근 데이터만 보였다.
어떤 화면에서는 사이트맵이 정상으로 보였지만, 다른 화면에서는 URL 검사가 제대로 되지 않았다.
게다가 robots.txt 관련 오류까지 떠 있었다.
이때부터 단순한 실적 하락 문제가 아니라 서치콘솔 연결과 사이트 접근성 문제가 함께 있을 수 있다고 판단했다.
처음에는 계정 문제부터 확인했다
가장 먼저 확인한 것은 구글 서치콘솔 계정이었다.
나는 데스크탑과 노트북에서 서로 다른 구글 계정으로 접속하고 있었다. 처음에는 둘 다 같은 사이트를 보고 있다고 생각했지만, 실제로는 아니었다.
한쪽 계정은 helimaster.net 도메인 속성을 보고 있었고, 다른 계정은 https://helimaster.net/ URL 접두어 속성을 보고 있었다.
겉으로 보면 같은 사이트처럼 보이지만 구글 서치콘솔에서는 서로 다른 속성으로 인식될 수 있다. 그래서 실적 그래프와 색인 현황이 다르게 보였던 것이다.
이 문제를 해결하기 위해 도메인 속성을 기준으로 잡고, 두 계정 모두 해당 속성에 접근할 수 있도록 권한을 정리했다.
계정 권한을 정리하고 나니 어떤 데이터를 기준으로 봐야 하는지가 명확해졌다.
워드프레스 블로그를 운영한다면 구글 서치콘솔에서 내가 보고 있는 속성이 정확히 무엇인지 먼저 확인하는 것이 중요하다.
도메인 속성과 URL 접두어 속성은 다르다
이번에 가장 크게 배운 것 중 하나는 도메인 속성과 URL 접두어 속성이 다르다는 점이다.
구글 서치콘솔에서 도메인 속성은 사이트 전체를 넓게 보는 방식이다. http, https, www, non-www까지 통합해서 확인할 수 있다.
반면 URL 접두어 속성은 특정 주소 체계만 본다. 예를 들어 https://helimaster.net/ 속성은 해당 주소로 시작하는 URL만 기준으로 데이터를 보여준다.
이 차이를 모르면 같은 사이트를 보고 있다고 착각하기 쉽다.
나도 처음에는 왜 데스크탑과 노트북에서 데이터가 다르게 보이는지 이해하지 못했다. 그런데 알고 보니 서로 다른 속성을 보고 있었던 것이다.
앞으로는 helimaster.net 도메인 속성을 기준으로 보기로 정리했다.
워드프레스 사이트를 처음 서치콘솔에 등록한다면 가능하면 도메인 속성을 기준으로 확인하는 것이 더 깔끔하다.
워드프레스 구글 서치콘솔 robots.txt 오류의 핵심 원인
이번에 겪은 워드프레스 구글 서치콘솔 robots.txt 오류의 핵심은 파일 내용 자체보다 구글봇이 해당 파일에 안정적으로 접근하지 못했다는 점이었다. 계정과 속성 문제를 정리한 뒤에도 문제가 남아 있었다.
구글 서치콘솔에서 URL 검사를 해보니 “URL을 Google에 등록할 수 없음”이라는 메시지가 나왔다. 세부 정보를 확인해보니 robots.txt를 찾을 수 없다는 오류가 있었다.
처음에는 robots.txt 파일 내용이 잘못된 줄 알았다.
하지만 브라우저에서 직접 https://helimaster.net/robots.txt 주소를 입력해보니 어떤 때는 열리고, 어떤 때는 연결이 거부되었다.
특히 크롬과 엣지에서 결과가 다르게 나오는 상황도 있었다.
이건 단순히 robots.txt 파일 내용 문제가 아니라 사이트 접근 자체가 불안정한 상태로 보였다.
정상적인 robots.txt라면 보통 다음과 같은 형태로 보인다.
User-agent: *
Allow: /
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
이런 구조는 사이트 전체를 막는 내용이 아니다.
문제는 Googlebot이 이 파일에 안정적으로 접근하지 못하고 있었다는 점이었다.
robots.txt 오류는 색인 생성에 직접적인 영향을 줄 수 있다. 구글이 사이트를 크롤링하기 전에 robots.txt를 확인하려고 하는데, 이 파일을 가져오지 못하면 URL 검사가 실패할 수 있다.
DNS와 서버 방화벽도 함께 확인했다
robots.txt 접근 오류가 계속되자 DNS도 확인했다.
도메인을 관리하는 Namecheap에서 A 레코드가 서버 IP를 제대로 가리키고 있는지 확인했다. 다행히 helimaster.net과 www 모두 같은 서버 IP로 연결되어 있었다.
또한 AAAA 레코드가 있는지도 확인했다.
AAAA 레코드는 IPv6 주소를 의미한다. 만약 IPv6 설정이 제대로 되어 있지 않은데 AAAA 레코드가 남아 있으면 일부 구글봇이나 브라우저가 IPv6로 접속하다가 실패할 수 있다.
내 경우에는 AAAA 레코드가 없었다. 그래서 IPv6 문제는 아닌 것으로 판단했다.
그다음에는 Vultr 서버 방화벽도 확인했다.
웹사이트 접속에는 기본적으로 HTTP 80번 포트와 HTTPS 443번 포트가 필요하다. 이 두 포트가 열려 있어야 브라우저와 구글봇이 사이트에 정상적으로 접근할 수 있다.
방화벽 설정까지 확인한 뒤에는 DNS나 포트 문제보다는 캐시와 사이트 응답 상태가 더 의심되었다.
결국 캐시 전체 삭제가 핵심이었다
이번 문제를 해결하면서 가장 크게 느낀 부분은 캐시였다.
워드프레스 구글 서치콘솔 robots.txt 오류가 계속된다면 LiteSpeed Cache 같은 캐시 플러그인도 함께 확인해야 한다.
처음에는 일부 캐시만 삭제했다. 그런데 문제가 완전히 해결되지 않았다. 브라우저에서는 열리는 것 같다가도, 서치콘솔 실시간 테스트에서는 계속 robots.txt를 찾을 수 없다고 나왔다.
이후 LiteSpeed Cache에서 관련 캐시를 전체적으로 정리했다.
LSCache, CSS/JS 캐시, 객체 캐시, 옵코드 캐시, 클라우드 캐시까지 함께 제거했다.
그 뒤 브라우저에서 robots.txt가 정상적으로 열리는지 다시 확인했고, 크롬과 엣지 모두에서 접근이 되는지 확인했다.
캐시를 전체적으로 비운 뒤 구글 서치콘솔에서 다시 URL 검사를 진행하니 이전과 달리 드디어 기다리고 찾고 헤이이던 초록색 결과가 나왔다.
“색인 생성 요청됨”
“URL을 Google에 등록할 수 있음”이라는 메시지가 뜬 것이다. 이게 이렇게 반가운 글씨일줄이야 ㅎㅎ
드디어 robots.txt 접근 문제가 사실상 해결되었다고 볼 수 있었다.
이번 경험상 워드프레스에서 LiteSpeed Cache를 사용하고 있다면 단순히 페이지 캐시 하나만 지울 것이 아니라, 접근 오류나 색인 오류가 생겼을 때는 전체 캐시를 정리하는 것이 더 확실하다.
나 또한 구글링을 통해 온갖 사람들이 올려놓은 해결방식을 다 살펴보고 따라해봤지만 해결되지 않았는데 나의 경우에는 캐시에서 해결할수 있었던 것이다. 캐시 삭제도 내가 안해본것이 아니었다. 파란색과 빨간색으로 표시해놓은 저 캐시들을 모두 삭제하구서야 해결이 되었던 것이다.
색인 생성 요청까지 성공했다
워드프레스 구글 서치콘솔 robots.txt 오류를 해결할 때는 먼저 서치콘솔 계정과 속성을 확인하고, 그다음 robots.txt 직접 접속 여부를 확인하는 것이 좋다. robots.txt 문제가 해결된 뒤 가장 먼저 메인 주소를 URL 검사에 넣었다. 결과는 성공이었다.
페이지 색인을 생성할 수 있다는 메시지가 나왔고, 바로 색인 생성 요청을 진행했다.
그다음 최근 발행한 글 3개도 차례대로 URL 검사를 진행했다. 다행히 모두 색인 생성 요청에 성공~~.
처음에는 “URL이 Google에 등록되어 있지 않음”이라고 나왔지만, 이것은 아직 색인되지 않았다는 뜻이지 요청 자체가 실패했다는 뜻은 아니다.
중요한 것은 색인 생성 요청이 정상적으로 접수되었다는 점이다.
최종적으로 사이트맵도 성공 상태였고, 발견된 페이지도 정상적으로 잡히고 있었다.
처음에는 서치콘솔 실적 급감으로 시작한 문제였지만, 결과적으로는 계정 정리, 속성 정리, robots.txt 접근 복구, 캐시 정리, 색인 생성 요청까지 한 번에 점검하는 계기가 되었다.
같은 문제를 겪는 사람을 위한 해결 순서
워드프레스에서 구글 서치콘솔 robots.txt 오류가 뜨거나 색인 생성 요청이 안 된다면 아래 순서대로 확인하는 것이 좋다.
첫째, 구글 서치콘솔 계정을 확인한다.
내가 어떤 구글 계정으로 접속하고 있는지 먼저 봐야 한다. 계정이 다르면 같은 사이트라도 권한이나 데이터가 다르게 보일 수 있다.
둘째, 보고 있는 속성이 무엇인지 확인한다.
도메인 속성인지, URL 접두어 속성인지 확인해야 한다. 가능하면 도메인 속성을 기준으로 보는 것이 좋다.
셋째, robots.txt를 직접 열어본다.
브라우저 주소창에 https://내도메인/robots.txt를 입력해 실제로 파일이 열리는지 확인한다.
넷째, 크롬과 엣지 등 다른 브라우저에서도 확인한다.
브라우저마다 결과가 다르다면 캐시나 접속 상태가 꼬였을 수 있다.
다섯째, DNS 레코드를 확인한다.
A 레코드가 서버 IP를 제대로 가리키는지 확인하고, 불필요한 AAAA 레코드가 있는지도 본다.
여섯째, 서버 방화벽에서 80번과 443번 포트가 열려 있는지 확인한다.
HTTPS 사이트라면 443번 포트가 매우 중요하다.
일곱째, LiteSpeed Cache를 사용 중이라면 전체 캐시를 제거한다.
페이지 캐시만이 아니라 객체 캐시, CSS/JS 캐시, 옵코드 캐시, 클라우드 캐시까지 함께 확인하는 것이 좋다.
여덟째, 서치콘솔 URL 검사에서 실시간 테스트를 다시 실행한다.
여기서 “URL을 Google에 등록할 수 있음”이 뜨면 복구된 것으로 볼 수 있다.
아홉째, 메인 주소와 최근 발행 글 몇 개만 색인 생성 요청을 진행한다.
한 번에 너무 많은 URL을 요청하기보다는 핵심 글부터 천천히 확인하는 것이 좋다.
결론
결국 워드프레스 구글 서치콘솔 robots.txt 오류는 글 품질 문제가 아니라 사이트 접근성 문제에서 시작될 수 있다. 워드프레스 구글 서치콘솔 robots.txt 오류는 생각보다 복잡할 수 있다.
단순히 robots.txt 파일 한 줄만 고쳐서 해결되는 경우도 있지만, 실제 운영 중에는 계정, 속성, DNS, 서버 방화벽, 캐시, 사이트맵이 함께 얽혀 있을 수 있다.
나도 처음에는 실적 그래프가 떨어진 것만 보고 검색 노출 문제라고 생각했다. 하지만 실제로는 서치콘솔 계정과 속성이 섞여 있었고, robots.txt 접근 오류와 캐시 문제가 함께 겹쳐 있었다.
다행히 하나씩 확인한 끝에 메인 URL과 최근 발행 글 3개까지 색인 생성 요청에 성공했다.
이번 경험을 통해 워드프레스 운영에서 중요한 것은 글을 많이 쓰는 것만이 아니라는 것을 느꼈다. 구글이 내 사이트에 정상적으로 접근할 수 있는지, 사이트맵은 제대로 제출되어 있는지, 캐시가 꼬이지 않았는지 주기적으로 확인하는 것도 매우 중요하다.
같은 문제를 겪는다면 조급하게 플러그인을 삭제하거나 DNS를 막 바꾸기보다, 계정 확인부터 robots.txt 직접 접속, 캐시 전체 삭제, 서치콘솔 실시간 테스트 순서로 차근차근 확인해보는 것이 좋다.
오늘의 결론은 단순하다. 단순한 결론이지만 모르면 복잡한 길이된다.
워드프레스 색인 문제는 글 문제가 아닐 수도 있다.
먼저 구글봇이 내 사이트에 제대로 들어올 수 있는지부터 확인해야 한다.여러분들을 괴롭히는 robots.txt 빨리 해결되어 색인요청이 원활하게 이루어지길 이 글이 도움되었기를 바란다.
결론은 아래 내용들을 따라가다보면 ~ 실마리가 그기에 있다.
- 계정이 맞나?
- 속성이 맞나?
- robots.txt가 직접 열리나?
- 사이트맵은 성공인가?
- DNS A레코드는 맞나?
- AAAA 레코드가 꼬였나?
- 80/443 포트 열렸나?
- LiteSpeed 전체 캐시 비웠나?
- 실시간 테스트 통과하나?
- 색인 요청 접수되나?