구조·마크업 · 공식 문서
URL 하이픈 언더바 대소문자, 표기 규칙 선택 기준
단어 구분은 하이픈(-)으로, 글자는 소문자 하나로 정합니다. 구글은 밑줄 대신 하이픈을 권장하고, URL의 대소문자를 구분해 /APPLE 과 /apple 을 다른 URL로 봅니다.
URL 표기는 개발 초기에 한 번 정하면 페이지가 늘어날수록 바꾸기 어려워집니다. 하이픈이냐 밑줄이냐는 사소해 보여도 수백 개 페이지의 URL에 그대로 박힙니다.
구글 「Google 검색의 URL 구조 권장사항」은 이 질문에 항목을 따로 두고 답했습니다. 그 원문으로 구분자와 대소문자를 고르는 기준을 정리했습니다.
발견 01
표기 후보 5가지 중 구글이 권장한 것은 하이픈 구분과 소문자 통일 2가지입니다
| 표기 | 예 | 구글 문서 판단 | 원문 |
|---|---|---|---|
| 하이픈(-)으로 구분 | /summer-clothing | 권장 | Specifically, we recommend using hyphens (-) instead of underscores (_) to separate words in your URLs, as it helps users and search engines better identify concepts in the URL.URL의 단어 구분에는 밑줄(_) 대신 하이픈(-)을 권장한다. 사용자와 검색엔진이 URL 속 개념을 더 잘 알아본다. |
| 밑줄(_)로 구분 | /summer_clothing | 권장하지 않음 | For historical reasons, we don't recommend using underscores, as underscores are commonly used for denoting concepts that should be kept together, for example, by various programming languages to name functions (such as format_date), whereas hyphens clearly signal a word boundary.관습상 밑줄은 권장하지 않는다. 밑줄은 여러 프로그래밍 언어가 함수 이름(format_date)처럼 한데 묶을 개념을 나타낼 때 흔히 쓰고, 하이픈은 단어 경계를 분명히 나타낸다. |
| 붙여 쓰기 | /greendress | 권장하지 않음 | We recommend separating words in your URLs, when possible.가능하면 URL 속 단어를 서로 나누기를 권장한다. |
| 소문자로 통일 | /apple | 권장(서버가 대소문자를 같게 처리할 때) | If upper and lower case text in a URL is treated the same by your web server, convert all text to the same case so it's easier for Google to determine that URLs reference the same page.웹 서버가 대소문자를 같게 처리한다면, 모든 글자를 한쪽으로 통일해 구글이 같은 페이지임을 쉽게 알게 하라. |
| 대소문자 섞기 | /APPLE 과 /apple | 서로 다른 URL로 처리 | Like any other HTTP client following IETF STD 66, Google Search's URL handling is case sensitive (for example, Google treats both /APPLE and /apple as distinct URLs with their own content).구글 검색의 URL 처리는 대소문자를 구분한다. /APPLE 과 /apple 을 서로 다른 URL로 본다. |
For historical reasons, we don't recommend using underscores, as underscores are commonly used for denoting concepts that should be kept together, for example, by various programming languages to name functions (such as format_date), whereas hyphens clearly signal a word boundary.
관습상 밑줄은 권장하지 않는다. 밑줄은 여러 프로그래밍 언어가 함수 이름(format_date)처럼 한데 묶을 개념을 나타낼 때 흔히 쓰고, 하이픈은 단어 경계를 분명히 나타낸다.
밑줄을 피하는 이유는 관습입니다. 프로그래밍에서 밑줄은 format_date 처럼 두 단어를 한 덩어리로 묶을 때 쓰이고, 하이픈은 단어 경계를 분명히 나타냅니다.
구글은 URL 경로에 설명하는 단어를 넣으라고도 적었습니다(원문: Add descriptive words in URL paths. The words in URLs may help Google better understand the page.) 단어를 하이픈으로 나누면 사람도 URL을 읽기 쉽습니다.
발견 02
구글은 URL의 대소문자를 구분하므로, 서버 설정에 따라 할 일이 갈립니다
| 서버 상태 | 일어나는 일 | 할 일 | 원문 |
|---|---|---|---|
| 대문자 URL이 404를 돌려줌(대소문자 구분) | 링크 하나에 대문자가 섞이면 그 링크만 404로 끊깁니다. | 내부 링크·사이트맵·캐노니컬을 소문자 URL로 맞춥니다. | Like any other HTTP client following IETF STD 66, Google Search's URL handling is case sensitive (for example, Google treats both /APPLE and /apple as distinct URLs with their own content).구글 검색의 URL 처리는 대소문자를 구분한다. /APPLE 과 /apple 을 서로 다른 URL로 본다. |
| 대문자 URL도 같은 내용으로 열림(대소문자 무시) | 같은 페이지가 두 URL로 열려 구글이 둘 다 가져가 봐야 같은 페이지인 줄 압니다. | 대문자 URL을 소문자 URL로 301 리다이렉트하고 캐노니컬도 소문자로 둡니다. | If upper and lower case text in a URL is treated the same by your web server, convert all text to the same case so it's easier for Google to determine that URLs reference the same page. Google may not realize that two URLs return the same page until after both are retrieved.웹 서버가 대소문자를 같게 처리한다면 한쪽으로 통일하라. 구글은 두 URL을 모두 가져온 뒤에야 같은 페이지임을 알 수도 있다. |
네이버 서치어드바이저도 같은 방향입니다. 가이드는 「웹 서버의 종류에 따라서 대소문자를 구분할 수 있으며, 통상적으로 소문자로 처리합니다.」라고 적었습니다.
그래서 규칙은 하나로 충분합니다. URL은 전부 소문자로 만들고, 대문자로 들어오는 요청은 소문자 URL로 보냅니다.
발견 03
이미 다른 표기로 쓰고 있다면 4가지 상황으로 나눠 판단합니다
| 상황 | 판단 | 원문 |
|---|---|---|
| 새 사이트·새 섹션을 만든다 | 처음부터 하이픈·소문자 규칙으로 시작합니다. | 검색 친화적인 URL은 사이트를 처음 구축할 시점에서 고려해야 됩니다. |
| 같은 페이지가 대소문자만 다른 URL로 열린다 | 지금 한쪽으로 모읍니다. 중복 URL이 크롤링 요청을 늘립니다. | Minimize the number of alternative URLs that return the same content to avoid Google making more requests to your site than needed.같은 내용을 돌려주는 대체 URL 수를 줄여, 구글이 필요 이상으로 사이트에 요청하지 않게 하라. |
| 밑줄 URL이 이미 색인되어 유입이 있다 | 표기만을 이유로 바꾸지 않습니다. 리뉴얼처럼 URL을 어차피 바꿀 때 함께 고칩니다. | Don't drop everything and start reorganizing your site right now though: while these suggestions can be helpful long term (especially if you're working on a larger website), search engines will likely understand your pages as they are right now, regardless of how your site is organized.그렇다고 하던 일을 다 멈추고 지금 당장 사이트를 재구성할 필요는 없다. 이 제안들은 특히 큰 사이트에서 길게 보면 도움이 되지만, 검색엔진은 사이트 구성과 상관없이 지금 상태의 페이지도 이해할 가능성이 크다. |
| URL 속 단어로 순위를 올리려 한다 | 표기는 읽기 위한 규칙입니다. 순위 효과는 탐색경로 표시 정도입니다. | From a ranking perspective, the keywords in the name of the domain (or URL path) alone have hardly any effect beyond appearing in breadcrumbs.순위 관점에서 도메인 이름이나 URL 경로 속 키워드만으로는 탐색경로에 나오는 것 말고는 영향이 거의 없다. |
색인된 URL을 바꾸면 검색엔진은 새 URL을 다시 배웁니다. 표기만을 이유로 그 비용을 치를지는 페이지 수와 유입을 보고 정합니다.
바꾸기로 했다면 리다이렉트와 내부 링크를 함께 고칩니다. 순서는 「URL 변경 SEO」 편에 자세히 적었습니다.
발견 04
같은 규칙도 B2B·B2C·B2G 사이트는 지키기 어려운 자리가 다릅니다
예시 ① 산업용 센서 제조사의 제품 사이트(B2B)
품번에 대문자가 들어가 /products/TS-200A 처럼 URL을 만들기 쉽습니다. 영업 자료에는 대문자로, 사이트 메뉴에는 소문자로 링크가 갈라집니다.
품번도 URL에서는 소문자로 적고, 대문자 요청은 소문자 URL로 301 리다이렉트합니다.
예시 ② 의류 쇼핑몰의 기획전 페이지(B2C)
기획전마다 담당자가 URL을 직접 지으면 /summer_sale 과 /winter-sale 이 섞입니다. 페이지가 쌓인 뒤에는 표기를 고치기 어렵습니다.
운영 문서에 「소문자, 하이픈 구분」 한 줄을 적어 두고, 새 기획전부터 그 규칙으로 만듭니다.
예시 ③ 공공기관 누리집의 게시판 URL(B2G)
게시판 프로그램이 /board_list 처럼 밑줄 URL을 자동으로 만드는 경우가 있습니다. 이미 색인되어 있다면 표기만 보고 바꿀 이유는 약합니다.
누리집 개편으로 URL이 어차피 바뀔 때 과업지시서에 하이픈·소문자 규칙을 넣습니다.
그럼 우리 사이트 URL 표기 규칙은 어떻게 정하나요?
- 단어 구분은 하이픈(-), 글자는 소문자로 한다는 규칙을 개발·운영 문서에 한 줄로 적습니다.
- 대문자를 섞은 URL을 열어 보고 서버가 대소문자를 구분하는지 확인합니다.
- 대문자 URL도 열린다면 소문자 URL로 301 리다이렉트를 겁니다.
- 내부 링크·사이트맵·캐노니컬에 대문자나 밑줄이 섞인 URL이 있는지 찾습니다.
- 이미 색인된 밑줄 URL은 목록으로만 두고, 다음 개편 때 리다이렉트와 함께 바꿉니다.
조사 방법
- Google Search Central 「URL structure best practices for Google Search」 (문서 수정일 2026-10-21) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/crawling-indexing/url-structure
- Google Search Central 「Designing a URL structure for ecommerce websites」 (문서 수정일 2025-12-10) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/specialty/ecommerce/designing-a-url-structure-for-ecommerce-sites
- Google Search Central 「SEO Starter Guide: The Basics」 (문서 수정일 2025-12-10) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/fundamentals/seo-starter-guide
- 네이버 서치어드바이저 「검색 친화적인 URL 구축하기」 (문서 수정일 2021-03-24) · 최종 확인일 2026-10-25 · https://searchadvisor.naver.com/guide/seo-advanced-url
- 표기 후보 5가지와 상황별 판단 4가지는 위 문서들이 적은 권장사항을 표기 선택 단위로 묶은 것입니다. 묶는 방식은 편집 판단입니다.
- 예시 ①②③은 이해를 돕기 위해 만든 가상 상황이며, 실제 기업·기관의 사례가 아닙니다.
- 원문은 영어판(hl=en)이고, 문서·항목 이름은 같은 문서 한국어판(hl=ko) 표기를 따랐습니다. 네이버 가이드는 한국어 원문입니다.