이전 과정에서 발생하는 웹사이트 링크 변경 분석

런칭 전 리디렉션 맵을 구축하세요

리디렉션 맵은 이전 과정에서 사람들이 과소평가하는 부분입니다. 목적지가 가장 중요합니다. 이전 후 링크 데이터를 분석하기 전에 구 URL에 명확한 목적지가 있어야 합니다. 왜냐하면 그 URL들이 이미 링크가 가리키고 있는 주소이기 때문입니다.

1:1 매핑이 홈페이지로 일괄 리디렉션하는 것보다 낫습니다

수많은 관련 없는 구 URL을 홈페이지로 리디렉션하면 검색 엔진과 방문자에게 거의 아무런 의미도 전달되지 않습니다. 관련성이 핵심 테스트입니다. 각 고가치 구 URL을 가장 가까운 신규 페이지에 매핑하고, 나머지 URL은 해당 주제와 여전히 일치하는 섹션으로 리디렉션하세요.

상태 코드가 포함된 구 URL을 먼저 내보내세요. 이 파일을 안전하게 보관하세요. 이 파일이 체크리스트이며, 어떤 페이지가 링크를 획득했는지 보여줍니다.

페이지에 근사치가 없는 경우 맵에 명시하고 가장 가까운 섹션으로 리디렉션하며 메모를 추가하세요. 빈 셀은 선택 사항을 숨깁니다. 표의 빈 셀은 아무도 결정을 내리지 않았다는 의미입니다.

런칭 전 리디렉션 체인을 단순화하세요

새 페이지에 도달하기 전에 두 가지 이전 규칙을 거치는 리디렉션은 지연과 위험을 초래합니다. 두 번째 이전이 첫 번째 위에 겹쳐지면 체인이 쉽게 생성되므로, 여전히 깨끗하다고 가정하지 말고 각 전환 전에 맵을 검토하세요. 각 추가 홉은 비용이 듭니다. 전환 후 각 구 URL을 한 번 요청하고 단일 홉으로 응답하는지 확인하세요.

조금이라도 빨리 수정하세요. 런칭 후 하나씩 수정하기보다 맵 자체에서 체인을 수정하여 목록을 짧게 유지하세요.

아직 작동하는 경로 유지

리디자인 시 URL 구조 변경은 가장 피할 수 있는 손실입니다. 경로는 링크의 변경을 의미하며, 그 링크들은 외부에서 관리됩니다. 작동하는 것은 유지하세요. 경로가 여전히 작동한다면 그대로 유지하고, 이전으로 인해 변경해야 하는 부분만 변경하세요.

리디렉션이 적을수록 오류도 적습니다. 유지하는 경로가 많을수록 리디렉션이 필요 없는 링크가 많아집니다.

유지된 경로는 구 앵커 행이 여전히 유용한 곳을 가리키게 하므로, 시트에서 다시 구축해야 할 항목이 줄어듭니다. 이후에 다시 구축할 작업이 적어집니다.

이전 후 예상되는 사항

리디렉션이 주요 작업을 수행하며, 구 URL에서 새 URL로 301 리디렉션은 기존 링크가 계속 작동하도록 합니다. 각 구 URL당 하나의 리디렉션을 유지하고 중간에 체인이 없으면 각 링크의 가치를 온전히 유지하는 가장 간단한 방법입니다. 3~4홉의 리디렉션 체인은 크롤러를 느리게 하므로 단순화하는 것이 좋습니다.

URL이 이동해도 앵커 텍스트는 변경되지 않습니다. 텍스트는 링크를 건 페이지에 존재하기 때문입니다. 변경되는 것은 목적지 수입니다. 상위 페이지 테이블은 몇 달간의 갱신을 거치며 구 호스트가 감소하고 새 호스트가 증가하는 모습을 보여줄 것입니다. 목적지 변화는 서서히 일어납니다.

흔히 발생하는 놀라움 중 하나는 구 플랫폼을 너무 빨리 삭제하는 것입니다. 그러지 마세요. Squarespace, Wix 및 유사한 호스트는 종종 리디렉션 규칙을 유지하므로, 플랜을 취소하면 규칙이 제거되어 링크가 다른 곳에서 규칙을 다시 구축할 때까지 죽은 곳을 가리키게 됩니다.

hreflang과 canonical 태그도 주의 깊게 살펴봐야 합니다. 불일치가 흔합니다. 예를 들어 CRA에서 Next.js로 마이그레이션한 후, 사이트는 종종 canonical 태그와 hreflang 세트가 일치하지 않아 링크가 페이지의 두 버전으로 분산되는 경우가 많습니다.

이전 후 숫자가 일치하지 않으면 링크가 손실되었다고 가정하기 전에 문제 해결 표를 확인하세요. 월별 갱신만으로 많은 격차가 설명됩니다. 격차는 종종 타이밍 문제입니다.

런칭 약 두 달 후의 첫 번째 깨끗한 비교를 예상하세요. 각 갱신 날짜를 시트에 기록하여 평월이 멈춘 것으로 오해되지 않도록 하세요. 시간을 주세요. Ahrefs나 Semrush는 중간 검토가 필요할 경우 더 새로운 크롤로 격차를 채워줄 수 있습니다.

런칭 공지 없이 이동하는 항목 주시

런칭일에는 체크리스트가 있지만, 여러 문제가 나중에 조용히 발생합니다. 팀이 다른 작업으로 이동한 지 오래된 후에도 행과 인덱스에 나타납니다. 놓치기 쉽습니다.

스테이징 빌드와 함께 이동하는 noindex

검색에서 제외된 스테이징 사본이 설정을 라이브 사이트에 가져올 수 있습니다. 첫 크롤 시 robots 메타 태그와 noindex 헤더를 확인하고, 홈페이지뿐만 아니라 각 섹션의 샘플 페이지를 확인하세요. 모든 섹션을 샘플링하세요.

템플릿이 먼저 깨집니다. 런칭 후 전체 섹션이 인덱스에서 사라지면 콘텐츠보다 템플릿을 먼저 확인하세요.

스크린샷도 도움이 됩니다. 스테이징 빌드의 robots 설정 사본도 보관하세요. 인덱스에서 무언가가 사라졌을 때 두 세트의 설정을 비교하면 오후를 보내는 대신 몇 분이면 됩니다.

인덱싱되는 프래그먼트 링크

목차 앵커와 같은 점프 링크는 검색 결과에서 별도의 URL로 나타날 수 있습니다. 검색 엔진은 일반적으로 이를 메인 페이지에 병합하지만, 그렇지 않을 경우 동일한 콘텐츠가 여러 주소 아래에 나타날 수 있습니다. 이는 메인 페이지에서 신호를 분산시키고 커버리지 보고서에서 중복 페이지처럼 보일 수 있습니다. 해시 URL은 조용히 증가합니다.

한 버전, 하나의 주소. 하나의 주소로 향하는 canonical 태그가 사이트맵에 다른 주소가 나열되면 혼합 신호가 전송되며 보고서에 불일치가 표시됩니다. 각 페이지의 canonical 버전을 하나만 설정하고 사이트맵이 동일한 버전을 나열하는지 확인하세요.

런칭 후 해시가 포함된 URL이 있는지 커버리지 보고서를 확인하세요. 이러한 URL이 조용히 증가하기 때문입니다. 해시가 원인입니다.

서브도메인이 메인 도메인이 되는 경우

스테이징 서브도메인에서 메인 도메인으로 사이트를 이동하면 두 버전 모두 일정 시간 동안 접근 가능하므로 자체 복제본이 발생합니다. 런칭 전 어느 호스트가 canonical인지 결정하세요. 호스트를 일찍 선택하세요.

모든 곳에서 하나의 호스트. 한 곳에서 호스트가 변경되고 다른 곳에서는 변경되지 않으면 오래된 버전이 아무도 눈치채지 못한 채 몇 달 동안 링크를 수집할 수 있습니다. 그런 다음 사이트맵, canonical 태그 및 hreflang 세트를 해당 호스트로 유지하세요.

소멸하는 것처럼 보이는 do-follow 링크

리디자인 후 도구에서 do-follow 행이 급격히 떨어질 수 있으며, 첫 번째 추측은 링크가 사라졌다는 것입니다. 그 추측을 받아들이기 전에 구 상위 페이지와 새 페이지를 비교한 후 각 구 주소가 올바르게 리디렉션되는지 확인하세요. 당황하기 전에 확인하세요.

가장 먼저 수정하세요. 링크 페이지에 여전히 존재하지만 죽은 주소로 향하는 링크가 가장 먼저 수정해야 할 사례입니다.

날짜를 일찍 정하세요. 비교를 위한 고정 날짜를 팀에 제공하여 매일 다시 추출하고 노이즈를 뉴스라고 읽지 않도록 하세요.

이전 기간 중 개발자와의 협업

리디렉션 작업의 대부분은 개발자에게 맡겨지며, 모니터링은 시트를 읽는 사람에게 맡겨집니다. 짧은 표로 분할을 기록하고 각 셀에 한 명의 이름을 적는 것으로 두 사람이 동일한 작업을 가정하는 것을 방지할 수 있는 경우가 많습니다. 런칭 전에 이러한 역할을 문서화하여 서로가 상대방이 모니터링하고 있다고 가정하지 않도록 하세요. 역할에는 이름이 필요합니다.

개발자에게 작업 목록이 아닌 맵을 제공하세요

작업 목록은 개발자에게 무엇을 해야 하는지 알려주지만, 맵은 구 주소가 어디로 가야 하는지 보여줍니다. 상태 코드와 각 행의 이유가 포함된 1:1 테이블을 보내어 추측이 아닌 결정이 내려지도록 하세요. 결정이 추측보다 낫습니다.

테스트 계획이 먼저입니다. 상위 페이지 파일의 구 주소로 시작하는 짧은 테스트 계획을 요청하세요.

월별 파일을 읽을 사람 합의

첫 번째 깨끗한 비교는 런칭 약 두 달 후에 이루어지며, 파일에는 읽는 사람이 필요합니다. 런칭 후 첫 읽기는 일반적으로 노이즈가 많으며, 이를 아는 읽는 사람은 단일 이상한 달에 반응하지 않습니다. 그 사람, 그들이 파일을 여는 날짜, 결과가 들어갈 시트를 지정하세요. 누군가는 이를 책임져야 합니다.

날짜가 질문을 해결합니다. 각 파일 옆에 갱신 날짜를 기록하면 멈춘 인덱스에 대한 우려를 캘린더의 단순한 사실로 바꿉니다. 평월은 갱신 날짜를 기록한 사람이 없으면 멈춘 것으로 오해하기 쉽습니다.

변경 사항이 없더라도 갱신마다 한 줄씩 기록하도록 그 사람에게 요청하여 파일이 연속적인 기록을 유지하도록 하세요. 매번 한 줄.

런칭 전 롤백 계획 수립

새 호스트가 중요한 경로를 끊는 경우, 팀은 사전에 테스트된 복귀 경로가 필요합니다. 단계를 기록하고 스위치를 켤 수 있는 사람 및 롤백 중 리디렉션의 동작을 포함하세요. 런칭 전에 연습하세요.

롤백을 기록하세요. 한 사람의 머릿속에만 존재하는 롤백은 계획이 아닙니다.