1년 후 구 리다이렉션을 제거해야 하나요?

많은 마이그레이션 팀은 최소 1년 동안 유지합니다. 그 이후에도 구 URL이 외부 링크나 트래픽을 여전히 받으면 유지하세요. 리다이렉션 서비스 비용은 거의 없으므로 조기에 삭제할 좋은 이유는 거의 없습니다.

색인화된 페이지만 리다이렉션해도 되나요?

링크를 보유하고 있다면 안 됩니다. 색인 상태는 외부 가치에 대해 거의 알려주지 않습니다. 링크 도메인이 있는 모든 URL을 리다이렉션한 후, 나머지는 트래픽을 기준으로 결정하세요.

영구 이동에 302 또는 307을 사용해도 되나요?

영구 이동에는 301 또는 308을 사용하세요. 302를 장기간 유지하면 영구 이동으로 간주될 수 있지만, 이는 우연에 맡기는 것이며 리다이렉션의 다른 클라이언트는 다르게 해석할 수 있습니다.

구 사이트의 404를 신 사이트로 리다이렉션할 수 있나요?

가까운 매칭이 있을 때만 가능합니다. 관련 없는 페이지로의 리다이렉션은 Google에서 소프트 404로 간주합니다. 콘텐츠가 사라졌다면 실제 404 또는 410을 반환하세요.

리다이렉션 맵 레시피: 보유된 링크를 기준으로 구 URL 순위 매기기

리다이렉션 맵은 모든 URL을 나열한 스프레드시트가 아니라 우선순위 목록입니다. 다른 사이트에서 링크를 걸고 있는 페이지부터 시작하면 나머지 맵 구성이 훨씬 쉬워집니다.

ArchiLinks 연구팀 · 업데이트 2026-10-29

링크로 순위 매겨야 하는 이유

팀들은 크롤링 데이터로 맵을 만듭니다. 데이터는 완전하지만, 2014년의 잊혀진 보도자료 페이지를 메인 페이지와 동등하게 취급하기도 합니다.

내 사이트의 백링크를 확인하고 링크 도메인 수로 페이지를 정렬하면 대부분의 마이그레이션에서 한 가지 패턴이 나타납니다. 수십 개의 URL이 외부 가치의 대부분을 차지합니다. 이러한 URL은 수동으로 매칭하고, 두 번 검토하며, 가장 먼저 테스트합니다.

나머지는 규칙에 따릅니다. 폴더는 패턴으로 매칭하고, 파라미터는 제거하며, 링크와 트래픽이 없는 오버행 URL은 필요시 410을 반환할 수 있습니다. 마이그레이션 체크리스트와 함께 사용하여 맵을 출시 전과 45일 차에 다시 테스트하고, API 스크립트를 사용하여 월별 데이터 추출을 예약하세요.

1단계: 링크된 페이지 추출

한 번의 호출로 최대 1,000개의 행을 반환하며, 행 수에 관계없이 2크레딧이 소요됩니다. 아래 필드명은 예시이며, 실제 응답을 확인하여 키를 조정하세요.

python

import csv, requests

BASE = "https://archilinks.com/api.php"
KEY = "sk_live_..."

def call(action, **params):
    r = requests.get(BASE, params={"action": action, "key": KEY, **params}, timeout=30)
    r.raise_for_status()
    return r.json()

data = call("toppages", q="old-shop.com", per=1000)
rows = next(v for v in data.values() if isinstance(v, list))

with open("linked-pages.csv", "w", newline="") as f:
    w = csv.writer(f)
    w.writerow(["old_url", "links", "new_url"])
    for row in rows:
        w.writerow([row.get("url"), row.get("backlinks"), ""])

2단계: 세 번째 열 채우기

의미로 매칭하기

제품 페이지는 동일한 제품 페이지로, 제품이 사라졌다면 해당 카테고리 페이지로 리다이렉션해야 합니다. 해당 페이지가 메인 페이지였던 경우가 아니면 메인 페이지로 리다이렉션해서는 안 됩니다.

두 번째 사람이 상위 50개를 확인하게 하세요

저녁 6시에 지친 직원은 캐노니컬 가이드를 블로그 인덱스로 매핑할 수 있습니다. 검토자가 이를 잡아냅니다.

롱테일용 규칙

폴더용 패턴을 작성하고 추적 파라미터를 제거하세요. 각 규칙의 이유를 설명하는 주석과 함께 버전 관리에 유지하세요.

3단계: 서버 규칙 생성

nginx는 맵 파일을 잘 처리하며 수만 줄의 규칙도 확장 가능합니다.

nginx

# /etc/nginx/redirects.map  (generated from the csv)
/old/guide-canonicals    /guides/canonical-tags;
/products/blue-widget    /shop/widgets/blue;

# in nginx.conf, http context
map $request_uri $new_uri {
    default "";
    include /etc/nginx/redirects.map;
}

# in the server block of the old host
if ($new_uri) {
    return 301 https://new-shop.com$new_uri;
}

4단계: 모든 홉 테스트

200 응답으로 이어지는 단일 301이 아닌 모든 경우 파이프라인을 실패 처리하세요.

bash

while IFS=, read -r old new; do
  out=$(curl -s -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}" -L "https://old-shop.com$old")
  echo "$old -> $out"
done < redirect-pairs.csv | grep -v "^.* -> 200 1 " && echo "FIX ABOVE"

우선적으로 확인할 오류

증상	잠재적 원인	해결 방법
2~3홉 체인 발생	새로운 규칙 위에 오래된 규칙이 쌓임	구 규칙이 최종 URL을 직접 가리키도록 수정
모든 리다이렉션이 메인 페이지로 연결됨	게으른 캐치올 규칙	주제로 매칭하세요. Google은 대량의 메인 페이지 리다이렉션을 소프트 404로 간주할 수 있습니다.
쿼리 문자열 손실	규칙이 인수를 제거함	콘텐츠를 변경하는 파라미터는 유지하고 나머지는 제거하세요.
출시 후 상위 URL이 404 반환	CSV에서 누락됨	추출을 다시 실행하고 라이브 맵과 비교하세요.

수동 매칭 행이 필요한 URL

모든 URL이 사람의 개입을 필요로 하지는 않습니다. 링크 도메인 수로 구분하는 것이 유용합니다. 외부 사이트에서 링크를 거는 URL이 여러 개 있다면 수동으로 매칭하고, 나머지는 규칙 세트를 따르게 합니다. 예를 들어 구 URL이 4,000개 있고 그중 60개가 외부 링크의 대부분을 차지한다면, 이 60개에 오후 시간의 검토를 할애하고 나머지 3,940개는 패턴과 테스트로 처리합니다.

임계값을 사람의 머리가 아닌 스크립트에 유지하세요. 링크 도메인 5개는 중형 사이트의 적절한 시작점입니다. 거기에 시작하세요. 사이트 전체의 링크가 적으면 수치를 낮추고, 수동 목록이 검토자 한 명에게 너무 길어지면 수치를 높입니다.

수동 매칭 행과 규칙 매칭 행 분리 유지

수동 매칭 행에는 검토자 이름과 대상 선택 이유를 기록합니다. 규칙 매칭 행은 전체 폴더에 대해 테스트된 패턴을 가지므로, 예외 사항이 트래픽 차트에서 발견되기 전에 출시 전 테스트 보고서에 나타납니다.

혼합된 사례가 대부분의 혼란을 야기합니다. 단종되어 후속 제품으로 대체된 제품은 후속 제품으로 매핑합니다. 단종되었지만 대체 제품이 없는 제품은 카테고리 페이지로 매핑하며, 메인 페이지로 매핑하지 않습니다.

두 번째 추출을 통해 변경 사항 확인

맵이 최종화되기 전에 구 호스트에 대해 refdomains를 실행한 후, 출시 후에도 다시 실행합니다. 도메인별로 두 목록을 매칭하세요. 두 번째 추출에서 누락된 링크 도메인은 링크 소유자에게 문의할 사항이지 경계할 이유가 아닙니다. 제거된 링크가 색인에 반영되는 데 시간이 걸릴 수 있기 때문입니다.

두 파일을 마이그레이션 폴더에 날짜가 포함된 파일명으로 나란히 저장하세요. diff는 어디를 찾아야 하는지 알려주고, 맵은 그 문제에 대해 어떻게 처리했는지 보여줍니다.

링크가 없는 URL의 처리 결정

링크와 트래픽이 없는 오버행 URL은 처리하기 쉽습니다. 콘텐츠가 완전히 사라졌다면 명확한 404 또는 410을 반환하고, 가까운 대체 페이지가 있을 때만 리다이렉션하세요. 그러면 방문자와 크롤러 모두 유용한 페이지로 이동합니다.

확신이 서지 않을 때는 맵에 짧은 메모를 남기고 첫 주 로그 확인 후 다시 검토하세요. 서버 로그는 어떤 구 주소가 여전히 요청을 받는지 보여주며, 이는 가장 확실한 증거입니다.

맵의 출시 프로세스 통합

리다이렉션 맵은 사이트와 함께 변화합니다. 이를 염두에 두세요. 새 페이지가 추가되고, 구 페이지가 이름이 바뀌며, 템플릿 변경으로 인해 지난 달에는 안전해 보이던 규칙이 깨질 수 있습니다. 맵을 코드처럼 취급하세요. 버전 관리에 파일 하나를 두고, 각 배포 전 검토를 거치며, 변경 사항마다 테스트 실행을 수행합니다.

가능하면 맵을 한 레이어에 유지하세요. 애플리케이션, CDN, CMS에 걸쳐 리다이렉션이 분산되면 체인이 발생하며, 전체 크롤링 없이는 체인을 찾기 어렵습니다.

규칙의 위치

서버 맵은 빠르고 테스트하기 쉽습니다. CMS 플러그인은 소수의 페이지에 유용하지만 규모 있게 감사하기 어렵습니다. 어떤 방식을 선택하든, 단일 홉 테스트는 해당 위치에서 읽어야 합니다.

두 레이어가 동일한 URL을 리다이렉션하면 테스트에서 체인이 보고됩니다. 은퇴할 레이어에서 중복을 제거하세요.

변경 사항마다 실제 호스트에서 테스트

규칙 파일 변경 후 스테이징 환경에서 홉 테스트를 실행한 후 프로덕션 환경에서도 실행하세요. 스테이징에서는 통과하지만 캐시가 오래된 응답을 유지하여 프로덕션에서는 실패할 수 있으므로 두 번째 실행이 중요합니다.

출력을 날짜와 함께 저장하세요. 상위 URL이 몇 달 후 깨졌을 때 이전 결과가 규칙이 변경되었는지 사이트가 변경되었는지를 보여줍니다. 마이그레이션 체크리스트에는 해당 테스트의 시기가 명시되어 있으며, 먼저 실행하면 다음 테스트와의 비교가 가능합니다.

규칙 파일 변경 검토

맵 변경에 대한 검토자를 한 명 지정하고, 다음 세 가지를 확인하게 하세요: 각 대상이 여전히 주제와 일치하는지, 규칙이 몇 홉을 생성하는지, 패턴이 작성된 URL에만 적용되도록 충분히 좁은지. 검토를 거치지 않은 변경이 체인을 시작할 가능성이 가장 높습니다.

사이트 자체에 변경이 있을 때도 동일한 검토를 요청하세요. 구 폴더를 흡수하는 새 카테고리가 생성되면 맵을 편집하지 않아도 올바른 규칙이 잘못된 곳을 가리킬 수 있습니다.

검토자의 메모를 변경 사항 옆에 저장하세요. 6개월 후, 해당 메모는 임의적으로 보이는 규칙의 이유를 설명하고 동일한 질문에 대한 두 번째 조사를 절약합니다.

전체 실행 전 샘플 테스트

전체 목록을 실행하기 전에 상위 링크 페이지와 일반 페이지가 섞인 50개의 행 샘플을 선택하세요. 먼저 해당 샘플에 대해 홉 테스트를 실행하세요. 샘플은 읽기 빠르고, 규칙 오류는 전체 파일에 퍼지기 전에 샘플에서 먼저 나타납니다.

각 규칙 패턴에서 최소 한 행과 각 수동 매칭 그룹에서 한 행을 포함하세요. 200개 URL의 폴더를 커버하는 패턴은 샘플에 우연히 포함된 행으로만 테스트되므로 의도적으로 선택하세요.

규칙 파일 크기 유지

수백 개 패턴을 초과하는 규칙 파일은 검토하기 어렵습니다. 사이트의 섹션별로 파일을 분리하고, 검토자가 한 번에 읽을 수 있을 만큼 짧은 파일을 유지하세요.

폴더가 사라진 날 규칙을 제거하세요. 남겨진 구 규칙은 나중에 트래픽을 체인으로 유도합니다.

맵 출시 전 확인 사항

모든 행은 새 URL 또는 의도적인 404/410을 가집니다.
대상이 리다이렉션이 아닙니다.
링크 도메인이 가장 많은 50개 URL이 두 번째 사람에 의해 검토되었습니다.
콘텐츠를 변경하는 쿼리 파라미터가 유지됩니다.
규칙 파일은 버전 관리 중이며, 각 패턴에는 주석이 달려 있습니다.
출시 후 비교를 위한 참조 도메인 기준선이 저장되었습니다.

자주 묻는 리다이렉션 질문

1년 후 구 리다이렉션을 제거해야 하나요?: 많은 마이그레이션 팀은 최소 1년 동안 유지합니다. 그 이후에도 구 URL이 외부 링크나 트래픽을 여전히 받으면 유지하세요. 리다이렉션 서비스 비용은 거의 없으므로 조기에 삭제할 좋은 이유는 거의 없습니다.
색인화된 페이지만 리다이렉션해도 되나요?: 링크를 보유하고 있다면 안 됩니다. 색인 상태는 외부 가치에 대해 거의 알려주지 않습니다. 링크 도메인이 있는 모든 URL을 리다이렉션한 후, 나머지는 트래픽을 기준으로 결정하세요.
영구 이동에 302 또는 307을 사용해도 되나요?: 영구 이동에는 301 또는 308을 사용하세요. 302를 장기간 유지하면 영구 이동으로 간주될 수 있지만, 이는 우연에 맡기는 것이며 리다이렉션의 다른 클라이언트는 다르게 해석할 수 있습니다.
구 사이트의 404를 신 사이트로 리다이렉션할 수 있나요?: 가까운 매칭이 있을 때만 가능합니다. 관련 없는 페이지로의 리다이렉션은 Google에서 소프트 404로 간주합니다. 콘텐츠가 사라졌다면 실제 404 또는 410을 반환하세요.