SEO 도메인 설정 완벽 가이드: www와 non-www 차이점과 통일이 중요한 이유
목록으로최초 발행: 2025년 11월 27일 오전 05:26|최종 수정: 2025년 11월 27일 오전 09:16
SEO 도메인 설정 완벽 가이드: www와 non-www 차이점과 통일이 중요한 이유
웹사이트 주소를 입력할 때 www.naver.com과 naver.com 중 어떤 것을 사용하시나요? 대부분의 사용자는 이 둘을 같은 주소로 인식합니다. 브라우저에 어떤 형태로 입력해도 같은 페이지가 열리기 때문입니다.
하지만 검색 엔진의 관점에서 이 두 주소는 완전히 다른 웹사이트입니다. 마치 서울시 강남구 역삼동 123번지와 서울시 강남구 역삼동 123-1번지가 다른 주소인 것처럼, www.example.com과 example.com은 기술적으로 별개의 주소입니다. 이 차이를 이해하지 못하고 방치하면 검색 순위 하락, 트래픽 분산, 사용자 경험 저하 등 심각한 문제가 발생합니다.
이 문서에서는 www와 non-www의 기술적 차이를 명확히 설명하고, 왜 하나로 통일해야 하는지, 어떻게 설정해야 하는지를 다양한 사례와 함께 상세히 다룹니다.
- 이 포스팅의 시작 - AI 의 이 질문 때문에 공부하게 되다
1. www와 non-www의 기술적 차이 이해하기
1) 도메인 구조의 기본 개념
도메인은 계층 구조로 이루어져 있습니다. 오른쪽에서 왼쪽으로 읽으면 최상위 도메인(TLD)부터 하위 도메인까지 순서대로 나타납니다.
www.example.com을 분해하면:
- .com → 최상위 도메인 (Top-Level Domain, TLD)
- example → 2차 도메인 (Second-Level Domain)
- www → 서브도메인 (Subdomain)
여기서 핵심은 www가 서브도메인이라는 점입니다. blog.example.com, shop.example.com처럼 www도 하나의 서브도메인입니다. 역사적으로 World Wide Web 서비스를 구분하기 위해 www라는 접두어를 붙였던 관습이 지금까지 이어진 것입니다.
반면 example.com은 루트 도메인(Root Domain) 또는 에이펙스 도메인(Apex Domain)이라고 부릅니다. 서브도메인이 붙지 않은 기본 형태입니다.
2) DNS 레벨에서의 차이
DNS(Domain Name System)는 도메인 이름을 IP 주소로 변환하는 시스템입니다. www와 non-www는 DNS에서 서로 다른 레코드로 관리됩니다.
DNS 레코드 예시:
example.com A 93.184.216.34 (루트 도메인)
www.example.com A 93.184.216.34 (www 서브도메인)
또는
www.example.com CNAME example.com (루트 도메인을 참조)
같은 IP 주소를 가리키더라도 DNS 입장에서는 별개의 레코드입니다. 마치 같은 건물에 정문과 후문이 있는 것처럼, 두 도메인은 같은 서버로 연결되지만 입구가 다릅니다.
3) 브라우저와 서버의 처리 방식
사용자가 브라우저에 주소를 입력하면 다음과 같은 과정이 진행됩니다.
1. 사용자가 www.example.com 입력
2. 브라우저가 DNS 서버에 www.example.com의 IP 주소 요청
3. DNS 서버가 IP 주소 반환
4. 브라우저가 해당 IP의 서버에 HTTP 요청 전송
5. 요청 헤더에 Host: www.example.com 포함
6. 서버가 요청을 받아 응답 사용자가 example.com 입력하면:
1. 사용자가 example.com 입력
2. 브라우저가 DNS 서버에 example.com의 IP 주소 요청
3. DNS 서버가 IP 주소 반환
4. 브라우저가 해당 IP의 서버에 HTTP 요청 전송
5. 요청 헤더에 Host: example.com 포함
6. 서버가 요청을 받아 응답
서버는 Host 헤더를 보고 어떤 도메인으로 접속했는지 구분합니다. 별도 설정이 없으면 두 요청을 각각 독립적으로 처리합니다.
2. 검색 엔진이 두 도메인을 다르게 인식하는 이유
1) URL 기반 페이지 식별 원리
검색 엔진 크롤러는 URL을 페이지의 고유 식별자로 사용합니다. 사람이 보기에 같은 페이지라도 URL이 다르면 별개의 페이지로 인식합니다.
검색 엔진이 인식하는 서로 다른 페이지들:
- https://www.example.com/about
- https://example.com/about
- http://www.example.com/about
- http://example.com/about
- https://www.example.com/about/
- https://example.com/about/ 위 6개는 모두 다른 페이지로 인식됨
이것은 검색 엔진의 한계가 아니라 의도적인 설계입니다. URL이 다르면 콘텐츠가 다를 수 있기 때문에 각각을 독립적으로 크롤링하고 인덱싱합니다.
2) 실제 사례로 보는 중복 인덱싱 문제
한 쇼핑몰 사이트를 예로 들어보겠습니다. 이 사이트는 www와 non-www를 모두 사용 가능하게 두었습니다.
Google 검색 결과:
"여성 원피스 추천" 검색 시
1위: www.shop.com/dress/women
3위: shop.com/dress/women 같은 페이지가 두 번 노출되며, 순위가 분산됨
더 심각한 문제는 Google이 어떤 버전을 표준으로 선택할지 예측할 수 없다는 것입니다. 사이트 소유자는 www 버전을 원하는데 Google이 non-www를 선택하면, 내부 링크 구조와 불일치가 발생합니다.
3) Googlebot의 크롤링 동작 방식
Googlebot은 발견한 모든 URL을 크롤링 대기열에 추가합니다. 외부 사이트에서 www.example.com/page로 링크를 걸고, 내부에서는 example.com/page로 링크를 걸면 두 URL 모두 크롤링합니다.
크롤링 시나리오:
1. Googlebot이 외부 사이트에서 www.example.com/page 발견
2. 해당 페이지 크롤링, 콘텐츠 인덱싱
3. 페이지 내부 링크에서 example.com/other 발견
4. example.com/other 크롤링
5. 이 페이지에서 example.com/page 발견
6. example.com/page 크롤링 (이미 www 버전 인덱싱됨)
7. 두 버전 모두 인덱스에 등록 결과: 같은 콘텐츠가 두 개의 URL로 인덱싱됨
3. 도메인 미통일이 초래하는 구체적인 피해
1) 링크 자산(Link Equity) 분산 현상
SEO에서 백링크는 다른 사이트가 보내는 신뢰 투표와 같습니다. 100개의 백링크가 있다면 100표를 받은 것입니다. 그런데 이 투표가 두 주소로 나뉘어 들어오면 문제가 됩니다.
백링크 분산 예시:
사이트 A → www.example.com/product (DA 50 사이트에서 링크)
사이트 B → example.com/product (DA 60 사이트에서 링크)
사이트 C → www.example.com/product (DA 40 사이트에서 링크)
사이트 D → example.com/product (DA 55 사이트에서 링크) www 버전: DA 50 + DA 40 = 90 포인트
non-www 버전: DA 60 + DA 55 = 115 포인트 통일했다면: 205 포인트 (하나의 URL에 집중)
실제로는 단순 합산이 아니지만, 링크 가치가 분산된다는 핵심은 동일합니다. 경쟁 사이트는 모든 링크를 하나의 URL로 받는데, 내 사이트만 절반씩 나뉘어 받으면 경쟁에서 불리해집니다.
2) 크롤링 예산 낭비와 인덱싱 지연
Google은 각 사이트에 크롤링 예산을 할당합니다. 대규모 사이트의 경우 모든 페이지를 매일 크롤링하지 못합니다.
크롤링 예산 시나리오:
사이트 페이지 수: 10,000개
일일 크롤링 예산: 5,000 페이지 www와 non-www 미통일 시:
- www 버전 페이지: 10,000개
- non-www 버전 페이지: 10,000개
- 총 크롤링 대상: 20,000개
- 실제 크롤링: 5,000개 (25%만 크롤링) 통일 시:
- 총 크롤링 대상: 10,000개
- 실제 크롤링: 5,000개 (50% 크롤링)
크롤링 예산이 낭비되면 새로운 콘텐츠나 업데이트된 콘텐츠가 인덱싱되기까지 시간이 오래 걸립니다. 뉴스나 트렌드에 민감한 콘텐츠라면 치명적인 문제입니다.
3) 사용자 경험과 신뢰도 저하
기술적인 문제 외에도 사용자 경험에 영향을 미칩니다.
시나리오 1: 쿠키 불일치
1. 사용자가 www.shop.com에서 로그인
2. 장바구니에 상품 추가
3. 친구가 보낸 shop.com/product 링크 클릭
4. 로그인 상태 유지 안 됨, 장바구니 비어있음
5. 사용자 혼란과 이탈 시나리오 2: 북마크 혼란
1. 사용자가 www.blog.com/article 북마크
2. 나중에 blog.com으로 접속
3. 같은 글을 다시 북마크 (중복 북마크)
4. 어떤 것이 맞는 주소인지 혼란 시나리오 3: 소셜 공유 분산
1. 사용자 A가 www.news.com/article 공유 (좋아요 50개)
2. 사용자 B가 news.com/article 공유 (좋아요 30개)
3. 같은 기사인데 소셜 시그널 분산
4. 바이럴 효과 감소
4. www와 non-www 중 무엇을 선택해야 하는가
1) non-www를 선택하는 현대적 트렌드
최근 대부분의 신생 웹서비스는 non-www를 표준으로 채택합니다. 대표적인 사례들을 살펴보겠습니다.
non-www 사용 서비스:
- github.com (개발자 플랫폼)
- notion.so (협업 도구)
- figma.com (디자인 도구)
- vercel.com (호스팅 플랫폼)
- stripe.com (결제 서비스)
- discord.com (커뮤니케이션)
non-www를 선호하는 이유는 다음과 같습니다.
- 짧고 간결함: 타이핑이 빠르고 기억하기 쉬움
- 모바일 친화적: 작은 화면에서 URL이 덜 잘림
- 현대적 이미지: 기술 지향적이고 세련된 느낌
- DNS 설정 단순화: CNAME 레코드 제약 없음 (루트 도메인 특성)
2) www를 유지하는 것이 나은 경우
반면 www를 사용하는 것이 더 적절한 상황도 있습니다.
www 사용 서비스:
- www.apple.com (글로벌 기업)
- www.amazon.com (이커머스 대기업)
- www.bbc.com (전통 미디어)
- www.nytimes.com (신문사)
www를 유지하는 이유는 다음과 같습니다.
- 브랜드 일관성: 수십 년간 쌓아온 브랜드 인지도
- 레거시 백링크: 이미 www로 수백만 개의 백링크 축적
- 쿠키 관리 유연성: 서브도메인 간 쿠키 공유 제어 용이
- CDN 설정: 일부 CDN은 루트 도메인보다 www에서 더 유연함
3) 선택 기준 체크리스트
어떤 버전을 선택할지 결정할 때 다음 질문에 답해보세요.
신규 사이트인 경우:
☐ 짧고 현대적인 URL을 원하는가? → non-www
☐ 전통적이고 신뢰감 있는 URL을 원하는가? → www
☐ 서브도메인을 많이 사용할 계획인가? → www (쿠키 관리 용이)
☐ 기술 스타트업 이미지를 원하는가? → non-www 기존 사이트인 경우:
☐ 현재 백링크가 어느 버전에 더 많은가? → 해당 버전 유지
☐ Google Search Console에서 어느 버전이 인덱싱되어 있는가? → 해당 버전 유지
☐ 현재 트래픽이 어느 버전으로 더 많이 들어오는가? → 해당 버전 유지
핵심은 어떤 것을 선택하든 하나로 통일하는 것입니다. www와 non-www 중 선택은 취향이지만, 통일하지 않는 것은 SEO 실수입니다.
5. 301 리다이렉트를 활용한 도메인 정규화 구현
1) 301 리다이렉트의 작동 원리
301 리다이렉트는 "이 주소는 영구적으로 다른 주소로 이동했다"고 선언하는 HTTP 상태 코드입니다.
301 리다이렉트 흐름:
1. 사용자가 www.example.com/page 접속
2. 서버가 301 응답 + Location: https://example.com/page 헤더 반환
3. 브라우저가 자동으로 example.com/page로 이동
4. 사용자에게는 순간적으로 URL이 바뀌는 것만 보임 HTTP 응답 예시:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/page
301의 핵심 특징은 검색 엔진에게 "링크 자산을 새 URL로 전달하라"고 지시한다는 것입니다. 302(임시 이동)와 달리 301은 SEO 가치를 보존합니다.
2) 다양한 환경에서의 리다이렉트 설정
호스팅 환경에 따라 설정 방법이 다릅니다.
Apache (.htaccess):
RewriteEngine On
# www를 non-www로 리다이렉트
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]
Nginx:
server { server_name www.example.com; return 301 https://example.com$request_uri;
}
Vercel (vercel.json):
{ "redirects": [ { "source": "/:path*", "has": [{ "type": "host", "value": "www.example.com" }], "destination": "https://example.com/:path*", "permanent": true } ]
}
Next.js 미들웨어:
// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server'; export function middleware(request: NextRequest) { const hostname = request.nextUrl.hostname; if (hostname === 'www.example.com') { const url = request.nextUrl.clone(); url.hostname = 'example.com'; return NextResponse.redirect(url, { status: 301 ; } return NextResponse.next();
}
3) 리다이렉트 설정 후 검증 방법
설정이 올바르게 되었는지 확인하는 방법입니다.
# curl 명령어로 확인
curl -I https://www.example.com # 예상 응답:
HTTP/2 301
location: https://example.com/ # 리다이렉트 체인 전체 확인
curl -ILs https://www.example.com | grep -E "HTTP|location"
온라인 도구를 사용할 수도 있습니다.
- httpstatus.io: 리다이렉트 체인 시각화
- redirect-checker.org: 상세 리다이렉트 분석
6. SITE_CONFIG를 활용한 중앙 집중식 URL 관리
1) 하드코딩의 문제점
대규모 웹사이트에서는 URL이 수백 곳에서 사용됩니다. 이를 각각 하드코딩하면 유지보수가 어려워집니다.
// ❌ 하드코딩 예시 (나쁜 방식) // 파일 1: app/page.tsx
export const metadata = { openGraph: { url: 'https://www.example.com/', },
}; // 파일 2: app/about/page.tsx export const metadata = { openGraph: { url: 'https://example.com/about', // www 없음 (불일치!,
}; // 파일 3: app/sitemap.ts
const pages = [ { url: 'https://www.example.com/' }, { url: 'https://www.example.com/about' },
]; // 파일 4: components/share-button.tsx
const shareUrl = 'https://example.com/blog/post'; // 또 불일치!
위 코드에서 www와 non-www가 혼재되어 있습니다. 이런 불일치는 시간이 지날수록 누적됩니다.
2) SITE_CONFIG 패턴 구현
모든 URL을 중앙에서 관리하면 일관성이 보장됩니다.
// ✅ 중앙 집중식 관리 (좋은 방식) // constants/index.ts
export const SITE_CONFIG = { url: 'https://example.com', // 표준 URL (한 곳에서 관리) name: 'Example Site', description: '사이트 설명', author: 'Author Name',
}; // 파일 1: app/page.tsx
import { SITE_CONFIG } from '@/constants'; export const metadata = { openGraph: { url: SITE_CONFIG.url, },
}; // 파일 2: app/about/page.tsx
import { SITE_CONFIG } from '@/constants'; export const metadata = { openGraph: { url: `${SITE_CONFIG.url}/about`, },
}; // 파일 3: app/sitemap.ts
import { SITE_CONFIG } from '@/constants'; const pages = [ { url: SITE_CONFIG.url }, { url: `${SITE_CONFIG.url}/about` },
]; // 파일 4: components/share-button.tsx
import { SITE_CONFIG } from '@/constants'; const shareUrl = `${SITE_CONFIG.url}/blog/post`;
3) SITE_CONFIG의 실질적 이점
도메인 변경 시나리오:
example.com → newbrand.com으로 변경 하드코딩 방식:
- 100개 파일에서 URL 검색
- 각 파일 열어서 수정
- 일부 누락 가능성 높음
- 테스트 후에도 버그 발견 가능
- 예상 소요 시간: 수 시간 ~ 며칠 SITE_CONFIG 방식:
- constants/index.ts 파일 열기
- url: 'https://newbrand.com' 으로 변경
- 저장
- 끝
- 예상 소요 시간: 1분
7. Canonical 태그와 리다이렉트의 조합 전략
1) Canonical 태그의 역할과 한계
Canonical 태그는 HTML head에 삽입하여 "이 페이지의 표준 URL은 이것이다"라고 검색 엔진에 알려주는 힌트입니다.
<head> <link rel="canonical" href="https://example.com/page" />
</head>
하지만 canonical 태그는 힌트일 뿐 강제성이 없습니다.
Canonical 태그의 한계:
- Google이 무시하고 다른 URL을 선택할 수 있음
- 다른 검색 엔진은 다르게 해석할 수 있음
- 잘못 설정하면 오히려 혼란 초래
- 사용자는 여전히 두 URL 모두 접근 가능
2) 리다이렉트와 Canonical의 차이점
301 리다이렉트:
- 서버 레벨에서 강제 이동
- 사용자가 원래 URL에 머물 수 없음
- 검색 엔진이 무시할 수 없음
- 링크 자산 전달 보장 Canonical 태그:
- HTML 레벨의 힌트
- 사용자는 원래 URL에 머물 수 있음
- 검색 엔진이 무시할 수 있음
- 링크 자산 전달 보장 안 됨
3) 최적의 조합 전략
가장 확실한 방법은 둘을 함께 사용하는 것입니다.
권장 설정:
1. 301 리다이렉트: www → non-www (서버 레벨)
2. Canonical 태그: 모든 페이지에 non-www URL 명시 (HTML 레벨)
3. 내부 링크: 모든 내부 링크를 non-www로 통일 (콘텐츠 레벨)
4. 사이트맵: non-www URL만 포함 (크롤링 가이드)
5. robots.txt: non-www 도메인에서만 제공 (크롤링 가이드)
이렇게 5중 방어선을 구축하면 어떤 상황에서도 검색 엔진이 올바른 URL을 인식합니다.
8. 실무 체크리스트와 검증 방법
1) 도메인 통일 작업 체크리스트
DNS 및 호스팅 설정:
☐ 두 도메인 버전 모두 DNS에 등록
☐ SSL 인증서가 두 버전 모두 커버
☐ 호스팅에서 primary 도메인 지정
☐ 301 리다이렉트 규칙 설정
☐ 리다이렉트 동작 테스트 코드베이스 정리:
☐ SITE_CONFIG 생성 및 URL 중앙화
☐ 하드코딩된 URL 검색 (grep 또는 IDE 검색)
☐ 모든 하드코딩 URL을 SITE_CONFIG로 교체
☐ 메타데이터 canonical URL 확인
☐ OpenGraph URL 확인
☐ 사이트맵 URL 확인
☐ robots.txt Sitemap 경로 확인 검색 엔진 설정:
☐ Google Search Console에 선호 도메인 등록
☐ 네이버 서치어드바이저에 사이트 등록
☐ 새 사이트맵 제출
☐ URL 검사 도구로 인덱싱 상태 확인
☐ 기존 인덱싱된 www(또는 non-www) 페이지 처리 확인
2) 검증 도구 및 명령어
# 리다이렉트 확인
curl -I https://www.example.com
# 301과 Location 헤더 확인 # 전체 리다이렉트 체인 확인
curl -ILs https://www.example.com | grep -E "HTTP|location" # Canonical 태그 확인
curl -s https://example.com/page | grep canonical # 사이트맵 URL 확인
curl -s https://example.com/sitemap.xml | grep "<loc>"
3) Google Search Console에서 확인할 사항
확인 순서:
1. 색인 생성 → 페이지 → 색인이 생성되지 않음
2. "중복, 사용자가 선택한 표준 페이지가 아닙니다" 항목 확인
3. 해당 페이지들이 www/non-www 혼재인지 확인 4. URL 검사 도구 사용
5. www 버전 URL 입력
6. "Google에서 선택한 표준 URL" 확인
7. 원하는 버전과 일치하는지 확인 8. 실적 보고서에서 두 버전이 별도로 집계되는지 확인
9. FAQ
Q: 이미 www로 많은 백링크가 쌓여있는데 non-www로 변경해도 괜찮은가요? A: 301 리다이렉트를 설정하면 기존 백링크의 SEO 가치가 새 URL로 전달됩니다. Google은 301을 통해 "이 두 URL은 같은 페이지"라고 이해하고, 링크 자산을 통합합니다. 다만 인덱스 업데이트에 몇 주가 걸릴 수 있으므로, 변경 직후 일시적인 트래픽 변동은 정상입니다. 기존 백링크가 많다면 해당 버전을 유지하는 것도 고려해볼 만합니다.
Q: www와 non-www를 모두 사용하면서 canonical 태그로만 처리하면 안 되나요? A: 기술적으로 가능하지만 권장하지 않습니다. Canonical 태그는 검색 엔진에 대한 힌트일 뿐이며, Google이 이를 무시하고 자체적으로 다른 URL을 선택할 수 있습니다. 또한 사용자가 두 URL 모두에 접근할 수 있어 쿠키, 세션, 분석 데이터 등에서 문제가 발생합니다. 301 리다이렉트가 가장 확실하고 안전한 방법입니다.
Q: 서브도메인(예: blog.example.com)도 같은 방식으로 처리해야 하나요? A: 서브도메인은 별개의 사이트로 취급될 수 있으므로 상황이 다릅니다. blog.example.com 과 example.com/blog 중 어떤 구조를 선택할지는 콘텐츠 전략에 따라 다릅니다. 서브도메인을 사용한다면 해당 서브도메인 내에서 www 통일만 신경 쓰면 됩니다. 예를 들어 www.blog.example.com 을 blog.example.com으로 리다이렉트하는 것입니다.
Q: SITE_CONFIG 대신 환경변수(process.env)를 사용해도 되나요? A: 네, 환경변수를 사용해도 됩니다. 핵심은 URL을 한 곳에서 관리하여 일관성을 유지하는 것입니다. 환경변수는 배포 환경별로 다른 URL을 설정할 수 있다는 장점이 있습니다. 예를 들어 개발 환경에서는 localhost, 스테이징에서는 staging.example.com, 프로덕션에서는 example.com을 사용할 수 있습니다.
Q: 리다이렉트 설정 후 기존 www 페이지가 Google에서 언제 사라지나요? A: Google이 리다이렉트를 인식하고 인덱스를 업데이트하는 데는 며칠에서 몇 주가 걸립니다. 크롤링 빈도가 높은 사이트는 빠르게 업데이트되고, 트래픽이 적은 사이트는 더 오래 걸릴 수 있습니다. Google Search Console의 URL 검사 도구에서 "색인 생성 요청"을 하면 프로세스를 약간 앞당길 수 있습니다.
Q: HTTP에서 HTTPS로의 리다이렉트도 함께 설정해야 하나요? A: 네, 반드시 설정해야 합니다. 현대 웹에서 HTTPS는 필수이며, Google은 HTTPS를 순위 요소로 사용합니다. 가장 좋은 설정은 모든 변형을 하나의 표준 URL로 리다이렉트하는 것입니다. 예를 들어 http://www.example.com, http://example.com, https://www.example.com 모두 https://example.com으로 301 리다이렉트합니다.
10. 마무리
www와 non-www 도메인 통일은 SEO의 기초 중 기초입니다. 기술적으로는 간단한 작업이지만, 이를 방치하면 검색 순위 하락, 링크 자산 분산, 크롤링 예산 낭비 등 누적되는 피해가 상당합니다.
핵심 요약:
- www와 non-www는 기술적으로 완전히 다른 URL이며, 검색 엔진은 이를 별개의 페이지로 인식한다
- 두 버전을 통일하지 않으면 중복 콘텐츠, 링크 분산, 크롤링 낭비 문제가 발생한다
- www와 non-www 중 선택은 자유이지만, 반드시 하나로 통일해야 한다
- 301 리다이렉트가 가장 확실한 통일 방법이며, canonical 태그와 함께 사용하면 더욱 안전하다
- SITE_CONFIG를 활용한 중앙 집중식 URL 관리로 유지보수성과 일관성을 확보할 수 있다
- Google Search Console에서 현재 인덱싱 상태를 확인하고, 문제가 있다면 즉시 리다이렉트를 설정하라
지금 바로 브라우저에서 www.yourdomain.com과 yourdomain.com을 각각 입력해보세요. 둘 다 접근 가능하면서 URL이 통일되지 않는다면, 이 문서에서 설명한 대로 리다이렉트 설정이 필요합니다. 한 번 설정해두면 이후 별다른 관리 없이 SEO 기반이 탄탄해집니다.
