URL 마이그레이션 후 하나의 이전 URL-새 URL 매핑을 사용해 공개 링크, 표준 URL 선언, 리디렉션 및 사이트맵 항목을 업데이트하세요. 이 Mac 데스크톱 워크플로에서는 이러한 변경 사항을 서로 일치시키고 게시된 결과를 확인하는 방법을 설명합니다.

여기서는 같은 웹사이트의 새 경로로 옮기는 소규모 공개 HTML 문서 모음을 다룹니다. 예시에 나온 주소와 페이지 이름은 모두 가상입니다. 전체 워크플로를 수행하려면 게시 시스템, 리디렉션 설정, 관련 Search Console 속성에 액세스할 수 있어야 합니다.

마이그레이션 후 무엇이 일치해야 하나요?

이동한 문서마다 최종 도착지 하나를 정하세요. 직접 관리하는 링크는 그곳을 직접 가리키고, 도착지 문서는 자신을 표준 URL로 지정해야 하며, 현재 사이트맵에는 해당 주소가 나와야 합니다. 이전 주소는 그곳으로 리디렉션해야 합니다. Google은 리디렉션과 표준 URL 주석을 강력한 표준화 신호로 설명하며, 사이트맵 포함은 더 약한 신호라고 설명합니다. 이러한 방법은 서로 보완할 수 있지만, 궁극적으로 표준 URL을 선택하는 주체는 Google입니다. Google의 표준 URL 지정 안내.

각 방식의 역할은 다릅니다. 리디렉션은 이전 주소에 대한 요청을 처리합니다. 공개 링크는 독자가 다음에 이동할 곳을 정합니다. 표준 URL 선언은 문서에서 선호하는 URL을 지정합니다. WHATWG는 canonical 링크 유형에 이 의미를 정의합니다. 사이트맵은 검색 및 발견을 위해 선호 URL 목록을 제공합니다. 하나를 업데이트해도 나머지는 바뀌지 않습니다. WHATWG HTML 표준: canonical 링크 유형, Google의 사이트맵 안내.

아래의 일치 여부 표를 실용적인 승인 기준으로 사용하세요. 이는 문서를 바탕으로 만든 워크플로이며, Google의 점수 체계는 아닙니다.

항목 가상 Colors 문서에서 기대하는 결과
이전 주소 https://example.com/notes/colors.html가 도착지로 영구 리디렉션됨
도착지 https://example.com/library/colors/에서 Colors 문서 제공
탐색 및 문서 링크 https://example.com/library/colors/을 직접 가리킴
도착지 표준 URL https://example.com/library/colors/을 지정함
현재 사이트맵 항목 https://example.com/library/colors/을 나열함

개별 설정을 변경하기 전에 매핑 하나를 만드세요

Mac에서 스프레드시트나 일반 텍스트 편집기를 열고 각 이전 주소 옆에 의도한 도착지를 기록하세요. Google은 사이트 이전의 일부로 이전 URL과 새 URL의 매핑을 준비할 것을 권장합니다. 사이트맵 항목을 교체하더라도 리디렉션이 필요한 주소 기록이 사라지지 않도록 원본 목록을 보관하세요. Google의 사이트 이전 안내.

문서 이전 경로 최종 경로
Colors /notes/colors.html /library/colors/
Palette /notes/palette.html /library/palette/
Shapes /notes/shapes.html /library/shapes/

각 행에 변경해야 할 위치를 기록하세요. 페이지 편집기, 공통 탐색 메뉴, 표준 URL 설정, 리디렉션 설정, 사이트맵 생성기가 해당합니다. 공개 응답과 Search Console 검사 결과를 위한 확인 열도 추가하세요. 이렇게 하면 막연한 “URL 업데이트” 지시가 정해진 편집 및 확인 작업으로 바뀝니다.

매핑을 승인하기 전에 도착지 콘텐츠를 확인하세요. 이전 문서 두 개가 하나의 유용한 통합 문서로 바뀌었다면 두 주소 모두 그 문서로 리디렉션할 수 있습니다. 관련 없는 문서를 일반 홈페이지로 보내지 마세요. Google은 관련성이 없는 리디렉션이 소프트 404로 처리될 수 있다고 경고합니다. Google의 리디렉션 매핑 권장 사항.

공개 링크를 업데이트하고 상대 경로를 확인하세요

게시 편집기에서 매핑을 사용해 탐색 메뉴, 문서 색인, 관련 문서 링크, 본문 안의 링크를 업데이트하세요. 시스템이 페이지 레코드에서 탐색 메뉴를 생성한다면, 생성된 결과를 매번 수정하는 대신 원본 레코드나 템플릿을 변경하세요. 특히 설명용 예시에 이전 경로가 등장하는 경우, 저장하기 전에 각 대체 내용을 검토하세요.

링크 텍스트가 그대로여도 경로가 바뀌면 상대 링크의 도착지가 달라질 수 있습니다. WHATWG URL 표준은 기준 URL을 바탕으로 상대 참조를 해석합니다. 아래의 설명용 사례에서는 문서에 명시적인 기준 URL 재정의가 없다고 가정합니다. WHATWG URL 표준.

문서 URL 링크 값 해석된 도착지
https://example.com/notes/colors.html palette.html https://example.com/notes/palette.html
https://example.com/library/colors/ palette.html https://example.com/library/colors/palette.html
https://example.com/library/colors/ /library/palette/ https://example.com/library/palette/

이러한 가상 URL 해석 결과는 JavaScript의 URL API로 확인했습니다. 변경하지 않은 palette.html 값은 이제 Colors 디렉터리 안을 가리키므로, 다른 곳에서 텍스트를 성공적으로 대체해도 이 문제는 발견되지 않습니다. 이처럼 작은 문서 모음에서는 의도한 루트 기준 경로를 사용하면 도착지가 명확해집니다. 다른 호스트로 옮기는 경우에는 올바른 절대 주소를 사용하거나 루트 기준 링크가 의도한 호스트에 계속 연결되는지 확인하세요.

Mac 브라우저에서 게시된 Colors 문서를 열고 Palette 링크를 따라가세요. 표시된 문서와 최종 주소를 모두 확인하세요. 공통 탐색 메뉴와 섹션 링크도 반복해서 확인하세요. 링크에 #swatches가 포함되어 있다면 도착지에 해당 섹션 식별자가 여전히 있는지 확인하세요. 경로 매핑만으로는 이를 확인할 수 없습니다.

표준 URL과 영구 리디렉션을 원본에서 설정하세요

새 HTML 문서마다 표준 URL을 최종 절대 URL로 설정하세요. Google은 절대 표준 URL 사용을 권장하며, 문서의 head에서 HTML 표준 URL 요소를 사용할 수 있습니다. 게시 시스템에 표준 URL 필드가 있다면 그곳에 주소를 입력하고 실제 생성 결과를 확인하세요. Google의 표준 URL 구현 안내.

Colors 페이지에는 기존 문서의 head 안에 다음 메타데이터 조각을 넣으세요. 완전한 HTML 페이지가 아닙니다.

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

호스트가 HTTP Link 응답 헤더를 통해서도 표준 URL을 보내는지 확인하세요. Google은 두 방법을 모두 지원하지만, 서로 다른 도착지가 지정되는 문제를 막기 위해 한 가지 방법을 선택할 것을 권장합니다. 값을 생성하는 템플릿이나 설정을 수정해 다음 게시 때 이전 주소가 다시 설정되지 않도록 하세요. Google의 표준 URL 지정 방법.

이전 주소가 서버 측 영구 리디렉션을 통해 도착지로 연결되도록 설정하세요. RFC 9110은 301과 308을 영구 리디렉션으로 정의하고, Location 헤더에 도착지를 지정한다고 설명합니다. 두 상태 코드는 요청 메서드 처리 방식이 다릅니다. 308은 메서드를 유지하고, 301는 과거의 POST에서 GET으로 전환하는 동작을 허용합니다. 일반적인 문서 조회에서는 Google이 둘 다 영구 리디렉션 신호로 취급합니다. RFC 9110: HTTP 의미론, Google의 리디렉션 문서.

정확한 설정 방법은 호스트나 게시 시스템에 따라 다릅니다. 브라우저에서 편집하는 것만으로 HTTP 응답 규칙을 만들 수는 없습니다. 플랫폼에서 서버 측 리디렉션을 설정할 수 없다면, 문서화된 호스팅 설정을 사용하거나 호스팅 운영자에게 매핑 구현을 요청하세요. Google은 서버 측 리디렉션을 사용할 수 없을 때 대안으로 즉시 실행되는 meta refresh를 문서화하고 있습니다. 다른 방법을 사용할 수 없는 경우에만 JavaScript 리디렉션을 권장합니다. 표준 URL 선언만으로는 방문자가 새 주소로 이동하지 않습니다. Google이 지원하는 리디렉션 방식.

같은 도착지를 사용해 사이트맵을 다시 생성하세요

사이트맵의 원본을 업데이트한 다음 다시 생성하세요. 생성된 파일을 수동으로 수정하면 다음 빌드 때 수정 사항이 사라지기 쉽습니다. 이 마이그레이션의 현재 사이트맵에는 이전 경로가 아니라 Colors, Palette, Shapes의 최종 URL이 있어야 합니다.

Google은 사이트맵에 정규화된 절대 URL과 UTF-8 인코딩을 요구합니다. 웹페이지 목록만 필요하다면 텍스트 사이트맵도 지원됩니다. 한 줄에 URL 하나만 넣고 제목이나 설명을 추가하지 않습니다. 가상 페이지 세 개를 모두 포함한 예시는 다음과 같습니다.

https://example.com/library/colors/
https://example.com/library/palette/
https://example.com/library/shapes/

Google의 사이트맵 형식 및 요구 사항.

사이트에서 이미 XML 사이트맵을 생성한다면 지원되는 형식을 유지하고 URL 항목을 업데이트하세요. lastmod를 제공할 때는 정확한 수정 날짜를 사용하세요. Google은 이 값이 중요한 페이지 업데이트를 반영해야 한다고 설명합니다. 사이트맵이 최신처럼 보이도록 모든 날짜를 자동으로 바꾸지 마세요. Google의 XML 사이트맵 안내.

Mac에서 공개 결과를 확인하세요

편집기 미리보기로는 공개 주소의 HTTP 응답을 확인할 수 없으므로 배포된 결과를 검사하세요. Mac에서 터미널을 여세요. 다음 진단 명령은 가상 주소를 사용합니다. 실행하기 전에 자체 매핑의 해당 공개 URL로 바꾸세요. 이 예시는 실제 마이그레이션 결과를 나타내지 않습니다.

old_url='https://example.com/notes/colors.html'
new_url='https://example.com/library/colors/'

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --dump-header - --output /dev/null "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --location --max-redirs 5 --output /dev/null \
  --write-out 'status=%{http_code}\nfinal=%{url_effective}\nredirects=%{num_redirects}\n' \
  "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  "$new_url"

첫 번째 명령은 리디렉션을 따라가지 않고 최초 응답 헤더를 표시합니다. 두 번째 명령은 리디렉션을 따라가며 최종 상태, 주소, 리디렉션 횟수를 보고합니다. 세 번째 명령은 도착지 마크업을 가져와 검사합니다. 이러한 옵션은 curl 매뉴얼에 설명되어 있습니다.

간단한 매핑 페이지라면 최초 응답은 의도한 Location을 포함한 301 또는 308이고, 최종 주소에서는 문서가 성공적으로 제공되어야 합니다. 반환된 마크업에서 표준 URL을 확인하세요. 브라우저에서 문서도 읽어 보세요. HTTP 성공 응답만으로 올바른 콘텐츠가 도착했음을 입증할 수는 없습니다. Google은 여러 단계로 이어지는 리디렉션 대신 최종 도착지로 직접 리디렉션할 것을 권장합니다. RFC 9110: 상태 코드, Google의 사이트 이전 안내.

행에서 문제가 발견되면 다음 진단 순서를 사용하세요. 관찰된 결과에 따라 수정 작업을 진행할 수 있습니다.

관찰 결과 다음 작업
이전 URL이 의도하지 않은 페이지로 리디렉션됨 해당 매핑이나 리디렉션 규칙을 수정합니다
리디렉션이 또 다른 리디렉션으로 연결됨 이전 주소가 최종 도착지를 직접 가리키도록 설정합니다
올바른 페이지에 이전 표준 URL이 설정됨 메타데이터 원본을 수정하고 다시 게시합니다
탐색 메뉴가 여전히 이전 경로로 이동함 링크 원본이나 공통 템플릿을 업데이트합니다
사이트맵에 이전 경로가 남아 있음 생성기 입력을 수정하고 다시 생성합니다
터미널에서 시간 초과가 보고됨 연결 문제를 해결한 뒤 다시 확인하고, 테스트를 미완료로 기록합니다

사이트맵을 제출하고 실시간 확인과 색인 상태를 구분하세요

Search Console에서 새 URL이 포함되는 속성을 선택하고 Sitemaps 보고서를 사용해 공개 사이트맵 주소를 제출하세요. Google은 이 보고서를 제출 방법으로 설명하며, 처리 오류도 확인할 수 있습니다. 제출은 발견을 돕는 신호이며 색인을 보장하지 않습니다. Google의 사이트맵 제출 안내.

Search Console 검사창에 새 문서의 전체 URL을 입력해 검사하세요. 실시간 테스트로 현재 접근 가능 여부와 색인 생성 가능성에 영향을 줄 수 있는 요소를 살펴보세요. Google이 선택한 표준 URL은 색인 생성된 결과의 Google-selected canonical 필드에서 확인하세요. 실시간 테스트로는 표준 URL 선택을 예측할 수 없습니다. Search Console URL 검사 도구.

이 예시는 한 호스트 안에서 경로를 변경하므로 Change of Address 도구는 적용되지 않습니다. Google은 경로를 이동하는 게시자에게 리디렉션을 구현하고 사이트맵을 업데이트하도록 안내합니다. 이 도구는 사이트를 이전하고 리디렉션을 설정한 뒤 도메인이나 하위 도메인을 이전할 때 사용합니다. Search Console Change of Address 도구.

매핑을 유지 관리 기록으로 보관하세요. 공개 리디렉션, 도착지 콘텐츠, 링크, 표준 URL, 사이트맵이 서로 일치한 뒤에만 해당 행을 완료로 표시하세요. Google의 이후 색인 관찰 결과는 별도로 기록하세요. 리디렉션은 가능한 한 오래 유지하세요. Google의 일반적인 마이그레이션 안내는 최소 1년을 권장합니다. 이후 문서를 편집할 때도 최종 주소를 계속 사용하세요. Google의 마이그레이션 안내.

출처