URL 구조 설계, 검색엔진이 이해하는 사이트 아키텍처 만들기

홈페이지의 콘텐츠가 아무리 좋아도 URL 구조가 엉켜 있으면 검색엔진은 사이트를 제대로 이해하지 못합니다. 어떤 페이지가 중요한지, 어떤 페이지가 중복인지, 어떤 페이지를 색인해야 하는지 판단하는 기준이 바로 URL과 링크 구조이기 때문입니다. SEO에서 콘텐츠가 무엇을 말할 것인가의 문제라면, URL 구조는 그 말을 어떤 주소 체계 위에 올릴 것인가의 문제입니다.

이번 글에서는 URL 설계 원칙부터 중복 배제, canonical 오류, 저품질 페이지 관리, 링크 구조 최적화, 리다이렉트 검증까지 사이트 아키텍처 전반을 실무 수준에서 다룹니다.

URL 설계 기본 원칙

타겟 키워드 부여

URL에는 해당 페이지의 타겟 키워드가 포함되어야 합니다. /page?id=3872 같은 구조에서는 검색엔진도 사용자도 이 페이지가 무엇에 관한 것인지 알 수 없습니다. /seo/technical-seo-guide처럼 URL 자체가 페이지 주제를 설명하는 구조가 되어야 검색엔진이 페이지의 맥락을 빠르게 파악할 수 있습니다.

키워드를 URL에 넣을 때는 단어 사이를 하이픈(-)으로 구분하고, 언더스코어(_)나 공백은 피해야 합니다. 구글은 하이픈을 단어 구분자로 인식하지만 언더스코어는 하나의 단어로 이어 읽기 때문입니다. 또한 불필요한 불용어(the, and, of 등)를 제거해 URL을 간결하게 유지하는 것이 좋습니다.

가독성 확보

좋은 URL은 사람이 읽었을 때도 페이지 내용을 예측할 수 있어야 합니다. 구글은 공식 문서에서 단순한 URL 구조를 유지할 것을 권장하며, 사용자가 URL만 보고도 콘텐츠를 이해할 수 있는 형태가 이상적이라고 설명합니다.

한글 URL도 사용 가능하지만 SNS나 메신저에서 공유할 때 인코딩되어 길어지는 문제가 있습니다. 타겟 사용자와 공유 환경을 고려해 한글 또는 영문 중 일관된 규칙을 정하는 것이 중요합니다. 두 방식을 혼용하면 관리 복잡도가 높아지고, 사용자가 URL 패턴을 예측하기 어려워집니다.

URL 깊이도 가독성에 영향을 줍니다. /category/subcategory/sub-subcategory/page처럼 깊이가 4단계 이상으로 깊어지면 크롤러가 해당 페이지를 덜 중요하게 판단할 수 있고, 사용자도 구조를 파악하기 어렵습니다. 가능하면 루트 도메인에서 3클릭 이내에 모든 중요 페이지에 도달할 수 있는 플랫한 구조를 유지하는 것이 좋습니다.

URL 개별화

콘텐츠가 바뀌는데 URL이 변경되지 않는 경우가 있습니다. SPA(Single Page Application) 구조에서 AJAX나 JavaScript로 콘텐츠를 동적으로 교체하면서 URL은 그대로 유지되는 상황이 대표적입니다. 사용자 화면에는 다른 콘텐츠가 보이지만, 검색엔진이 보는 URL은 하나이기 때문에 개별 콘텐츠가 색인되지 않습니다.

이 문제를 해결하려면 각 콘텐츠 상태에 고유한 URL을 부여해야 합니다. 화면이 바뀔 때 주소창의 URL도 함께 바뀌도록 개발하거나, 서버에서 각 페이지의 HTML을 미리 만들어 두는 방식으로 전환해 각 페이지가 고유 URL을 갖도록 설계하는 것이 근본적인 해결책입니다. 탭이나 아코디언으로 콘텐츠를 숨기는 구조도 마찬가지입니다. 검색엔진이 접근할 수 있는 고유 URL이 없으면 해당 콘텐츠는 존재하지 않는 것과 같습니다.

폼 제출(POST 방식)을 통해서만 접근 가능한 페이지도 주의가 필요합니다. Googlebot은 페이지 렌더링 중 자동으로 발생하는 POST 요청은 따라갈 수 있지만, 사용자가 버튼을 눌러 폼을 제출해야 도달하는 페이지는 크롤링하지 못합니다. 검색 노출이 필요한 페이지라면 주소창에 URL을 입력해 바로 접근할 수 있는 구조를 제공해야 합니다.

내부링크 기반 사이트 아키텍처

페이지 구조 최적화

사이트 아키텍처는 페이지와 페이지 사이의 연결 방식이 만드는 전체 구조입니다. 검색엔진은 내부링크를 따라 사이트를 탐색하기 때문에, 내부링크의 연결 패턴이 곧 사이트의 구조가 됩니다.

이상적인 페이지 구조는 피라미드 형태입니다. 최상위에 메인 페이지가 있고, 그 아래 카테고리 페이지, 그 아래 개별 콘텐츠 페이지가 위치합니다. 각 층위의 페이지가 상하위 페이지와 내부링크로 연결되어 있어야 크롤러가 전체 구조를 빠짐없이 파악할 수 있습니다.

문제가 되는 구조는 특정 페이지가 어디에서도 링크되지 않는 고아 페이지, 특정 페이지에만 링크가 과도하게 집중된 불균형 구조, 그리고 깊이가 지나치게 깊어 크롤러가 도달하기 어려운 구조입니다. Google Search Console의 크롤링 통계 보고서에서 크롤 깊이를 확인하면 이런 구조적 문제를 발견할 수 있습니다.

디렉토리 구조 최적화

URL의 디렉토리 경로는 사이트의 정보 계층을 반영해야 합니다. /blog/seo-guide와 /services/seo-consulting처럼 콘텐츠 유형과 주제에 따라 디렉토리를 구분하면, 검색엔진이 사이트의 주제 영역을 명확하게 이해할 수 있습니다.

디렉토리 구조를 설계할 때 흔히 하는 실수는 날짜 기반 구조입니다. /blog/2026/06/03/post-title처럼 발행일을 디렉토리에 포함하면 URL이 길어지고, 콘텐츠를 업데이트해도 URL에 과거 날짜가 남아 최신성 신호가 약해집니다. /blog/post-title처럼 주제 기반의 플랫한 구조가 SEO에 더 유리합니다.

같은 카테고리에 속하는 콘텐츠는 같은 디렉토리 하위에 배치하고, 카테고리 페이지에서 하위 콘텐츠로의 내부링크를 일관되게 유지하는 것이 핵심입니다. 이렇게 하면 검색엔진이 디렉토리 단위로 토픽 클러스터를 인식하는 데 도움이 됩니다.

SEO 구조 설계의 전체 체계는 SEO 구조 설계란 무엇인가: 검색 상위 노출을 만드는 홈페이지 뼈대에서 확인하세요.

중복 URL 배제 전략

중복 URL은 검색엔진의 크롤 예산을 낭비하고, 페이지 간 권위를 분산시킵니다. 같은 콘텐츠가 여러 URL에 존재하면 검색엔진이 어느 URL을 대표로 삼아야 할지 혼란을 겪고, 결과적으로 어느 페이지도 높은 순위를 받지 못하는 상황이 발생합니다.

파라미터에 의한 중복

세션 ID가 URL에 포함되는 경우가 대표적입니다. /product?id=100&sessionid=abc123처럼 방문자마다 다른 세션 파라미터가 붙으면, 같은 상품 페이지가 수백 개의 서로 다른 URL로 존재하게 됩니다. 광고 캠페인 추적 파라미터(utm_source, utm_medium 등)도 마찬가지입니다. /landing?utm_source=google&utm_medium=cpc와 /landing은 같은 페이지이지만 검색엔진에는 별개의 URL로 인식됩니다.

해결 방법은 canonical 태그를 파라미터가 없는 원본 URL로 지정하는 것입니다. 예를 들어 /landing?utm_source=google&utm_medium=cpc 페이지에 접속하더라도, HTML head 안에 canonical을 /landing으로 지정해 두면 구글은 파라미터가 붙은 URL을 무시하고 /landing을 대표 페이지로 인식합니다. 여기서 ? 뒤에 붙는 utm_source, sessionid 같은 값이 파라미터이고, 이것을 제거한 주소가 원본 URL입니다. 같은 페이지인데 파라미터 때문에 URL이 달라져 구글이 별개 페이지로 인식하는 문제를 canonical 태그 한 줄로 해결하는 방식입니다.

예전에는 Google Search Console의 URL 매개변수 도구에서 특정 파라미터를 무시하도록 구글에 직접 설정할 수 있었지만, 이 기능은 2022년에 폐지되었습니다. 현재는 개발자가 canonical 태그와 robots.txt를 활용해 직접 관리해야 합니다.

세션 ID의 경우, /product?sessionid=abc123처럼 URL에 포함하면 방문자마다 URL이 달라져 중복 페이지가 끝없이 생깁니다. 세션 ID를 URL이 아닌 브라우저 쿠키에 저장하면 URL 자체가 깨끗하게 유지되기 때문에, 이것이 근본적인 해결책입니다. UTM 파라미터(?utm_source=google 등)는 광고 성과 추적에 필요하기 때문에 URL에서 완전히 없앨 수는 없지만, canonical 태그로 파라미터 없는 원본 URL을 지정해 두면 구글이 중복으로 인식하는 문제를 방지할 수 있습니다.

목록 페이지 중복 회피

상품 목록이나 검색 결과 페이지에서 정렬 순서나 필터 조건을 바꿀 때마다 URL이 달라지는 경우입니다. /products?sort=price_asc, /products?sort=newest, /products?color=red&size=L 같은 URL이 모두 유사한 콘텐츠를 담고 있으면서 각각 별개의 URL로 존재합니다.

정렬이나 필터 조합이 많아지면 수천 개의 중복 URL이 생성될 수 있습니다. 기본 정렬 페이지를 canonical로 지정하고, 필터 조합 페이지 중 검색 유입 가치가 없는 것은 noindex 처리하거나, robots.txt에서 파라미터 패턴을 차단하는 방식으로 관리합니다. 단, robots.txt로 차단하면 크롤러가 noindex 태그를 읽지 못하므로, 두 방법을 동시에 사용하지 않도록 주의해야 합니다.

• 기본 정렬 페이지를 canonical로 지정: products를 대표 URL로 삼아, /products?sort=price_asc 같은
  변형 URL이 canonical을 통해 원본을 가리키게 함
• noindex 처리: 검색 유입 가치가 없는 필터 조합 페이지(예: /products?color=red&size=L)에 를 넣어 구글 색인에서 제외
• robots.txt 파라미터 패턴 차단: Disallow: /products? 같은 규칙으로 크롤러가 아예 해당 URL을
  크롤링하지 못하게 차단하여 크롤 예산 낭비를 방지

상세 페이지 중복 회피

같은 제품의 색상만 다른 페이지, 모델 번호만 다른 페이지가 각각 별도 URL을 갖는 경우입니다. /product/shoes-red와 /product/shoes-blue의 설명 텍스트가 90% 동일하다면 검색엔진은 이를 중복 콘텐츠로 판단합니다.

색상이나 옵션 차이만 있는 페이지는 대표 제품 페이지 하나를 canonical로 지정하고, 나머지 변형 페이지는 canonical을 대표 페이지로 향하게 설정합니다. 각 변형 페이지에 고유한 설명이나 리뷰 등 차별화된 콘텐츠가 충분하다면 별도 URL을 유지할 수 있지만, 그렇지 않다면 하나의 페이지에서 옵션을 선택하는 구조로 통합하는 것이 SEO에 유리합니다.

Canonical 설계와 오류 방지

Canonical 태그는 중복 URL 문제를 해결하는 핵심 도구이지만, 잘못 구현하면 오히려 색인 문제를 일으킵니다. 구글은 canonical 태그를 강제 지시가 아닌 힌트로 취급하기 때문에, 구현에 오류가 있으면 구글이 의도와 다른 URL을 대표 페이지로 선택할 수 있습니다.

Canonical 체인과 루프

A 페이지의 canonical이 B를 가리키고, B의 canonical이 C를 가리키는 체인 구조가 발생하면 검색엔진이 최종 대표 URL을 판단하기 어려워집니다. 더 심각한 것은 루프입니다. A→B→C→A처럼 canonical이 순환하면 검색엔진이 어느 페이지도 대표로 인정하지 않을 수 있습니다.

체인 문제

A페이지 → “원본은 B야”
B페이지 → “원본은 C야”

A를 본 구글이 B로 갔더니, B도 자기가 원본이 아니라고 또 C를 가리킵니다. 구글 입장에서는 따라가다
지치고, 최종 원본이 뭔지 헷갈립니다.

루프 문제

A → “원본은 B”
B → “원본은 C”
C → “원본은 A” ← 다시 처음으로 돌아옴

끝없이 빙글빙글 돌아서 원본이 아예 없는 상태가 됩니다. 결국 구글이 세 페이지 모두 무시해버릴 수
있습니다.

올바른 방식

A → “원본은 C”
B → “원본은 C”
C → “원본은 C” (자기 자신)

모든 페이지가 중간 단계 없이 최종 원본(C)을 직접 가리키면 구글이 한 번에 원본을 파악할 수 있습니다.

모든 canonical 태그가 최종 대표 URL을 직접 가리키도록 해야 합니다. A와 B 모두 C를 canonical로 지정하는 것이 올바른 방식이고, A→B→C처럼 중간 단계를 거치는 체인은 피해야 합니다. Screaming Frog 같은 크롤링 도구로 사이트 전체의 canonical 태그를 추출하면 체인이나 루프를 한번에 발견할 수 있습니다.

Self-referencing Canonical

Self-referencing canonical은 자기 자신의 URL을 canonical로 선언하는 것입니다. 예를 들어 https://example.com/seo-guide 페이지의 HTML head 안에 <link rel="canonical" href="https://example.com/seo-guide">를 넣는 방식입니다.

이것이 필요한 이유는 같은 페이지라도 실제로는 여러 URL로 접근될 수 있기 때문입니다. UTM 파라미터가 붙은 https://example.com/seo-guide?utm_source=naver, 대소문자가 다른 https://example.com/SEO-Guide, SNS 공유 시 자동으로 붙는 https://example.com/seo-guide?fbclid=abc123 등이 모두 같은 페이지이지만 검색엔진에는 별개의 URL로 보입니다. Self-referencing canonical이 없으면 구글이 이 중 어떤 URL을 대표로 삼을지 자체 판단하고, 있으면 원본 URL을 명시적으로 알려주는 것이라 혼란이 없습니다.

WordPress의 Rank Math나 Yoast 같은 SEO 플러그인은 이 태그를 자동으로 생성해 주고, 직접 개발한 사이트는 페이지 템플릿에 한 줄만 추가해 두면 전체 페이지에 일괄 적용할 수 있습니다.

페이지네이션과 Canonical

쇼핑몰 상품 목록이 100개라면 한 페이지에 다 보여줄 수 없으니 1페이지(1~20번 상품), 2페이지(21~40번), 3페이지(41~60번) 식으로 나눕니다. 이렇게 목록을 여러 페이지로 쪼개는 구조가 페이지네이션입니다. 이 구조에서 canonical 설정은 특히 주의가 필요합니다.

과거에는 rel=prev/next 태그로 페이지 간 관계를 알려줬지만, 구글은 2019년에 이 태그를 공식적으로 더 이상 사용하지 않는다고 발표했습니다. 현재 권장되는 방식은 각 페이지네이션 페이지에 자기 자신을 canonical로 지정하는 것입니다.

흔한 실수는 2페이지·3페이지의 canonical을 전부 1페이지로 지정하는 것입니다. 이렇게 하면 구글이 2페이지 이후를 1페이지의 복사본으로 판단해서, 21번~100번 상품이 아예 색인에서 빠집니다. 각 페이지가 서로 다른 상품을 보여주는 고유한 페이지이므로, 각자의 URL을 canonical로 가져야 합니다.

또 하나 주의할 점은 페이지네이션의 최대 페이지 수를 초과한 뒤에도 다음 페이지 링크가 계속 생성되는 오류입니다. 상품이 5페이지까지만 있는데 6페이지·7페이지·8페이지 링크가 무한히 생성되면, 크롤러가 이 빈 페이지를 계속 따라가면서 크롤 예산이 낭비되고 소프트 404 페이지가 대량으로 쌓입니다. 페이지네이션 로직에서 마지막 페이지를 정확히 계산하고, 그 이후에는 다음 페이지 링크를 출력하지 않도록 구현해야 합니다.

저품질 페이지 관리

사이트 내 검색결과 noindex

사이트 내부 검색 기능의 검색결과 페이지는 대부분 색인할 가치가 없습니다. /search?q=seo 같은 내부 검색결과 페이지가 색인되면, 구글 검색결과에서 사용자가 내부 검색결과 페이지로 유입되는 불필요한 상황이 발생합니다. 이런 페이지는 콘텐츠가 동적으로 바뀌고 고유한 가치가 없기 때문에 구글이 저품질로 판단할 수 있습니다.

내부 검색결과 페이지에는 <meta name="robots" content="noindex">를 적용하고, robots.txt에서 /search 경로를 차단하는 것을 병행하는 것이 안전합니다. 단, noindex와 robots.txt 차단을 동시에 적용하면 크롤러가 noindex 태그를 읽지 못할 수 있으므로, noindex를 우선 적용하고 robots.txt는 크롤 예산 보호 목적으로 보조적으로 사용하는 것이 정석입니다.

소프트 404

소프트 404는 페이지가 실제로는 존재하지 않거나 콘텐츠가 없는데, 서버가 200 OK 상태 코드를 반환하는 경우입니다. 검색엔진에는 정상 페이지처럼 보이지만 실제로는 빈 페이지이기 때문에, 크롤 예산을 낭비하고 사이트 전체의 품질 평가에 부정적 영향을 줍니다.

Google Search Console의 페이지 색인 생성 보고서에서 소프트 404로 분류된 URL을 확인할 수 있습니다. 해당 페이지에 실제 콘텐츠가 있어야 하는데 비어 있다면 콘텐츠를 채우고, 더 이상 필요 없는 페이지라면 실제 404 상태 코드를 반환하거나 관련 페이지로 301 리다이렉트를 설정해야 합니다.

소프트 404가 자주 발생하는 원인은 상품이 품절되었을 때 빈 페이지를 보여주는 경우, 필터 조합에 해당하는 결과가 없을 때 빈 목록을 반환하는 경우, 삭제된 게시글 URL에 빈 템플릿만 남아 있는 경우 등입니다.

크롤 완료 — 인덱스 미등록

구글이 페이지를 크롤링했지만 색인에 등록하지 않은 상태입니다. Google Search Console의 페이지 보고서에서 크롤링됨 – 현재 색인이 생성되지 않음 항목으로 확인할 수 있습니다. 이 상태가 많다면 구글이 해당 페이지의 품질이나 고유성이 색인 기준에 미달한다고 판단한 것입니다.

원인은 다양합니다. 콘텐츠 분량이 너무 적거나, 다른 페이지와 내용이 지나치게 유사하거나, 내부링크가 부족해 중요도 신호가 약하거나, 사이트 전체의 품질 평가가 낮은 경우입니다. 해결 방법은 해당 페이지의 콘텐츠를 보강하고, 관련 페이지에서 내부링크를 연결하며, 필요 없는 페이지는 noindex 처리하거나 삭제해서 사이트 전체의 색인 품질을 높이는 것입니다.

크롤 완료-미등록 건수가 전체 페이지의 30%를 넘는다면 사이트 구조 차원의 점검이 필요합니다. 개별 페이지 수정보다 저품질 페이지 정리, 중복 콘텐츠 통합, 내부링크 재설계 같은 구조적 접근이 효과적입니다.

색인 문제 상세 진단에 대한 내용은 홈페이지 검색 노출이 안 되는 이유, 색인부터 점검하세요에서 확인하세요.

링크 구조 최적화

브레드크럼

브레드크럼은 현재 페이지가 사이트 전체 구조에서 어디에 위치하는지를 계층적으로 보여주는 네비게이션입니다. 홈 > 블로그 > SEO > URL 구조 설계 같은 형태로, 사용자에게는 탐색 편의를, 검색엔진에게는 사이트 계층 정보를 제공합니다.

브레드크럼을 구현할 때는 HTML 네비게이션과 함께 BreadcrumbList 구조화 데이터(JSON-LD)를 추가하는 것이 좋습니다. 구조화 데이터가 있으면 구글 검색결과에서 URL 대신 브레드크럼 경로가 표시되어 클릭률이 향상됩니다. 브레드크럼의 각 단계는 실제 존재하는 페이지로 연결되어야 하며, 마지막 항목(현재 페이지)은 링크 없이 텍스트로만 표시하는 것이 일반적입니다.

브레드크럼 구조가 URL 디렉토리 구조와 일치하면 검색엔진이 사이트 계층을 더 명확하게 이해합니다. /seo/url-structure 페이지의 브레드크럼이 홈 > SEO > URL 구조 설계라면 URL과 브레드크럼이 같은 계층을 가리키므로 신호가 일관됩니다.

헤더와 푸터

헤더와 푸터에 포함된 링크는 사이트 전체 페이지에 반복적으로 노출됩니다. 검색엔진은 이 점을 인식하고 있기 때문에, 헤더/푸터 링크의 개별적인 권위 전달 효과는 본문 내 링크보다 낮게 평가합니다. 그렇다 해도 헤더/푸터는 사이트의 핵심 구조를 드러내는 역할을 합니다.

헤더에는 핵심 서비스 페이지, 주요 카테고리 페이지 등 사이트의 가장 중요한 페이지만 포함하는 것이 좋습니다. 메가 메뉴로 수십 개의 링크를 나열하면 크롤러가 각 링크의 중요도를 판단하기 어려워지고, 크롤 예산도 분산됩니다. 푸터에는 이용약관, 개인정보처리방침 같은 필수 페이지와 함께 사이트맵 페이지 링크를 포함하는 정도가 적절합니다.

헤더/푸터 링크를 변경하면 사이트 전체의 내부링크 구조가 한꺼번에 바뀌므로, 변경 전후로 Google Search Console에서 크롤링 상태를 모니터링하는 것이 안전합니다.

아웃바운드 링크

아웃바운드 링크는 내 사이트에서 외부 사이트로 나가는 링크입니다. 신뢰할 수 있는 공식 문서나 권위 있는 출처로의 아웃바운드 링크는 콘텐츠의 신뢰도를 높이는 데 도움이 됩니다. 구글 공식 문서, 정부 기관 사이트, 업계 권위 있는 리서치 등이 좋은 아웃바운드 링크 대상입니다.

다만 한 페이지에서 아웃바운드 링크가 지나치게 많으면 페이지의 권위가 외부로 과도하게 분산될 수 있습니다. 콘텐츠 품질을 높이는 데 필요한 출처 링크는 유지하되, 불필요한 외부 링크는 정리하는 것이 좋습니다. 광고성 링크나 신뢰도가 낮은 사이트로의 링크는 rel="nofollow" 또는 rel="sponsored" 속성을 추가해 권위 전달을 차단합니다.

특정 페이지에서 아웃바운드 링크가 100개를 넘는다면 해당 페이지의 링크 구조를 점검해야 합니다. 링크 목록이 페이지의 주요 콘텐츠가 아니라면 과도한 아웃바운드 링크는 사용자 경험과 SEO 양쪽 모두에 부정적입니다.

301 리다이렉트 설계와 검증

URL을 변경하거나 페이지를 통합할 때 301 리다이렉트를 설정하지 않으면 기존 URL이 쌓아온 검색 순위와 권위가 사라집니다. 301은 영구 이동 신호로, 검색엔진에 이전 URL의 권위를 새 URL로 이전해달라고 요청하는 것입니다.

301과 302의 구분

301은 영구 이동, 302는 임시 이동입니다. URL을 영구적으로 변경하는 경우에는 반드시 301을 사용해야 합니다. 302를 잘못 사용하면 검색엔진이 이전 URL을 계속 색인에 유지하면서 권위 이전이 이루어지지 않습니다. 사이트 리뉴얼이나 URL 구조 변경 시 가장 흔하게 발생하는 실수가 302를 301 대신 사용하는 것입니다.

리다이렉트 체인 방지

A→B→C→D처럼 리다이렉트가 여러 단계를 거치는 체인은 각 단계마다 로딩 시간이 추가되고, 권위 전달 효율도 떨어집니다. 구글 공식 문서에 따르면 Googlebot은 최대 10회까지 리다이렉트를 따라가지만, John Mueller는 실질적으로 5회 이상이면 크롤러가 포기할 가능성이 높다고 언급한 바 있습니다. 실무에서는 모든 리다이렉트가 최종 URL을 직접 가리키도록, 1~2회 이내로 관리하는 것이 원칙입니다. 사이트 리뉴얼을 여러 번 거치면서 이전 리다이렉트 위에 새 리다이렉트가 쌓이는 경우가 많은데, 주기적으로 리다이렉트 맵을 정리해 체인을 제거해야 합니다.

리다이렉트 검증 방법

리다이렉트를 설정한 후에는 반드시 동작을 검증해야 합니다. 브라우저 개발자 도구의 네트워크 탭에서 HTTP 상태 코드를 확인하거나, curl -I 명령어로 응답 헤더를 확인할 수 있습니다. Screaming Frog로 사이트 전체를 크롤링하면 모든 리다이렉트의 상태 코드, 체인 여부, 최종 도착 URL을 한번에 파악할 수 있습니다.

리다이렉트 설정 후 Google Search Console에서 이전 URL의 색인 상태가 새 URL로 정상 전환되었는지도 확인해야 합니다. 이전 URL이 여전히 색인에 남아 있다면 구글이 리다이렉트를 아직 처리하지 않았거나, 리다이렉트가 정상 동작하지 않는 것일 수 있습니다.

URL 구조 진단 체크리스트

• URL에 타겟 키워드가 포함되어 있는가
• URL이 사람이 읽었을 때 페이지 내용을 예측할 수 있는가
• 동적 콘텐츠 변경 시 URL이 함께 변경되는가 (AJAX/SPA 문제)
• 주요 페이지가 루트에서 3클릭 이내에 도달 가능한가
• 디렉토리 구조가 콘텐츠 주제 계층을 반영하는가
• 세션/캠페인 파라미터에 의한 중복 URL이 canonical로 처리되었는가
• 정렬/필터 조합 페이지가 정규화되었는가
• 색상/옵션 차이만 있는 상세 페이지가 canonical로 통합되었는가
• Canonical 체인이나 루프가 없는가
• 페이지네이션 각 페이지가 self-referencing canonical을 사용하는가
• 마지막 페이지 이후 불필요한 next 링크가 생성되지 않는가
• 내부 검색결과 페이지에 noindex가 적용되었는가
• 소프트 404 URL 수가 관리되고 있는가
• 크롤 완료-인덱스 미등록 비율이 30% 이하인가
• 브레드크럼이 BreadcrumbList 구조화 데이터와 함께 구현되었는가
• 헤더 링크가 핵심 페이지 중심으로 구성되었는가
• 아웃바운드 링크 수가 페이지당 적정 수준인가
• 모든 URL 변경에 301 리다이렉트가 설정되었는가
• 리다이렉트 체인이 없는가

디지트미는 홈페이지 제작 단계에서 URL 구조와 사이트 아키텍처를 사전에 설계하고, 런칭 후에도 당사 SEO 유지관리 서비스를 통해 Google Search Console 데이터를 기반으로 중복·색인·리다이렉트 상태를 정기 점검하는 프로세스를 운영합니다. URL 구조 진단이나 사이트 아키텍처 개선이 필요하다면 디지트미에 상담을 요청해 주세요.

자주 묻는 질문