seo최적화 중 카테고리 구조 변경은 주소 대응표에서 시작합니다

seo최적화 도중 카테고리 구조 변경이 필요하면 메뉴 설계보다 대응표를 먼저 만듭니다. 대응표는 옛 주소마다 도착할 새 주소 하나를 정한 표입니다. 이 표를 기준으로 리디렉션, 내부 링크, 사이트맵을 맞추고 전환 뒤에도 이 표로 확인합니다. 같은 표에 주소별 전환 전 검색 유입을 적으면 전환 뒤 변화를 비교할 수 있습니다.

메뉴만 바꿀 때와 주소까지 바꿀 때는 준비가 어떻게 다른가요?

먼저 이번 변경이 화면의 메뉴만 바꾸는지, 페이지 주소까지 바꾸는지 구분합니다. 메뉴 이름이나 순서만 바뀌고 주소가 그대로라면 리디렉션 작업은 필요하지 않습니다. Google의 사이트 이전 문서는 같은 도메인 안에서 경로가 바뀌는 경우도 URL이 바뀌는 사이트 이전의 한 유형으로 봅니다. 카테고리를 합치거나 나누면서 경로가 바뀐다면 사이트 이전과 같은 준비를 합니다.

구조를 바꾸는 이유도 한 줄로 적습니다. Google SEO 기본 가이드(SEO Starter Guide)의 사이트 구성 항목은 URL이 수천 개를 넘는 사이트라면 콘텐츠 구성 방식이 크롤링과 색인에 영향을 줄 수 있다고 설명합니다. 같은 항목은 그렇다고 하던 일을 모두 멈추고 지금 당장 사이트를 재구성하지는 말라고 덧붙입니다. 재구성이 장기적으로 도움이 될 수는 있지만, 검색엔진은 바꾸지 않은 지금의 페이지도 이해할 가능성이 높다는 설명입니다.

실무에서는 근거가 있을 때 구조 변경을 결정하는 방법을 권합니다. 예를 들어 사이트 내 검색어나 고객 문의에서 원하는 정보를 찾기 어렵다는 기록이 되풀이될 때입니다.

1단계: 바뀌는 주소 목록과 기준 수치는 어디서 모으나요?

사이트 이전 문서는 사이트맵, 트래픽 자료, 서버 로그에서 중요한 URL부터 모으라고 권장합니다. 이미지, 동영상, 자바스크립트, CSS 파일의 주소도 목록에 넣습니다. 카테고리 목록 페이지만 보면 그 아래 상세 페이지와 첨부 파일 경로가 함께 바뀌는 것을 놓치기 쉽습니다.

1. 현재 사이트맵에 들어 있는 주소 전체
2. 검색 유입이나 방문 기록이 있는 페이지 주소
3. 서버 로그에 요청 기록이 남은 주소
4. 경로가 함께 바뀌는 이미지·동영상·자바스크립트·CSS 파일 주소
5. 정렬·필터처럼 매개변수가 붙은 카테고리 목록 주소

목록을 모으면서 전환 전 기준 수치도 기록합니다. 실무에서는 Search Console 실적 보고서에서 주소별 최근 3개월 클릭 수와 노출 수를 옮겨 적는 방법을 권합니다. 기록 양식은 「옛 주소 | 최근 3개월 클릭 수 | 노출 수 | 기록일」 네 칸이면 충분합니다. 이 값이 있어야 5단계에서 유입 변화를 같은 기준으로 비교할 수 있습니다.

완료 기준: 바뀌는 카테고리 아래 주소가 중복 없이 한 목록에 모였고, 주소마다 전환 전 클릭 수와 기록일이 적힌 상태입니다.

2단계: 옛 주소마다 새 주소는 어떻게 정하나요?

옛 주소마다 같은 내용을 담은 새 주소를 정합니다. 사이트 이전 문서는 많은 옛 주소를 새 홈페이지처럼 관련 없는 한 페이지로 보내지 말라고 권장합니다. 사용자가 혼란을 겪고 소프트 404 오류로 처리될 수 있기 때문입니다. 소프트 404는 내용이 없는데도 정상 페이지처럼 응답하는 경우입니다. 옮기지 않는 내용은 404 또는 410 응답 코드를 돌려주게 합니다.

새 주소를 지을 때는 Google의 URL 구조 권장 사항을 함께 적용합니다. 이 문서는 ID 숫자보다 읽을 수 있는 단어를 쓰고, 단어 사이는 밑줄 대신 하이픈으로 구분하라고 제시합니다. 필요 없는 매개변수도 줄입니다. URL은 대소문자를 구분하므로, 실무에서는 소문자로 통일하는 방법을 권합니다.

내용이 같은 여러 옛 주소를 한 페이지로 합칠 때는 여러 행이 같은 새 주소를 가리켜도 됩니다. 기준은 도착 페이지가 옛 주소의 내용을 실제로 담고 있는가입니다. 예를 들어 가상의 산업 장비 기업이 「제품」과 「솔루션」 카테고리를 「산업별 솔루션」 하나로 합친다면 대응표를 다음처럼 씁니다.

확인 메모 칸에는 그렇게 처리한 이유를 적습니다. 1단계의 기준 수치 칸을 이 표 오른쪽에 붙이면 한 장으로 관리할 수 있습니다. 전환 뒤 유입이 줄어든 페이지가 생기면 원인을 찾을 때 이 두 칸부터 봅니다.

완료 기준: 목록의 모든 옛 주소에 새 주소나 404·410 처리가 적혀 있습니다. 빈칸이 없고, 관련 없는 홈페이지 한 곳으로 몰린 행도 없는 상태입니다.

3단계: 새 메뉴와 본문에서 함께 고칠 곳은 어디인가요?

사이트 이전 문서는 새 사이트의 내부 링크를 옛 URL에서 새 URL로 바꾸라고 권장합니다. 리디렉션을 설정했더라도 내부 링크는 모두 새 주소로 바꿉니다. 옛 주소 링크가 남으면 사용자와 크롤러가 이동할 때마다 리디렉션을 한 번 더 거칩니다. 메뉴, 본문, 푸터, 이동 경로(브레드크럼)를 모두 대상으로 잡습니다.

• 메뉴 링크 형식: Google의 링크 권장 사항 문서에 따르면 Google은 일반적으로 href 속성이 있는 a 요소만 크롤링할 수 있습니다. onclick이나 span으로 만든 메뉴는 링크로 인식되지 않을 수 있습니다.
• 빠지는 페이지 확인: 같은 문서는 중요한 페이지마다 사이트 안의 다른 페이지 하나 이상에서 링크하라고 권장합니다. 카테고리를 합친 뒤 어느 메뉴에도 연결되지 않은 상세 페이지가 생겼는지 확인합니다.
• 링크 문구: 「더 보기」 같은 일반 문구 대신 도착 페이지를 설명하는 짧은 문구를 씁니다.
• 이동 경로: Google의 브레드크럼 문서는 URL 구조를 그대로 옮기기보다 사용자가 그 페이지에 흔히 도달하는 경로를 보여 주라고 권장합니다.
• 표준 주소: 새 주소마다 canonical 태그를 넣어 자기 주소를 가리키게 합니다. canonical은 여러 주소 가운데 대표 주소를 알리는 태그입니다. hreflang(언어·지역별 대체 페이지를 알리는 태그)을 쓰고 있다면 이것도 새 주소로 바꿉니다.
• 차단 설정: 새 사이트의 robots.txt(크롤러 접근 범위를 정하는 파일)가 막으려는 부분만 막는지 확인합니다. 이전 작업에만 필요했던 noindex(검색 결과에서 빼 달라는 지시)나 차단 규칙은 지웁니다.

개발 담당자에게는 다음처럼 요청하면 작업 범위가 분명해집니다.

「첨부한 주소 대응표를 기준으로 옛 주소마다 서버에서 301 리디렉션을 설정하고, 중간 경유 없이 최종 주소로 보내 주십시오. 메뉴·본문·이동 경로의 내부 링크를 새 주소로 바꿔 주십시오. 새 페이지의 canonical 태그가 자기 주소를 가리키는지, 개발 중에 넣은 noindex가 남아 있지 않은지도 확인 부탁드립니다.」

완료 기준: 사이트의 내부 링크를 수집했을 때 옛 주소로 가는 링크가 0건이고, 새 페이지의 canonical이 모두 자기 주소를 가리키는 상태입니다.

4단계: 리디렉션은 어떤 방식으로 걸고 어떻게 시험하나요?

Google의 리디렉션 문서는 서버 측 영구 리디렉션(301 또는 308)을 권장합니다. 이 문서의 표는 영구 리디렉션을 도착 주소가 표준 주소라는 신호로 쓰고, 검색 결과에 새 주소를 보여 준다고 설명합니다. 302, 303, 307 같은 임시 리디렉션은 색인 과정에서 이 신호로 쓰지 않고, 검색 결과에 원래 페이지를 보여 준다고 설명합니다. 다만 다른 표준화 신호가 있으면 도착 페이지가 색인될 수도 있다고 덧붙입니다. 되돌릴 계획이 없는 카테고리 이전에는 임시 리디렉션을 쓰지 않습니다.

서버 설정을 바꿀 수 없을 때만 즉시 실행되는 메타 새로고침을 씁니다. 같은 문서는 0초 메타 새로고침을 영구로, 지연이 있는 것을 임시로 분류합니다. 자바스크립트 리디렉션은 렌더링이 실패하면 Google이 보지 못할 수 있어 마지막 수단으로 둡니다.

리디렉션이 여러 번 이어지지 않게 합니다. 사이트 이전 문서는 연쇄 리디렉션을 피하고 최종 도착 주소로 바로 보내라고 권장합니다. 예전에 이미 리디렉션한 주소가 있다면 그 주소도 이번 최종 주소로 곧바로 가도록 고칩니다.

1. 대응표의 옛 주소를 모두 요청해 응답 코드가 301 또는 308인지 확인합니다.
2. 도착 주소가 대응표의 새 주소와 같고 중간 단계가 없는지 확인합니다.
3. 404나 410으로 정한 주소가 실제로 그 코드를 돌려주는지 확인합니다.
4. 대표 페이지 몇 개는 Search Console의 URL 검사 도구로 따로 확인합니다.

주소를 하나씩 볼 때는 URL 검사 도구를 씁니다. 주소가 많으면 개발 담당자에게 「대응표의 옛 주소 전체에 대해 응답 코드와 최종 도착 주소를 표로 뽑아 주십시오」라고 요청합니다. 결과표는 「옛 주소 | 응답 코드 | 최종 도착 주소 | 대응표 일치 여부」 네 칸으로 받으면 불일치 행을 바로 찾을 수 있습니다.

새 주소로 사이트맵을 만들어 Search Console에 제출합니다. 실무에서는 옛 주소 사이트맵도 전환 직후 한동안 확인용으로 남기는 방법을 권합니다. 옛 사이트맵을 남기면 옛 주소가 리디렉션된다는 경고가 표시될 수 있습니다. 사이트 이전 문서는 이 경고를 정상적인 결과로 보고 무시해도 된다고 설명합니다. 같은 문서는 이후 Google이 새 사이트맵을 쓰게 되면 옛 사이트맵을 삭제해도 된다고 안내합니다.

사이트 이전 문서는 중소규모 사이트라면 한 구역씩이 아니라 모든 주소를 한 번에 옮기라고 권장합니다. 대규모 사이트는 구역별로 나누어 옮길 수 있다고 설명합니다. 다른 검색엔진의 웹마스터 도구도 쓰는 사이트라면, 실무에서는 같은 새 사이트맵을 그쪽에도 제출하는 방법을 권합니다.

완료 기준: 결과표의 모든 행이 대응표와 일치하고, 새 사이트맵 제출까지 끝난 상태입니다.

5단계: 전환 뒤에는 무엇을 지켜보고 언제 마무리하나요?

사이트 이전 문서는 이전 기간에 순위가 일시적으로 흔들릴 수 있다고 설명합니다. 중소규모 사이트는 대부분의 페이지가 옮겨지기까지 몇 주가 걸릴 수 있고, 큰 사이트는 더 오래 걸립니다. 관찰할 흐름은 옛 주소의 유입이 줄고 새 주소의 유입이 느는 것입니다. 이 흐름을 상급자와 관련 부서에 미리 공유하면 전환 직후의 수치 변동을 문제로 오해하는 일을 줄일 수 있습니다.

실무에서는 다음 시점에 나누어 확인하는 방법을 권합니다.

사이트 이전 문서는 리디렉션을 가능한 한 오래, 일반적으로 최소 1년 유지하라고 권장합니다. 자사가 관리하는 다른 채널의 링크와 유입이 많은 외부 링크도 새 주소로 바꾸는 대상입니다. 외부 링크는 링크를 건 사이트의 담당자에게 새 주소로 고쳐 달라고 요청합니다.

완료 기준: 주 단위 클릭 수가 몇 주 연속 큰 변동 없이 이어지고, 1단계 기준 기록과의 차이를 담당자가 설명할 수 있는 상태입니다. 리디렉션 유지 기간과 담당자도 문서로 정해져 있어야 합니다.

정리

카테고리 구조 변경은 주소 대응표 한 장을 기준으로 리디렉션, 내부 링크, 사이트맵을 맞추는 작업입니다. 다음 순서로 바로 시작합니다.

1. 이번 변경이 주소까지 바꾸는지 구분하고, 바꾸는 이유를 한 줄로 적습니다.
2. 사이트맵, 유입 기록, 서버 로그로 바뀌는 주소 목록을 만들고 주소별 전환 전 클릭 수를 기록합니다.
3. 옛 주소마다 새 주소나 404·410 처리를 정해 대응표를 완성합니다.
4. 내부 링크, canonical, robots.txt를 고치고 서버 측 301을 설정한 뒤 전체 주소를 결과표로 시험합니다.
5. 새 사이트맵을 제출하고 기준 기록과 유입을 주 단위로 비교하며, 리디렉션을 최소 1년 유지합니다.

참고 자료

• Site moves with URL changes (Google Search Central, 확인일 2026-10-22)
• Redirects and Google Search (Google Search Central, 확인일 2026-10-22)
• URL structure best practices for Google Search (Google Search Central, 확인일 2026-10-22)
• Link best practices for Google (Google Search Central, 확인일 2026-10-22)
• SEO Starter Guide (Google Search Central, 확인일 2026-10-22)
• Breadcrumb (BreadcrumbList) structured data (Google Search Central, 확인일 2026-10-22)