사이트 이전 체크리스트: T-4주부터 45일 차까지

404로 끝나는 301은 아무것도 유지하지 못합니다.

일부 팀은 모든 구 URL을 새 홈으로 보내고 대상 페이지가 나중에 만료되도록 합니다. 리디렉션 자체는 작동합니다. 이것이 습관이 위험한 이유입니다. 각 홉은 로그에서 깨끗해 보이지만 끝의 페이지가 404를 반환하기 때문입니다.

가게를 새 도메인으로 이동하고 여전히 판매되는 제품만 유지한다고 가정해 보세요. 외부 링크의 대부분을 담고 있던 카테고리 페이지는 이제 쓸모없는 곳으로 연결됩니다. 무언가를 은퇴하기 전에 외부 링크된 URL을 세어보세요. 첫 번째 단계로 만드세요. 링크 도메인이 있는 페이지는 같은 주제에 대한 활성 대상이 필요합니다. 무관심한 태도가 아닙니다.

규칙을 짧게 유지하세요: 단일 홉, 그 다음 최종 200. 그 외의 것은 당신이 선택한 누수입니다.

활성 페이지로의 단일 홉 301이 보호하는 것

링크의 가치는 가리키는 URL에 있습니다. 리디렉션은 도착 주소가 응답하고 여전히 주제와 일치할 때만 그 가치를 전달합니다. 새 카탈로그의 동일한 제품으로 이동된 제품은 이 테스트를 통과하지만, 사람들이 링크하던 페이지인 홈페이지로 보내진 제품은 일반적으로 통과하지 못합니다.

모든 템플릿 변경 후 최종 상태를 재확인하세요. 출시 시 작동하던 리디렉션은 나중에 메뉴 정리 중 카테고리를 제거할 때 404로 끝날 수 있습니다.

410이 정직한 답변일 때

일부 구 URL에는 링크도 방문도 실제 대체품도 없었습니다. 그런 경우, 구 URL이 던졌던 질문에 답하지 않는 페이지로의 리디렉션보다 명확한 404 또는 410이 더 정직합니다. 관련 없는 페이지로의 리디렉션은 종종 소프트 404로 처리되므로 아무것도 구해내지 못합니다.

URL 그룹별로 결정을 기록하고 그 옆에 이유를 적으세요. 은퇴된 튜토리얼 폴더는 링크 도메인이 80개 있는 페이지 폴더와 다른 답변을 얻으며, 6개월 후 동료에게 그 차이를 설명해야 할 것입니다.

첫 홉뿐만 아니라 마지막 홉 확인하기

대부분의 리디렉션 테스트는 첫 번째 응답에서 멈추는데, 이는 멈추기에 잘못된 위치입니다. 체인의 끝까지 따라가고, 홉 수와 최종 상태를 구 URL 옆에 기록하세요. 두 홉의 체인은 끊어지지 않았지만 지연을 추가하고 규칙이 실패할 수 있는 지점을 하나 더 만듭니다.

스크립트를 사용할 수 없다면 스프레드시트와 몇 가지 curl 호출로 작업을 수행할 수 있습니다. API 스크립트 페이지에는 예약할 수 있는 버전이 있습니다.

출력 후 사이트맵 및 수동 요청

이동 후 몇 주 동안은 구 사이트맵을 접근 가능하게 유지하세요. 구 호스트를 다시 방문하는 크롤러는 한 목록에서 이러한 주소를 여전히 찾을 수 있으며, 이는 리디렉션을 통한 첫 번째 통과를 가속화합니다.

수동 요청은 다른 도구입니다. 가장 중요한 몇 페이지에만 사용하고, 수백 개의 URL을 하나씩 제출하는 데 사용하지 마세요. 내부 링크가 없고 본문이 얇은 요청된 페이지는 다시 사라지는 경향이 있으므로 요청은 그 뒤의 페이지만큼만 유효합니다.

대기는 유효한 계획입니다. 크롤링에 시간을 주고, 데이터에 따라 판단하세요.

구 사이트맵을 잠시 동안 유지하기

구 URL이 크롤링 통계에 더 이상 표시되지 않을 때까지 Search Console에 구 사이트맵을 그대로 두세요. 그런 다음 의도적으로 제거하고 이전 로그에 날짜를 기록하세요.

속성을 깔끔하게 보이게 하기 위해 출시 당일 제거하지 마세요. 조기 제거는 여전히 추적해야 하는 모든 구 URL을 명시하는 유일한 목록을 숨깁니다.

링크를 포함한 페이지에 대한 인덱싱 요청

리디렉션 맵을 위해 구축한 동일한 조인을 사용하여 외부 링크가 가장 많은 20개의 새 URL을 선택하고 수동으로 요청하세요. 그러면 노력이 사이트의 크기가 아닌 리스크에 따라 따릅니다.

요청한 페이지가 몇 주 후에도 여전히 누락되어 있다면 다시 요청하기 전에 페이지를 확인하세요. 내부 링크, canonical 및 콘텐츠를 확인하세요. 다섯 번째 요청은 아무것도 바꾸지 못합니다.

이동이 판단되기까지 걸리는 시간

첫 번째 링크 추출이 아닌 두 번째 링크 추출로 이동을 판단하세요. 우리 인덱스는 약 한 달에 한 번 업데이트되므로 3일 차 추출은 주로 지난달의 상황을 보여줍니다. 업데이트 후 두 번째 추출을 실행하고 이를 사용하여 새 호스트의 모든 백링크를 찾으세요.

Pages 보고서와 링크 데이터는 서로 다른 질문에 답합니다. 같은 이동에 대한 경쟁적인 판결로 읽지 말고 나란히 읽으세요.

출력 전뿐만 아니라 출력 후 사이트 모니터링

출력 전 감사는 실행 당시의 사실을 기록합니다. 대부분의 출력 피해는 플러그인 업데이트, CDN 규칙 변경 또는 아무도 검토하지 않은 설정을 변경하는 템플릿 이후에 나중에 나타납니다.

출력 후 감사를 저장된 베이스라인에 대한 작은 차이 분석 세트로 취급하세요. 대시보드가 필요하지 않습니다. 일정과 날짜가 있는 파일 폴더면 충분합니다.

주간 감사가 비교해야 할 사항

변경될 경우 가장 큰 피해를 줄 수 있는 체크를 선택하고 매주 같은 날에 실행하세요.

• 상위 50개 링크된 구 URL의 상태 코드 및 최종 URL
• 주요 템플릿의 robots.txt 및 robots 메타 태그
• 라이브 200 URL의 수 대 새 사이트맵의 수
• 홈페이지, 카테고리 하나, 기사 하나의 canonical 태그

일회성 감사가 느린 드리프트를 놓치는 이유

출력 후 설정이 드리프트됩니다. 남겨진 테스트 플래그, URL 구조를 다시 쓰는 플러그인 또는 하나의 페이지를 수정하기 위해 추가된 리디렉션은 각각 계획의 일부를 무효화할 수 있습니다. 출시 당일의 감사는 이러한 사항을 모두 볼 수 없습니다.

예약된 차이 분석은 가능합니다. 베이스라인 파일을 버전 관리에 보관하고 매주 출력을 비교하여 예상치 못한 변경이 발생한 당일에도 볼 수 있도록 하세요.

서브도메인, 제거 및 전체 사이트 도메인 변경

일부 팀은 섹션을 서브도메인으로 이동하고 인기 페이지만 인덱싱합니다. 이는 작동할 수 있습니다. 비용은 조용한 페이지를 향한 링크가 이제 역사가 적은 호스트에 도착한다는 것입니다. 무언가를 자르기 전에 세어보세요.

제거 요청은 들리는 것보다 좁습니다. Search Console은 요청을 제출한 속성에 제거를 적용하므로 서브도메인에서 만든 요청은 메인 도메인에서 작동하지 않습니다. 먼저 속성을 확인하세요. 그런 다음 제출하고 둘 다 확인된 상태로 유지하세요.

서브도메인의 인기 페이지만 인덱싱하기

해당 섹션의 URL당 링크부터 시작하세요. 외부 링크는 많지만 트래픽이 적은 페이지는 인기 페이지 전용 규칙이 숨길 첫 번째 대상입니다. 크롤링 가능하게 유지하거나 각 페이지를 가장 가까운 인기 페이지로 리디렉션하고 규칙 옆에 이유를 기록하세요.

메인 사이트가 서브도메인에 링크하는 위치는 페이지가 얼마나 쉽게 발견되는지를 결정합니다. 어떤 페이지를 숨길지 선택하기 전에 이러한 링크를 나열하세요. 메인 사이트가 링크하지 않는 페이지는 어쨌든 도달하기 어렵습니다.

전체 사이트 도메인 변경, 페이지별

호스트 수준 규칙은 루트를 처리하지만, 도메인 변경에는 경로 수준 맵도 필요합니다. URL의 첫 번째 부분이 변경되고 슬러그가 동일하게 유지되면 호스트 교환이 대부분의 페이지를 처리하며, 예외 사항에는 자체 줄이 필요합니다.

링크된 페이지에서 목록을 먼저 구축한 다음 각 구 경로를 새 경로에 매칭하세요. 리디렉션 맵 레시피에 링크 기준으로 목록을 순위 매기는 방법이 나와 있습니다.