URL은 사용자가 복사하고, 붙여넣고, 즐겨찾기하고, 인쇄하고, 링크로 거는 유일한 인터페이스 요소입니다. 디자인 시스템보다, CMS보다, 대개는 그것을 정한 팀보다 오래 남습니다. 프레임워크가 기본으로 만들어준 값이 아니라 설계 결정이 필요한 이유입니다.
URL이 전달해야 하는 것
우선순위대로 세 가지입니다.
- 이 페이지가 계층에서 어디에 있는지
- 사람이 알아볼 수 있는 말로 무엇에 대한 페이지인지
- 그 외에는 아무것도 — 구현 세부사항, 세션 상태, CMS 발행 시각 같은 것
비교해 보세요.
https://example.com/solutions/thermal/heat-pump-modules
https://example.com/pages/detail.aspx?cat=3&sub=12&id=88271
둘 다 동작합니다. 하지만 플랫폼을 옮겨도 의미가 유지되는 쪽은 하나뿐이고, 사용자에게 무엇을 열게 되는지 알려주는 쪽도 하나뿐입니다.
채택할 만한 규칙
항상 소문자. 대부분의 서버에서 /Products와 /products는 다른 URL이지만, 사용자에게는 같은 것입니다. 소문자로 정하고 나머지는 리다이렉트하세요.
언더스코어가 아니라 하이픈. heat-pump-modules는 단어로 분리되지만 heat_pump_modules는 역사적으로 그렇지 않습니다. 이건 결론이 난 논쟁입니다.
짧고 의미 있는 세그먼트. 세그먼트당 3~5단어를 넘기지 마세요. 의미 없는 조사·관사는 뺍니다. /blog/how-to-audit-internal-links는 괜찮고, /blog/a-guide-on-how-you-can-audit-the-internal-links-of-your-website는 아닙니다.
콘텐츠 페이지에 확장자 금지. .html, .do, .aspx는 기술 스택을 드러내고, 마이그레이션 때 눈에 보이게 깨집니다.
트레일링 슬래시 규칙 하나. 항상 붙이거나 항상 빼거나, 301로 강제합니다. 어느 쪽이든 되지만 뒤섞이면 안 됩니다.
DB가 아니라 IA를 반영하는 깊이. 상품이 개념적으로 하나의 카테고리에 속한다면 /category/product가 맞습니다. 다섯 카테고리에 속한다면 임의로 하나를 고르기보다 /products/product-name 플랫 구조가 정직하며, 대표 카테고리는 브레드크럼으로 표현하면 됩니다.
3~4단계에서 멈춥니다. 단계가 늘수록 홈에서의 클릭 수가 늘고, 크롤 우선순위와 사용자 인내심이 함께 줄어듭니다.
로케일 위치
다국어 사이트라면 로케일 세그먼트는 맨 앞입니다.
/ko/solutions/thermal
/en/solutions/thermal
/solutions/ko/thermal도, /solutions/thermal?lang=ko도 아닙니다. 로케일이 맨 앞에 있으면 라우팅, 애널리틱스, 사이트맵 분리, 캐시 규칙, hreflang 생성이 모두 하나의 경로 접두사로 처리됩니다. /ko/로 스코프를 건 크롤러가 정확히 한국어 사이트만 크롤하게 된다는 점도 중요합니다.
국가 코드(kr, us)가 아니라 언어 코드(ko, en, ja)를 쓰세요. 언어가 아니라 시장 단위로 사이트를 분리한 경우가 아니라면 그렇습니다. 이 구분은 hreflang을 붙일 때 결정적입니다. kr은 유효한 언어 값이 아닙니다.
기본 언어에도 접두사를 붙여야 할까요? 붙이는 쪽이 낫습니다. 영어는 루트, 한국어만 /ko/인 구조보다 /en/과 /ko/가 대칭인 구조가 이후 모든 규칙을 단순하게 만듭니다.
파라미터
파라미터는 별도 색인이 필요 없는 '질의 변형'에는 적합합니다.
?page=2— 페이지네이션?sort=price— 정렬?q=keyword— 검색
하지만 콘텐츠의 기본 주소 체계로는 부적합합니다. ?id=88271은 DB 키를 인터페이스로 노출한 것입니다.
파라미터가 크롤 문제로 번지지 않게 하는 두 가지 규칙이 있습니다.
- 순서와 대소문자가 결정적이어야 합니다.
?a=1&b=2와?b=2&a=1이 모두 접근 가능해서는 안 됩니다. - 트래킹 파라미터(
utm_*,fbclid,gclid)는 내부 링크에 절대 등장하면 안 되고, 페이지는 이를 제거한 형태로 canonical을 잡아야 합니다.
AttractiveWebAI의 크롤러는 정규화 단계에서 이들을 자동 제거합니다. 이유는 단순합니다. 정규화가 없으면 캠페인 태그 다섯 개가 붙은 한 페이지가 여섯 페이지처럼 보이고, 그 지점에서 크롤 예산 문제가 시작됩니다.
트래픽을 잃지 않고 URL 바꾸기
언젠가 리뉴얼은 구조를 바꿉니다. 실제로 통하는 순서입니다.
- 현행 URL 인벤토리 확보. 운영 사이트를 크롤링해 상태 코드·canonical·타이틀과 함께 전체 URL을 내보냅니다. (DeepAnalyzer는 이를 IA 시트로 만들어 주고, 그대로 마이그레이션 매핑표가 됩니다.)
- 구→신 1:1 매핑. 모든 구 URL에 정확히 하나의 목적지를 지정합니다. 실제로 통합되는 페이지의 N:1은 괜찮지만, 전부 홈으로 보내는 것은 안 됩니다. 위장된 소프트 404입니다.
- 302가 아니라 301. 영구는 영구입니다.
- 체인 금지. 구→신을 1홉으로. 세 번째 리뉴얼이라면 1차 리뉴얼 URL이 2차가 아니라 오늘의 URL을 가리키게 하세요.
- 내부 링크 갱신. 리다이렉트는 외부 링크와 즐겨찾기를 위한 것입니다. 내부 링크는 최종 주소를 직접 가리켜야 합니다.
- 리다이렉트는 최소 1년 유지. 외부 백링크가 있는 URL은 더 길게.
- 새 사이트맵 제출 후 4~6주간 파일별 색인 현황을 관찰합니다.
전체 마이그레이션 절차는 웹사이트 리디자인 체크리스트에서 다루고, 이 글은 그중 URL 핵심만 정리한 것입니다.
예시 설계
상품·솔루션·고객지원·뉴스룸을 갖춘 글로벌 브랜드 사이트라면 이렇게 됩니다.
/ko/ 메인
/ko/company/history 기업정보 → 연혁
/ko/solutions/thermal 솔루션 → 열관리
/ko/solutions/thermal/heat-pump 솔루션 → 열관리 → 히트펌프
/ko/products/lf21 제품 → LF21
/ko/support/faq 고객지원 → FAQ
/ko/newsroom/2026-q3-results 뉴스룸 → 아티클
/ko/legal/privacy 정책 → 개인정보
모든 경로가 브레드크럼처럼 읽히고, 모든 세그먼트가 실제 IA 노드이며, 로케일 이후 깊이는 3단계를 넘지 않고, 영문 사이트는 /en/ 아래 동일한 트리입니다. 이 대칭성이 hreflang 생성·사이트맵 분리·IA 문서화를 수작업이 아니라 기계적인 작업으로 만들어 줍니다.
자주 묻는 질문
URL에 키워드를 넣으면 순위에 도움이 되나요?
아주 미미하며, 과거보다 훨씬 약합니다. 더 강한 근거는 사람 쪽입니다. 읽기 쉬운 URL은 검색 결과에서 클릭을 얻고, 공유될 때 의미가 유지됩니다. 사람을 위해 쓰면 작은 검색 이득은 따라옵니다.
블로그 URL에 날짜를 넣어야 하나요?
대개 넣지 않는 편이 낫습니다. /blog/post-title은 계속 유효하지만 /blog/2023/03/post-title은 오래됨을 드러내고 글을 갱신하기도 애매해집니다. 보도자료나 행사처럼 시점이 본질인 콘텐츠에만 사용하세요.
플랫 구조가 중첩 구조보다 나은가요?
일반적으로 우열은 없습니다. 중첩 URL은 계층을 전달하고 섹션 단위 분석을 쉽게 합니다. 플랫 URL은 재분류가 잦은 아이템에 안정적입니다. 계층이 실제로 안정적인 곳에는 중첩을, 카테고리 간 이동이 잦은 곳에는 플랫을 쓰세요.
상품이 여러 카테고리에 속할 때 URL은?
/products/name 플랫 구조에 브레드크럼으로 대표 카테고리를 표현하세요. 다중 카테고리 상품을 하나의 경로 아래 중첩하면 중복 접근 가능 주소가 생기고, 결국 canonical로 수습해야 합니다.
URL에 한글을 써도 되나요?
기술적으로는 가능합니다. 퍼센트 인코딩되고 검색엔진도 처리합니다. 다만 메신저·메일·스프레드시트에 붙여넣는 순간 읽을 수 없는 문자열이 되는데, URL이 공유되는 곳이 바로 거기입니다. 로마자나 영문 슬러그가 안전합니다.