모두
모두콘텐츠
얼마 전 운영 중인 사이트의 방문자가 갑자기 줄었다는 연락을 받았다. 글 순위를 걱정하고 있었지만, 접속 기록을 보니 검색 로봇이 방문한 시간에 서버가 간헐적으로 오류를 내고 있었다. 홈페이지노출이 줄면 콘텐츠부터 손보고 싶어진다. 그런데 서버가 페이지를 안정적으로 전달하는지 먼저 확인해야 원인을 좁힐 수 있다.
노출 감소와 접속 장애를 먼저 구분한다
검색 결과에서 덜 보이는 것과 사이트가 열리지 않는 것은 다른 문제다. 검색 관리 도구에서 노출 수가 줄었는지, 노출은 비슷한데 클릭만 줄었는지부터 확인한다. 특정 페이지만 빠졌다면 그 페이지의 색인 상태를 보고, 사이트 전체가 비슷한 날부터 떨어졌다면 서버 변경이나 장애 기록을 함께 본다.
같은 화면이 내 컴퓨터에서는 잘 열려도 검색 로봇에게는 다르게 보일 수 있다. 캐시가 정상 화면을 보여주는 동안 원본 서버는 오류를 낼 수 있고, 보안 설정이 로봇 요청만 막기도 한다. 그래서 브라우저 화면 하나로 정상 여부를 판단하지 않는다. 서버 접속 기록에서 해당 페이지의 응답 코드와 응답 시간을 확인하고, 외부에서 접속한 결과도 비교한다.
- 정상 페이지가 200 응답을 주는지 확인한다.
- 없는 페이지가 정상 화면처럼 200을 주고 있지는 않은지 확인한다.
- 특정 시간대에 5xx 오류나 시간 초과가 몰리는지 확인한다.
- 보안 장비나 요청 제한 설정이 검색 로봇에 403 또는 429를 주는지 확인한다.
구글 검색 센터 안내에서도 200 응답만으로 색인이 보장되지는 않는다고 설명한다. 다만 서버 오류나 과도한 요청 제한이 반복되면 크롤링이 줄 수 있다. 접속이 불안정한 상태에서 제목과 본문만 고쳐서는 변화가 더딘 이유다.
색인을 막는 설정을 순서대로 찾는다
서버가 안정적이라면 다음은 접근 허용과 색인 설정이다. 사이트를 만들 때 임시로 넣은 noindex가 배포 뒤에도 남아 있는 경우를 종종 본다. 페이지의 메타 태그뿐 아니라 서버가 보내는 헤더에도 색인 제외 지시가 들어갈 수 있다. 둘 다 확인해야 한다.
robots.txt에서 수집을 막아 놓은 경우도 있다. 이 설정은 로봇의 접근을 제한하는 용도다. 접근을 막았다고 검색 결과에서 주소가 반드시 사라지는 것은 아니며, 반대로 페이지에 noindex를 넣어도 로봇이 페이지에 접근하지 못하면 그 지시를 읽을 수 없다. 두 설정을 섞어 쓰기 전에 원하는 동작을 분명히 해야 한다.
주소를 통합하는 설정도 중요하다. 같은 글이 여러 경로에서 열리면 검색엔진이 대표 페이지를 선택한다. 사이트 이전 뒤 예전 주소에서 새 주소로 이동하는 규칙, 페이지에 선언한 대표 주소, 사이트맵에 적힌 주소가 서로 다르면 확인이 어려워진다. 대표 주소를 한 가지로 정하고 내부 링크도 그쪽을 가리키게 한다. 이동 규칙은 여러 번 거치지 않도록 실제 요청으로 확인한다.
특히 개편 직후라면 배포 전과 후의 설정 파일을 비교할 만하다. 테스트 환경을 복사하면서 색인 차단 설정까지 함께 옮기는 사고가 있다. 이때는 설정을 바로잡은 뒤 검색 관리 도구에서 해당 페이지를 다시 검사한다. 재검사를 요청해도 노출 시점이나 순위가 보장되는 것은 아니다.
속도 문제는 서버 사양보다 병목부터 본다
홈페이지노출이 걱정된다고 VPS부터 상위 요금제로 바꿀 필요는 없다. 하루 페이지 조회 1만 건이면 24시간 평균은 초당 약 0.12건이다. 실제 접속은 특정 시간에 몰리고, 페이지 한 번을 여는 동안 이미지와 스크립트 요청도 생긴다. 평균 조회 수만으로 서버 사양을 결정할 수 없다는 뜻이다.
나는 접속이 몰리는 시간의 요청 수, 응답 시간, CPU와 메모리 사용량을 함께 본다. 예를 들어 동적인 페이지 요청이 초당 2건이고 처리에 평균 0.5초가 걸린다면, 단순 계산으로 동시에 처리 중인 요청은 평균 약 1건이다. 실제 운영에서는 순간적인 몰림과 느린 데이터베이스 질의까지 고려해야 하지만, 이런 수치를 보면 증설이 필요한지 판단할 출발점이 생긴다.
첫 화면이 늦는 원인이 큰 이미지나 외부 스크립트라면 서버를 키워도 체감 속도는 거의 그대로일 수 있다. 반대로 이미지 전송은 빠른데 데이터베이스 질의가 밀린다면 캐시와 질의부터 확인한다. 구글 검색 센터가 안내하는 사용자 경험 지표도 확인할 만하지만, 점수 하나를 높였다고 검색 순위가 오르는 식으로 받아들이면 안 된다. 사용자가 실제로 느끼는 지연과 서버의 병목을 같이 봐야 한다.
이전과 장애 뒤에는 복구 가능성을 확인한다
도메인 설정이나 호스팅을 바꾼 뒤 노출이 줄었다면 변경 시각부터 적는다. 그다음 이름 서버 설정, 인증서 상태, 이동 규칙, 주요 페이지의 응답 코드를 순서대로 확인한다. 접속 불가가 여러 지역에서 나타나는지, 일부 사용자에게만 나타나는지도 나눠 본다. 설정 전파 중인 문제와 원본 서버 장애는 대응이 다르다.
백업 파일이 있다는 사실만으로 복구를 장담할 수는 없다. 파일과 데이터베이스가 같은 시점의 것인지, 별도 장소에 보관되는지, 실제로 복원해 주요 페이지와 로그인 기능이 열리는지 확인해야 한다. 이전 작업 전에는 현재 설정과 콘텐츠를 보관하고, 이전 후에는 대표 페이지 몇 개를 직접 열어 응답 코드와 이동 경로까지 검사한다. 장애가 난 뒤에 처음 복원 절차를 읽으면 시간이 오래 걸린다.
서버 운영을 오래 하며 느낀 건 홈페이지노출 문제에도 확인 순서가 있다는 점이다. 노출 수와 색인 상태를 보고, 서버 응답과 설정 변경 기록을 대조하면 불필요한 요금제 변경을 피하기 쉽다. 사이트가 꾸준히 열리고 복구도 가능한 상태를 먼저 만들어 두는 편이 오래 간다.
