한 페이지에 주소가 여러 개면 — 정본 주소 하나로 모으는 법과 빙 URL 검사 상태 읽기

한 페이지가 주소 셋으로 열리고 있었다

2026년 10월 18일, 이 사이트(hwano-ai.com)의 응답을 직접 확인하다가 문제를 하나 찾았습니다. 홈페이지가 세 주소에서 모두 열리고 있었습니다.

• https://hwano-ai.com/ — 원래 쓰려던 주소
• http://hwano-ai.com/ — 리디렉트 없이 200으로 같은 문서를 내보냄
• https://www.hwano-ai.com/ — 리디렉트 없이 200으로 같은 문서를 내보냄

사람이 보기에는 아무 문제가 없습니다. 어느 주소로 들어와도 같은 화면이 뜹니다. 하지만 검색엔진이 보기에는 주소가 다른 문서 세 개가 같은 내용을 담고 있는 상태입니다. 같은 날 두 가지가 더 보였습니다. 끝에 슬래시가 없는 /profile은 307(임시 리디렉트)로 /profile/에 넘어가고 있었고, 사이트맵의 lastmod 일부가 실제로 고친 날과 맞지 않았습니다.

이 글은 그때 무엇을 근거로 어떻게 고쳤는지, 다음 날 다시 재서 찾은 것을 어떻게 고쳤는지, 그리고 빙 웹마스터 도구의 URL 검사 화면을 어떻게 읽었는지를 정리한 것입니다. 고친 것이 색인에 효과가 있었는지는 아직 모릅니다. 그 부분은 끝에 따로 적었습니다.

검색엔진은 주소가 여러 개인 페이지를 어떻게 보나

구글은 같은 내용을 가진 주소들 중 대표 하나를 고르는 일을 ‘정본화(canonicalization)’라고 부르고, 중복이 생기는 이유 가운데 하나로 http와 https 같은 ‘Protocol variants’를 들었습니다. 같은 문서는 사이트에 어느 정도 중복이 있는 것은 정상이고 스팸 정책 위반도 아니라고 하면서도, 같은 내용이 여러 URL에서 열리면 사용자 경험이 나빠질 수 있고 검색 성과를 추적하기도 어려워진다고 적었습니다.

빙은 더 직접적입니다. 빙 웹마스터 가이드라인의 ‘Consolidate Duplicate URLs’ 항목입니다.

“Avoid serving the same content across multiple URLs. Duplicate URLs dilute signals and reduce Bing’s confidence in selecting a URL for grounding results or citations.”

같은 내용을 여러 URL에서 내보내지 말라는 것, 그리고 중복 URL은 신호를 나누고 빙이 답변의 근거(grounding)나 인용에 쓸 URL을 고르는 확신을 떨어뜨린다는 뜻입니다. 이 가이드라인은 첫머리에서 자신이 Bing 검색뿐 아니라 Copilot과 grounding API 결과에서 콘텐츠를 어떻게 다루는지 설명하는 문서라고 밝히고 있습니다.

정본 하나로 모으는 네 가지 방법

구글은 정본을 알리는 방법의 세기를 이렇게 나눴습니다.

“Redirects: A strong signal that the target of the redirect should become canonical.”

“rel=“canonical” link annotations: A strong signal that the specified URL should become canonical.”

“Sitemap inclusion: A weak signal that helps the URLs that are included in a sitemap become canonical.”

리디렉트와 rel=canonical은 강한 신호, 사이트맵에 넣는 것은 약한 신호라는 뜻입니다. 같은 문서는 이 방법들을 함께 쓰면 더 효과적이라고 덧붙였고, 내부 링크에 대해서도 한 줄을 남겼습니다.

“When linking within your site, link to the canonical URL rather than a duplicate URL.”

http와 https 사이에서는 구글이 기본적으로 https를 정본으로 선호한다고 적었습니다(인증서가 잘못됐거나, https 페이지가 http로 넘기거나 http를 canonical로 가리키는 등 신호가 어긋나는 경우는 예외).

빙 가이드라인의 사이트맵 항목에는 “List only canonical URLs”, “Remove deleted or redirected URLs promptly”라고, 사이트맵에는 정본 URL만 넣고 삭제되거나 리디렉트되는 URL은 빨리 빼라고 적혀 있습니다. 정리하면 네 가지입니다.

빙은 rel=canonical만으로 해결하려는 것을 경계합니다. 중복 콘텐츠 항목에 “Canonical tags help signal preference but do not replace fixing underlying issues”라고, 정본 태그는 선호를 알릴 뿐 근본 문제를 고치는 일을 대신하지 않는다고 적었고, 콘텐츠가 옮겨 갈 때는 “Use redirects instead of canonical tags”, 정본 태그 대신 리디렉트를 쓰라고 했습니다. 그래서 이 사이트에서는 태그만 두지 않고 리디렉트를 먼저 걸었습니다.

lastmod를 정직하게 다루는 이유는 AI 답변 최신성과 갱신일 관리 글에 따로 정리했습니다.

301과 302·307은 무엇이 다른가

브라우저에서는 셋 다 ‘다른 주소로 넘어간다’로 똑같이 보입니다. 차이는 검색엔진이 그 리디렉트를 어떻게 해석하느냐에 있습니다. 구글 문서의 설명입니다.

“Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.”

영구 리디렉트(301·308)는 도착 주소를 정본으로 삼으라는 신호로 쓰인다는 뜻입니다. 임시 리디렉트(302·307)에 대해서는 반대로 적었습니다.

“Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.”

임시 리디렉트는 따라가기는 하지만 정본 신호로는 쓰지 않는다는 말입니다(다른 정본 신호가 있으면 도착 페이지가 색인될 수는 있다고 덧붙였습니다). 같은 문서는 영구 리디렉트는 검색 결과에 새 주소를, 임시 리디렉트는 원래 주소를 보여 준다고 정리했습니다. 빙 가이드라인도 같은 방향입니다. “Use 301 redirects for permanent URL changes”, “Use 302 redirects only for very short-term changes (less than 2 days)” — 영구 변경에는 301을, 302는 2일 미만의 아주 짧은 변경에만 쓰라는 뜻입니다.

이 사이트의 /profile → /profile/ 307은 일부러 고른 것이 아니라 호스팅의 기본 동작이었습니다. 끝 슬래시는 앞으로도 바꿀 계획이 없는 영구 규칙이므로 301이 맞다고 판단했습니다.

리디렉트를 여러 번 거치는 문제도 있습니다. 빙의 URL 검사 도움말은 Live URL 기능이 리디렉트를 따라가지 않는다고 설명하면서, 이것이 빙봇이 일하는 방식이라며 이렇게 적었습니다.

“Every redirect requires a brand-new fetch, and this new fetch does not necessarily happen immediately after encountering the redirect.”

리디렉트마다 새로 가져와야 하고, 그 새 요청이 리디렉트를 만난 직후에 일어나는 것도 아니라는 뜻입니다. 도움말이 ‘리디렉트 횟수를 줄이라’고 직접 쓴 것은 아니지만, 저는 이 설명을 근거로 정본까지 한 번에 보내는 편이 낫다고 봅니다.

2026-10-18에 고친 것

같은 날 아래를 고쳤습니다.

1. Cloudflare 워커로 http://와 www.로 들어온 요청을 모두 https://hwano-ai.com으로 301 리디렉트
2. 끝 슬래시 없는 문서 주소(/profile 등)를 끝 슬래시 주소로 301 리디렉트(기존 307 대신)
3. 사이트맵 lastmod를 각 페이지를 실제로 고친 날로 맞춤
4. 바뀐 URL을 IndexNow로 보냄 — Bing은 200으로 접수

IndexNow의 200을 색인으로 읽으면 안 됩니다. IndexNow 문서의 응답표에서 200은 “URL submitted successfully”이고, 본문에는 “The HTTP 200 response code only indicates that the search engine has received your URL”, 즉 검색엔진이 URL을 받았다는 것만 뜻한다고 적혀 있습니다. IndexNow를 써도 크롤·색인이 보장되지 않는다는 빙의 설명과 실제로 걸린 기간은 AI 상위노출은 얼마나 걸리나에 정리했습니다.

다음 날 다시 잰 결과 (2026-10-19)

고친 다음 날 curl -sI로 다시 확인했습니다. 리디렉트를 끝까지 따라간 경로는 curl -sIL로 봤습니다. 아래 값은 모두 2026-10-19, 아래에 적은 추가 수정을 하기 전 배포본을 잰 것입니다.

/profile/의 HTML에는 <link rel="canonical" href="https://hwano-ai.com/profile/">가 있고, 사이트맵에도 https://hwano-ai.com/profile/만 들어 있는 것을 같은 날 확인했습니다.

마지막 줄은 2026-10-19에 이 측정에서 찾은 것입니다. http://나 www.에 끝 슬래시까지 빠진 주소는 호스트를 고치는 301과 슬래시를 붙이는 301을 차례로 거쳐, 리디렉트 두 번 만에 정본에 닿고 있었습니다. 둘 다 301이라 정본 신호는 같은 방향을 가리키지만, 위 빙 도움말 설명을 보면 한 번에 보내는 편이 낫다고 판단했습니다.

그래서 같은 날 워커를 고쳐, 호스트(https·www 없음)와 끝 슬래시를 한 응답에서 함께 바로잡고 301을 한 번만 보내도록 바꿨습니다. 이 변경은 이 글과 같은 배포에 들어갔고, 배포 뒤 같은 날 다시 쟀습니다.

빙 웹마스터 도구 URL 검사 상태 읽기

2026-10-18, 주소를 고친 날 빙 웹마스터 도구의 URL 검사에 주소 세 개를 넣어 봤습니다. 오른쪽 칸은 상태 이름을 보고 제가 읽은 것입니다.

여기서 배운 것은 단순합니다. URL 검사에는 정본 주소를 넣어야 합니다. 슬래시 하나 차이로 ‘발견 안 됨’과 ‘발견됐지만 크롤 안 됨’이 갈렸습니다. 정본이 아닌 주소의 결과를 보고 ‘프로필 페이지를 빙이 모른다’고 결론 냈다면 틀린 진단이었을 것입니다.

빙 도움말은 URL 검사의 Index 카드가 URL이 언제·어디서 발견되고 크롤되고 색인됐는지 단계별로 보여 주며, 색인되지 않았을 때는 오류와 함께 색인 요청·지원 문의·robots.txt 수정 같은 조치를 보여 준다고 설명합니다. 다만 상태 이름 하나하나의 정의는 도움말에 적혀 있지 않았습니다. 그래서 아래 표의 ‘제 해석’과 ‘제가 하는 일’은 상태 이름과 그 설명을 바탕으로 제가 정리한 것이지, 빙이 밝힌 정의가 아닙니다. 직접 본 세 상태만 적었습니다.

‘Discovered but not crawled’는 다른 사이트에서도 본 적이 있습니다. 그 기록은 빙 색인 101개 중 5개 연구와 크롤과 색인의 차이 기록에 있으니 여기서는 되풀이하지 않습니다.

빙 색인이 AI 검색과 어떤 관계인가

근거가 있는 만큼만 적습니다.

• Copilot: 빙 웹마스터 가이드라인은 Bing과 Copilot 검색 경험이 기존 검색과 같은 크롤·색인·순위 기반에 기대고 있다고 적었습니다(“Bing and Copilot search experiences rely on the same core crawling, indexing, and ranking foundation as traditional search”).
• ChatGPT 검색: OpenAI는 ChatGPT 검색이 “third-party search providers”, 즉 외부 검색 제공자와 파트너가 직접 제공한 콘텐츠를 쓴다고 밝혔습니다. 도움말에는 검색 제공자의 개인정보 처리방침으로 Microsoft 개인정보 처리방침이 링크돼 있습니다(2026-10-19 확인). 그러나 OpenAI 문서에서 ‘ChatGPT 검색 결과는 빙 색인에서 나온다’거나 그 비중을 밝힌 문장은 찾지 못했습니다. 검색 제공자에게 질문이 어떻게 넘어가는지는 ChatGPT에만 있는 작업에 따로 정리했습니다. 빙 색인이 0건인 경쟁사 페이지가 다른 답변엔진에 인용된 사례도 직접 본 적이 있습니다(연구).

그래서 저는 빙 색인을 ‘AI 답변에 나오는 조건’이 아니라, 밖에서 확인할 수 있는 몇 안 되는 지표 중 하나로 봅니다.

직접 확인하는 법 — 사장님·작업자용 점검표

터미널이 있다면 curl로, 없다면 브라우저로 확인할 수 있습니다.

1. 주소 변형 네 가지를 차례로 열어 본다. http://, https://, www. 붙인 것·뺀 것을 주소창에 직접 쳐 보고, 모두 같은 하나의 주소로 바뀌는지 봅니다. 주소창이 그대로 머무는 변형이 있으면 그 주소가 따로 열리고 있는 것입니다.
2. 응답 코드를 본다. curl -sI http://example.com/을 실행해 첫 줄이 301이고 Location:이 정본 주소인지 확인합니다. 302·307이면 영구 규칙인지 따져 보고 301로 바꿉니다. 브라우저라면 개발자 도구(F12) → Network 탭 → ‘Preserve log’를 켜고 주소를 열어 Status 열을 봅니다.
3. 끝 슬래시를 본다. 하위 페이지 하나를 슬래시를 붙인 것·뺀 것으로 열어 보고, 하나로 301 되는지 확인합니다.
4. 리디렉트 횟수를 본다. curl -sIL http://www.example.com/page로 끝까지 따라가 HTTP/ 줄이 몇 번 나오는지 셉니다. 301이 두 번 이상이면 한 번에 정본으로 보내도록 줄입니다.
5. 정본 태그를 본다. 페이지에서 오른쪽 클릭 → ‘페이지 소스 보기’ → canonical을 찾아, 지금 보고 있는 정본 주소와 글자 하나까지 같은지 봅니다.
6. 사이트맵을 본다. /sitemap.xml을 열어 <loc>에 정본 주소만 있는지, http://·www.·슬래시 없는 주소가 섞이지 않았는지, lastmod가 실제로 고친 날인지 봅니다.
7. 내부 링크를 본다. 메뉴와 본문 링크가 정본 주소를 가리키는지 확인합니다. 리디렉트되는 주소로 링크가 걸려 있으면 정본으로 바꿉니다.
8. 빙 URL 검사에는 정본 주소를 넣는다. 결과 상태는 위 표(제 해석)를 참고해 읽고, 색인 요청은 한 번만 합니다.

비슷한 어긋남, 즉 대표 주소와 사이트맵은 슬래시 없는 주소를 가리키는데 서버는 슬래시 주소로 넘기던 일은 다른 사이트 기록에 있습니다.

아직 모르는 것

• 2026-10-18·19의 수정이 빙 색인에 영향을 줬는지는 아직 알 수 없습니다. 2026-10-18 URL 검사 때 /profile/은 2026-10-15에 발견된 뒤 크롤 전 상태였고, 고친 지 하루밖에 지나지 않았습니다. 약 1주 뒤 같은 주소를 URL 검사로 다시 확인할 예정입니다.
• 그때 상태가 바뀌어 있더라도, 주소를 정리한 것 때문인지 시간이 지나서인지는 가릴 수 없습니다. 고치지 않은 비교 대상이 없기 때문입니다.
• 2026-10-19에 바꾼 ‘한 번에 301’ 동작은 배포 뒤 실제 주소로 확인했지만, 이것이 빙의 수집에 어떤 차이를 냈는지는 아직 모릅니다.
• 한 사이트·한 시점의 기록입니다.

크롤과 색인에 걸리는 시간 자체는 AI 상위노출은 얼마나 걸리나에 단계별로 정리했습니다.

이 글을 쓴 사람

이 글은 AI 상위노출(AI 검색 노출) 작업을 하는 유환호가 썼습니다. 이 주제로 일을 하고 있으므로 이해관계가 있습니다. 표에 나온 응답 코드는 이 사이트(hwano-ai.com)를 날짜를 적어 직접 잰 값이고, 인용한 구글·빙·IndexNow·OpenAI 문서는 2026-10-19에 원문을 열어 문장을 대조했습니다. 고친 것의 효과는 확인되는 대로 이 글에 날짜와 함께 덧붙입니다.