같은 글의 주소가 여러 개일 때: canonical과 301 중 무엇을 쓸까

방문자를 이동시킬지 중복 주소를 유지할지 고르는 자체 제작 개념도입니다.

옛 주소로 들어온 방문자도 새 주소로 보내려면 301 리디렉션을 사용합니다. 여러 주소를 계속 열어 두면서 Google에 대표 주소를 알려 주려면 rel="canonical"을 검토하세요. 먼저 정할 것은 중복 주소를 방문자에게 계속 제공할 이유가 있는지입니다.

예를 들어 글 주소를 /old-guide에서 /guide로 바꿨다면 예전 링크로 들어온 독자도 새 글을 읽어야 합니다. 반면 뉴스레터에 붙인 /guide?campaign=mail은 방문 경로를 구분하려고 남겨 두고 싶을 수 있습니다. 둘 다 같은 내용을 보여 주더라도 주소를 유지하는 목적이 다릅니다.

방문자의 주소가 바뀌는가

301은 HTTP 응답으로 새 위치를 알려 줍니다. 브라우저는 그 주소로 이동합니다. Google도 301 같은 영구 리디렉션을 새 주소가 대표 URL이라는 강한 신호로 사용합니다. 일시적인 이동이라면 영구 이동과 구분해야 합니다. 리디렉션과 Google 검색

Canonical은 페이지의 대표 주소를 검색엔진에 알려 주는 표기입니다. 이를 넣어도 독자의 브라우저가 자동으로 그 주소로 이동하지 않습니다. 중복 페이지는 계속 열립니다. Google이 사이트의 선호를 전달받는 것이지, 작성자가 Google의 최종 선택을 강제로 지정하는 기능은 아닙니다. 대표 URL 지정 방법

그래서 “검색에는 새 주소가 나오면 좋겠지만 옛 주소의 화면도 유지해야 한다”는 요구와 “옛 페이지는 이제 없애고 모두 새 주소로 보낸다”는 요구를 먼저 구분합니다. 대표주소 설정을 한 뒤에도 브라우저 주소가 그대로인 것은 canonical의 동작과 맞습니다.

/old-guide를 없애는 경우

설명용 사이트 https://example.com에서 글 경로를 바꾼다고 해 보겠습니다. 옛 경로의 서버 응답은 다음 관계를 갖도록 설정합니다.

HTTP/1.1 301 Moved Permanently
Location: https://example.com/guide

위 코드는 응답의 모양이며 HTML 본문에 붙여 넣는 코드가 아닙니다. 사용하는 서버나 호스팅 서비스의 리디렉션 설정에서 구현해야 합니다. Location이 가리키는 /guide는 실제 글을 정상 응답으로 제공해야 합니다.

옛 주소에서 중간 주소를 몇 번 거쳐 도착하도록 쌓기보다 최종 글로 바로 연결하는 편이 점검하기 쉽습니다. 예전에 경로를 여러 번 바꿨다면 /old-guide와 /older-guide가 각각 어디로 가는지 확인하세요. 서로를 가리키는 순환이 생기면 독자가 글에 도착하지 못합니다.

다음 명령은 실제 자신의 주소로 바꿔 응답 헤더를 확인하는 용도입니다. 이 글에서 해당 서버를 배포하거나 명령 결과를 수집한 것은 아닙니다.

curl -sS -D - -o /dev/null \
  https://example.com/old-guide

첫 응답의 상태 코드와 Location을 봅니다. 이어 최종 주소도 열어 제목과 본문이 맞는지 확인합니다. 리디렉션은 기술적으로 성공해도 엉뚱한 글이나 홈페이지로 보내면 독자가 찾던 내용을 잃게 됩니다. 사라진 모든 글을 홈페이지 하나로 묶는 설정은 글별 대체 관계를 표현하지 못합니다.

캠페인 주소를 남겨 두는 경우

같은 글을 제공하는 /guide?campaign=mail과 /guide에서 기본 주소를 대표로 쓰려면 HTML의 <head>에 다음처럼 지정할 수 있습니다.

<link rel="canonical"
  href="https://example.com/guide">

대표 페이지인 /guide에도 자기 주소를 지정하면 일관된 관계가 됩니다. 내부 링크와 사이트맵 역시 선택한 주소로 맞춥니다. 한쪽은 /guide, 다른 쪽은 매개변수가 붙은 URL을 대표로 알리면 신호가 충돌합니다. Google은 canonical과 사이트맵 등 여러 신호를 함께 살핍니다. Canonical의 배치와 일관성

주소에 매개변수가 있다는 이유만으로 모두 없애지는 마세요. ?campaign=mail이 단지 유입 정보를 나타내는 경우와, ?page=2가 두 번째 목록을 보여 주는 경우는 본문이 다를 수 있습니다. 먼저 두 URL을 열어 주요 내용이 실제로 같은지 비교합니다. 서로 다른 글을 한 주소로 묶는 용도로 canonical을 쓰면 글별 검색 의도를 제대로 설명하지 못합니다.

위 태그를 블로그 편집기의 본문에 넣는 것도 피해야 합니다. HTML 문서의 <head>에 들어가야 하므로, 스킨이나 호스팅이 제공하는 설정 경로를 확인해야 합니다. 이미 자동으로 canonical을 넣는 시스템이라면 두 번째 태그를 추가하기 전에 현재 소스를 봅니다. 같은 페이지에 서로 다른 대표주소를 두 개 넣으면 진단이 더 어려워집니다.

설정 결과와 검색 결과를 따로 봅니다

배포 직후 확인할 수 있는 것은 응답과 HTML입니다. 301의 이동 목적지, 최종 페이지의 응답, canonical의 위치와 주소를 먼저 확인합니다. Google의 검색 결과가 언제 바뀔지는 이 검사만으로 알 수 없습니다.

Search Console의 URL 검사에서는 Google이 마지막으로 수집한 페이지 정보와 선택한 대표 URL을 살필 수 있습니다. 사용자가 선언한 주소와 Google이 고른 주소가 다르다면 수집 시점, 실제 중복 내용, 리디렉션과 내부 링크를 함께 확인합니다. 실시간 테스트는 현재 접근 가능한 페이지를 검사하는 도구이며, 색인에 반영된 대표 URL의 최종 선택을 대신 보여 주지는 않습니다. URL 검사 보고서

수집을 막으면 대표주소 문제도 사라진다고 생각해 robots.txt부터 차단하지 마세요. 수집이 막힌 페이지의 HTML canonical은 확인할 수 없고, 차단된 URL 자체가 검색에서 반드시 없어지는 것도 아닙니다. noindex는 페이지를 검색에서 빼려는 지시이므로, 대표주소를 모으는 문제와 목적이 다릅니다. 중복 URL 통합 시 주의사항

지금 정리하려는 URL 두 개를 열고 다음을 결정하세요. 옛 주소를 계속 제공할 이유가 없다면 최종 글로 영구 이동시킵니다. 두 주소가 필요하고 본문도 같다면 대표주소를 일관되게 알립니다. 어느 쪽이든 설정한 주소와 실제 도착한 글을 확인한 뒤 검색 반영 상태를 추적하면 됩니다.

2026년 9월 28일 Google Search Central과 Search Console 도움말을 확인했습니다. 예제 도메인은 설명용이며 특정 사이트의 순위나 색인 개선을 측정하지 않았습니다.