URL 구조는 프로토콜, 호스트, 경로, 쿼리 등으로 웹 자원의 주소를 구성하는 방식입니다. 페이지의 위치와 요청 조건이 일관된 규칙으로 표현되면 사용자와 검색엔진이 주소를 이해하기 쉬워집니다.
웹 페이지 URL의 주요 구성 요소
https://www.example.com/glossary/url-structure?lang=ko#examples
| 부분 | 예시 | 역할 |
|---|---|---|
| 프로토콜 | https | 브라우저가 서버와 통신할 방식 |
| 호스트 | www.example.com | 요청을 보낼 서버의 이름 |
| 경로 | /glossary/url-structure | 해당 호스트에서 요청할 자원의 경로 |
| 쿼리 | ?lang=ko | 서버에 전달할 추가 조건과 값 |
| fragment(부분 식별자) | #examples | 문서 안에서 이동할 특정 위치 |
이 예시에서 lang=ko는 서버에 전달하는 값이고, #examples는 문서 안의 위치를 가리킵니다. fragment는 HTTP 요청에 포함되지 않고 브라우저에서 처리합니다. URL의 경로가 실제 서버의 폴더나 파일 배치와 일치할 필요는 없습니다.
슬러그는 url-structure처럼 경로에서 개별 페이지를 식별하는 부분입니다. 퍼머링크는 게시물에 계속 사용할 고정 주소를 뜻하며, URL을 구성하는 특정 부분의 이름은 아닙니다.
검색 친화적 URL의 조건
Google과 네이버는 콘텐츠 분류에 맞고 사람이 이해하기 쉬운 URL 구조를 권장합니다.
- 페이지 내용을 설명하는 짧은 단어를 사용합니다.
- Google 검색을 고려할 때 단어 구분에는 밑줄보다 하이픈을 사용합니다.
- 콘텐츠 분류와 경로 구조를 일관되게 만듭니다.
- 불필요한 세션 ID와 추적 파라미터를 줄입니다.
- 경로의 대소문자를 통일합니다.
/Guide와/guide가 같은 내용을 보여도 Google은 서로 다른 URL로 처리할 수 있습니다. - 페이지 링크는
<a>태그의href속성에 목적지 URL을 적습니다. 클릭할 때만 실행되는 자바스크립트 함수에 목적지를 숨기지 않습니다.
권장: https://example.com/glossary/url-structure
지양: https://example.com/index.php?id=8273&menu=14&session=abc
두 번째 예시가 문제가 되는 이유는 쿼리 자체가 아니라 주소에서 내용을 알아보기 어렵고 세션 값에 따라 URL이 늘어날 수 있기 때문입니다. 숫자 ID나 필요한 파라미터를 모두 없애야 하는 것은 아닙니다.
한글 URL 사용의 조건
Google은 대상 사용자의 언어로 된 단어를 URL에 쓸 수 있다고 안내합니다. 한글도 사용할 수 있습니다. 다만 링크를 만들 때는 ASCII 범위 밖의 문자를 퍼센트 인코딩(percent encoding)해야 합니다. 브라우저가 한글로 표시하던 주소도 복사하면 %와 숫자, 영문자로 길게 표시될 수 있습니다.
한글 주소를 선택했다면 CMS가 생성한 링크와 복사해 공유한 링크가 모두 같은 페이지를 여는지 확인합니다. 인코딩된 주소가 길다는 이유만으로 영문 주소로 바꿀 필요는 없습니다.
파라미터 조합과 중복 URL
정렬, 필터, 추적값의 조합마다 주소가 달라지면 같은 콘텐츠에 여러 URL이 생길 수 있습니다. 검색로봇이 중복 URL을 반복해서 수집하느라 중요한 페이지의 발견이 늦어질 수도 있습니다.
추적값만 다르고 본문이 같은 주소라면 캐노니컬 태그로 대표 URL을 알리고 내부 링크와 사이트맵에도 그 주소를 씁니다. 반면 필터로 상품 목록이나 설명이 달라지고 해당 조건을 찾는 사용자에게 유용하다면 별도 페이지로 운영할지 판단해야 합니다. 내용이 다른 필터 페이지까지 무조건 기본 목록의 중복으로 처리하지 않습니다.
canonical은 검색엔진에 대표 URL을 제안하는 신호이지 크롤링 차단 명령이 아닙니다. 파라미터 조합이 무한히 늘어나는 문제라면 URL 생성 방식과 크롤링 범위도 별도로 조정해야 합니다.
운영 중 URL 변경 시 후속 작업
URL을 바꿨는데 기존 주소를 연결해 두지 않으면 검색결과나 외부 링크로 들어온 사용자가 404 오류를 만날 수 있습니다. 이전 주소와 새 주소를 대응시켜 301 리디렉션을 설정하고, 내부 링크와 canonical, 사이트맵도 새 주소로 갱신합니다. 주소를 짧게 다듬는 이익만으로 이런 이전 작업을 감수할 필요가 있는지 먼저 판단합니다.
Google 검색의 AI 기능을 겨냥하더라도 별도의 URL 문법은 필요하지 않습니다. 기존 검색 지침에 맞게 페이지를 수집할 수 있는 주소와 링크를 제공하는 것이 기본입니다.
사이트 전체 URL 구조를 확인하는 방법
사이트맵과 크롤링 결과의 공개 URL을 모아 프로토콜, 호스트, 경로, 파라미터별로 비교합니다. HTTP와 HTTPS, 대소문자, 끝 슬래시, 추적 파라미터만 다른 주소가 같은 내용을 보여 주는지 확인합니다.
같은 본문을 보여 주는 주소가 여러 개라면 각 URL의 응답 코드와 canonical을 대조합니다. Search Console의 URL 검사에서는 Google이 선택한 대표 URL이 의도한 주소와 같은지도 봅니다. Google이 선택한 대표 URL은 실시간 테스트가 아닌 저장된 URL 검사 결과에서 확인합니다.
주소를 변경했다면 이전 URL이 의도한 새 URL로 301 응답을 보내는지, 새 URL이 200으로 정상 본문을 반환하는지 확인합니다. 내부 링크와 사이트맵에 이전 주소가 남아 있으면 새 주소로 고칩니다.
자주 묻는 질문
URL에 키워드를 꼭 넣어야 하나요?
페이지 내용을 설명하는 단어를 자연스럽게 사용할 수 있습니다. 키워드를 반복하거나 문장 전체를 넣어 주소를 길게 만들 필요는 없습니다.
하이픈과 밑줄 중 무엇을 써야 하나요?
Google은 단어를 구분할 때 하이픈 사용을 권장합니다. 사이트 전체에서 같은 규칙을 유지하세요.
fragment로 서로 다른 페이지를 만들어도 되나요?
검색에 노출할 별도 페이지라면 fragment만 바꿔 구별하지 않습니다. Google은 일반적으로 fragment를 지원하지 않으며, 네이버도 부분 식별자로 다른 콘텐츠를 구분하지 말고 독립 URL을 제공하라고 안내합니다. 문서 안의 특정 제목으로 이동하는 목차 링크에는 fragment를 쓸 수 있습니다.
함께 알아두면 좋은 용어
- 쿼리 파라미터: URL의
?뒤에서 서버에 추가 조건과 값을 전달하는 부분 - fragment: 같은 문서 안의 위치를 나타내는
#이후 부분 - 캐노니컬 태그: 중복 URL 중 대표 URL 선호를 전달하는 신호
- 301 리디렉션: 기존 URL 요청을 새 주소로 영구 이전하는 처리