canonical 제대로 넣었는데
중복 페이지가 안 사라지는 이유

주소 끝에 슬래시(/)가 붙고 안 붙고는 사소해 보입니다. 사람 눈엔 /seo/what-is-seo 나 /seo/what-is-seo/ 나 같은 글이죠. 그런데 검색엔진은 글자가 다른 두 주소를 서로 다른 페이지로 볼 수 있습니다. 둘 다 똑같은 내용을 열어 주면, “같은 글이 두 군데 있다”처럼 읽힐 수 있습니다.

문제를 키운 건 우리 쪽 구조였습니다. 우리 사이트의 대표 주소(canonical) 태그는 방문한 주소를 그대로 가리킵니다. 슬래시 없는 주소로 들어오면 대표 주소도 슬래시 없이, 슬래시 붙은 주소로 들어오면 대표 주소도 슬래시 붙은 채로 적힙니다. 즉 “어떤 형태로 링크를 걸었느냐”가 곧 그 글의 대표 주소를 정합니다. 그러니 내부 링크가 두 형태로 섞이면, 같은 글의 대표 주소가 두 개로 갈라지는 셈입니다.

스키마를 잘못 넣어 또렷하게 틀린 신호를 줬던 지난 구조화 데이터 실록과 결이 같습니다. 이번엔 주소 한 글자가 같은 일을 합니다 — 눈에 잘 안 보이는데, 기계에는 또렷하게 갈라져 보이는 신호죠.

이 글은 그 갈라짐을 어떻게 발견하고, 어떻게 판별하고, 사이트 전체 링크를 어떻게 한 형태로 모았는지를 그대로 적은 현장 기록입니다. 일반론이 아니라, 우리가 실제로 겪고 고친 일입니다(2026년 5월).

내부 링크를 점검하다 한 가지가 눈에 걸렸습니다. 같은 글인데 어떤 메뉴는 슬래시를 붙여, 어떤 본문 링크는 슬래시 없이 걸려 있었습니다. 직접 두 주소를 다 두드려 보니 — 둘 다 정상(200)으로 열렸습니다. 하나가 막혀 있으면 차라리 문제가 안 됩니다. 둘 다 열려서 문제였습니다.

더 신경 쓰였던 건 범위였습니다. 단발 실수 한두 개가 아니라, 헤더와 푸터가 함께 쓰는 공통 메뉴 한 곳에서 형태가 어긋나 있었습니다. 그 메뉴는 사이트 거의 모든 페이지에 똑같이 박히니까, 한 곳의 불일치가 사이트 전체에 동시에 번진 셈이었습니다(반대로 말하면, 한 곳만 고치면 전체가 같이 정리된다는 뜻이기도 했습니다).

검색엔진은 같은 내용이 여러 주소에 있으면 그중 하나를 대표로 골라 묶으려 합니다(이걸 정규화·canonicalization이라 부릅니다). 그런데 우리가 거는 링크와 사이트맵이 두 형태로 갈려 있으면, “대표가 누구인지”에 대해 우리가 서로 다른 신호를 동시에 보내는 셈입니다. 그러면 한 글이 받아야 할 평가가 두 주소로 나뉠 수 있습니다. canonical은 명령이 아니라 힌트라, 신호가 엇갈리면 우리 뜻과 다르게 묶일 수도 있습니다.

// 우리 canonical 은 "방문한 주소"를 그대로 가리킨다 (자기참조)
<link rel="canonical" href="{사이트}{지금 요청한 경로}">

// 그래서 같은 글이라도 들어온 형태에 따라…
/seo/what-is-seo   → canonical = /seo/what-is-seo
/seo/what-is-seo/  → canonical = /seo/what-is-seo/   // 다른 대표 주소!

// 정리: 한 글은 한 형태로만 링크 → canonical 도 하나로 모인다
// 내부 링크·본문·사이트맵 전부 같은 형태:
/seo/what-is-seo          // 말단 콘텐츠(파일) → 슬래시 X
/seo/                     // 섹션 루트(디렉터리) → 슬래시 O
/seo/portfolio/           // 목록·페이징 → 슬래시 O

형태를 정하는 기준이 필요했습니다. 취향으로 정하면 또 흔들리니까요. 그래서 주소를 슬래시 없이 요청해 응답 코드를 보는 단순한 규칙을 세웠습니다. 슬래시 붙은 쪽으로 넘겨주면(301) 그 페이지는 슬래시를 붙이는 게 맞고, 그대로 열리면(200) 슬래시 없는 형태로 통일합니다. 서버가 이미 정해 둔 자연스러운 형태를 그대로 따르는 셈입니다.

// 의사코드 — 페이지를 눈으로 도는 게 아니라 "형태를 판별·대조"
for url in allInternalLinks:
  code = head(stripSlash(url))            // 슬래시 빼고 요청
  form = (code == 301) ? withSlash(url) : noSlash(url)
  enforce(form)                           // 링크·canonical·sitemap 모두 이 형태로

// 마지막: 메뉴 ↔ 사이트맵 자동 대조
assert( menuLinks ⊆ sitemapLocs )       // 형태까지 같아야 통과

핵심은 “느낌으로 통일”이 아니라 “서버 응답으로 판별”한다는 점, 그리고 한 번 고치고 끝이 아니라 메뉴↔사이트맵 대조를 점검으로 남겨 다음에 또 어긋나면 바로 걸리게 한다는 점입니다.

한 걸음 더 — 가장 강한 방법은 301
교과서적으로 가장 깔끔한 건 한 형태만 200으로 열고 나머지는 301로 넘기는 것입니다(짝퉁 주소로 들어와도 진짜 주소로 자동 이동). 우리 사이트의 디렉터리 주소(/seo/ 같은 섹션 루트)는 서버가 이미 그렇게 자동으로 넘깁니다. 다만 말단 글 주소는 둘 다 200으로 열리는 구조라, 우리는 링크를 한 형태로 모으고 canonical이 자기 주소를 가리키게 해 신호를 일치시켰습니다. 서버에서 한쪽을 301로 강제하는 것도 다음 단계 옵션입니다 — 사이트 구조에 따라 고르면 됩니다.

관측된 결과 — 통일 후 링크·canonical·사이트맵이 한 형태로 일치하게 됐습니다. 다만 여기까지가 관측된 사실이고, 이걸로 순위가 올랐다거나 트래픽이 늘었다고는 말하지 않습니다. 우리가 본 것만 책임집니다 — 측정의 경계를 지킵니다.

많은 점검이 “깨진 링크가 있나(404)”에서 끝납니다. 그런데 더 조용히 비용을 키우는 건, 안 깨졌는데 두 주소로 다 열리는 경우입니다. 둘 다 200이라 점검에선 멀쩡해 보이는데, 정작 대표 주소가 둘로 갈리고 있는 상태죠. 그래서 우리는 “열리나”가 아니라 “같은 글이 한 곳을 가리키나”를 봅니다.

그리고 한 페이지가 아니라 사이트 전체의 링크 형태를 한꺼번에 봅니다. 1편(구조화 데이터)에서 같은 대상을 같은 이름으로 쓰는지를 봤듯, 이번엔 같은 글을 같은 형태로 가리키는지를 한 번에 맞춥니다. 페이지 한 장의 실수보다, 공통 틀을 타고 전체에 번지는 누적 오류가 더 위험하다고 보기 때문입니다.

그래서 차이는 — 트레일링 슬래시는 ‘링크를 거는’ 문제가 아니라 ‘한 곳을 가리키게 하는’ 문제입니다. 링크는 누구나 겁니다. 같은 글이 한 주소로 모이게 맞추는 일은 측정 없이는 안 됩니다 — 그게 넥스트티가 하는 일입니다.

CONCLUSION

트레일링 슬래시는 ‘링크’가 아니라 ‘한 곳을 가리키는가’의 문제입니다.

둘 다 열린다고 안전한 게 아닙니다. 중요한 건 같은 글이 한 주소로 모이는가입니다. 링크·canonical·사이트맵이 같은 곳을 가리키게 맞추는 것 — 그게 이 글이 말하려던 전부입니다.

덧붙이자면, 이 글의 주소에도 끝에 슬래시가 없습니다(/seo/canonical-trailing-slash). 우리가 정한 규칙을 이 페이지부터 지킵니다.