주소만 보고 페이지 역할을 설명할 수 있는가
URL은 브라우저 주소창과 검색결과, 공유 메시지, 분석 보고서에서 반복해서 보인다. 먼저 홈페이지·서비스·상품·예약·공지·블로그 등 대표 페이지 10개를 표로 모으고, 주소만 읽어도 무엇을 다루는 페이지인지 말해 본다. 숫자 ID나 의미 없는 문자열만 남아 설명이 어렵다면 개선 후보로 표시한다. 다만 기존 주소를 보기 좋게 만들겠다는 이유만으로 즉시 바꾸지는 않는다. 이미 공개된 URL은 외부 링크와 고객의 즐겨찾기, 검색엔진 기록에 연결되어 있을 수 있기 때문이다.
페이지 주제를 나타내는 단어를 고른다
새 주소에는 페이지의 실제 내용을 대표하는 단어만 넣는다. 예를 들어 매장 이용 안내라면 /visit-guide/, 환불 정책이라면 /refund-policy/처럼 주소와 본문의 역할이 맞아야 한다. Google은 사람이 이해할 수 있는 설명형 단어와 이용자의 언어를 권장한다. 한국어와 영문 중 하나가 절대적으로 우월한 것은 아니므로 운영 도구의 호환성과 팀의 작성 편의성을 기준으로 선택하되, 같은 유형의 페이지에서는 한 규칙을 유지한다. 검색어를 반복하거나 지역명·서비스명을 무리하게 이어 붙이는 방식은 피한다.
하이픈과 소문자로 표기 규칙을 통일한다
여러 단어를 구분할 때는 하이픈(-)을 사용하고, 공백·밑줄·불필요한 기호는 섞지 않는다. Google 공식 지침도 단어 구분에 하이픈을 권장한다. 대문자와 소문자가 다른 주소로 처리되는 서버가 있으므로 새 URL은 소문자 기준으로 통일하면 관리 실수를 줄이기 쉽다. 날짜는 뉴스처럼 시점이 핵심인 콘텐츠에만 쓰고, 상품번호나 내부 관리코드는 고객에게 꼭 필요한 경우에만 노출한다. 최종 규칙은 ‘소문자 영문, 단어는 하이픈, 한 주소에 한 주제’처럼 한 줄로 문서화한다.
폴더는 고객의 탐색 구조에 맞춘다
폴더는 조직 내부 부서가 아니라 고객이 찾는 정보 묶음을 기준으로 정한다. /services/ 아래에 서비스 상세 페이지를, /locations/ 아래에 지점 페이지를 두는 식이다. 같은 내용이 /product/, /item/, /shop/처럼 여러 경로에 흩어지면 담당자도 주소를 예측하기 어렵다. 반대로 모든 정보를 지나치게 깊게 넣을 필요도 없다. 판단 기준은 세 가지다. 상위 폴더가 같은 주제를 묶는가, 주소가 메뉴 구조와 모순되지 않는가, 새 페이지를 어디에 둘지 담당자가 바로 결정할 수 있는가를 확인한다.
중복 주소와 매개변수를 분리해 점검한다
검색·필터·정렬·광고 추적 기능은 같은 본문에 여러 주소를 만들 수 있다. 물음표 뒤 매개변수가 붙은 URL, 대소문자만 다른 URL, 끝 슬래시 유무가 다른 URL을 표본으로 열어 본다. 각각의 주소가 별도 페이지로 필요한지, 하나의 대표 URL로 모아야 하는지 구분한다. 대표 주소를 정했다면 canonical 설정과 내부 링크가 그 주소를 가리키는지 함께 확인한다. 매개변수를 모두 삭제하는 식의 일괄 처리는 기능을 깨뜨릴 수 있으므로 개발 환경에서 주문·예약·검색 동작을 먼저 시험한다.
변경 전후 6항목을 함께 확인한다
기존 URL을 바꿔야 한다면 주소 변경만으로 끝내지 않는다. ① 기존 주소에서 새 주소로 301 리디렉션이 되는가 ② 메뉴와 본문 내부 링크가 새 주소를 가리키는가 ③ canonical이 새 주소와 일치하는가 ④ XML 사이트맵에 새 주소만 남았는가 ⑤ 이전 주소가 404나 리디렉션 반복으로 끝나지 않는가 ⑥ 예약·문의·결제 기능이 정상 작동하는가를 점검한다. 변경표에는 기존 URL, 새 URL, 변경 이유, 적용일, 확인 담당자를 기록한다. 새 페이지에는 정한 규칙을 적용하고, 기존 페이지는 명확한 필요와 전환 계획이 있을 때만 바꾸는 것이 안전하다.