구글이 권장하는 URL 구조의 기본 원칙

구글은 방문자가 쓰는 언어로 된 간단하고 서술적인 단어를 써서 URL을 논리적으로, 사람이 이해할 수 있는 방식으로 구성하라고 권장합니다. 숫자 ID나 임의의 해시값만으로 구성된 URL은 서버 입장에서는 효율적일지 몰라도, 사람이 그 URL만 보고 어떤 페이지인지 짐작할 수 없다는 점에서 검색엔진 역시 같은 어려움을 겪습니다.

하이픈과 밑줄, 왜 이렇게까지 구분하나

구글은 URL에서 하이픈(-)은 단어 사이 공백으로, 밑줄(_)은 단어를 이어붙이는 문자로 해석합니다. 즉 "floral-midi-dress"는 "플로럴", "미디", "드레스" 세 단어로 각각 인식되지만, "floral_midi_dress"는 하나로 붙은 단어처럼 처리될 수 있어 검색어와의 매칭 정확도에 미묘한 차이를 만듭니다. 이미 밑줄로 구축된 사이트를 전면 교체하기보다는, 신규 페이지부터 하이픈 규칙을 적용하고 기존 URL은 캐노니컬·리다이렉트로 관리하는 편이 현실적입니다.

파라미터가 많은 URL이 크롤링에 주는 부담

파라미터가 많고 복잡한 URL은 사실상 동일하거나 유사한 콘텐츠를 가리키는 URL 수를 불필요하게 늘려 구글봇이 대역폭을 낭비하거나 사이트 전체를 완전히 인덱싱하지 못하게 만들 수 있습니다. 상품 목록에 정렬·필터 파라미터가 여러 개 조합되는 이커머스몰이라면, 이 조합 전부가 별개의 크롤링 대상 URL이 될 수 있다는 점을 인지하고 설계해야 합니다.

URL 뎁스는 왜 3~4단계를 기준으로 잡나

URL을 사이트의 콘텐츠 계층을 반영하도록 구조화하되 뎁스를 3~4단계 최대로 유지하는 것은 사용자와 검색엔진 모두가 페이지 관계를 이해하는 데 도움이 됩니다. "/여성의류/원피스/브랜드명/상품명"처럼 뎁스가 지나치게 깊어지면 홈페이지에서부터 그 페이지에 도달하기까지 클릭 수가 늘어나고, 이는 크롤러가 그 페이지를 상대적으로 덜 중요하게 평가하는 신호로 작용할 수 있습니다.

불용어를 URL에서 걷어내는 기준

"그리고", "의", "에서" 같은 불용어는 가독성에 꼭 필요한 경우가 아니면 URL에서 빼는 것이 권장됩니다. 다만 이 규칙을 기계적으로 적용하다 의미가 통하지 않는 어색한 URL이 되면 오히려 사람이 이해하기 어려워지므로, 불용어 제거는 가독성을 해치지 않는 선에서만 적용해야 합니다.

breadcrumbs와 URL 구조를 함께 설계해야 하는 이유

화면에 보이는 breadcrumbs 내비게이션(예: 홈 > 여성의류 > 원피스)과 실제 URL 경로 구조를 일치시켜두면, 사용자가 주소창만 보고도 현재 위치를 파악할 수 있고 구글도 이 계층 구조를 리치 스니펫의 경로 표시에 활용할 수 있습니다. breadcrumbs 화면과 실제 URL 구조가 서로 다르게 설계된 사이트는 이런 이점을 놓치게 됩니다.

기존 URL 구조를 바꾸고 싶을 때의 절차

이미 운영 중인 사이트의 URL 구조를 대대적으로 바꾸는 것은 사실상 9강에서 다룬 이관 작업과 같은 리스크를 지니므로, 전체 URL 매핑표와 301 리다이렉트 계획 없이 URL 구조만 따로 바꾸는 결정은 지양해야 합니다. 신규 섹션을 만들 때만 새 URL 규칙을 적용하고, 기존 섹션은 별도 프로젝트로 계획해 진행하는 편이 안전합니다.

URL 파라미터를 써야 할 때의 최소 규칙

검색·필터처럼 파라미터가 불가피한 경우에는 파라미터명과 값 사이에 등호를, 서로 다른 파라미터 사이에는 앰퍼샌드를 쓰고 콜론·대괄호·쉼표 같은 문자는 피하는 것이 구글의 URL 구조 권장 사항입니다. 이 규칙을 지키지 않으면 일부 크롤러나 도구가 URL을 잘못 파싱해 엉뚱한 페이지로 처리하는 부작용이 생길 수 있습니다.

다국어·다지역 사이트에서 URL 구조가 더 복잡해지는 이유

언어별·국가별로 콘텐츠를 나누는 사이트라면 URL 경로에 언어 코드를 넣을지, 서브도메인을 나눌지, 별도 도메인을 쓸지부터 결정해야 하며 이 결정이 이후 hreflang 태그 설계와도 맞물립니다. 이 구조를 나중에 바꾸는 것은 사실상 전체 이관과 같은 작업이 되므로, 다국어 확장 계획이 있다면 URL 구조를 초기 설계 단계에서부터 염두에 둬야 합니다.

소문자 통일과 대소문자 혼용이 만드는 중복 문제

서버 설정에 따라 대문자와 소문자로 된 같은 경로가 서로 다른 URL로 인식되는 경우가 있어, 예를 들어 "/Product/Dress"와 "/product/dress"가 별개의 페이지로 크롤링되면 6강에서 다룬 중복 콘텐츠 문제가 URL 구조 단계에서부터 발생하게 됩니다. URL은 소문자로 통일하는 규칙을 초기에 정해두고, 이미 대소문자가 혼재된 사이트라면 한쪽으로 통일한 뒤 나머지를 리다이렉트하는 정리 작업이 필요합니다.