www·.html 중복 주소가 계산기 색인을 갈라놓은 과정

2026-09-13 · 글쓴이 딸깍이 아저씨 (Mr. Ddalkak Uncle)

계산기 페이지에 canonical이 있어도 www, 루트 도메인, .html, 확장자 없는 주소가 모두 발견되면 Google은 여러 URL을 크롤링합니다. 우리 사이트에서는 실제 계산기 4개가 www로 색인됐고, 내부 .html 링크가 미색인 주소를 계속 만들고 있었습니다.

처음 보인 신호는 미색인 50개였다

2026년 8월 6일 Search Console에서 색인되지 않은 페이지 50개를 살폈습니다. 이 가운데 42개가 우리가 의도한 대표 주소가 아니라 .html이 붙은 파생 주소와 연결돼 있었습니다. 리디렉션이 포함된 페이지 20개와 발견됨 - 현재 색인 생성되지 않음 22개였습니다.

Cloudflare Pages는 실제 .html 파일 요청을 확장자 없는 주소로 이동시켰습니다. canonical과 사이트맵은 이미 확장자 없는 주소를 가리켰지만, 본문과 카드의 내부 링크에는 .html이 남아 있었습니다.

검색엔진은 사이트맵만 읽지 않습니다. 페이지 안의 링크도 따라갑니다. 우리가 모든 글에서 옛 주소를 계속 알려 주고 있었으니 Google은 그 주소를 발견하고, 리디렉션을 확인하고, 대표 주소를 다시 처리해야 했습니다.

www는 더 눈에 띄지 않는 중복이었다

8월 10일 색인된 페이지 65개를 열다가 www.trendgacharadar.com/tools/loan-calculator를 발견했습니다. 확인해 보니 www가 루트 도메인과 같은 내용을 리디렉션 없이 200으로 제공하고 있었습니다.

양쪽 페이지의 canonical은 https://trendgacharadar.com/...을 가리켰습니다. 그래도 Google은 두 호스트를 각각 크롤링했고, 다음 계산기 4개는 www 주소로 색인했습니다.

• 대출 상환 계산기
• 예적금 계산기
• 대출 한도 계산기
• 중도상환수수료 계산기

canonical은 강한 신호지만 서버 이동을 대신하지 않습니다. 사용자가 어느 호스트로 들어와도 200을 받고 같은 내용을 볼 수 있으면, 검색엔진은 두 주소의 관계를 확인하는 데 자원을 씁니다. 대표 주소 하나로 모으려면 링크·사이트맵·canonical뿐 아니라 서버 응답도 같은 결론을 말해야 합니다.

주소 신호를 한곳으로 모은 방법

첫째, 생성기의 모든 내부 링크에서 .html을 제거했습니다. index.html은 디렉터리 주소로, 글과 도구는 확장자 없는 주소로 연결했습니다. 외부 링크와 쿼리·앵커는 건드리지 않았습니다.

둘째, canonical과 사이트맵도 같은 루트 도메인·확장자 없는 URL만 사용했습니다. 사이트맵에는 실제 색인시키고 싶은 주소만 남겼습니다.

셋째, 이미 Google이 발견한 옛 슬러그는 실제 새 글이 있을 때만 301로 연결했습니다. 삭제한 글을 모두 홈으로 보내지는 않았습니다. 대체 내용이 없으면 404가 더 정확하기 때문입니다.

넷째, Cloudflare의 Page Rule에서 www.trendgacharadar.com/*를 https://trendgacharadar.com/$1로 301 이동시켰습니다. 정적 사이트의 _redirects는 경로는 처리하지만 호스트 이름을 조건으로 잡지 못했기 때문에 대시보드 설정이 필요했습니다.

고친 뒤 무엇을 확인했나

설정 화면에서 저장됐다는 표시만 보지 않고 실제 요청을 확인했습니다.

연쇄 리디렉션도 최종 도착지를 확인했습니다. www + 옛 슬러그처럼 조건이 두 개 겹치면 301을 두 번 거칠 수 있습니다. 가능하면 한 번이 좋지만, 잘못된 200이나 404보다 의도한 대표 페이지에 도착하는지가 먼저입니다.

Search Console 숫자는 수정 직후 사라지지 않았습니다. 과거에 발견된 URL은 Google이 다시 방문해 새 응답을 처리해야 합니다. 그래서 코드 수정과 “Google이 새 상태를 확인한 것”을 같은 완료로 보지 않았습니다.

재발을 막은 검사

생성된 HTML의 내부 링크가 실제 파일을 가리키는지 빌드에서 검사합니다. 링크 하나가 잘못되면 배포 전에 실패합니다. 사이트맵도 모든 URL의 수정일을 빌드 날짜로 덮지 않고, 실제 발행일을 아는 글만 lastmod를 넣도록 바꿨습니다.

새 도메인을 연결할 때는 다음 네 가지를 한 묶음으로 확인하면 빠릅니다.

1. http → https 이동
2. www → 대표 호스트 이동
3. 확장자·슬래시 규칙
4. canonical·내부 링크·사이트맵의 URL 일치

자주 묻는 질문

canonical만 있으면 301은 없어도 되나요?

항상 그런 것은 아닙니다. canonical은 대표 URL을 알리는 신호이고, 301은 사용자와 검색엔진을 실제 대표 주소로 이동시킵니다. 호스트를 하나로 운영한다면 서버 이동과 링크 신호를 함께 맞추는 편이 명확합니다.

리디렉션 페이지가 Search Console에 보이면 오류인가요?

목적지가 정확하고 대표 URL이 색인된다면 리디렉션 주소 자체가 색인 대상에서 빠지는 것은 정상입니다. 다만 내부 링크와 사이트맵이 계속 옛 주소를 제출하고 있지는 않은지 확인하세요.

www 주소가 아직 검색결과에 보이면 다시 색인 요청해야 하나요?

먼저 www 요청이 301로 대표 주소에 도착하는지 확인하세요. 중요한 대표 URL은 URL 검사로 현재 상태를 볼 수 있지만, 반복 요청이 처리 속도를 보장하지는 않습니다.

참고 자료

• Google 검색 센터, 리디렉션과 Google 검색
• Google 검색 센터, 중복 URL 통합
• Google 검색 센터, Google이 이해할 수 있는 링크

글쓴이 딸깍이 아저씨 (Mr. Ddalkak Uncle) · 글감 찾다 지쳐서 직접 도구를 만든 콘텐츠 운영자. 소개 보기

이 글 수정