웹사이트를 꼭 옮겨야만 하는 경우는 생각보다 자주 발생한다. 회사나 브랜드가 변경되거나 하기도 하고, 도메인을 바꾸어야 하는 상황도 생기고, 이따금씩은 기술적인 이유로 인해 서버를 이전하는 경우가 생기기도 하는데, 이 모든 경우들은 그간 안정적으로 운영되던 사이트의 검색 최적화를 뒤흔드는 사건이 될수 있다.
그럴리는 없겠지만 그저 예전 사이트를 닫아버리고, 새 사이트를 오픈해서 열심히 광고를 걸어 트래픽을 모으면 되는 거 아닌가 생각하는 책임자들을 이따금식 만나게 된다. 그분들에게 SEO 자산은 할아버지에게 물려받은, 있는지도 모르는 100만평짜리 땅인 셈이다. 그 자산의 중요성을 모르면 한 순간에 그 자산을 송두리째 잃고, 처음부터 다시 사이트를 키워나가는 지난한 과정을 반복하게 된다.
아마도 그 소중한 자산을 잃어버린 것을 뒤늦게 깨닫게 되었을 때는, 꾸주히 받쳐주던 유기적 검색 트래픽이 바닥을 찍고 있을테고, 연관된 회사명이나 브랜드명, 당연히 첫 페이지에 보여야 할 우리 브랜드와 매장, 사이트 링크들이 몇 페이지 뒤로 숨어버린 뒤일수 있다. 더군다나 요즘처럼 검색을 AI에게 질의를 하는 대화방식의 경우라면, 새로 만든 깔끔한 사이트는 아무도 찾지 않는 쓸쓸한 디지털 브로셔가 되버리게 된다.
지금 웹 사이트 이관이 계획되어 있다면?!
아래 문서를 하나씩 꼼꼼하게 읽어보며, 사전에 점검하고 준비해야 할 것들을 챙겨보자. 물론 이 글을 읽는 것은 쉽지 않다. 기본적으로는 뛰어난 AI 에이전트(Gemini PRO 2.5 Pro Preview)의 꼼꼼하고 철저한 조사 결과가 담겨있어서, 너무 어렵고 이해기 어려운 개념이 많아서일수도 있겠지만, 대개의 경우는 웹 사이트의 관리작업은 ‘기술자들의 일’이라고 여겨져서, 누군가 하고 있을 일이라 생각할 뿐 내가 알아보고 익혀야 할 영역이 아니라고 생각해서일 것이다.
그러나 생각해보시라! 모든 정보와 콘텐츠는 AI의 손을 거쳐 세상에 나온다. 점점 더 그들의 산출물은 인간에게 익숙한 문서나 보고서 형태가 아니라, 각종 링크와 주석, 참조 문헌 링크 (Citation), 차트와 표, 인포그래픽, 대시보드나 각종 인터랙티브 요소가 듬뿍 담긴 하나의 독립된 웹 사이트처럼 만들어진다. 심지어 많은 진화된 Agentic AI들은 점차 그들의 생산물을 “웹사이트로 퍼블리싱 하시겠습니까?” 하고 묻는다.
웹 사이트를 만드는 일이 너무너무 쉬워졌고, 심지어 1-Click으로 AI가 만들어주기도 하는 시대가 되었지만, 결국 그 변화는 우리에게 웹 사이트를 바라보는 관점을 다시 생각해보게 만든다. 웹으로 콘텐츠를 만든다는 것, ‘웹 앱’이라고 부르는 생산물을 만들줄 안다는 것과 글쓰기와 사진 넣기 밖에 모르는 문과생 사이에는 넘을 수 없는 소통의 간극이 놓여지게 된다. 이제는 웹 사이틀 만들고 운영한다는 건, 더 이상 ‘기술자들의 일’이 아니라 누구나 읽고 쓰기를 할수 있어야 하는 ‘디지털 리터러시(Digital Literacy)’의 문제가 된다.
자 그러니 이 복잡하고 긴 문서의 스크롤 압박이 있다하더라도, 어딘가 잘 메모해두거나 스크랩, 임베딩 해두고 필요할 때 짬잠이 읽어보자. 웹 사이트의 이관은 집을 새로 옮기는 일만큼이나 복잡하고 스트레스가 어마어마한 일이라는 사실을 겸허히 받아들이고, 마음의 준비를 먼저 해보록 하자!
안전한 리디렉션 설정 매뉴얼을 위한 조사 자료
웹사이트 이전 시 안전한 리다이렉션 설정 매뉴얼
[참고] Google Search Central 웹 사이트 이관
도메인, 서버, 검색엔진 최적화
본 매뉴얼은 운영 중인 웹사이트를 새로운 도메인으로 이전할 때 발생할 수 있는 검색엔진 최적화(SEO) 손실을 최소화하고, 사용자 경험을 원활하게 유지하기 위한 안전한 리다이렉션 설정 절차, 체크포인트, 그리고 주요 유의사항을 상세히 안내합니다. 도메인 변경부터 서버(Apache, Nginx, IIS) 설정, 검색엔진 도구 활용, 개별 페이지 수준의 리다이렉션 검증까지 전 과정을 체계적으로 다룹니다. 각 조치사항의 기술적 원리, 유의사항, 실제 사용 사례, 예제 코드 및 설정 파일, 테스트 방법을 포함하여 실무에 즉시 적용할 수 있도록 구성되었습니다.
도메인 및 DNS 설정 점검
도메인 이전의 첫 단계는 DNS(Domain Name System) 설정을 정확하게 이해하고 계획하는 것입니다. DNS는 웹사이트의 주소인 도메인 이름을 서버의 IP 주소로 변환해주는 시스템으로, 리다이렉션 과정에서 중요한 역할을 합니다.
도메인 포워딩과 HTTP 리다이렉션의 이해
- DNS 레코드 유형 및 역할
- A 레코드: 도메인 이름(예: example.com)을 IPv4 주소에 직접 매핑합니다.
- AAAA 레코드: 도메인 이름을 IPv6 주소에 매핑합니다.
- CNAME (Canonical Name) 레코드: 하나의 도메인 이름(별칭)을 다른 도메인 이름(정식 이름)에 매핑합니다. 예를 들어 www.example.com을 example.com으로 연결할 수 있습니다. CNAME은 동일 FQDN(Fully Qualified Domain Name) 내에서 사용해야 하며, 경로를 포함한 URL 전체를 전달하지는 못합니다. CNAME 레코드는 다른 DNS 레코드(예: MX 레코드)와 동일한 이름으로 공존할 수 없습니다.
- ALIAS (ANAME) 레코드: CNAME과 유사하게 작동하지만, 루트 도메인(Apex zone, 예: example.com)에도 사용할 수 있다는 장점이 있습니다. ALIAS 레코드는 DNS 공급자가 내부적으로 A 레코드로 변환하여 응답하므로, 클라이언트 입장에서는 직접 IP 주소를 받는 것과 같습니다. ALIAS 레코드는 CNAME이나 웹 리다이렉션 레코드를 제외한 다른 유형의 DNS 레코드와 공존할 수 있습니다. 다만, 모든 DNS 제공업체가 ALIAS 레코드를 지원하는 것은 아니며, GeoDNS나 CDN 서비스와는 호환성 문제가 있을 수 있습니다.
- URL 리다이렉션 레코드 (도메인 포워딩 서비스): 일부 DNS 제공업체나 도메인 등록기관은 DNS 설정 수준에서 HTTP 리다이렉션(주로 301 또는 302)을 설정하는 기능을 제공합니다. 이를 ‘URL 리다이렉션 레코드’ 또는 ‘도메인 포워딩’이라 부릅니다. 이 방식은 서버 설정을 직접 변경하기 어려울 때 유용하지만, 세밀한 제어에는 한계가 있을 수 있습니다.
표 1: 주요 DNS 레코드 유형 비교 (도메인 이전 관점)
| 레코드 유형 | 주요 기능 | 루트 도메인 사용 | 경로 보존 | SEO 영향 | 비고 |
| A/AAAA | 도메인을 IP 주소로 직접 매핑 | 가능 | 해당 없음 | 직접적인 리다이렉션 기능 없음 | 새 서버 IP 지정 시 사용 |
| CNAME | 도메인을 다른 도메인 이름으로 매핑 (별칭) | 불가 | 불가 | SEO 가치 전달에 부적합, 경로 유지 안됨 | www를 루트 도메인으로 연결 등 제한적 사용 |
| ALIAS (ANAME) | CNAME과 유사, 루트 도메인에 사용 가능 | 가능 | 불가 | CNAME과 유사, 경로 유지 안됨. SEO에는 HTTP 리다이렉션 권장 | 일부 DNS 제공자만 지원 |
| URL 리다이렉션 (포워딩) | DNS 제공자가 HTTP 리다이렉션(301/302) 수행 | 가능 | 가능 | 301 설정 시 SEO 가치 이전 가능, 경로 보존 | 제공자별 기능 상이, 세부 제어 어려움 |
| HTTP 리다이렉션 (서버) | 웹 서버에서 직접 HTTP 301/302 응답 반환 | 해당 없음 | 가능 | SEO 가치 이전 및 경로 보존에 가장 효과적 | 가장 권장되는 방식 |
- 도메인 포워딩 옵션: Masked vs. Unmasked (Permanent 301)
- Unmasked (비마스크) 포워딩 / Permanent (301) Redirect: 사용자가 이전 도메인 주소로 접속하면, 브라우저의 주소창이 새로운 도메인 주소로 변경되면서 해당 페이지로 이동합니다. 검색엔진은 이를 영구적인 이동으로 인지하고 기존 도메인의 SEO 가치(링크 주스, 페이지랭크 등)를 새로운 도메인으로 이전시킵니다. 사이트 이전 시 SEO 가치 보존을 위해 반드시 301 영구 리다이렉션을 사용해야 합니다.
- Masked (마스크) 포워딩 / URL Cloaking: 사용자가 이전 도메인 주소로 접속하면, 브라우저의 주소창은 이전 도메인 주소로 유지된 채 새로운 도메인의 콘텐츠가 표시됩니다. 이는 주로 프레임(iframe) 기술이나 프록시 서버를 통해 구현됩니다. 마스크 포워딩은 SEO에 매우 부정적인 영향을 미칩니다. 검색엔진은 이를 중복 콘텐츠로 간주하거나 사용자를 기만하는 행위(클로킹)로 판단하여 페널티를 부과할 수 있습니다. 12 따라서 사이트 이전 시에는 절대 사용해서는 안 됩니다.
TTL (Time To Live) 설정 및 전파 시간
- TTL의 개념 및 중요성
- TTL은 DNS 레코드가 DNS 해석기(Resolver)에 캐시되는 시간을 초 단위로 지정하는 값입니다. TTL 값이 짧으면 DNS 변경 사항이 빠르게 전파되지만, DNS 서버에 대한 쿼리가 증가합니다. TTL 값이 길면 DNS 서버 부하가 줄지만, 변경 사항 전파가 느립니다.
- 도메인 이전 시 TTL 관리 전략
- 사이트 이전 작업 **최소 24~48시간 전 (또는 기존 TTL 값 이상)**에 이전 대상 도메인의 A 레코드, CNAME 레코드 등의 TTL 값을 매우 짧게(예: 300초 또는 60초) 변경합니다. 2 이는 DNS 정보 변경 시 전 세계 DNS 서버에 새로운 정보가 신속하게 업데이트되도록 하여, 이전 과정에서의 다운타임이나 접속 불안정을 최소화하기 위함입니다.
- DNS 정보가 짧은 TTL로 충분히 전파되었다고 판단되면, 실제 도메인 연결 정보(예: 새 서버 IP 주소)를 변경합니다.
- 이전 작업이 안정적으로 완료된 후에는 TTL 값을 다시 원래의 권장 값(예: A 레코드의 경우 1시간~24시간, CNAME의 경우 12~24시간)으로 복원하여 DNS 서버의 부하를 줄입니다.
DNS 변경 사항이 전 세계로 전파되는 시간은 TTL 설정뿐만 아니라 각 지역 ISP의 DNS 해석기 캐시 정책에 따라 달라질 수 있으므로, 충분한 시간을 두고 계획하는 것이 중요합니다. TTL 값을 급격히 줄이면 DNS 서버에 일시적인 부하 증가가 발생할 수 있으므로, 서비스 중요도와 트래픽 상황을 고려하여 점진적으로 조정하는 방안도 고려할 수 있습니다.
SSL 인증서 준비 및 적용
- 새 도메인용 SSL 인증서 발급
- 새로운 도메인에 대한 SSL 인증서를 미리 발급받아야 합니다. 이전이 완료된 후 HTTPS 연결 오류가 발생하지 않도록 하기 위함입니다.
- 기존 인증서가 와일드카드 인증서(*.olddomain.com)이거나 멀티 도메인(SAN) 인증서에 새 도메인이 포함되어 있지 않다면, 새 도메인 또는 새 도메인을 포함하는 새 인증서가 필요합니다.
- https://olddomain.com에서 https://newdomain.com으로 리다이렉션하려면 두 도메인 모두 유효한 SSL 인증서가 설치되어 있어야 합니다.
- 리다이렉션 전후 SSL 설정 일관성 유지
- 이전 사이트가 HTTPS를 사용했다면, 새 사이트도 반드시 HTTPS를 사용해야 하며, 모든 HTTP 트래픽은 HTTPS로 강제 리다이렉션되도록 설정해야 합니다. 이는 보안뿐만 아니라 SEO에도 중요합니다.
- 리다이렉션 설정 시, HTTP에서 HTTPS로의 리다이렉션과 도메인 변경 리다이렉션이 동시에 올바르게 처리되는지 확인해야 합니다.
서버 환경별 리다이렉션 설정
웹 서버 수준에서의 HTTP 301 영구 리다이렉션은 SEO 가치를 가장 효과적으로 이전하는 방법입니다. 3 각 서버 환경(Apache, Nginx, IIS)에 맞는 정확한 설정을 적용해야 합니다.
리다이렉션 기본 원리 및 SEO 영향
- HTTP 상태 코드의 이해
- 301 Moved Permanently: 요청한 리소스가 영구적으로 새 URL로 이전되었음을 나타냅니다. 검색엔진은 이 코드를 받으면 이전 URL의 SEO 가치(페이지랭크, 링크 주스 등)를 새 URL로 전달합니다. 사이트 도메인 이전 시 반드시 사용해야 하는 코드입니다.
- 302 Found (또는 HTTP 1.0에서는 307 Moved Temporarily): 요청한 리소스가 일시적으로 다른 URL에 있음을 나타냅니다. 검색엔진은 이를 일시적인 변경으로 간주하여 SEO 가치를 이전하지 않을 수 있습니다. 9 따라서 도메인 이전에는 부적합합니다.
- 308 Permanent Redirect: 301과 유사하게 영구 이전을 의미하지만, 요청 메소드(GET, POST 등)와 본문을 변경하지 않고 리다이렉션을 수행하도록 명시합니다. 9 SEO 측면에서는 301과 동일하게 취급됩니다.
- 리다이렉션과 SEO
- 링크 주스(Link Equity) 보존: 올바른 301 리다이렉션은 이전 페이지가 축적한 백링크의 가치를 새 페이지로 전달합니다.
- 중복 콘텐츠 방지: 이전 URL과 새 URL에 동일한 콘텐츠가 존재할 경우, 리다이렉션 없이는 중복 콘텐츠로 간주되어 SEO에 불이익을 받을 수 있습니다. 301 리다이렉션은 새 URL이 표준(canonical)임을 명확히 합니다.
- 사용자 경험(UX) 향상: 사용자가 이전 URL로 접속해도 자동으로 새 페이지로 안내되어 끊김 없는 경험을 제공합니다.
- 리다이렉션 대상 페이지의 관련성: 이전 페이지와 최대한 관련성이 높은 페이지로 리다이렉션해야 합니다. 관련 없는 페이지(예: 홈페이지)로의 일괄 리다이렉션은 SEO 가치 손실 및 사용자 혼란을 야기할 수 있습니다.
Apache 서버 (.htaccess)
Apache Server (.htaccess)
Apache 서버에서는 .htaccess 파일을 통해 mod_rewrite 모듈 또는 mod_alias 모듈의 지시어를 사용하여 리다이렉션을 설정합니다. mod_rewrite는 더 복잡하고 유연한 규칙 설정이 가능합니다.
- mod_rewrite 활성화 및 기본 설정
- .htaccess 파일 상단에 다음을 추가하여 mod_rewrite 엔진을 활성화합니다.
Apache
RewriteEngine On - Apache 주 설정 파일(httpd.conf 또는 가상 호스트 설정)에서 AllowOverride 지시어가 .htaccess 파일을 읽을 수 있도록 설정되어 있어야 합니다 (예: AllowOverride All 또는 AllowOverride FileInfo)
RewriteEngine On
- .htaccess 파일 상단에 다음을 추가하여 mod_rewrite 엔진을 활성화합니다.
- 주요 리다이렉션 시나리오 및 예제 코드
- 개별 URL 리다이렉션
- # mod_alias 사용 (더 간단)
Redirect 301 /old-page.html https://newdomain.com/new-page.html
또는 mod_rewrite 사용: - Apache
RewriteRule ^old-page.html$ https://newdomain.com/new-page.html - 특정 디렉토리(폴더) 전체 리다이렉션
- Apache
RewriteRule ^old-folder/(.*)$ https://newdomain.com/new-folder/$1 - 이전 도메인 전체를 새 도메인으로 리다이렉션 (경로 유지)
Apache
RewriteEngine On
RewriteCond %{HTTP_HOST} ^olddomain.com$
RewriteCond %{HTTP_HOST} ^www.olddomain.com$
RewriteRule ^(.*)$ https://newdomain.com/$1
11 - WWW를 non-WWW로 표준화
Apache
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.example.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 - non-WWW를 WWW로 표준화
Apache
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 - HTTP를 HTTPS로 리다이렉션 (HTTP to HTTPS):
Apache
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto}!https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} - 플래그 설명: R=301 (영구 리다이렉션), L (마지막 규칙, 처리 중단), NC (No Case, 대소문자 구분 안 함).
- 개별 URL 리다이렉션
.htaccess 파일 내 규칙의 순서는 매우 중요합니다. Apache는 .htaccess 규칙을 순차적으로 처리하므로, 광범위한 규칙(예: 도메인 전체 리다이렉션)이 특정 페이지 리다이렉션 규칙보다 먼저 나오면 특정 규칙이 무시될 수 있습니다. 따라서 더 구체적인 규칙을 일반적인 규칙보다 앞에 배치해야 합니다.
표 2: Apache Redirect/RedirectMatch vs. RewriteRule 비교
| 기능 | Redirect / RedirectMatch (mod_alias) | RewriteRule (mod_rewrite) |
| 모듈 | mod_alias (표준) | mod_rewrite (더 강력하며, 활성화 필요할 수 있음) |
| 복잡성 | 기본 리다이렉션에 더 간단한 구문 | 더 복잡하며, 정규 표현식 사용, 뛰어난 유연성 제공 |
| 조건부 로직 | 단순 경로 매칭 외 조건부 로직 없음 | 헤더, 서버 변수, 파일 존재 여부 등에 기반한 복잡한 조건(RewriteCond) 지원 |
| 사용 사례 | 간단한 페이지 대 페이지 또는 디렉토리 대 디렉토리 리다이렉션 | 복잡한 리다이렉션, 표준화(WWW/non-WWW, HTTP/HTTPS), 경로 보존을 포함한 도메인 수준 리다이렉션 |
| 경로 처리 | Redirect는 접두사 일치, RedirectMatch는 정규식 사용 | 경로 일치 및 대체에 대한 완전한 정규식 제어 |
| 예시 | Redirect 301 /old /new | RewriteRule ^old/(.*)$ /new/$ |
- 일반적인 문제점 및 해결 방법
- 리다이렉션 루프
상충하는 규칙(예: A→B와 B→A)으로 인해 발생합니다. 철저히 테스트해야 합니다. - 구문 오류
.htaccess는 민감하여 작은 오타도 500 내부 서버 오류를 유발할 수 있습니다. Apache 오류 로그를 확인하고 온라인 구문 검사기를 사용합니다. - 잘못된 플래그 사용 (Incorrect Flags): R=301 대신 R (기본값 302)을 사용하는 경우입니다.
- 성능 (Performance): 지나치게 많거나 복잡한 규칙은 서버 성능에 약간의 영향을 줄 수 있습니다. 가능한 경우 정규 표현식을 최적화합니다.
- 파일 권한 (File Permissions): .htaccess 파일이 올바른 권한(예: 644)을 가지고 있는지 확인합니다.
- AllowOverride 지시어 (AllowOverride Directive): Apache의 주 설정 파일에서 .htaccess 파일이 처리되도록 AllowOverride All 또는 AllowOverride FileInfo 등이 설정되어 있어야 합니다.
- 리다이렉션 루프
Nginx 서버
Nginx Server Configuration
Nginx에서는 주로 server 블록 내에서 return 또는 rewrite 지시어를 사용하여 리다이렉션을 설정합니다.
- 리다이렉션을 위한 return과 rewrite 지시어 비교 및 사용법
- return 지시어: 직접적인 리다이렉션에 더 간단하고 빠릅니다. 처리를 중단하고 지정된 코드와 URL을 반환합니다. 대부분의 일반적인 301 리다이렉션에 선호됩니다. 20
- 예시: return 301 https://newdomain.com$request_uri;
- rewrite 지시어: 더 강력하며, 복잡한 URL 조작을 위해 정규 표현식을 사용합니다. 내부 재작성도 수행할 수 있습니다. 정규 표현식 처리로 인해 간단한 리다이렉션에는 return보다 느립니다. permanent 플래그는 301 리다이렉션을 의미합니다. 20
- 예시: rewrite ^/old/(.*)$ /new/$1 permanent;
- return 지시어: 직접적인 리다이렉션에 더 간단하고 빠릅니다. 처리를 중단하고 지정된 코드와 URL을 반환합니다. 대부분의 일반적인 301 리다이렉션에 선호됩니다. 20
Nginx는 설정을 한 번 로드하므로, 단순 301의 경우 return이 rewrite의 정규식 처리 오버헤드 없이 직접 리다이렉션을 실행하여 특히 트래픽이 많은 사이트에서 성능상 이점을 가집니다.
- 주요 리다이렉션 시나리오 및 예제 코드
Key Redirection Scenarios and Example Code
표 3: Nginx return vs. rewrite 지시어 비교 (리다이렉션 관점)
| 기능 | return 지시어 | rewrite 지시어 |
| 주요 사용 | 특정 HTTP 상태 코드 및 URL 반환 | 정규식을 사용한 복잡한 URL 조작, 내부 재작성, 조건부 리다이렉션 |
| 성능 | 간단한 리다이렉션에 더 빠름 (정규식 평가 없음) | 정규식 처리로 인해 간단한 리다이렉션에 더 느림 |
| 복잡성 | 더 간단한 구문 | 더 복잡하며, 정규식 지식 필요 |
| 리다이렉션 코드 | 명시적으로 지정 (예: return 301…) | permanent 플래그 사용 시 301, 기본값 302 |
| 경로 처리 | 지정된 정확한 URL로 리다이렉션 | 정규식을 사용하여 이전 URL의 일부를 캡처하여 새 URL에 사용할 수 있음 |
| 예시 (301) | return 301 https://new.com$request_uri; | rewrite ^/old/(.*)$ https://new.com/new/$1 permanent; |
- 권장 설정 및 최적화 방안
- 일치하지 않는 도메인에 대한 포괄적 처리가 필요할 경우 server_name _를 사용하되, 가능한 한 구체적으로 지정합니다.
- 리다이렉션 server 블록을 주 server 블록보다 먼저 설정 파일에 배치합니다.
- Nginx를 다시 로드하거나 다시 시작하기 전에 nginx -t 명령으로 설정 구문을 테스트합니다.
- 많은 수의 페이지 대 페이지 리다이렉션의 경우, 여러 개별 rewrite 규칙보다 깔끔한 설정과 더 나은 성능을 위해 map 지시어를 활용합니다.
Nginx
# map을 사용한 다수 리다이렉션 예시
map $request_uri $redirect_uri {
/old-page1.html /new-page1.html;
/old-page2.html /new-page2.html;
#… 추가 매핑
}
server {
#…
if ($redirect_uri) {
return 301 $redirect_uri;
}
#…
}
IIS 서버 web.config
IIS(Internet Information Services)에서는 web.config 파일과 URL Rewrite 모듈을 사용하여 리다이렉션을 설정합니다.
- URL Rewrite 모듈 설치 및 설정
- IIS는 고급 리다이렉션을 위해 URL Rewrite 모듈을 사용합니다. 이 모듈은 서버에 설치되어 있어야 합니다.
- URL Rewrite 모듈은 Microsoft 웹사이트에서 다운로드할 수 있습니다.
- 설정은 web.config 파일의 <system.webServer><rewrite><rules> 섹션 내에서 직접 XML로 작성하거나, IIS 관리자 GUI를 통해 구성할 수 있습니다.
- 주요 리다이렉션 시나리오 및 예제 코드
Key Redirection Scenarios and Example Code- 이전 도메인 전체를 새 도메인으로 리다이렉션 (경로 유지):
XML
<rule name=”Domain Redirect” stopProcessing=”true”>
<match url=”(.*)” />
<conditions>
<add input=”{HTTP_HOST}” pattern=”^(www.)?olddomain.com$” />
</conditions>
<action type=”Redirect” url=”https://newdomain.com/{R:1}” redirectType=”Permanent” />
</rule> - WWW를 non-WWW로 표준화:
XML
<rule name=”Redirect to non-WWW” stopProcessing=”true”>
<match url=”(.*)” />
<conditions>
<add input=”{HTTP_HOST}” pattern=”^www.example.com$” />
</conditions>
<action type=”Redirect” url=”https://example.com/{R:1}” redirectType=”Permanent” />
</rule>
19 - non-WWW를 WWW로 표준화:
XML
<rule name=”Redirect to WWW” stopProcessing=”true”>
<match url=”(.*)” />
<conditions>
<add input=”{HTTP_HOST}” pattern=”^example.com$” />
</conditions>
<action type=”Redirect” url=”https://www.example.com/{R:1}” redirectType=”Permanent” />
</rule>
19 - HTTP를 HTTPS로 리다이렉션:
XML
<rule name=”HTTP to HTTPS redirect” stopProcessing=”true”>
<match url=”(.*)” />
<conditions>
<add input=”{HTTPS}” pattern=”off” ignoreCase=”true” />
</conditions>
<action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” />
</rule> - 개별 URL/폴더 리다이렉션:
XML
<rule name=”Redirect old-page to new-page” stopProcessing=”true”>
<match url=”^old-page.html$” />
<action type=”Redirect” url=”/new-page.html” redirectType=”Permanent” />
</rule>
<rule name=”Redirect old-folder to new-folder” stopProcessing=”true”>
<match url=”^old-folder/(.*)” />
<action type=”Redirect” url=”/new-folder/{R:1}” redirectType=”Permanent” />
</rule>
- 이전 도메인 전체를 새 도메인으로 리다이렉션 (경로 유지):
- 영구(301) 리다이렉션 보장 방법
- 핵심은 <action> 태그 내의 redirectType=”Permanent” 속성입니다. 이 속성은 IIS가 301 HTTP 상태 코드를 전송하도록 보장합니다.
- IIS 관리자 GUI를 사용하는 경우 “Permanent (301)” 옵션이 선택되었는지 확인합니다.
IIS의 URL Rewrite 모듈은 강력하지만, XML 기반 설정에 익숙하지 않은 사용자에게는 GUI를 사용하지 않을 경우 직관적이지 않을 수 있습니다. 규칙 로직에서 stopProcessing=”true” 속성은 Apache의 [L] 플래그와 유사하게, 일치하는 요청이 후속 규칙에 대해 평가되는 것을 방지하는 데 중요합니다. 이를 생략하면 요청이 동일한 web.config 내의 다른 규칙에 의해 여러 번 리다이렉션되어 예기치 않은 동작이나 체인이 발생할 수 있습니다.
URL 매핑 및 개별 페이지 리다이렉션
이 단계는 이전 URL을 새 URL에 정확히 연결하여 개별 페이지의 SEO 가치를 보존하는 핵심 과정입니다. 수동 및 AI 지원 접근 방식을 모두 다룹니다.
URL 매핑의 중요성
- 가치 있는 모든 이전 URL은 새 사이트의 직접적인 해당 페이지 또는 가장 관련성 높은 페이지로 1:1 리다이렉션되어야 합니다.
- 다수의 이전 페이지를 새 홈페이지나 소수의 일반 카테고리 페이지로 일괄 리다이렉션하는 것은 링크 가치를 희석시키고 사용자 경험을 저해하므로 피해야 합니다.
- 1:1 매핑은 특정 콘텐츠에 대한 키워드 순위와 사용자 기대를 보존합니다.
세분화된 1:1 URL 매핑에 투자하는 노력은 특히 롱테일 키워드 순위 보존과 직접적으로 연관됩니다. 많은 웹사이트가 매우 구체적인 다중 단어 검색어인 롱테일 키워드로부터 상당한 트래픽을 유도합니다. 이러한 검색어는 일반적으로 홈페이지나 일반 카테고리 페이지가 아닌 특정 콘텐츠 페이지로 연결됩니다. 만약 이러한 특정 이전 페이지가 새로운 해당 페이지(또는 가장 관련성 높은 페이지)로 1:1 매핑되지 않으면, 새 사이트는 해당 롱테일 검색어에 대한 순위를 잃을 가능성이 높습니다. 검색 엔진은 이전 URL의 순위 신호를 특정 콘텐츠와 연관시키는데, 관련성이 낮은 페이지로의 리다이렉션은 이러한 연관성을 깨뜨립니다. 따라서 철저한 1:1 매핑은 사이트의 전체적인 유기적 검색 가시성을 유지하기 위한 투자입니다.
수동 URL 매핑
- 프로세스 (Process):
- 이전 사이트를 크롤링하여 전체 URL 목록을 확보합니다(예: Screaming Frog 사용)
- 새 사이트(스테이징 또는 라이브)를 크롤링하여 대상 URL 목록을 확보합니다.
- 스프레드시트를 사용하여 한 열에는 이전 URL을, 다른 열에는 수동으로 찾은 해당 새 URL을 나열합니다.
- 사전 마이그레이션 감사에서 식별된 고가치 페이지(트래픽, 백링크가 많은 페이지)를 우선적으로 매핑합니다.
- 도구 (Tools):
Screaming Frog, Google Search Console(트래픽/백링크가 있는 이전 URL 확인용), Ahrefs/Semrush(이전 URL에 대한 백링크 데이터 확인용), 스프레드시트 소프트웨어(Excel, Google Sheets). - 템플릿 (Template):
간단한 스프레드시트 구조를 제안합니다: 이전 URL | 새 URL | 리다이렉션 유형 (301) | 비고/우선순위.
크롤링된 URL 리스트 기반 AI 에이전트를 활용한 URL 매핑 분석 및 자동화/지원 방안
대규모 사이트의 경우 수동 URL 매핑은 시간이 많이 걸리고 오류 발생 가능성이 높습니다. AI는 이전 URL/페이지와 새 URL/페이지의 요소를 비교하여 유사성을 기반으로 일치 항목을 제안함으로써 이 과정을 지원할 수 있습니다.
- 개념: 콘텐츠 유사도 분석을 위한 AI 활용
- AI는 URL 문자열 구조, 페이지 제목, H1 제목, 메타 설명 또는 전체 텍스트 콘텐츠 간의 유사성을 분석하여 매칭을 제안할 수 있습니다.
- 이를 통해 대규모 마이그레이션에서 수동 작업의 부담을 크게 줄일 수 있습니다.
- 도구 및 기술 (Tools & Technologies)
- 크롤링 도구: Screaming Frog (URL 및 메타데이터 추출)
- 프로그래밍 언어: Python (매칭 로직 스크립팅)
- 실행 환경: Google Colab (로컬 설정 없이 Python 스크립트 실행)
- 라이브러리:
- BeautifulSoup: HTML 파싱 및 텍스트 콘텐츠(제목, 헤딩, 본문) 추출
- rapidfuzz 또는 fuzzywuzzy: 문자열 퍼지 매칭(제목, URL 간 유사도 비율 계산)
- Sentence Transformers / all-MiniLM-L6-v2 모델: 텍스트 임베딩(텍스트 의미의 수치 표현) 생성
- FAISS (Facebook AI Similarity Search): 대규모 벡터 세트에 대한 효율적인 유사성 검색
- 기타 유사도 알고리즘: 자카드 유사도, 유클리드 거리, 코사인 유사도(주로 임베딩과 함께 사용)
- 전문 도구: Rapid301, Growthack URL Matcher Tool 등 이러한 기능을 패키징한 상용 또는 오픈소스 도구가 있을 수 있습니다.
- 단계별 실행
- 이전 사이트 크롤링: Screaming Frog를 사용하여 라이브(이전) 웹사이트를 크롤링합니다. 200 상태 코드의 HTML 페이지를 URL, 제목, H1, 메타 설명과 함께 내보냅니다.
- 새 사이트(스테이징) 크롤링: 스테이징(새) 웹사이트에 대해 동일한 작업을 반복합니다.
- 데이터 준비: CSV 파일을 정리하고 형식을 지정합니다. URL이 절대 경로인지 확인합니다.
- Python 스크립트 실행 (예: Google Colab에서):
- 이전(origin.csv) 및 새(destination.csv) URL 목록을 업로드합니다.
- 유사성 일치에 사용할 필드를 선택합니다(예: URL 경로, 페이지 제목, H1).
- 스크립트가 데이터를 처리합니다:
- CSV에 아직 없는 경우 선택한 콘텐츠를 가져오거나 추출합니다.
- (고급 NLP 사용 시) 텍스트 필드에 대한 임베딩을 생성합니다.
- 유사성 점수를 계산합니다
(예: 임베딩에 대한 코사인 유사성, 문자열에 대한 퍼지 비율).- 결과 검토: 스크립트는 old_url, matched_new_url, similarity_score가 포함된 CSV를 출력합니다.
- 수동 검증: 유사성 점수별로 정렬합니다. 모든 일치 항목, 특히 점수가 낮은 항목을 수동으로 검토합니다.
이 단계는 매우 중요하며 생략할 수 없습니다.
- 자동화/지원 전략 및 한계점
- 접근법
- 한계점:
- AI는 완벽하지 않으며, 미묘한 맥락을 놓치거나 “어리석은” 오류를 범할 수 있습니다.
- 정확성은 입력 데이터의 품질과 이전 사이트와 새 사이트 콘텐츠/구조 간의 일관성에 따라 달라집니다.
- 수동 검토 없이 자동화에 과도하게 의존하는 것은 뜻하지 않은 오류를 양산할수도 있습니다.
- 도구가 JavaScript를 렌더링하지 않아 동적 사이트의 콘텐츠를 놓칠 수 있습니다.
- 내용이 크게 재작성되었거나 목적이 완전히 다른 페이지는 자동으로 일치시키기 어렵습니다.
- LLM은 콘텐츠 정리 또는 통합과 같은 전략적 결정을 본질적으로 이해하지 못합니다.
URL 매핑에서 AI의 진정한 힘은 완전 자동화가 아니라 지루한 수동 매칭작업의 부담을 덜고, 콘텐츠 매칭의 검증이나 복잡한 예외 처리에 집중할수 있게 하는데 있습니다. AI 유사성 매칭을 위한 데이터 포인트(URL 문자열, 제목, H1, 본문 콘텐츠) 선택은 사이트 마이그레이션의 특성에 따라 조정되어야 합니다. 예를 들어, URL 경로는 동일하고 도메인 TLD만 변경되는 경우 URL 문자열 유사성이 매우 효과적일 것입니다. URL 경로는 변경되지만 페이지 주제는 유지되는 경우 페이지 제목이나 H1을 기반으로 한 매칭이 더 정확할 수 있습니다.
이전되지 않는 페이지의 404 오류 처리 방안
모든 이전 페이지가 새 사이트에 직접적인 대응 페이지를 갖지는 않을 수 있습니다(예: 오래된 콘텐츠, 정리 대상인 빈약한 콘텐츠)
- 옵션 1: 사용자 정의 404 페이지: 직접적인 대체 페이지 없이 의도적으로 제거된 페이지의 경우 404 상태 코드를 반환하도록 합니다. 사용자가 사이트의 다른 관련 부분으로 이동하는 데 도움이 되는 사용자 친화적인 사용자 정의 404 페이지(예: 검색 창, 인기 카테고리/홈페이지 링크 포함)가 있는지 확인합니다.
- 옵션 2: 관련 카테고리/상위 페이지로 리다이렉션 : 특정 페이지가 제거되었지만 해당 페이지의 광범위한 주제가 여전히 다뤄지고 있다면, 상위 카테고리 페이지나 밀접하게 관련된 개요 페이지로 리다이렉션하는 것을 고려합니다. 더 구체적인 관련 대상이 있는 경우 홈페이지로 리다이렉션하는 것보다 낫습니다.
- 옵션 3: 홈페이지로 리다이렉션 : 다른 관련 페이지가 없는 경우에만 최후의 수단으로 홈페이지로 리다이렉션합니다.
- 404 오류 모니터링 : 마이그레이션 후 Google Search Console에서 404 오류를 모니터링합니다. 가치 있는 페이지(예: 백링크 또는 트래픽이 있는 페이지)가 의도치 않게 404를 반환하는 경우 즉시 적절한 301 리다이렉션을 구현합니다.
정리된 콘텐츠에 대해 전략적으로 404를 사용하는 것은 실제로 쓸모 없어진 페이지에 대한 것이고 여전히 가치(예: 백링크)를 지닌 페이지가 아닌 경우, 크롤링 예산과 링크 가치를 더 가치 있는 페이지에 집중함으로써 SEO에 도움이 될 수 있습니다.
검색엔진 알림 및 설정
리다이렉션이 준비되면, 다음 핵심 단계는 검색엔진에 공식적으로 이전을 알리고 새 사이트 구조를 이해하고 색인하는 데 필요한 정보를 제공하는 것입니다.
Google Search Console (GSC)
- 새 도메인 속성 확인
- GSC 내에서 도메인 변경 프로세스를 시작하기 전에 새 도메인 속성을 추가하고 소유권을 확인해야 합니다.
- 새 도메인의 www 및 non-www 버전, 그리고 HTTP 및 HTTPS 버전을 모두 확인하거나, 가급적 도메인 수준 속성을 확인합니다.
- 확인 방법에는 DNS 레코드, HTML 파일 업로드, HTML 태그, Google Analytics, Google Tag Manager 등이 있습니다.
- 주소 변경 도구 사용법
- 목적: 한 도메인/하위 도메인에서 다른 도메인/하위 도메인으로의 사이트 이전을 Google에 알립니다(예: example.com에서 example.org로). Google 검색 결과 마이그레이션을 돕습니다.
- 선행 조건:
- 이전 사이트에서 새 사이트로 301 리다이렉션(페이지 대 페이지)이 구현되어 있어야 합니다.
- 이전 사이트와 새 사이트 모두 동일한 Google 계정으로 GSC에서 확인되어야 합니다.
- 새 XML 사이트맵 제출 Submitting New XML Sitemap
- 색인하려는 모든 표준 URL을 포함하는 새 도메인용 XML 사이트맵을 만듭니다.
- 사이트맵의 URL이 새 도메인과 올바른 프로토콜(HTTPS)을 사용하는지 확인합니다. 정규화된 절대 URL을 사용합니다.
- Google Search Console(색인 생성 > 사이트맵)을 통해 새 사이트맵을 제출합니다.
- 이전 도메인의 GSC 속성에서 이전 도메인의 사이트맵을 제거하거나 비어 있거나 404를 반환하는지 확인합니다.
- 사이트맵은 Google이 새 URL을 더 빨리 찾는 데 도움이 되지만 색인 생성이나 순위를 보장하지는 않습니다.
- 크기 제한: 압축되지 않은 경우 50MB 또는 URL 50,000개. 더 큰 사이트의 경우 사이트맵 색인 파일을 사용합니다.
Naver Search Advisor
- 새 도메인 등록 및 소유 확인
- 네이버 서치어드바이저(구 네이버 웹마스터 도구)는 네이버의 GSC에 해당합니다.
- 네이버 서치어드바이저에 새 도메인을 등록합니다.
- 일반적으로 HTML 파일 업로드 또는 홈페이지에 메타 태그를 추가하여 소유권을 확인합니다.
- 사이트 재수집 요청 및 수집 주기 조정
- GSC의 주소 변경 도구와 달리 네이버에는 직접적인 “사이트 이전” 도구가 없습니다. 프로세스는 새 사이트를 구성하고 이전 사이트가 올바르게 리다이렉션되도록 하는 것을 포함합니다.
- 새 사이트의 경우:
- 새 도메인의 기본 URL에 대해 웹 페이지 수집/재수집을 수동으로 요청합니다.
- 네이버 서치어드바이저에서 [요청 > 웹 페이지 수집]으로 이동하여 새 도메인을 입력하고 제출합니다.
- 수집 주기 조정: [설정 > 수집주기 설정]으로 이동하여 처음에는 “빠르게”로 설정합니다. 사이트가 색인되고 안정화되면 “일반”으로 되돌립니다.
- 이전 사이트의 경우 (리다이렉션이 적용된 후에도 네이버 검색 결과에 계속 표시되는 경우):
- 새 URL로 리다이렉션되는 특정 이전 URL에 대해 웹 페이지 수집 요청을 사용하여 네이버가 변경 사항을 인식하도록 돕습니다.
- 이전 사이트의 경우 (리다이렉션이 적용된 후에도 네이버 검색 결과에 계속 표시되는 경우):
네이버의 사이트 이전 프로세스는 Google의 전용 “주소 변경” 도구보다는, 이전 도메인으로부터의 강력한 301 리다이렉션과 함께 새 도메인에 대한 명시적인 재수집 요청 및 사이트맵 제출에 더 의존하는 것으로 보입니다. “품질 지수” 이전에는 시간이 걸린다고 언급됩니다.
- 새 XML 사이트맵 제출
- 네이버 서치어드바이저를 통해 새 도메인에 대한 XML 사이트맵을 만들고 제출합니다.
- 이는 네이버가 새 사이트의 모든 URL을 찾는 데 도움이 됩니다.
- 사이트맵이 표준 프로토콜을 따르고 표준 URL을 포함하는지 확인합니다.
- 네이버의 사이트 이전 처리 방식 및 랭킹 시그널 이전 이해
- 네이버는 도메인/호스트 이름 변경이 이전 사이트(A)에서 새 사이트(B)로 “품질 지수”가 이전됨에 따라 검색 결과에 일시적인 변동을 일으킬 수 있음을 인정합니다. 이 이전에는 시간이 걸립니다.
- 잦은 도메인 변경은 이 품질 지수에 부정적인 영향을 미칠 수 있습니다. 사이트 이전은 브랜드 변경과 같은 필수적인 경우에만 고려해야 합니다.
- 적절한 301 리다이렉션(URL 대 URL, 1:1)은 네이버가 이전을 이해하고 신호를 이전하는 데 매우 중요합니다.
- 네이버는 검색 로봇이 새 사이트를 크롤링하고 이전 사이트의 리다이렉션을 발견하는 것에 의존합니다.
- 새 사이트에서 표준 URL을 사용하면 새 사이트의 검색 노출 URL이 이전 도메인으로 지정되는 것을 방지하는 데 도움이 됩니다.
- 네이버는 신선하고 지역적이며 멀티미디어 콘텐츠를 중요하게 생각합니다. 백링크는 Google보다 덜 강조되지만 외부 링크는 신뢰도를 높입니다.
표 4: Google Search Console vs. Naver Search Advisor – 사이트 이전 프로세스 비교
| 기능 | Google Search Console | Naver Search Advisor |
| 사이트 이전 도구 | 예 (“주소 변경” 도구) | 직접적인 “사이트 이전” 도구 없음. 리다이렉션 및 새 사이트 등록/크롤링에 의존. |
| 알림 방법 | 주소 변경 도구를 통한 명시적 알림. | 301 리다이렉션, 새 사이트 등록, 사이트맵 제출, 재수집 요청을 통한 암시적 알림. |
| 신호 이전 | 도구가 검색 결과 및 신호 마이그레이션을 도움. | “품질 지수”가 시간이 지남에 따라 이전됨. 1:1 리다이렉션이 핵심. |
| 사이트맵 제출 | 예, 새 도메인용. | 예, 새 도메인용. |
| 크롤링 요청 | 개별 URL에 대한 URL 검사 도구. | 사이트/URL에 대한 “웹 페이지 수집” 요청, 수집 주기 조정. |
| 주요 강조 사항 | 명확한 신호 전달을 위한 301 리다이렉션 + 주소 변경 도구. | 강력한 1:1 301 리다이렉션, 새 사이트 설정, 새 사이트의 표준 URL, 품질 지수 이전을 위한 인내. |
새 도메인을 위한 robots.txt 설정
- 이전 도메인의 robots.txt:
마이그레이션 후 리다이렉션이 확인되면, 이전 도메인의 robots.txt는 크롤러가 이전 URL에 접근하여 301 리다이렉션을 볼 수 있도록 차단하지 않아야 합니다. 이전 서버가 중단되면 이는 무의미해집니다. - 새 도메인의 robots.txt:
- 모든 중요한 콘텐츠의 크롤링을 허용하는지 확인합니다.
- 실수로 전체 사이트에서 크롤러를 차단하지 않도록 주의합니다(스테이징 사이트에서 라이브로 푸시될 때 흔히 발생하는 실수).
- 새 XML 사이트맵의 위치를 지정합니다.
- 색인되어서는 안 되는 URL(예: 관리자 영역, 검색 결과 페이지, 중복 유틸리티 페이지)을 차단합니다.
- robots.txt 파일을 새 도메인의 루트 디렉토리에 배치합니다.
- 올바른 구문을 사용합니다. 파일 이름은 대소문자를 구분합니다(robots.txt).
- 네이버 가이드는 “새 사이트의 robots.txt를 모두 허용하도록 설정…”이라고 명시합니다.
새 사이트의 캐노니컬 태그 (rel=”canonical”) 설정 및 검수
- 목적: 캐노니컬 태그는 여러 버전이 존재할 경우(예: 매개변수, 동일 콘텐츠에 대한 다른 경로로 인해) URL의 기본 버전을 지정하여 중복 콘텐츠 문제를 방지합니다.
- 새 사이트에서의 구현:
- 색인 가능한 모든 페이지에는 자체 절대 URL을 가리키는 자체 참조 캐노니컬 태그가 있어야 합니다.
- 상대 경로가 아닌 절대 URL(예: https://newdomain.com/page)을 사용합니다.
- 일관성을 유지합니다(소문자, 올바른 프로토콜 HTTPS, 후행 슬래시 규칙).
- 캐노니컬 태그는 HTML의 <head> 섹션에 있어야 합니다.
- 캐노니컬이 JavaScript 렌더링의 영향을 받지 않도록(즉, 원시 HTML에 존재하도록) 합니다.
- 검수:
- 새 사이트를 크롤링하고 누락되거나 잘못되었거나 충돌하는 캐노니컬 태그를 확인합니다.
- 캐노니컬 처리된 URL이 색인 가능하고 200 상태 코드를 반환하는지(404 또는 리다이렉션이 아님) 확인합니다.
- 캐노니컬 체인(A가 B를 가리키고, B가 C를 가리킴)을 피합니다. A가 C를 직접 가리키도록 합니다.
- 캐노니컬과 리다이렉션을 충돌하는 방식으로 혼합하지 마십시오(예: 페이지 A가 B로 캐노니컬 처리되지만 B는 A로 리다이렉션됨).
- 네이버 컨텍스트: 네이버 가이드는 “새 사이트의 모든 페이지에 선호 URL(캐노니컬 URL)을 지정합니다. 이는 새 사이트의 검색 노출 URL이 이전 도메인으로 지정되는 것을 방지하는 역할을 합니다.”라고 구체적으로 언급합니다.
다국어 사이트의 경우 Hreflang 태그 관리 (해당 시)
- 목적: Hreflang 태그는 특정 잠재고객을 위한 페이지의 언어 및 지역 버전을 검색 엔진에 알립니다. 국제 SEO에 필수적입니다. 50
- 마이그레이션 고려 사항:
- 모든 hreflang 주석은 새 도메인 URL을 반영하도록 업데이트되어야 합니다.
- 양방향 링크(반환 태그)를 유지합니다. 페이지 A가 페이지 B를 대체 항목으로 링크하면 페이지 B도 페이지 A로 다시 링크해야 합니다.
- hreflang 태그에 절대 URL을 사용합니다.
- 자체 참조 hreflang 태그가 올바른지 확인합니다.
- x-default hreflang 태그는 새 도메인의 올바른 기본/대체 페이지를 가리켜야 합니다.
- 올바른 언어(ISO 639-1) 및 지역(ISO 3166-1 Alpha 2) 코드를 확인합니다.
- 구현 방법(HTML <head>, XML 사이트맵, HTTP 헤더)은 새 사이트에 일관되게 적용되어야 합니다.
- 검수 :
마이그레이션 후 hreflang 태그에 오류(누락된 반환 태그, 잘못된 코드, hreflang 주석 내 끊어진 링크)가 있는지 검수합니다. Sitebulb 또는 ahrefs나 SEMRUSH와 같은 도구가 도움이 될 수 있습니다.
테스트, 검증 및 모니터링
이 단계는 모든 것이 의도한 대로 작동하는지 확인하고 사용자나 SEO에 큰 영향을 미치기 전에 문제를 파악하는 것입니다. 출시 후 지속적인 모니터링 또한 매우 중요합니다.
리다이렉션 종합 테스트 전략
- 수동 샘플 테스트 (Manual Sample Testing)
- 이전 사이트에서 홈페이지, 주요 카테고리 페이지, 인기 제품/콘텐츠 페이지, 복잡한 URL 구조를 가진 페이지, 알려진 백링크가 있는 페이지 등 다양한 샘플 URL 목록을 만듭니다.
- 이러한 이전 URL을 브라우저에 수동으로 입력하고 다음을 확인합니다:
- 올바른 새 URL로 리다이렉션되는지 여부.
- 리다이렉션이 301인지 여부.
- 새 페이지가 올바르게 로드되고(200 OK) 예상 콘텐츠를 표시하는지 여부. 17
- 브라우저 개발자 도구 활용
- Network 탭:
- DevTools를 엽니다(F12 또는 마우스 오른쪽 버튼 클릭 > 검사). Network 탭으로 이동합니다.
- 리다이렉션 간 추적을 위해 “Preserve log”를 활성화합니다.
- 이전 URL을 입력하고 리다이렉션 체인을 관찰합니다.
- 리다이렉션된 요청을 클릭합니다. “Headers” 하위 탭에서 다음을 확인합니다:
- Status Code: 이전 URL의 경우 301, 최종 새 URL의 경우 200이어야 합니다.
- Response Headers > Location: 301의 경우 리다이렉션 대상 URL을 표시
- 다중 리다이렉션(체인) 또는 루프를 식별합니다.
- Console 탭:
- 새 사이트에서 리다이렉션 또는 페이지 로딩을 방해할 수 있는 JavaScript 오류 또는 기타 클라이언트 측 문제를 확인합니다. 60
- JavaScript를 통해 리다이렉션이 구현된 경우(주요 SEO 리다이렉션에는 권장되지 않음) 문제 진단에 유용합니다.
- Network 탭:
Chrome DevTools의 Network 탭에서 “Preserve log” 기능은 다단계 리다이렉션 체인을 정확하게 추적하거나 리다이렉션이 예기치 않게 쿼리 매개변수를 삭제하는 시점을 식별하는 데 필수적입니다. 이 기능이 없으면 전체 시퀀스를 보기 어렵습니다. 이 기능은 각 홉, 상태 코드 및 헤더를 볼 수 있게 해줍니다.
이는 301이 다른 곳으로 302 리다이렉션되는 URL로 리다이렉션되거나, 서버의 리다이렉션 로직(예: .htaccess의 정규식)이 이를 캡처하고 추가하도록 구성되지 않아(예: $request_uri 누락 또는 특정 쿼리 문자열 처리 누락) 중요한 UTM 매개변수를 제거하는 리다이렉션과 같은 문제를 진단하는 데 중요합니다.
- 자동화된 크롤링 도구(예: Screaming Frog, Sitebulb)를 이용한 대량 검증
- Screaming Frog:
- “List” 모드를 사용하여 이전 URL 목록을 업로드합니다.
- Spider 구성: Spider > Configuration > Advanced > “Always Follow Redirects” – 활성화.
- 목록을 크롤링합니다.
- “Response Codes” 탭을 확인하고 “Redirection (3xx)”으로 필터링합니다. 상태 코드(301이어야 함), 최종 상태 코드(200이어야 함) 및 최종 리다이렉션된 URL을 확인합니다.
- 체인, 유형 및 최종 대상에 대한 포괄적인 개요를 보려면 “All Redirects” 보고서를 내보냅니다.
- “Reports > Redirects > Redirect Chains”를 사용하여 체인 및 루프를 식별합니다.
- Sitebulb:
- URL 목록을 크롤링하거나 사이트 크롤링 중에 리다이렉션을 발견할 수도 있습니다.
- 리다이렉션 체인, 루프 및 끊어진 페이지로의 리다이렉션에 대한 보고서를 제공합니다.
- Sitebulb의 “Hints”는 리다이렉션 관련 문제를 알려줍니다.
- Screaming Frog:
- 명령줄 도구(예: cURL)를 이용한 헤더 검사 및 리다이렉션 추적
- curl은 HTTP 요청을 만드는 다용도 명령줄 도구입니다.
- 단일 URL 헤더 확인 (리다이렉션 추적 안 함):
Bash
curl -I http://olddomain.com/page.html
(헤더 표시, HTTP 상태 코드 포함. -I는 HEAD 요청 전송) - 리다이렉션 추적 및 각 홉 헤더 표시:
Bash
curl -I -L http://olddomain.com/page.html
(-L 또는 –location은 리다이렉션 추적. 헤더는 -I, 요청 및 응답 헤더를 포함한 자세한 정보는 -v와 함께 사용) - 상세 분석을 위한 자세한 출력:
Bash
curl -v -L http://olddomain.com/page.html - 추적할 리다이렉션 수 제한: –max-redirs <숫자>
리다이렉션 체인 및 루프 식별과 해결
- 리다이렉션 체인: URL A → URL B → URL C. 각 리다이렉션은 대기 시간을 추가하고 과도할 경우 링크 가치를 희석시킬 수 있습니다.
- 리다이렉션 루프: URL A → URL B → URL A. 사용자와 크롤러가 최종 페이지에 도달하는 것을 방해합니다.
- 식별 방법:
- Screaming Frog (“Redirect Chains” 보고서).
- Sitebulb. 64
- Chrome DevTools Network 탭 (수동 검사).
- Ayima Redirect Path와 같은 온라인 도구
- 해결 방법:
- 내부 링크를 최종 대상 URL로 직접 연결하도록 업데이트합니다.
- 초기 URL에서 최종 표준 URL로 직접 연결되도록 서버 측 리다이렉션 규칙을 수정합니다(예: A → B → C 대신 A → C)
- 체인/루프의 일반적인 원인을 피하기 위해 URL 구조(HTTP/HTTPS, WWW/non-WWW, 후행 슬래시)의 일관성을 보장합니다.
새 사이트의 내부 링크 업데이트 확인
- 새 사이트의 모든 내부 링크(탐색, 본문 콘텐츠, 바닥글 등)는 이전 도메인의 URL이 아닌 새 도메인의 URL을 가리켜야 합니다. 8
- 리다이렉션되는 이전 URL로 연결하면 불필요한 서버 부하가 추가되고 사용자 경험 및 크롤링 효율성이 저하될 수 있습니다. 8
- 확인 방법:
- Screaming Frog 또는 Sitebulb로 새 사이트를 크롤링합니다.
- 이전 도메인을 가리키거나 내부 리다이렉션을 유발하는 내부 아웃링크가 있는지 확인합니다.
- 발견된 링크는 새 사이트의 올바른 최종 URL로 직접 수정합니다.
- 데이터베이스 검색 및 바꾸기 스크립트나 플러그인(CMS 사용 시)을 사용하여 대량 업데이트를 수행할 수 있지만, 주의해서 사용하고 백업 후 테스트해야 합니다.
SSL 인증서 유효성 검사 (Validating SSL Certificate)
- 새 도메인에 SSL 인증서가 올바르게 설치되고 구성되었는지 확인합니다.
- 브라우저에서 HTTPS로 접속 시 경고가 없는지, 자물쇠 아이콘이 올바르게 표시되는지 확인합니다.
- 온라인 SSL 검사 도구(예: SSL Labs SSL Test)를 사용하여 인증서 체인, 프로토콜 지원, 알려진 취약점 등을 종합적으로 점검합니다.
- 혼합 콘텐츠(HTTPS 페이지 내 HTTP 리소스 로드) 오류가 없는지 확인합니다. 이는 브라우저에서 보안 경고를 유발할 수 있습니다. Chrome DevTools의 Console 탭에서 혼합 콘텐츠 오류를 확인할 수 있습니다.
마이그레이션 후 SEO 성능 모니터링
- Google Search Console 및 Naver Search Advisor 활용
- 색인 상태 모니터링
- GSC: “색인 생성 > 페이지” 보고서를 통해 새 도메인의 페이지가 얼마나 색인되었는지, 오류는 없는지 확인합니다. “URL 검사” 도구를 사용하여 특정 URL의 색인 상태를 확인할 수 있습니다.
- Naver Search Advisor: “리포트 > 수집 현황”, “리포트 > 색인 현황” 메뉴를 통해 유사한 정보를 확인합니다. “검증 > URL 검사” 기능을 사용할 수 있습니다.
- 크롤링 오류 확인
- GSC: “색인 생성 > 페이지” 보고서 내 “색인이 생성되지 않은 이유” 섹션에서 404 오류, 서버 오류 등을 확인하고 해결합니다.
- Naver Search Advisor: “리포트 > 사이트 진단”에서 오류 정보를 확인하거나, “요청 > 웹 페이지 수집” 결과에서 수집 실패 사유를 확인합니다.
- 사이트맵 처리 상태
- GSC 및 Naver Search Advisor 모두에서 제출한 새 사이트맵이 오류 없이 처리되었는지, 포함된 URL 수가 예상과 일치하는지 확인합니다.
- 보안 문제 및 수동 조치
- GSC의 “보안 및 수동 조치” 섹션을 정기적으로 확인하여 문제가 없는지 확인합니다.
- 색인 상태 모니터링
- 웹 분석 도구(예: Google Analytics 4)를 통한 트래픽 변화 추이 분석
- 키워드 순위 변동 모니터링 (Monitoring Keyword Ranking Fluctuations)
- 주요 타겟 키워드들의 순위 변화를 마이그레이션 전후로 꾸준히 추적합니다. Semrush, Ahrefs와 같은 SEO 도구나 자체 순위 추적 시스템을 활용합니다. 68
- 순위 하락이 감지되면 해당 페이지의 리다이렉션, 콘텐츠, 기술적 문제 등을 점검합니다.
리다이렉션 적용 후 이관 작업 완료까지의 평균 소요 시간
사이트 이전 후 검색엔진이 새 도메인을 완전히 인지하고 이전 사이트의 SEO 평가를 새 사이트로 이전하는 데 걸리는 시간은 여러 요인에 따라 크게 달라집니다. 일반적으로 몇 주에서 몇 달이 소요될 수 있습니다.
- 영향 요인
- 사이트 규모 및 복잡성
URL 수가 많고 구조가 복잡한 대규모 사이트는 소규모 사이트보다 재색인 및 평가에 더 오랜 시간이 걸립니다. - 301 리다이렉션의 정확성 및 완전성
모든 중요 페이지가 정확하게 1:1로 301 리다이렉션되었는지 여부가 중요합니다. 누락되거나 잘못된 리다이렉션은 시간을 지연시킵니다. - 서버 속도 및 응답 시간
새 서버의 속도가 빠르고 안정적이어야 검색엔진 크롤러가 효율적으로 사이트를 탐색하고 색인할 수 있습니다. - 크롤링 예산
검색엔진은 각 사이트에 할당된 크롤링 예산 내에서 페이지를 수집합니다. 사이트가 크거나 기술적 문제가 있으면 크롤링이 지연될 수 있습니다. - XML 사이트맵 제출 및 robots.txt 설정
정확한 사이트맵 제출과 올바른 robots.txt 설정은 검색엔진이 새 사이트 구조를 이해하는 데 도움을 줍니다. - 내부 링크 구조
새 사이트 내의 내부 링크가 모두 새 URL로 업데이트되어 있어야 합니다. - 외부 백링크 업데이트
중요한 백링크 소스에 연락하여 링크를 새 URL로 업데이트하도록 요청하면 도움이 될 수 있지만, 필수적인 것은 아닙니다. 301 리다이렉션이 링크 가치를 전달합니다. - 검색엔진의 처리 속도
Google, Naver 등 각 검색엔진의 내부적인 처리 속도도 영향을 미칩니다. Google은 일반적으로 몇 주 내에 대부분의 페이지 이동을 처리하지만, 대형 사이트는 더 오래 걸릴 수 있습니다. Naver는 “품질 지수” 이전에 시간이 걸린다고 명시합니다.
- 사이트 규모 및 복잡성
- 일반적인 타임라인 추정
- 초기 발견 및 크롤링
며칠에서 1~2주. 검색엔진이 새 도메인과 리다이렉션을 인지하기 시작합니다. - 색인 업데이트
몇 주. 새 URL이 점진적으로 색인에 반영되고 이전 URL은 색인에서 제외되기 시작합니다. GSC의 “주소 변경 도구” 사용 시 Google은 새 사이트 크롤링을 우선시합니다. - 랭킹 안정화 및 SEO 평가 이전
몇 주에서 몇 달. 검색엔진이 새 사이트의 콘텐츠와 기술적 요소를 완전히 평가하고 이전 사이트의 신호(링크 가치 등)를 새 사이트로 이전하는 데 시간이 걸립니다. 이 기간 동안 순위 변동이 있을 수 있습니다. 23 Google은 301 리다이렉션으로 인한 PageRank 손실은 없다고 밝혔습니다.
- 초기 발견 및 크롤링
사이트 이전은 단기적인 작업이 아니며, 이전 후에도 지속적인 모니터링과 최적화 노력이 필요합니다. 특히 대규모 사이트의 경우, 모든 URL이 재색인되고 순위가 안정화되기까지 3~6개월 이상 소요될 수도 있습니다. 90
정리 & 핵심 권장 사항
웹사이트를 새 도메인으로 성공적으로 이전하고 SEO 가치를 보존하기 위해서는 철저한 계획, 정확한 기술적 실행, 그리고 지속적인 모니터링이 필수적입니다.
핵심 권장 사항:
- 사전 준비 철저:
- 이전 최소 24-48시간 전에 DNS 레코드의 TTL 값을 낮추어 변경 사항의 신속한 전파를 유도합니다.
- 새 도메인에 대한 SSL 인증서를 미리 준비하고, HTTPS 환경을 일관되게 유지합니다.
- 이전할 모든 URL 목록과 새 URL 목록을 준비하여 1:1 URL 매핑 계획을 수립합니다. 대규모 사이트의 경우 AI 기반 URL 매핑 도구를 보조적으로 활용하되, 반드시 수동 검증을 거칩니다.
- 301 영구 리다이렉션의 정확한 구현:
- 모든 이전 URL에서 새 해당 URL로 서버 수준의 301 영구 리다이렉션을 설정합니다. 이는 SEO 가치 이전에 가장 중요합니다.
- Apache, Nginx, IIS 등 사용하는 서버 환경에 맞는 정확한 리다이렉션 규칙을 적용합니다.
- 리다이렉션 시 경로와 쿼리 파라미터가 올바르게 유지되는지 확인합니다.
- 검색엔진에 이전 알림:
- Google Search Console에서 새 도메인을 확인하고, “주소 변경 도구”를 사용하여 이전을 알립니다.
- Naver Search Advisor에 새 도메인을 등록하고, 웹 페이지 재수집 요청 및 수집 주기 조정을 통해 변경 사항을 알립니다.
- 두 검색엔진 모두에 새 도메인의 XML 사이트맵을 제출합니다.
- 기술적 SEO 요소 점검:
- 새 도메인의 robots.txt 파일이 검색엔진 크롤링을 올바르게 허용/차단하는지 확인합니다.
- 새 사이트의 모든 페이지에 올바른 자체 참조 표준(canonical) 태그가 설정되어 있는지 확인합니다.
- 다국어 사이트의 경우 hreflang 태그가 새 URL을 정확히 반영하도록 업데이트합니다.
- 철저한 테스트 및 검증:
- 브라우저 개발자 도구(특히 Network 탭), Screaming Frog과 같은 크롤링 도구, cURL 명령어 등을 활용하여 모든 리다이렉션이 301 상태 코드로 올바른 대상 URL로 작동하는지, 리다이렉션 체인이나 루프는 없는지 철저히 테스트합니다.
- 새 사이트의 내부 링크가 모두 새 도메인 URL을 가리키도록 업데이트되었는지 확인합니다.
- 지속적인 모니터링:
- 마이그레이션 후 최소 180일 동안, 또는 이전 URL로의 유의미한 트래픽이 사라질 때까지 301 리다이렉션을 유지합니다.
- Google Search Console, Naver Search Advisor, 웹 분석 도구(GA4 등)를 통해 새 사이트의 색인 상태, 크롤링 오류, 트래픽 변화, 키워드 순위 변동을 지속적으로 모니터링하고 문제 발생 시 신속하게 대응합니다. (본문 V.E 참조)
도메인 이전은 복잡하고 신중을 기해야 하는 작업입니다. 본 매뉴얼에 제시된 절차와 권장 사항을 따르면, 웹사이트 이전으로 인한 부정적인 영향을 최소화하고 안정적으로 새 도메인에서 서비스를 이어갈 수 있을 것입니다. 예상되는 이전 완료 시간은 사이트의 규모와 복잡성에 따라 다르지만, 검색엔진이 변경 사항을 완전히 처리하고 순위가 안정화되기까지는 수 주에서 수개월이 소요될 수 있음을 인지하고 장기적인 관점에서 접근해야 합니다.
레퍼런스 사이트 & 문서 목록
딥 리서치 인용 자료
- Differences Among A, CNAME, ALIAS, and URL records – DNSimple Help, 5월 19, 2025에 액세스, https://support.dnsimple.com/articles/differences-between-a-cname-alias-url/
- DNS TTL Values: Tutorial & Best Practices – Catchpoint, 5월 19, 2025에 액세스, https://www.catchpoint.com/dns-monitoring/dns-ttl
- CNAME or Redirect? – DNS Made Easy Blog, 5월 19, 2025에 액세스, https://dnsmadeeasy.com/post/cname-or-redirect
- Exploring CNAME & Alias DNS Records – Key Differences | Gcore, 5월 19, 2025에 액세스, https://gcore.com/learning/differences-between-cname-and-alias
- What is an ALIAS Record? Simplify Root Domain Setup – ClouDNS, 5월 19, 2025에 액세스, https://www.cloudns.net/wiki/article/18/
- How to set up a URL redirect for a domain – Namecheap, 5월 19, 2025에 액세스, https://www.namecheap.com/support/knowledgebase/article.aspx/385/2237/how-to-set-up-a-url-redirect-for-a-domain/
- Forward my GoDaddy domain, 5월 19, 2025에 액세스, https://www.godaddy.com/help/forward-my-godaddy-domain-12123
- Domain Forwarding & Redirection: How to Preserve SEO Rankings …, 5월 19, 2025에 액세스, https://www.namesilo.com/blog/en/marketing-tips/domain-forwarding–redirection-how-to-preserve-seo-rankings
- 301 Redirect: A Comprehensive Guide to 301 Redirects & SEO, 5월 19, 2025에 액세스, https://victorious.com/blog/301-redirects/
- What Is a 301 Redirect? + How They Affect SEO – Semrush, 5월 19, 2025에 액세스, https://www.semrush.com/blog/301-redirects/
- Guide to 301 Redirects Using The .htaccess File | Fhoke, 5월 19, 2025에 액세스, https://www.fhoke.com/htaccess-301-redirect/
- Everything you Need to Know about Link and Domain Masking – Bluehost, 5월 19, 2025에 액세스, https://www.bluehost.com/blog/everything-you-need-to-know-about-url-masking/
- What is Domain Masking? Impact On SEO Ranking | UltaHost Blog, 5월 19, 2025에 액세스, https://ultahost.com/blog/what-is-domain-masking/
- Website Migration Checklist for SEO: 14 Important Steps to Take …, 5월 19, 2025에 액세스, https://www.wpdownloadmanager.com/website-migration-checklist-for-seo-14-important-steps-to-take/
- Website Migration Checklist – Move Your Site Safely – Bluehost, 5월 19, 2025에 액세스, https://www.bluehost.com/blog/essential-website-migration-checklist-for-safe-site-transfer/
- Redirect Checker – DNS Propagation Checker, 5월 19, 2025에 액세스, https://www.whatsmydns.net/redirect-checker
- Redirects 101: A Beginner’s Guide to Setup & Best Practices – Backlinko, 5월 19, 2025에 액세스, https://backlinko.com/redirects
- htaccess redirect: how do I 301 redirect URLs on Apache? – Conductor, 5월 19, 2025에 액세스, https://www.conductor.com/academy/redirects/faq/htaccess/
- A Guide on Setting Up 301 Redirects in the htaccess and web.config …, 5월 19, 2025에 액세스, https://hostpro.com/billing/index.php?rp=/knowledgebase/28/A-Guide-on-Setting-Up-301-Redirects-in-the-htaccess-and-web.config.-Files.html
- Nginx Redirect · GitHub, 5월 19, 2025에 액세스, https://gist.github.com/esfand/8246661
- How To Setup A NGINX 301 Redirect, 5월 19, 2025에 액세스, https://resources.twiz.io/article/nginx-301-redirect
- 301 Redirect for IIS – Stack Overflow, 5월 19, 2025에 액세스, https://stackoverflow.com/questions/9041592/301-redirect-for-iis
- Site Moves and Migrations | Google Search Central | Documentation, 5월 19, 2025에 액세스, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- The Ultimate SEO Guide to Redirects and Error Handling – Market Brew, 5월 19, 2025에 액세스, https://marketbrew.ai/the-ultimate-seo-guide-to-redirects-and-error-handling
- 12 site migration mistakes that damage SEO | Embryo, 5월 19, 2025에 액세스, https://embryo.com/blog/12-site-migration-mistakes-that-damage-seo/
- Redirect mapping for a site migration – Elixirr Digital, 5월 19, 2025에 액세스, https://www.elixirrdigital.com/2020/08/26/redirect-mapping-for-a-site-migration/
- SEO Website Migration Checklist for 2025 | Step-by-Step Guide, 5월 19, 2025에 액세스, https://www.techmagnate.com/blog/website-migration-checklist/
- How to speed up site migrations with AI-powered redirect mapping …, 5월 19, 2025에 액세스, https://paidsearch.org/how-to-speed-up-site-migrations-with-ai-powered-redirect-mapping/
- Free URL Redirect Mapping Tool for Website Migrations | URL Matcher – Growthack Digital, 5월 19, 2025에 액세스, https://growthackdigital.com/tools/url-redirect-matcher-tool-for-website-migrations/
- How Machine Learning Automates Source-to-Target mapping – Kanerika, 5월 19, 2025에 액세스, https://kanerika.com/blogs/source-to-target-mapping/
- URL Redirect Mapping with Python for Website Migrations, 5월 19, 2025에 액세스, https://stringerseo.co.uk/technical/seo-migration-automate-url-mapping-with-python/
- Ultimate Guide To Text Similarity With Python | NewsCatcher, 5월 19, 2025에 액세스, https://www.newscatcherapi.com/blog/ultimate-guide-to-text-similarity-with-python
- Website Migration Analyser & Quoting Tool ⚡️ – Rapid301, 5월 19, 2025에 액세스, https://www.rapid301.com/website-migration-analysis-tool
- What Steps Should You Follow in GSC Before Initiating a Change of Address?, 5월 19, 2025에 액세스, https://library.linkbot.com/what-steps-should-you-follow-in-gsc-before-initiating-a-change-of-address/
- Submitting your sitemap to Google Search Console: A step-by-step guide | Web Community, 5월 19, 2025에 액세스, https://webcommunity.sites.uiowa.edu/submitting-your-sitemap-google-search-console-guide
- Change of Address Tool – Search Console Help, 5월 19, 2025에 액세스, https://support.google.com/webmasters/answer/9370220?hl=en
- Build and Submit a Sitemap | Google Search Central | Documentation, 5월 19, 2025에 액세스, https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
- How to use Naver Search Advisor: A full Guide 2025 updated, 5월 19, 2025에 액세스, https://www.interad.com/en/insights/naver-search-advisor-a-full-guide
- How to do Naver SEO – factors and checklists to rank in Korea – Punch Digital Marketing, 5월 19, 2025에 액세스, https://punchkorea.com/how-to-do-naver-seo-factors-and-checklists-to-rank-in-korea/
- 웹 사이트 이전 – 네이버 서치어드바이저, 5월 19, 2025에 액세스, https://searchadvisor.naver.com/guide/seo-basic-migration
- 네이버 검색창에 사이트 등록하기(네이버 웹마스터도구) – 가비아커머스 자주하는 질문, 5월 19, 2025에 액세스, https://www.gabiacns.com/customer/faq/450086242/
- 사이트 정보 재수집 요청 및 수집주기 변경하기 ( 네이버 검색노출), 5월 19, 2025에 액세스, https://help.campaignus.me/ko/articles/%EC%82%AC%EC%9D%B4%ED%8A%B8-%EC%A0%95%EB%B3%B4-%EC%9E%AC%EC%88%98%EC%A7%91-%EC%9A%94%EC%B2%AD-%EB%B0%8F-%EC%88%98%EC%A7%91%EC%A3%BC%EA%B8%B0-%EB%B3%80%EA%B2%BD%ED%95%98%EA%B8%B0–%EB%84%A4%EC%9D%B4%EB%B2%84–%EA%B2%80%EC%83%89%EB%85%B8%EC%B6%9C-f050d111
- 사이트 정보 재수집 요청 및 수집주기 변경하기 – 아임웹, 5월 19, 2025에 액세스, https://imweb.me/faq?mode=view&category=29&category2=35&idx=71376
- 네이버 서치어드바이저 도구 수집설정 변경하기 : 애드리빙 – 관리페이지 개요, 5월 19, 2025에 액세스, https://appsweb.kr/2435/?bmode=view&idx=3665406
- Search engine optimization (SEO) in South Korea: Naver vs. Google and comprehensive content strategies – Xpert.Digital, 5월 19, 2025에 액세스, https://xpert.digital/en/search-engine-optimization-in-suedkorea/
- Robots.txt File: A Beginners Guide – Hike SEO, 5월 19, 2025에 액세스, https://www.hikeseo.co/learn/technical/robots-txt
- How to Avoid Multiple Page Redirects For a Fast WordPress Site, 5월 19, 2025에 액세스, https://nitropack.io/blog/post/how-to-avoid-multiple-page-redirects
- Guide to Canonical Tags & How to Audit Them | Sitebulb, 5월 19, 2025에 액세스, https://sitebulb.com/resources/guides/full-guide-to-the-canonical-tag/
- A Complete Guide To Canonical Tags In SEO, 5월 19, 2025에 액세스, https://surferseo.com/blog/canonical-tags-in-seo/
- What Is Hreflang and How To Implement It the Right Way in 2025 – Backlinko, 5월 19, 2025에 액세스, https://backlinko.com/hreflang-tag
- Hreflang Tags for Multilingual SEO: Best Practices for E-commerce Websites – Next Basket, 5월 19, 2025에 액세스, https://nextbasket.com/the-impact-of-hreflang-tags-on-multilingual-seo-best-practices/
- What Is Hreflang and How To Implement It the Right Way in 2025, 5월 19, 2025에 액세스, https://backlinko.com/hreflang-tag/
- Hreflang Checker for International SEO Validation – Sitebulb, 5월 19, 2025에 액세스, https://sitebulb.com/product/international/
- How to track the Redirect Path of a URL in DevTools – SEOSLY, 5월 19, 2025에 액세스, https://seosly.com/blog/how-to-track-the-redirect-path-of-a-url-in-devtools/
- How to track the redirect path of a URL in DevTools – YouTube, 5월 19, 2025에 액세스, https://www.youtube.com/watch?v=vCeIQTm0MEE&pp=0gcJCfcAhR29_xXO
- Chrome Developer Tools – Network Tab – Requestly, 5월 19, 2025에 액세스, https://requestly.com/blog/chrome-developer-tools-network-tab/
- Inspect network activity | Chrome DevTools, 5월 19, 2025에 액세스, https://developer.chrome.com/docs/devtools/network
- www.matthewedgar.net, 5월 19, 2025에 액세스, https://www.matthewedgar.net/http-response-status/#:~:text=Check%20HTTP%20Status%20Code%20in%20Google%20Chrome%20DevTools&text=To%20load%20DevTools%2C%20before%20opening,clicking%20%E2%80%9C%3E%3E%E2%80%9D.)
- How to view HTTP headers in Google Chrome? – Mkyong.com, 5월 19, 2025에 액세스, https://mkyong.com/computer-tips/how-to-view-http-headers-in-google-chrome/
- Using the DevTools Console in Google Chrome to Identify Errors, 5월 19, 2025에 액세스, https://help.interplaylearning.com/en/help/using-the-console-in-google-chrome-to-identify-errors
- Browser console shows DevTools failed to load SourceMap warning message In Jira, 5월 19, 2025에 액세스, https://support.atlassian.com/jira/kb/browser-console-shows-devtools-failed-to-load-sourcemap-warning-message-in-jira/
- How To Audit Redirects In A Site Migration Using The SEO Spider …, 5월 19, 2025에 액세스, https://www.screamingfrog.co.uk/seo-spider/tutorials/audit-redirects/
- How To Bulk Check Redirects – Screaming Frog, 5월 19, 2025에 액세스, https://www.screamingfrog.co.uk/seo-spider/tutorials/redirect-checker/
- Redirects – Sitebulb, 5월 19, 2025에 액세스, https://sitebulb.com/hints/redirects/
- Redirect Chains: How You Can Identify, Fix & Prevent for SEO – Hike …, 5월 19, 2025에 액세스, https://www.hikeseo.co/learn/technical/redirect-chains
- How to Show HTTP Response Headers in cURL? – Oxylabs, 5월 19, 2025에 액세스, https://oxylabs.io/blog/curl-show-response-headers
- How to follow redirects using cURL – Apify Blog, 5월 19, 2025에 액세스, https://blog.apify.com/curl-follow-redirect/
- A Step-By-Step Blueprint To Migrate Your Blog Without Losing SEO – beehiiv Blog, 5월 19, 2025에 액세스, https://blog.beehiiv.com/p/a-step-by-step-blueprint-to-migrating-your-blog-without-losing-seo
- Broken links after moving wordpress site – Stack Overflow, 5월 19, 2025에 액세스, https://stackoverflow.com/questions/28624749/broken-links-after-moving-wordpress-site
- How to auto update the sharing URL after migrate SharePoint documents to a new domain, 5월 19, 2025에 액세스, https://learn.microsoft.com/en-us/answers/questions/1427620/how-to-auto-update-the-sharing-url-after-migrate-s
- Google Search Console’s Page Indexing Statuses Explained – Lyrical Host, 5월 19, 2025에 액세스, https://www.lyricalhost.com/blog/google-search-consoles-page-indexing-statuses-explained/
- Page Indexing report – Search Console Help, 5월 19, 2025에 액세스, https://support.google.com/webmasters/answer/7440203?hl=en
- Google Search Console을 사용하여 웹 사이트 검색 노출시키기 – velog, 5월 19, 2025에 액세스, https://velog.io/@mzhong/%EB%82%B4%EA%B0%80-%EB%A7%8C%EB%93%A0-%EC%9B%B9%EC%82%AC%EC%9D%B4%ED%8A%B8-%EA%B2%80%EC%83%89-%EC%97%94%EC%A7%84%EC%97%90-%EB%85%B8%EC%B6%9C-%EC%8B%9C%ED%82%A4%EA%B8%B0
- How long does SEO for site migration take? – AUQ.io, 5월 19, 2025에 액세스, https://auq.io/knowledge-base/how-long-does-seo-for-site-migration-take/
- What Is Google Analytics 4 and Why Should You Migrate? – RudderStack, 5월 19, 2025에 액세스, https://www.rudderstack.com/learn/GA4/what-is-google-analytics-4-and-why-should-you-migrate/
- Google Analytics Migration – 10 Steps to Success – MeasureU, 5월 19, 2025에 액세스, https://measureu.com/google-analytics-4-migration/
- [GA4] Identify unwanted referrals – Analytics Help – Google Help, 5월 19, 2025에 액세스, https://support.google.com/analytics/answer/10327750?hl=en
- GA4 Migration Guide – Sphere Partners, 5월 19, 2025에 액세스, https://www.sphereinc.com/blogs/ga4-migration-guide/
- Referral Exclusions on GA4 | Analyzify Docs, 5월 19, 2025에 액세스, https://docs.analyzify.com/referral-exclusions-on-ga4
- How to add a referral exclusion list in GA4 – Littledata Help Center, 5월 19, 2025에 액세스, https://help.littledata.io/posts/add-referral-exclusion-list-ga4
- GA4 Annotations in 2025 — Everything You Need to Know | GA4 Help – Fresh Egg, 5월 19, 2025에 액세스, https://www.freshegg.co.uk/blog/ga4-annotations-in-2025-everything-you-need-to-know/
- Annotations in GA4: A Guide to Tracking Changes and Insights – Weberlo, 5월 19, 2025에 액세스, https://www.weberlo.com/blog/annotations-in-ga4
- Google Analytics 4 Comparisons – How to use them?, 5월 19, 2025에 액세스, https://www.analyticsmania.com/post/google-analytics-4-comparisons-how-to-use-them/
- GA4 Advanced Segments: Make Comparisons More Useful – Two Octobers, 5월 19, 2025에 액세스, https://twooctobers.com/blog/ga4-advanced-segments-make-comparisons-more-useful/
- [GA4] Apply comparisons to reports – Analytics Help, 5월 19, 2025에 액세스, https://support.google.com/analytics/answer/9269518?hl=en
- Free Keyword Rank Checker Monitor Google Rankings – Backlinko, 5월 19, 2025에 액세스, https://backlinko.com/tools/rank-checker
- Free Keyword Rank Checker Monitor Google Rankings – Backlinko, 5월 19, 2025에 액세스, https://backlinko.com/tools/rank-checker/
- Website Indexing 101: How to Get Your Site Indexed – SEO.com, 5월 19, 2025에 액세스, https://www.seo.com/basics/how-search-engines-work/indexing/
- How long does it take for google to index your pages? : r/SEO – Reddit, 5월 19, 2025에 액세스, https://www.reddit.com/r/SEO/comments/1akfbli/how_long_does_it_take_for_google_to_index_your/
- How Long Does An SEO Site Migration Take? Mastering Timelines …, 5월 19, 2025에 액세스, https://nav43.com/blog/how-long-does-an-seo-site-migration-take/