[구글 SEO 05] URL은 절대 바꾸지 마라, 색인 날린 이야기

1편에서 잠깐 언급했지만, 내가 저지른 가장 뼈아픈 실수는 사이트 초기에 URL 구조를 두 번 바꾼 것이다. 개발자 입장에선 그냥 라우팅 리팩터링인데, 검색엔진 입장에선 사이트의 신원이 두 번 뒤집힌 대형 사건이다. 이번 편은 왜 URL 변경이 그렇게 치명적인지, 그리고 정말 불가피하게 바꿔야 한다면 어떻게 피해를 최소화하는지를 정리한다.

결론을 먼저 박아두면 이렇다. URL은 기능이 아니라 자산이다. 코드는 언제든 리팩터링해도 되지만 URL은 한번 공개되면 외부 세계와 맺은 계약이 된다. 검색엔진이 기억하고, 다른 사이트가 링크로 걸고, 사람들이 북마크한다. 이 감각을 초반에 못 잡으면 나처럼 회복에만 몇 달을 쓰게 된다. 그러니 이 한 편은 사실상 하지 마라는 경고문에 가깝다.

1. URL은 콘텐츠의 영구 식별자다

구글의 색인은 URL 단위로 저장된다. 어떤 글의 주소가 바뀌면 구글은 그걸 같은 글의 이사로 자동 인식하지 못한다. 기본적으로는 옛 주소의 문서는 죽은 것으로, 새 주소는 처음 보는 남남인 문서로 취급한다. 사람 눈엔 같은 글이지만 검색엔진에겐 완전히 별개의 두 문서다.

그동안 옛 주소가 쌓아온 색인 이력과 순위, 외부 링크의 신뢰가 새 주소로 자동 승계되지 않는다는 뜻이다. 신생 사이트에겐 이게 특히 치명적이다. 가뜩이나 쌓아둔 신뢰가 없는데 그 얼마 안 되는 것마저 리셋되기 때문이다. 어렵게 색인시킨 몇백 개가 하루아침에 처음 상태로 돌아간다. 그래서 URL은 콘텐츠의 이름표가 아니라 주민등록번호에 가깝다. 사람 이름은 바꿔도 주민번호는 안 바꾸듯, URL은 한 번 정하면 안 바꾸는 게 원칙이다.

조금 극단적으로 들리겠지만, 나는 이제 URL 설계를 데이터베이스 스키마만큼 신중하게 대한다. 스키마의 기본 키를 함부로 안 바꾸듯 URL도 그렇게 다룬다. 오픈 전에 충분히 고민해서 확정하고, 그 뒤엔 웬만하면 손대지 않는다. 이 원칙 하나만 지켜도 신생 사이트가 겪는 사고의 상당수가 애초에 안 생긴다.

2. 신호 이전은 오직 301로

불가피하게 주소를 옮긴다면 옛 주소에서 새 주소로 301 리다이렉트를 정확히 걸어야 한다. 301은 영구 이동을 뜻하고, 오직 이걸 통해서만 색인 자산(link equity)이 새 주소로 넘어간다. 반드시 301이어야 한다. 302는 임시 이동이라, 구글이 원래 주소가 곧 돌아올 걸로 보고 옛 주소를 계속 붙잡은 채 신호를 안 넘긴다.

그리고 옛 주소가 또 다른 주소로, 그게 다시 다른 주소로 넘어가는 리다이렉트 체인은 반드시 피해야 한다. 홉이 하나 늘 때마다 신호가 새고, 체인이 길면 크롤러가 최종 목적지에 닿기 전에 포기한다. 리다이렉트는 항상 한 방에 최종 목적지로 보낸다. 특히 리다이렉트 규칙을 짤 때 옛것 위에 옛것을 계속 쌓으면 자기도 모르게 3단, 4단 체인이 생기니, 규칙은 주기적으로 평탄화(flatten)해서 언제나 1홉을 유지하도록 관리해야 한다.

301을 걸 때 놓치기 쉬운 디테일이 하나 있다. 리다이렉트 응답 자체는 캐시될 수 있어서, 잘못 건 301을 나중에 고쳐도 브라우저나 중간 캐시가 옛 301을 한동안 붙잡을 수 있다. 그래서 301은 처음부터 정확히 걸어야 하고, 확신이 없다면 되돌리기 쉬운 302로 테스트한 뒤 확정될 때 301로 바꾸는 것도 방법이다.

301을 서버 어느 계층에 두느냐도 고민할 지점이다. CDN이나 엣지에서 처리하면 빠르고 서버 부하도 적지만 규칙이 흩어지기 쉽고, 애플리케이션에서 처리하면 관리는 편한데 매 요청이 서버까지 온다. 규모가 크지 않다면 한 곳에 규칙을 모아두는 걸 권한다. 리다이렉트 규칙이 여러 계층에 흩어지면 나중에 체인의 원인을 찾기가 지옥이다.

3. 슬러그(제목) URL의 유혹

초보자가 흔히 예뻐 보인다고 /post/123/글-제목 같은 슬러그 URL을 쓰고 싶어 한다. 그런데 여기엔 함정이 있다. 제목을 수정하면 슬러그가 바뀌고, 그럼 URL이 바뀌어서 앞서 말한 모든 문제가 그대로 재발한다. 커뮤니티처럼 제목 수정이 잦은 서비스라면 매 수정이 작은 URL 사고가 되어 관리 지옥이 된다.

그래서 나는 숫자 ID 기반의 짧고 영속적인 주소를 권한다. 대형 커뮤니티들도 대부분 숫자 URL을 쓴다. 슬러그의 SEO 이득은 생각보다 작고, 제목 키워드는 title 태그와 본문, 그리고 H1에서 이미 충분히 전달된다. 굳이 슬러그를 쓰겠다면 제목이 바뀌어도 URL은 고정되도록, 즉 숫자 ID만으로도 정상 접근되고 슬러그는 장식으로만 붙어서 달라져도 무방한 구조로 설계해야 한다. 그래야 제목 수정이 URL 변경으로 번지지 않는다.

숫자 ID URL의 또 다른 장점은 공유와 추적이 쉽다는 것이다. 짧고 안정적이라 카톡이나 SNS에 붙여도 안 깨지고, 로그에서 어떤 글이 인기인지 집계하기도 편하다. 슬러그가 붙은 긴 한글 URL은 공유 과정에서 인코딩이 깨지거나 잘리는 일도 잦다. 여러모로 숫자 기반이 운영 부담이 적다.

덧붙이자면 이미 슬러그 URL로 운영 중이라도 지금 당장 숫자로 갈아엎으라는 건 아니다. 그건 또 하나의 URL 변경 사고다. 대신 앞으로는 슬러그가 바뀌어도 숫자 ID로 접근되게 만들고, 옛 슬러그는 새 주소로 301을 걸어 서서히 정리하는 게 안전하다. 원칙을 안 뒤부터는 새 사고를 안 만드는 것이 먼저다.

4. 구조 변경도 URL 변경이다

다국어를 넣으면서 /post/123을 /ko/post/123으로 바꾸는 것 같은 경로 프리픽스 추가도 엄연한 URL 변경이다. 개발자는 그저 폴더 하나 앞에 붙인 정도로 사소하게 느끼지만, 구글에겐 사이트 전체가 이사한 사건이다.

이런 구조 변경을 할 땐 옛 주소 전부에 대해 301 매핑 표를 만들어 하나도 빠짐없이 연결하고, 다국어라면 hreflang으로 언어별 대응 관계까지 알려줘야 한다. 하나라도 누락되면 그 글은 색인에서 조용히 증발한다. 나는 이 매핑을 대충 눈대중으로 했다가 상당수 글을 날렸다. 매핑은 감이 아니라, 옛 URL 목록을 전부 뽑아 새 URL과 일대일로 맞춘 표를 코드로 검증하며 만들어야 한다. 스프레드시트든 스크립트든, 빠진 항목이 0인지를 기계적으로 확인하고 넘어가야 한다.

구조 변경을 꼭 해야 한다면, 트래픽이 가장 적은 시간대에 하고 변경 직후 며칠은 GSC와 서버 로그를 평소보다 자주 들여다보길 권한다. 301이 제대로 물리는지, 404가 튀지 않는지, 크롤 통계가 요동치지 않는지를 초기에 잡아야 피해가 작다. 큰 변경일수록 배포 후 관찰이 배포 자체보다 중요하다.

구조 변경의 숨은 비용은 외부 링크에도 있다. 다른 사이트가 이미 옛 주소로 나를 링크해 뒀다면 그 링크의 신뢰도 301을 타고 넘어와야 보존된다. 301을 안 걸거나 잘못 걸면 어렵게 얻은 백링크 한 개가 그대로 증발한다. 신생 사이트에게 백링크 하나하나는 귀하니, 구조를 바꿀 땐 외부에서 들어오는 링크까지 살아남는지를 반드시 챙겨야 한다.

5. 이미 바꿔버렸다면

이미 사고를 쳤다면 수습 순서는 이렇다. 옛 주소에서 새 주소로 301을 빠짐없이 걸고, 사이트맵에는 새 주소만 남기고, GSC의 주소 변경 도구가 해당된다면 사용하고, 옛 URL이 구글 색인에서 완전히 빠질 때까지 그 301을 절대 내리지 않고 오래 유지한다. 301을 성급히 걷어내면 아직 옛 주소를 기억하는 구글이 다시 404를 만나 신호가 끊긴다.

회복은 몇 주에서 몇 달이 걸린다. 그동안 할 수 있는 최선은 더 이상 아무것도 바꾸지 않는 것이다. 조급해서 또 손대면 회복 시계가 다시 0으로 돌아간다. 신생 도메인이 신뢰를 잃는 가장 빠른 길이 잦은 주소 변경이라는 걸 기억하자. 반대로 말하면, 주소를 안 바꾸고 가만히 두는 것만으로도 신뢰는 시간과 함께 쌓인다. 다음 편은 이 URL 변경 과정에서 필연적으로 생기는 죽은 옛 주소를, 404와 410으로 어떻게 청소하는지다.

마지막으로, 이미 벌어진 사고 앞에서 가장 흔한 유혹이 한 번 더 갈아엎어서 깔끔하게 정리하자는 생각이다. 이건 거의 항상 상황을 악화시킨다. 회복은 변화가 아니라 안정에서 온다. 걸어둔 301을 지키고, 사이트맵을 정돈하고, 그다음엔 손을 떼고 시간을 주는 것. 아무것도 안 하는 게 최선의 조치인 순간이 분명히 있다.