리다이렉트되는 주소를 대표 주소로 지정해 두고 있었다
한눈에 답변
실제 배포된 서버는 경로 끝에 슬래시가 붙은 주소로 정상 응답하고 슬래시 없는 주소는 자동으로 다른 곳으로 넘기고 있었는데, 정작 대표 주소 지정과 사이트맵과 구조화 데이터의 URL은 전부 슬래시 없는 형태로 나가고 있었다. 검색엔진이 색인해야 할 대상으로 지정한 주소가 실제로는 다른 주소로 튕겨 나가는 주소였던 셈이라, 형식을 서버의 실제 동작에 맞춰 통일하고 URL을 조립하는 함수를 한 곳으로 모았다.
무엇이 어긋나 있었나
실제 배포된 서버에 직접 요청을 보내 확인해 보니, 경로 끝에 슬래시가 붙은 주소는 정상적으로 페이지를 보여주고, 슬래시가 없는 주소로 요청하면 슬래시가 붙은 주소로 자동으로 넘겨졌다. 그런데 대표 주소 지정, 사이트맵, 구조화 데이터 안의 URL은 전부 슬래시가 없는 형태로 만들어지고 있었다.
왜 이대로 두면 안 되나
검색엔진에게 “이 주소가 진짜 대표 주소다”라고 알려주는 값이, 실제로는 다른 주소로 튕겨 나가는 값이었다. 색인 대상으로 지정한 주소 자체가 리다이렉트되는 주소라면, 검색엔진 입장에서는 신뢰하기 어려운 신호가 된다.
왜 처음부터 슬래시 형태로 통일하지 않았나
URL을 조립하는 코드가 여러 페이지에 흩어져 있었다. 형식이 여러 곳에 따로따로 존재하면, 그중 한 곳은 반드시 어긋나게 마련이다. 이번에 발견된 것도 여러 조립 지점 중 일부만 슬래시를 빠뜨리고 있던 경우였다.
어떻게 고쳤나
먼저 사이트 전체 설정에서 슬래시가 항상 붙도록 기본값을 정했다. 그리고 대표 주소·사이트맵·구조화 데이터에 들어가는 모든 URL을 한 곳에 모아 둔 조립 함수 하나를 거치도록 통일했다. 형식이 흩어져 있던 문제를, 형식을 다루는 자리 자체를 하나로 줄여서 해결한 것이다.
시도했다가 되돌린 방법도 있었나
있었다. 반대로 슬래시를 아예 없애는 설정도 시도해 봤는데, 정적 페이지를 만드는 과정에서 페이지 경로 자체가 파일 확장자가 붙은 형태로 바뀌면서 대표 주소에 그 확장자가 그대로 섞여 나가는 부작용이 있었다. 서버가 실제로 슬래시 붙은 형태로 응답하고 있었으므로, 없애는 방향이 아니라 있는 형태로 통일하는 것이 서버의 실제 동작과 맞는 선택이었다.