30,000페이지 사이트 마이그레이션, SEO 순위 유지

지난해 34,000페이지의 e-커머스 사이트를 모놀리식 WordPress 설치에서 Next.js와 headless CMS를 사용한 headless 아키텍처로 마이그레이션했습니다. 클라이언트의 오가닉 트래픽은 매출의 72%를 차지했습니다. 압박감 있죠?

마이그레이션에는 14주의 계획 수립과 6주의 실행이 소요되었습니다. 스위치를 뒤집었을 때 1주차에 오가닉 트래픽이 3.2% 감소했고, 3주차에 회복되었으며, 2개월차에는 11% 증가했습니다. 이것은 운이 아닙니다 -- 프로세스입니다.

마이그레이션이 끔찍하게 잘못되는 경우를 많이 봤습니다. 같은 클라이언트의 경쟁사는 6개월 전에 마이그레이션했고 하룻밤 사이에 오가닉 트래픽의 40%를 잃었습니다. 8개월이 지난 지금도 여전히 회복되지 않았습니다. 성공적인 대규모 마이그레이션과 재앙 사이의 차이는 준비, 리디렉트 관리, 실제로 신뢰할 수 있는 롤백 계획으로 귀결됩니다.

이 글은 수만 개의 페이지가 있는 사이트를 마이그레이션할 때 우리가 수행하는 모든 과정을 단계별로 설명합니다. WordPress에서 Next.js로 이동하든, Drupal에서 Astro로 이동하든, 또는 다른 플랫폼 전환이든 동일한 프로세스입니다.

대규모 마이그레이션이 실패하는 이유
1단계: 마이그레이션 전 감사 및 크롤링
2단계: URL 매핑 및 리디렉트 전략
3단계: 기술 SEO 동등성 체크리스트
4단계: 콘텐츠 마이그레이션 및 검증
5단계: 스테이징 환경 테스트
6단계: 런칭 당일 실행
7단계: 마이그레이션 후 모니터링
대규모 리디렉트 구현
국제 및 다국어 사이트 처리
순위를 망치는 일반적인 실수
사용하는 도구 및 스택
FAQ

30,000페이지 웹사이트를 SEO 손실 없이 마이그레이션하는 방법

대규모 마이그레이션이 실패하는 이유

대부분의 마이그레이션 실패는 동일한 근본 원인을 공유합니다. 이를 미리 이해하면 실패한 런칭의 묘지에 들어가는 것을 방지할 수 있습니다.

리디렉트 문제

500페이지 사이트에서는 모든 URL을 수동으로 매핑할 수 있습니다. 30,000페이지 사이트에서는 불가능합니다. 팀은 URL의 90%를 커버하는 정규식 기반 리디렉트 규칙을 작성하고 나머지 10%는 알아서 정리될 것이라고 가정합니다. 나머지 10%는 3,000페이지입니다. 그 중 많은 부분이 최고 성능의 콘텐츠입니다.

2025년 Ahrefs 연구에 따르면 마이그레이션 중 색인된 페이지의 15% 이상을 잃은 사이트는 평균 34%의 오가닉 트래픽 감소를 경험했습니다. 그리고 회복에는 평균 4-8개월이 걸렸습니다.

동등성 문제

Google은 콘텐츠만 신경 쓰는 것이 아니라 구조를 신경 씁니다. 내부 링킹 패턴, 제목 계층 구조, 구조화된 데이터, 정규 태그, 페이지 매김 처리, 패싯 네비게이션. 이 중 너무 많은 것을 동시에 변경하면 Google은 기본적으로 전체 사이트를 처음부터 다시 평가해야 합니다.

타이밍 문제

팀이 새 사이트를 완벽하게 만드는 데 몇 개월을 보낸 후 리더십의 성급함 때문에 실제 마이그레이션을 서둘렀습니다. 30,000페이지 사이트를 금요일 오후에 마이그레이션하지 않습니다. 최대 트래픽 시즌 중에 마이그레이션하지 않습니다. 그리고 테스트된 롤백 계획 없이는 절대 마이그레이션하지 않습니다.

1단계: 마이그레이션 전 감사 및 크롤링

무엇이든 건드리기 전에 오늘 무엇이 존재하는지에 대한 완전한 그림이 필요합니다. 이것이 당신의 기준선이며 마이그레이션 전체에 걸쳐 계속 참조할 것입니다.

전체 사이트 크롤링

Screaming Frog, Sitebulk 또는 Lumar(이전 Deepcrawl)와 같은 클라우드 기반 크롤러를 사용하여 완전한 크롤을 실행합니다. 30,000+ 페이지의 경우 클라우드 옵션을 원할 것입니다 -- 데스크톱 크롤러는 이 정도 크기의 사이트에서 작동하지 않으며, 크롤 데이터를 팀 전체에서 공유할 수 있어야 합니다.

모든 것을 캡처합니다:

모든 URL 및 HTTP 상태 코드
제목 태그 및 메타 설명
H1 태그
정규 태그
Hreflang 태그 (해당되는 경우)
내부 링크 (페이지당 인바운드 및 아웃바운드)
존재하는 구조화된 데이터 유형
페이지 로드 시간
페이지당 단어 수
이미지 및 대체 텍스트

분석 기준선

지난 12개월의 Google Analytics 데이터와 Google Search Console 데이터를 내보냅니다. 다음이 필요합니다:

오가닉 세션별 상위 1,000개 랜딩 페이지
클릭 및 노출 수별 상위 5,000개 쿼리
크롤 통계 (일일 크롤된 페이지, 응답 시간)
Core Web Vitals 점수
색인 적용 범위 보고서 (색인됨, 제외됨, 오류)

상위 500개의 오가닉 랜딩 페이지에 태그를 지정합니다. 이 페이지들은 절대 깨져서는 안 됩니다. 마이그레이션 중 및 후에 각각을 개별적으로 확인합니다.

백링크 감사

Ahrefs, Semrush 및 Google Search Console에서 백링크 데이터를 가져옵니다. 교차 참조하여 이를 가리키는 외부 링크가 있는 모든 URL을 찾습니다. 이 URL들은 완벽한 301 리디렉트가 필요합니다 -- 높은 권위의 페이지에서 백링크 자산을 잃는 것이 순위를 망치는 가장 빠른 방법 중 하나입니다.

# 예: 백링크된 URL 내보내기 및 중복 제거
ahrefs-export.csv + semrush-export.csv + gsc-export.csv
| sort -u 
| awk -F',' '{print $1}' 
> unique_backlinked_urls.txt

wc -l unique_backlinked_urls.txt
# 출력: 8,247개의 백링크가 있는 고유 URL

2단계: URL 매핑 및 리디렉트 전략

이것이 마이그레이션이 성공하거나 실패하는 곳입니다. 30,000페이지 사이트에서는 자동화된 매핑을 중요한 페이지에 대한 수동 검증과 결합하는 체계적인 접근 방식이 필요합니다.

리디렉트 맵 구축

URL을 패턴으로 분류하여 시작합니다. 대부분의 대규모 사이트는 페이지의 대부분을 차지하는 비교적 적은 수의 URL 패턴을 가집니다:

URL 패턴	예시	페이지 수	전략
상품 페이지	`/products/blue-widget-123`	18,000	정규식 + ID 매핑
카테고리 페이지	`/category/widgets`	450	수동 매핑
블로그 글	`/blog/2024/03/post-title`	3,200	슬러그 보존
태그/필터 페이지	`/products?color=blue`	6,500	평가: 리디렉트 또는 noindex
정적 페이지	`/about`, `/contact`	85	수동 매핑
페이지 매김	`/category/widgets/page/3`	1,800	새 페이지 매김으로 매핑

3계층 접근법

1계층: 수동 매핑 (상위 500페이지) 최고 트래픽, 최고 매출 페이지는 개별적으로 매핑됩니다. 사람이 각 리디렉트를 검증합니다. 예외는 없습니다.

2계층: 패턴 기반 매핑 (다음 ~25,000페이지) 이전 URL 패턴을 새로운 패턴으로 변환하는 변환 규칙을 작성합니다. 배포 전에 전체 URL 목록에 대해 이러한 규칙을 테스트합니다.

# 예: 리디렉트 규칙 생성
import csv
import re

def generate_redirect(old_url):
    # 상품 페이지: /products/blue-widget-123 -> /shop/blue-widget
    product_match = re.match(r'/products/([a-z-]+)-(\d+)$', old_url)
    if product_match:
        slug = product_match.group(1)
        return f'/shop/{slug}', 301
    
    # 블로그 글: /blog/2024/03/post-title -> /blog/post-title
    blog_match = re.match(r'/blog/\d{4}/\d{2}/(.+)$', old_url)
    if blog_match:
        slug = blog_match.group(1)
        return f'/blog/{slug}', 301
    
    return None, None

# 모든 URL 처리
with open('all_urls.csv') as f:
    reader = csv.reader(f)
    unmapped = []
    for row in reader:
        old_url = row[0]
        new_url, status = generate_redirect(old_url)
        if new_url is None:
            unmapped.append(old_url)
    
    print(f"매핑되지 않은 URL: {len(unmapped)}")

3계층: 나머지 매핑되지 않은 페이지 (~4,500페이지) 이것이 당신의 예외 사항입니다. 수동으로 살펴봅니다. 일부는 의도적으로 중단하는 페이지입니다 (가장 관련성 있는 페이지로 리디렉트). 일부는 패턴 분석에서 놓친 URL입니다. 트래픽이나 백링크가 있었던 페이지에는 404를 남기지 마십시오.

리디렉트 체인 및 루프

이전 사이트에 이미 리디렉트가 있는 경우 새 리디렉트가 체인을 만들 수 있습니다 (A → B → C). 런칭 전에 이를 해결합니다. 모든 리디렉트는 한 번의 홉으로 이전 URL에서 최종 목적지로 직접 이동해야 합니다. 리디렉트 체인은 PageRank를 소모합니다 -- Google의 John Mueller는 여러 번 체인을 따라갈 것이지만 직접 리디렉트가 항상 더 좋다고 확인했습니다.

30,000페이지 웹사이트를 SEO 손실 없이 마이그레이션하는 방법 - 아키텍처

3단계: 기술 SEO 동등성 체크리스트

새 사이트는 이전 사이트와 기술 SEO 동등성을 유지해야 합니다 -- 이상적으로는 개선되어야 합니다. 확인할 내용은 다음과 같습니다:

중요한 동등성 항목

제목 태그: 동일하거나 개선됨. 마이그레이션 중에 절대 비워두지 마십시오.
메타 설명: 나중에 다시 작성할 계획이 있더라도 포함합니다.
H1 구조: 페이지당 하나의 H1, 이전 사이트의 키워드 타게팅과 일치합니다.
정규 태그: 모든 페이지에서 자체 참조 정규 태그. 이전 사이트에 교차 도메인 정규 태그가 있었다면 유지합니다.
Robots.txt: 런칭 시 실수로 Googlebot을 차단하지 마십시오. 이것이 발생하는 것을 원하는 것보다 더 많이 봤습니다.
XML 사이트맵: 모든 새 URL로 새 사이트맵을 생성합니다. 런칭 후 몇 시간 내에 제출합니다.
구조화된 데이터: 모든 스키마 마크업을 마이그레이션합니다. 상품 스키마, FAQ 스키마, 빵조각 스키마 -- 모두입니다.
내부 링킹: 새 사이트의 내부 링크 그래프는 이전 사이트의 것과 긴밀하게 미러링되어야 합니다.

성능 요구사항

Google의 Core Web Vitals는 순위 요소입니다. 새 사이트는 이전 사이트의 성능을 만족하거나 초과해야 합니다:

지표	좋은 임계값	목표
LCP (Largest Contentful Paint)	≤ 2.5s	≤ 2.0s
INP (Interaction to Next Paint)	≤ 200ms	≤ 150ms
CLS (Cumulative Layout Shift)	≤ 0.1	≤ 0.05
TTFB (Time to First Byte)	≤ 800ms	≤ 400ms

이것은 Next.js나 Astro와 같은 현대적인 스택으로 마이그레이션할 때 실제로 장점을 주는 한 영역입니다. 정적 생성과 에지 렌더링은 TTFB를 극적으로 개선할 수 있습니다. 전통적인 WordPress에서 Next.js ISR이 포함된 또는 정적 출력이 있는 Astro로 이동할 때 TTFB가 1.2s에서 200ms 이하로 떨어지는 것을 봤습니다.

4단계: 콘텐츠 마이그레이션 및 검증

자동화된 콘텐츠 추출

30,000페이지의 경우 자동화된 콘텐츠 추출이 필요합니다. 일반적으로 커스텀 스크래퍼를 구축하거나 CMS의 내보내기 API를 사용하여 콘텐츠를 구조화된 형식 (보통 JSON 또는 CSV)으로 가져와서 새 headless CMS에 가져옵니다.

가져온 후 주요 검증:

문자 인코딩 (깨진 특수 문자 주의)
이미지 참조 (모든 이미지가 해결되나요?)
내부 링크 (새 URL 패턴으로 업데이트되었나요?)
포함된 미디어 (비디오, iframe, 위젯)
표 형식
코드 블록

콘텐츠 Diff 테스트

상위 500개 URL에 대해 이전 페이지와 새 페이지 간의 자동 비교를 실행합니다. 스크립트가 두 버전을 가져오고, HTML을 제거하고, 텍스트 콘텐츠를 비교합니다. 텍스트 유사도가 95% 미만인 페이지는 수동 검토용으로 플래그됩니다.

// 간단한 콘텐츠 비교
const { diff } = require('fast-diff');
const cheerio = require('cheerio');

async function comparePages(oldUrl, newUrl) {
  const oldHtml = await fetch(oldUrl).then(r => r.text());
  const newHtml = await fetch(newUrl).then(r => r.text());
  
  const oldText = cheerio.load(oldHtml)('main').text().trim();
  const newText = cheerio.load(newHtml)('main').text().trim();
  
  const changes = diff(oldText, newText);
  const unchanged = changes
    .filter(([type]) => type === 0)
    .reduce((sum, [, text]) => sum + text.length, 0);
  
  const similarity = unchanged / Math.max(oldText.length, newText.length);
  
  return {
    similarity: Math.round(similarity * 100),
    oldLength: oldText.length,
    newLength: newText.length,
    needsReview: similarity < 0.95
  };
}

5단계: 스테이징 환경 테스트

철저한 스테이징 테스트 없이 마이그레이션을 시작하지 마십시오. 확인할 내용은 다음과 같습니다:

리디렉트 테스트

모든 단일 리디렉트를 테스트합니다. 네, 모두 30,000개입니다. 리디렉트 체인을 따라가고 최종 목적지를 검증하는 스크립트를 사용합니다:

# 매핑 파일에서 리디렉트 테스트
while IFS=, read -r old_url new_url; do
  response=$(curl -s -o /dev/null -w "%{http_code} %{redirect_url}" "$old_url")
  status=$(echo $response | cut -d' ' -f1)
  redirect=$(echo $response | cut -d' ' -f2)
  if [ "$status" != "301" ] || [ "$redirect" != "$new_url" ]; then
    echo "실패: $old_url -> $status $redirect (301 $new_url 예상)"
  fi
done < redirect_map.csv

렌더링 검증

클라이언트 사이드 렌더링 (CSR) 또는 수화 집약적 접근 방식을 사용하는 경우 Googlebot이 실제로 콘텐츠를 볼 수 있는지 검증합니다. Google의 Rich Results Test 또는 Search Console의 URL Inspection 도구를 사용하여 렌더링된 출력을 확인합니다.

이것은 특히 React 기반 프레임워크에서 일반적인 문제입니다. 콘텐츠가 렌더링되려면 JavaScript가 필요하고 SSR이나 SSG를 제대로 구현하지 않았으면 Google이 빈 페이지를 볼 수 있습니다. 항상 SEO가 중요한 페이지에 대해 서버 사이드 렌더링 또는 정적 생성을 사용합니다.

6단계: 런칭 당일 실행

런칭 체크리스트

DNS TTL: 마이그레이션 최소 48시간 전에 DNS TTL을 300초로 낮춥니다
리디렉트 배포: 모든 301 리디렉트를 이전 서버/CDN에 라이브로 배포합니다
DNS 전환: 도메인을 새 인프라로 포인트합니다
리디렉트 검증: 프로덕션에 대해 자동화된 리디렉트 테스트를 실행합니다
사이트맵 제출: Search Console에 새 XML 사이트맵을 제출합니다
인덱싱 요청: URL Inspection 도구를 사용하여 상위 50개 페이지의 인덱싱을 요청합니다
모니터링: 이상을 위해 실시간 분석을 봅니다
Robots.txt 검증: Googlebot이 차단되지 않았는지 확인합니다
CDN/캐싱 확인: 리디렉트 헤더가 잘못 캐시되지 않는지 확인합니다

타이밍

화요일 또는 수요일 아침에 런칭합니다. 절대 금요일이 아닙니다. 주말 전에 3개 이상의 전체 영업일이 있어야 모니터링하고 문제를 해결할 수 있습니다. 높은 트래픽 기간이나 주요 쇼핑 이벤트 중에 런칭하지 마십시오.

또한 런칭 후 밤새 누군가가 모니터링하고 있는지 확인합니다. Google은 종종 업무 시간 외에 더 공격적으로 크롤링하며, 리디렉트에 문제가 있으면 빨리 잡아야 합니다.

롤백 계획

15분 이내에 실행할 수 있는 테스트된 롤백 계획을 가지십시오. 이는 보통 마이그레이션 후 최소 2주 동안 이전 인프라를 병렬로 실행 상태로 유지하는 것을 의미합니다. 두 환경을 임시로 유지하는 비용은 실패한 마이그레이션의 비용과 비교하면 아무것도 아닙니다.

7단계: 마이그레이션 후 모니터링

일일 모니터링 (1-2주차)

크롤 오류: Search Console을 매일 확인하여 새로운 404 및 서버 오류를 확인합니다
색인 적용 범위: 색인 적용 범위 보고서에서 감소를 모니터링합니다
오가닉 트래픽: 일일 오가닉 세션을 기준과 비교합니다
순위: 상위 200개 키워드를 매일 추적합니다
서버 로그: 새 사이트에서 Googlebot의 크롤 패턴을 분석합니다
Core Web Vitals: 필드 데이터가 들어오기 시작하면 확인합니다

주간 모니터링 (3-8주차)

주별로 오가닉 트래픽을 비교합니다
순위 변동성을 모니터링합니다
새로운 크롤 문제를 확인합니다
리디렉트 체인이 실수로 생성되지 않았는지 검증합니다
백링크 프로필의 손실된 링크를 모니터링합니다

예상 트래픽 패턴

잘 실행된 마이그레이션은 일반적으로 다음을 보여줍니다:

1주차: 5-15% 트래픽 감소 (Google이 변경사항을 처리 중)
2-3주차: 마이그레이션 이전 수준으로 회복
4-8주차: 새 사이트가 기술적으로 우수하면 종종 트래픽 증가를 볼 것입니다

3주차까지 회복되지 않는 30%+ 감소를 보면 리디렉트 또는 기술 구현에 문제가 있습니다. Search Console을 즉시 파악합니다.

대규모 리디렉트 구현

리디렉트를 구현하는 위치는 중요합니다. 30,000+ 리디렉트의 경우 모두 .htaccess 파일이나 Next.js redirects config 배열에 넣지 마십시오 -- 성능을 죽입니다.

권장 접근 방식

에지 수준 리디렉트 (성능 최고) Cloudflare Workers, Vercel Edge Middleware 또는 Netlify의 _redirects 파일을 사용하여 CDN/에지 수준에서 리디렉트를 구현합니다. 에지 리디렉트는 애플리케이션 코드 이전에 실행되므로 매우 빠릅니다.

// Vercel Edge Middleware 예시
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

// 리디렉트 맵 로드 (배포 시 미리 빌드됨)
import redirectMap from './redirects.json';

export function middleware(request: NextRequest) {
  const path = request.nextUrl.pathname;
  const redirect = redirectMap[path];
  
  if (redirect) {
    return NextResponse.redirect(
      new URL(redirect.destination, request.url),
      redirect.permanent ? 301 : 302
    );
  }
  
  return NextResponse.next();
}

데이터베이스 기반 리디렉트 (유연성 최고) 리디렉트를 데이터베이스에 저장하고 요청 시 조회합니다. 이를 통해 재배포 없이 리디렉트를 추가, 수정, 감사할 수 있습니다. 공격적인 캐싱 (Redis 또는 유사)을 추가하여 데이터베이스 조회가 레이턴시를 추가하지 않도록 합니다.

하이브리드 접근법 (보통 우리가 하는 것) 에지에서의 패턴 기반 리디렉트, 데이터베이스의 개별 리디렉트. 최고의 양쪽을 얻습니다.

국제 및 다국어 사이트 처리

30,000페이지 사이트에 여러 언어 또는 지역이 포함되어 있으면 복잡도가 곱해집니다. 각 언어 버전은 자체 리디렉트 맵이 필요합니다. Hreflang 태그는 새 URL을 참조하도록 업데이트되어야 합니다. 그리고 Search Console의 언어/지역 타게팅이 여전히 제대로 작동하는지 확인해야 합니다.

일반적인 함정:

모든 언어 버전에서 동시에 hreflang 주석을 업데이트하는 것을 잊음
hreflang 상호 요구사항 깨기 (페이지 A가 페이지 B를 가리키면 페이지 B는 페이지 A를 다시 가리켜야 함)
Google이 신호로 사용하는 언어별 URL 구조 손실

순위를 망치는 일반적인 실수

302 대신 301 사용: 임시 리디렉트는 전체 링크 자산을 통과하지 않습니다. 리디렉트 상태 코드를 삼중 확인합니다.
스테이징 사이트를 차단하고 차단 해제하는 것을 잊음: 스테이징의 robots.txt는 Disallow: /를 나타냅니다. 스테이징을 프로덕션에 배포합니다. Googlebot은 아무것도 크롤할 수 없습니다.
콘텐츠와 URL을 동시에 변경: Google은 다른 콘텐츠의 새 URL을 봅니다. 새 페이지인가요? 이동된 페이지인가요? 모호성을 줄입니다 -- 먼저 URL을 마이그레이션하고 나중에 콘텐츠를 변경합니다.
모든 것을 홈페이지로 리디렉트: 게으른 리디렉트 구현은 모든 이전 URL을 홈페이지로 보냅니다. 장황한 순위를 즉시 파괴합니다.
JavaScript 렌더링 무시: 새 React 앱은 Chrome에서 멋져 보입니다. Googlebot은 빈 <div id="root"></div>를 봅니다.
후행 슬래시를 일관되게 처리하지 않음: /products/widget과 /products/widget/은 다른 URL입니다. 하나를 선택하고 다른 하나로 리디렉트합니다.
리디렉트 없이 페이지 제거: 페이지에 트래픽이 있었다면 리디렉트가 필요합니다. 그 콘텐츠를 중단하더라도 가장 관련성 있는 페이지로 리디렉트합니다.

사용하는 도구 및 스택

도구	목적	비용 (2026)
Screaming Frog	데스크톱 크롤링	$259/년
Lumar (Deepcrawl)	대규모 사이트를 위한 클라우드 크롤링	맞춤형 가격
Ahrefs	백링크 분석, 순위 추적	$129/월부터
Google Search Console	색인 모니터링, 크롤 통계	무료
Redirectchecker.com	대량 리디렉트 테스트	무료 계층 사용 가능
ContentKing	실시간 SEO 모니터링	$99/월부터
커스텀 Python/Node 스크립트	리디렉트 매핑, 콘텐츠 diffing	당신의 시간

실제 사이트 빌드의 경우 일반적으로 프로젝트의 필요에 따라 Next.js 또는 Astro를 사용하며, Sanity, Contentful 또는 Storyblok과 같은 headless CMS와 쌍을 이룹니다. 마이그레이션을 계획 중이고 아키텍처에 대해 논의하고 싶다면 가격 책정을 확인하거나 문의하세요.

FAQ

30,000페이지 웹사이트를 마이그레이션하는 데 얼마나 걸립니까?

총 12-20주를 예상하세요. 계획 및 URL 매핑 단계가 가장 오래 걸립니다 -- 보통 8-14주입니다. 실제 기술 마이그레이션 및 런칭은 일반적으로 4-6주입니다. 계획 단계를 서두르는 것이 마이그레이션 실패의 가장 큰 예측 지표입니다.

마이그레이션 중에 반드시 일부 SEO 트래픽을 잃을까요?

5-15%의 임시 감소는 정상이며 완벽한 마이그레이션에서도 예상됩니다. Google은 수만 개의 리디렉트를 처리하고 새 사이트를 다시 크롤링하는 시간이 필요합니다. 감소는 일반적으로 2-3주 내에 해결됩니다. 더 큰 감소를 보거나 회복하지 않으면 리디렉트와 기술 구현을 조사합니다.

마이그레이션 중에 URL 구조를 변경해야 할까요?

변경할 강한 이유가 있을 때만. 모든 URL 변경은 위험을 추가합니다. 현재 URL 구조가 기능하고 설명적이면 유지합니다. 정말 나쁜 경우 (예: 깔끔한 경로 대신 쿼리 매개변수가 있는 URL), 마이그레이션은 이를 수정할 좋은 기회입니다 -- 하지만 리디렉트 맵에 따라 계획하세요.

한 번에 모두 마이그레이션하는 대신 단계적으로 마이그레이션할 수 있습니까?

네, 그리고 매우 큰 사이트의 경우 종종 더 안전한 접근 방식입니다. 블로그 먼저 마이그레이션한 후 상품 페이지, 그 다음 카테고리 페이지를 섹션별로 마이그레이션할 수 있습니다. 이는 위험을 줄이지만 보통 리버스 프록시 뒤에서 두 플랫폼을 동시에 실행하기 때문에 복잡도를 증가시킵니다. 성공적으로 몇 번 했지만 신중한 라우팅 구성이 필요합니다.

마이그레이션 중에 Google 광고는 어떻게 되나요?

광고 랜딩 페이지 URL을 마이그레이션 전이나 직후에 새 URL로 업데이트합니다. 리디렉트가 있으면 광고가 여전히 작동하지만 리디렉트는 레이턴시를 추가하고 Google 광고 품질 점수는 리디렉트 체인의 영향을 받을 수 있습니다. URL을 직접 업데이트하는 것이 항상 더 좋습니다.

마이그레이션 중에 제거하고 싶은 페이지는 어떻게 처리합니까?

페이지에 오가닉 트래픽이나 백링크가 있었다면 새 사이트의 가장 관련성 있는 페이지로 리디렉트합니다. 둘 다 없었다면 404 또는 410 (Gone) 상태를 반환할 수 있습니다. 관련 없는 페이지를 홈페이지로 리디렉트하지 마십시오 -- Google은 대량 홈페이지 리디렉트를 소프트 404로 취급합니다.

301 또는 308 리디렉트를 사용해야 할까요?

대부분의 경우 301을 사용합니다. 둘 다 영구 리디렉트이지만 301은 모든 봇과 브라우저에서 보편적으로 이해됩니다. 308은 HTTP 메서드를 유지합니다 (POST는 POST로 유지됨). API 엔드포인트에서는 중요하지만 SEO 중심의 페이지 리디렉트에서는 중요하지 않습니다.

이전 리디렉트를 언제 제거해야 할까요?

최소 1년, 이상적으로는 무한정 유지합니다. 리디렉트 유지는 저렴하고 제거하면 이전 북마크, 외부 링크 또는 캐시된 검색 결과가 404를 히트한다는 의미입니다. 작동하는 301 리디렉트를 제거할 좋은 이유는 거의 없습니다.

목차