카테고리·필터 페이지 SEO, 패싯 내비게이션 관리법
필터가 만드는 중복 URL, 색인할 조합과 막을 조합을 구분하는 기준과 robots.txt·canonical·noindex 적용법을 정리합니다.
쇼핑몰이나 정보성 사이트에서 카테고리 페이지에 색상·가격·브랜드 같은 필터(패싯)를 달아 두면, 필터를 조합할 때마다 새 주소(URL)가 만들어진다. 상품 1,000개에 필터가 5종류, 필터마다 값이 10개씩만 있어도 이론상 조합 가능한 URL은 수백만 개에 이른다.
결론부터 말하면 이렇다. 검색 수요와 전환 가능성이 모두 있는 조합만 색인을 허용하고, 나머지는 robots.txt·canonical 태그·noindex 중 상황에 맞는 도구로 정리해야 한다. 세 도구를 섞어 쓰면 오히려 구글을 혼란스럽게 하므로, 도구마다 언제 쓰는지 원칙을 먼저 정해야 한다는 점이 이 글의 핵심이다.
카테고리·필터 페이지 관리를 잘못하면 벌어지는 일은 단순하다. 크롤러가 의미 없는 정렬·필터 조합에 시간을 쓰느라, 정작 새로 올린 중요한 페이지는 색인이 늦어진다. 순위 신호도 수백 개 URL로 흩어져 어느 하나도 힘을 받지 못한다.
이 문제는 상품 수만 개짜리 대형 쇼핑몰만의 이야기가 아니다. 상품 200개, 필터 3종류 정도만 돼도 실제 조합은 수천 개 단위로 늘어난다. 필터 기능을 새로 넣는 순간부터 규칙이 필요하다는 뜻이다. 이 글은 쇼핑몰뿐 아니라 부동산 매물, 구인구직, 여행·숙박처럼 필터형 목록 페이지를 쓰는 모든 사이트에 그대로 적용된다.
이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.
- 패싯 내비게이션이 왜 대형 쇼핑몰만이 아니라 중소형 사이트에도 문제가 되는지
- 색인할 필터와 막을 필터를 가르는 검색 수요 × 전환 가능성 판단 기준
- robots.txt·canonical 태그·noindex를 상황별로 구분해 쓰는 법과 흔한 충돌 사례
- 자바스크립트로 필터를 구현하면 정말 안전한지에 대한 현실적인 답
- 서버 로그로 크롤 낭비를 직접 확인하는 법
- 쇼핑몰과 블로그·정보성 사이트의 카테고리 페이지를 다르게 접근해야 하는 이유
패싯 내비게이션이 뭐길래 크롤 예산을 다 먹나요?
패싯 내비게이션은 카테고리 페이지에서 색상·사이즈·가격대·브랜드 같은 조건으로 상품이나 글을 좁혀 보는 필터 기능이다. 사용자에게는 편리하지만, 필터를 선택할 때마다 ?color=red&size=m 같은 파라미터가 붙은 새 URL이 생기는 경우가 많다는 게 문제다.
숫자로 보면 이 문제는 금방 이해된다. 상품 1,000개에 필터 5종류, 필터마다 값이 10개면 이론상 조합 가능한 URL은 수백만 개까지 늘어난다. 실제로 대형 쇼핑몰에서 필터 기능을 추가한 뒤 색인된 페이지 수가 수십만 개에서 수백만 개로 튄 사례도 보고된 바 있다.
구글은 전통적으로 발견한 URL을 하나씩 크롤링하는 방식을 써 왔고, 최근에는 엔티티와 검색 의도 기반의 판단을 함께 활용해 수요가 있는 조합("빨간 러닝화" 같은)의 우선순위를 높이는 쪽으로 변하고 있다. 그렇다고 필터 URL을 방치해도 된다는 뜻은 아니다.
필터 페이지 자체가 나쁜 것이 아니다. 기준 없이 모든 조합을 크롤러에게 열어 두는 것이 문제다.
문제의 핵심은 결국 크롤 예산이다. 크롤 버짓(크롤링 예산, 검색엔진 로봇이 한 사이트를 방문해 페이지를 읽는 데 쓰는 시간과 자원의 총량)에 대해서는 크롤 버짓 완벽 가이드에서 더 자세히 다뤘으니 개념이 낯설다면 먼저 읽어 보는 것을 권한다. 필터 URL이 크롤 예산을 잠식하면, 정작 색인돼야 할 신상품·신규 글의 발견이 늦어진다.
실제로 자주 관찰되는 흐름은 이렇다. 필터 기능을 새로 추가한 지 몇 주 뒤, 서치 콘솔의 색인 생성 보고서에서 "중복, 사용자가 선택한 것과 다른 정규 URL"이나 "발견됨-현재 색인되지 않음" 상태의 URL이 갑자기 급증한다. 이 시점에 원인을 찾아보면 십중팔구 필터 조합이 만들어낸 URL이 원인이다. 문제가 커지기 전에, 필터 기능을 기획하는 단계에서부터 색인 규칙을 함께 설계하는 편이 사후에 정리하는 것보다 훨씬 수월하다.
색인할 필터와 막을 필터, 어떻게 구분하나요?
기준은 하나다. 검색 수요가 있고, 그 조합으로 들어온 방문자가 실제로 전환할 가능성이 있는 페이지만 색인 대상으로 남긴다. 둘 중 하나라도 낮으면 색인에서 빼는 쪽이 안전하다.
예를 들어 "여성 러닝화"처럼 사람들이 실제로 검색하는 조합은 검색 수요와 전환 가능성이 모두 높으니 독립된 카테고리 페이지로 만들어 적극적으로 색인시킬 가치가 있다. 반면 "가격 5만 3천 원–5만 4천 원" 같은 세밀한 가격 구간 필터는 아무도 그렇게 검색하지 않으므로 색인할 이유가 없다.
이 판단은 감이 아니라 데이터로 한다. 네이버·구글 키워드 도구로 필터 조합의 실제 검색량을 확인하고, 서치 콘솔의 검색어 보고서에서 이미 유입되고 있는 조합이 있는지도 함께 봐야 한다. 검색량이 확인되면 그 조합만 정식 카테고리 페이지(고유한 제목·설명·소개 문구를 갖춘)로 승격시키는 편이 좋다.
매트릭스의 네 칸을 각각 풀어 보면 이렇다. 검색 수요와 전환 가능성이 모두 높은 칸은 독립 페이지로 적극 육성할 대상이고, 수요는 있지만 전환 가능성이 낮은 칸(예: 단순 정보 탐색용 조합)은 색인은 시키되 상품 개수를 늘리기보다 콘텐츠 설명에 더 신경 쓸 대상이다. 수요는 낮지만 전환 가능성이 있는 칸(재구매 고객이 즐겨찾기로 접근하는 세부 필터 등)은 색인 없이 canonical로 정리해도 실제 매출에는 영향이 적고, 둘 다 낮은 칸은 망설임 없이 정리 대상으로 분류하면 된다.
나머지, 즉 검색 수요가 거의 없는 세부 필터 조합에는 아래에서 설명할 robots.txt·canonical 태그·noindex 세 가지 도구를 상황에 맞게 적용한다. 이 판단표 하나만 조직 내에서 합의해 둬도, 개발팀과 마케팅팀 사이에 "이 필터는 새 URL을 만들어도 되는가"를 두고 벌어지는 반복 논쟁이 크게 줄어든다.
업종마다 색인할 조합과 막을 조합은 다르게 나타난다. 실제 판단에 바로 쓸 수 있도록 업종별 예시를 정리하면 다음과 같다.
| 업종 | 색인할 조합(검색 수요·전환 있음) | 막을 조합(검색 수요 거의 없음) |
|---|---|---|
| 쇼핑몰 | 나이키 러닝화, 여성 슬랙스, 겨울 패딩 | 색상+사이즈+브랜드+가격대 4중 조합 |
| 부동산 매물 | 강남구 아파트 전세, 판교 오피스텔 매매 | 평수 1제곱미터 단위 세부 필터 |
| 여행·숙박 | 제주도 호텔, 부산 게스트하우스 | 특정 날짜+인원+가격대 3중 조합 |
| 구인구직 | 서울 마케팅 채용, 재택근무 개발자 | 연봉 100만 원 단위 세부 구간 |
표에서 보듯 "사람이 실제로 그렇게 검색하는가"가 판단의 출발점이다. 색상 하나, 가격 구간 하나처럼 세부 조건이 여러 겹 겹칠수록 검색 수요는 급격히 사라지므로, 조합이 두세 겹을 넘어가면 대부분 막는 쪽이 안전하다.
이 원칙을 팀 안에서 문서화할 때는 다음과 같은 3줄짜리 공식을 그대로 써도 된다.
- 이 필터 조합으로 실제 검색되는 키워드가 있는가 — 있으면 2번, 없으면 곧바로 canonical 처리.
- 그 키워드로 들어온 방문자가 전환(구매·문의·지원)할 가능성이 있는가 — 있으면 독립 페이지로 승격.
- 승격한 페이지에는 고유한 제목·설명·소개 문구를 반드시 채워, 다른 필터 페이지와 콘텐츠가 겹치지 않게 한다.
robots.txt로 막아야 하는 파라미터는 무엇인가요?
검색 가치가 전혀 없는 파라미터는 robots.txt에서 아예 크롤링을 막는다. 대표적으로 세션 ID, 정렬 순서(?sort=price_asc), 페이지 내부에서만 쓰는 추적 파라미터가 여기 해당한다.
Disallow: /*?sort=
Disallow: /*sessionid=
이렇게 막으면 크롤러가 아예 그 URL을 방문하지 않으므로 크롤 예산이 절약된다. 다만 이미 색인이 된 URL은 robots.txt 차단만으로는 검색 결과에서 빠지지 않는다는 점을 조심해야 한다. robots.txt는 앞으로의 크롤링을 막을 뿐, 이미 색인된 페이지를 지우는 도구가 아니다.
robots.txt 문법 자체가 낯설다면 robots.txt란? 검색엔진 크롤링 제어 쉽게 정리에서 기본 문법과 흔한 실수를 먼저 확인하는 것이 좋다. 이미 색인된 저가치 URL을 빼려면 noindex 메타 태그를 먼저 적용해 구글이 다시 방문해 제거하게 만든 다음, 충분한 시간이 지난 뒤에 robots.txt로 크롤링까지 막는 순서가 안전하다.
robots.txt는 "가지 말라"는 안내판이지, "이미 있는 것을 지워라"는 명령이 아니다.
나쁜 예와 좋은 예를 나란히 보면 차이가 명확해진다. 나쁜 예는 Disallow: /category/처럼 카테고리 경로 전체를 통째로 막는 것이다. 이렇게 하면 색인시켜야 할 정식 카테고리 페이지까지 함께 차단돼 버린다.
좋은 예는 검색 가치가 없는 파라미터만 정확히 지정하는 것이다.
User-agent: *
Disallow: /*?sort=
Disallow: /*?sessionid=
Disallow: /*&page=99
Allow: /category/
이렇게 파라미터 단위로 정밀하게 막으면, 정식 카테고리 경로는 그대로 열어 두면서 낭비성 조합만 걸러낼 수 있다.
robots.txt를 수정한 뒤에는 반드시 서치 콘솔의 robots.txt 보고서에서 규칙이 의도한 대로 적용되는지 확인해야 한다. 정규 표현식 패턴 하나만 잘못 써도 색인시켜야 할 정식 페이지까지 함께 막아 버리는 사고로 이어질 수 있기 때문이다. 규칙을 바꾼 직후에는 대표 URL 몇 개를 직접 테스트해 차단 여부를 눈으로 확인하는 습관을 들이는 것이 안전하다.
canonical 태그, 언제 쓰고 뭘 조심해야 하나요?
사용자 경험에는 필요하지만 별도로 순위를 받을 필요는 없는 필터에는 canonical 태그를 쓴다. 예를 들어 /shoes?color=red처럼 색상 하나만 바뀌는 필터 페이지는 부모 페이지인 /shoes를 정규 URL로 지정한다.
canonical 태그의 기본 문법과 자기참조 원칙은 중복 콘텐츠와 canonical 태그 — 순위 손해 막는 법에서 자세히 다뤘다. 필터 페이지 <head>에는 다음과 같이 넣는다.
<!-- /shoes?color=red 페이지의 head -->
<link rel="canonical" href="https://내도메인.com/shoes" />
패싯 페이지에 적용할 때 특히 조심할 점은 일관성이다.
흔한 실수는 어떤 필터 조합은 자기 자신을 canonical로 쓰고, 비슷한 다른 조합은 부모 페이지를 가리키는 식으로 규칙이 뒤섞이는 것이다. 이렇게 신호가 충돌하면 구글은 어느 쪽을 믿어야 할지 판단하지 못하고, 결국 구글이 자체적으로 정규 URL을 다시 정해 버리는 경우도 생긴다.
원칙은 간단하게 정리할 수 있다. "이 필터 조합이 색인용 후보인가, 단순 UX 보조 기능인가"를 먼저 정하고, 후자라면 예외 없이 같은 규칙(대개는 부모 카테고리를 canonical로)을 적용한다. 필터가 여러 개 동시에 걸린 조합(?color=red&size=m)도 마찬가지로 일관되게 부모를 가리키게 한다.
여기까지 나온 네 가지 도구를 한눈에 비교하면 다음과 같다.
| 도구 | 크롤링 | 색인 | 링크 신호 전달 | 적합한 경우 |
|---|---|---|---|---|
| robots.txt 차단 | 안 함 | 되지 않음(신규 URL 기준) | 전달 안 됨 | 세션 ID·정렬 등 검색 가치가 전혀 없는 파라미터 |
| canonical 태그 | 함 | 부모로 통합 | 부모로 전달 | UX상 필요하지만 별도 순위가 필요 없는 필터 |
| noindex, follow | 함 | 되지 않음 | 다른 페이지로 전달 | 순위는 불필요해도 링크 가치는 살리고 싶을 때 |
| 자바스크립트 구현 | 새 URL 없음 | 해당 없음 | 해당 없음 | 정렬처럼 콘텐츠 자체는 그대로인 필터 |
표에서 볼 수 있듯 robots.txt와 canonical을 같은 URL에 동시에 걸면 안 된다. robots.txt로 막힌 페이지는 크롤러가 방문하지 못하므로, 그 안에 적어 둔 canonical 태그를 구글이 아예 읽을 수 없기 때문이다.
의외로 자주 놓치는 부분은 파라미터 순서다. ?color=red&size=m과 ?size=m&color=red는 사람 눈에는 같은 필터지만, 시스템에 따라 서로 다른 URL로 인식돼 각각 콘텐츠가 중복 생성될 수 있다. 개발 단계에서 파라미터 순서를 알파벳순 등으로 고정해 항상 같은 형태의 URL만 생성되게 만들면, canonical 태그를 붙이기도 전에 중복 URL 자체가 절반으로 줄어든다.
noindex, follow는 언제 쓰나요? 부작용은 없나요?
순위에는 필요 없지만 그 페이지가 가진 링크 가치는 다른 페이지로 전달하고 싶을 때 noindex, follow 메타 로봇 태그를 쓴다. 정렬 순서만 바뀌는 페이지, 재고 임시 소진으로 상품이 거의 안 남은 필터 조합이 대표적인 예다.
<meta name="robots" content="noindex, follow" />
이 방식의 장점은 명확하다. 저가치 페이지는 검색 결과에서 빠지면서도, 그 페이지가 내부적으로 연결하고 있는 다른 페이지로는 여전히 링크 신호가 흘러간다. canonical 태그처럼 "이 페이지는 존재하지 않는 척"하지 않고, "존재는 하되 검색에는 노출하지 않는다"는 뜻을 명확히 전달하는 셈이다.
다만 부작용도 분명히 있다. noindex 상태를 너무 오래 유지하면, 구글이 그 URL을 "어차피 색인 안 하는 페이지"로 판단해 아예 크롤링 우선순위에서도 제외해 버릴 수 있다. 링크 가치를 전달할 목적이라면 정기적으로 해당 페이지가 여전히 크롤링되고 있는지 서치 콘솔에서 확인하는 편이 좋다.
실무에서 noindex를 쓰기 좋은 상황은 두 가지로 나뉜다. 하나는 재고가 일시적으로 소진된 필터 조합처럼 곧 다시 색인될 가능성이 있는 페이지이고, 다른 하나는 특정 시즌에만 잠깐 쓰는 "설 연휴 특가" 같은 한시적 필터 페이지다. 두 경우 모두 페이지 자체는 남겨 두되 검색 노출만 잠시 꺼 두는 것이 목적이므로 noindex가 적합하다.
반대로 앞으로 다시 쓸 일이 없는 필터라면 noindex보다 아예 페이지를 삭제하고 404나 301 리다이렉트로 처리하는 편이 낫다. 쓰지 않는 페이지를 noindex 상태로만 방치하면 사이트 안에 불필요한 URL이 계속 쌓여, 나중에 어떤 것이 진짜 관리 대상인지 파악하기 더 어려워진다.
정리하면, canonical은 존재하되 흡수시킬 페이지, noindex는 존재하되 잠시 감출 페이지, 삭제는 더 이상 필요 없는 페이지로 역할을 나눠 기억해 두면 실무에서 헷갈릴 일이 크게 줄어든다. 세 가지 처리 방식을 하나의 원칙표로 정리해 개발팀과 공유해 두면, 새로운 필터가 추가될 때마다 같은 기준으로 빠르게 판단할 수 있다.
canonical과 noindex는 비슷해 보이지만 역할이 다르다. canonical은 "진짜 주소는 저기다", noindex는 "이 주소는 검색에 내보내지 마라"는 뜻이다. 둘을 같은 페이지에 충돌하게 넣으면 안 된다.
자바스크립트로 필터를 구현하면 정말 안전한가요?
정렬처럼 이미 있는 콘텐츠의 순서만 바꾸는 필터라면, 새 URL 없이 자바스크립트로 화면만 갱신하는 방식이 가장 깔끔하다. URL이 아예 생기지 않으니 크롤러가 방문할 대상 자체가 늘지 않는다.
다만 모든 필터를 이 방식으로 처리할 수 있는 것은 아니다. "여성 러닝화"처럼 검색 수요가 있어 독립 페이지로 키우고 싶은 필터 조합은 오히려 정식 URL과 고유한 콘텐츠를 갖춘 페이지로 만들어야 색인·유입이 가능하다. 자바스크립트 방식은 "색인이 필요 없는 필터"에만 어울리는 선택지다.
또 하나 조심할 점은 필터 상태가 URL에 전혀 반영되지 않으면 사용자가 그 결과를 북마크하거나 공유할 수 없다는 UX 손실이다. 그래서 실무에서는 검색 수요가 없는 세부 필터는 자바스크립트로, 검색 수요가 있는 조합은 정식 URL과 canonical 규칙을 갖춘 페이지로 이원화하는 방식을 가장 많이 쓴다.
기술적으로는 history.pushState로 URL 표시만 바꾸고 실제로는 새로운 페이지를 서버에 요청하지 않는 방식이 흔히 쓰인다. 구글봇이 자바스크립트를 렌더링할 수 있다는 사실과, 그 URL을 독립된 색인 대상으로 취급할지는 별개의 문제라는 점을 기억해야 한다. 렌더링이 되더라도, 애초에 새 URL 자체가 생기지 않으면 색인 대상도 늘지 않는다는 것이 이 방식의 핵심 효과다.
구조화 데이터로 필터 페이지의 의미를 더 명확히 알릴 수 있나요?
그렇다. 정식 카테고리 페이지로 남기기로 한 필터 조합에는 ItemList·Product·BreadcrumbList 구조화 데이터(JSON-LD)를 함께 넣어 주는 것이 좋다. 구글과 AI 검색 모두에게 그 페이지가 무엇을 나열하는 목록인지 명확한 신호를 주기 때문이다.
카테고리 페이지에는 나열된 상품들을 ItemList 스키마로, 각 상품 카드는 가격·재고 상태를 담은 Product 스키마로 표시할 수 있다. 색상·사이즈 같은 속성값도 구조화 데이터 안에 함께 넣으면, 구글이 "이 페이지는 빨간색 러닝화를 모아 놓은 목록"이라는 것을 문장을 분석하지 않고도 데이터만으로 파악한다.
카테고리 계층 구조는 BreadcrumbList 스키마로 함께 표시한다. 브레드크럼(탐색경로) 완벽 가이드에서 다룬 것처럼, "홈 > 신발 > 러닝화 > 여성 러닝화"처럼 계층을 명확히 보여주면 구글이 상위·하위 카테고리 관계를 정확히 이해한다.
색인시키지 않기로 한 필터 조합(canonical·noindex 처리된 페이지)에는 굳이 구조화 데이터를 별도로 넣을 필요가 없다. 힘을 쏟아야 할 곳은 색인하기로 결정한 소수의 정식 카테고리 페이지다.
이렇게 엔티티(색상·사이즈·브랜드 같은 구체적 속성)를 구조화 데이터로 명확히 밝혀 두는 작업은 최근 늘어나는 AI 검색 인용 대응(GEO)에도 그대로 도움이 된다. AI가 답변을 생성할 때도 애매한 문장보다 명확한 속성 데이터를 더 신뢰하는 경향이 있기 때문이다.
우리 사이트 크롤 낭비, 어떻게 확인하나요?
말로만 판단하지 말고 서버 로그를 직접 봐야 한다. 크롤러가 어떤 URL 패턴을 얼마나 자주 방문하는지 로그에 고스란히 남기 때문이다.
Screaming Frog의 로그 파일 분석기, Oncrawl 같은 도구로 로그를 열어 보면 구글봇이 반복적으로 방문하는 패턴이 드러난다. 실무에서는 필터·정렬 파라미터가 붙은 URL에 전체 크롤 요청의 3분의 1 이상이 쓰이는 사례도 드물지 않게 나온다.
로그를 열어 보기 전까지는 "우리 사이트는 크롤 예산 문제가 없다"고 자신하지 않는 편이 좋다. 중소형 사이트도 필터 조합이 몇 개만 겹치면 수천 개 URL이 순식간에 생긴다.
로그 분석이 부담스럽다면 최소한 서치 콘솔의 색인 생성 > 페이지 보고서에서 "발견됨-현재 색인되지 않음", "중복, 사용자가 선택한 것과 다른 정규 URL" 같은 상태의 URL이 얼마나 되는지부터 확인한다. 이 상태의 URL이 많다면 필터 페이지 관리 규칙을 다시 점검해야 한다는 신호다.
서버 로그 접근 권한이 없는 경우라면 서치 콘솔의 설정 > 크롤링 통계 보고서도 참고할 만하다. 여기서는 구글봇이 최근 하루하루 몇 번이나 사이트를 방문했는지, 응답 코드별 비율은 어떤지 큰 그림으로 볼 수 있다. 파일 형식별 크롤링 요청 비중에서 HTML 페이지 요청이 유난히 많은데 신규 색인 속도는 느리다면, 필터 URL이 그 요청량을 차지하고 있을 가능성을 의심해 볼 수 있다.
점검 순서는 다음처럼 잡으면 된다.
- 서버 로그(또는 CDN 로그)에서 최근 7–14일치를 확보해 구글봇 요청만 걸러낸다.
- URL을 경로별로 그룹화해, 파라미터가 붙은 요청 비율을 계산한다.
- 그 비율이 전체의 20–30퍼센트를 넘어가면, 어떤 파라미터가 가장 많은지부터 robots.txt·canonical 규칙에 반영한다.
로그에서는 대개 이런 패턴이 반복해서 보인다. GET /shoes?color=red&size=230&sort=price_desc&page=3 같은 요청이 몇 시간 간격으로 계속 잡힌다면, 그 자체가 크롤러가 저가치 조합에 발이 묶여 있다는 뚜렷한 증거다.
쇼핑몰과 블로그 카테고리 페이지, 접근법이 다른가요?
쇼핑몰은 필터 조합이 기하급수로 늘어나는 구조라 엄격한 원칙이 필요하고, 블로그·정보성 사이트의 카테고리·태그 페이지는 조합 자체가 적어 상대적으로 관리가 쉽다.
쇼핑몰의 나쁜 예는 이렇다. 색상·사이즈·브랜드·가격대 필터를 모두 조합 가능하게 열어 두고, canonical 태그도 없이 모든 조합이 색인되도록 방치하는 경우다. 이러면 "빨강+M+나이키+5만 원대"처럼 검색 수요가 전혀 없는 URL까지 수천 개씩 색인돼 크롤 예산과 순위 신호를 함께 갉아먹는다.
좋은 예는 검색 수요가 확인된 조합("나이키 러닝화", "여성 슬랙스")만 별도 카테고리 페이지로 만들고, 나머지 세부 조합은 canonical로 부모를 가리키게 하며, 정렬·페이지네이션은 noindex, follow로 처리하는 구조다. 쇼핑몰 SEO 완벽 가이드에서 이커머스 SEO 전반을 함께 확인하면 이 판단을 세우는 데 도움이 된다.
블로그·정보성 사이트라면 상황이 단순하다. 태그가 몇 개 없고 조합도 잘 발생하지 않으므로, 태그 페이지 자체를 없애거나, 실제로 방문자가 유입되는 태그 몇 개만 골라 색인시키는 정도로 충분하다. 굳이 복잡한 canonical·noindex 규칙을 세울 필요 없이, 의미 없는 태그 페이지는 애초에 만들지 않는 편이 가장 깔끔하다.
부동산 매물 사이트도 쇼핑몰과 비슷한 원리로 접근한다. "강남구 아파트 전세"처럼 지역과 매물 유형을 조합한 페이지는 실제 검색 수요가 뚜렷하므로 정식 페이지로 만들지만, 평수를 1제곱미터 단위로 잘게 쪼갠 필터나 층수 하나만 다른 조합은 canonical로 상위 지역 페이지를 가리키게 정리한다.
구인구직 플랫폼 역시 마찬가지다. "서울 마케팅 채용"처럼 직무와 지역을 묶은 조합은 색인 가치가 높지만, 연봉을 100만 원 단위로 잘게 나눈 필터까지 전부 독립 페이지로 놔두면 거의 똑같은 채용 공고 목록이 조금씩만 다른 URL로 수백 개 생기는 결과를 낳는다. 업종이 달라도 판단 기준은 동일하다. 실제 검색되는 조합인지, 그 조합에 고유한 콘텐츠를 채울 수 있는지를 먼저 보는 것이다.
이 원칙을 사이트 구조 설계 단계부터 반영하면 더 좋다. 정식으로 색인시킬 카테고리 목록을 먼저 정하고, 그 목록에 없는 조합은 필터 UI를 통해서만 접근 가능하게(즉 메뉴나 사이트맵에서 별도 링크를 만들지 않게) 설계하면, 나중에 하나씩 canonical·noindex를 붙이며 정리하는 수고를 크게 줄일 수 있다. 개발 초기의 URL 설계가 이후 몇 년간의 SEO 관리 부담을 좌우한다고 봐도 무리가 아니다.
자주 하는 실수 5가지는 무엇인가요?
패싯 페이지 관리에서 반복되는 실수는 대체로 다섯 가지로 좁혀진다. 대부분 규칙을 몰라서가 아니라, 규칙을 세우고도 일부 페이지에서 예외를 두면서 생긴다. 발행 전에 하나씩 점검해 보는 것이 좋다.
- 모든 필터 조합에 canonical 태그를 안 넣는 실수: 필터 페이지가 전부 자기 자신을 정규 URL로 선언하면, 사실상 색인 방지 효과가 전혀 없다. 개발 단계에서 "필터 페이지는 기본적으로 부모를 canonical로 한다"는 규칙을 템플릿 수준에서 넣어 둬야 나중에 하나씩 놓치는 일이 없다.
- canonical과 robots.txt 차단을 동시에 거는 실수: robots.txt로 막힌 페이지는 크롤러가 방문 자체를 못 하므로, 그 안에 있는 canonical 태그를 구글이 읽을 수 없다. 둘 중 하나만 골라야 하며, 보통은 canonical을 우선 적용하고 robots.txt 차단은 정말 크롤 예산이 심각하게 낭비되는 파라미터에만 제한적으로 쓴다.
- noindex 페이지를 사이트맵에 그대로 넣어 두는 실수: 사이트맵은 "색인해 달라"는 요청 목록이므로, noindex 페이지는 사이트맵에서 빼는 것이 원칙이다. 사이트맵 생성 로직을 짤 때 noindex 여부를 함께 확인하는 조건을 넣어 두면 이 실수를 예방할 수 있다.
- 필터 결과가 0건인 페이지를 그대로 200 응답으로 노출하는 실수: 상품이 하나도 없는 필터 조합은 소프트 404(내용은 없는데 서버 응답만 정상 200으로 오는 상태)가 되기 쉬우므로, 결과가 없으면 404나 noindex 처리를 해야 한다. "검색 결과가 없습니다" 문구만 띄우고 200 응답을 주는 페이지가 쌓이면 사이트 전체 품질 신호에도 좋지 않다.
- 내부 링크가 저가치 필터 URL을 직접 가리키는 실수: 메뉴·상품 카드 등에서 세부 필터 URL로 바로 링크를 걸면, 크롤러가 그 URL을 "중요한 페이지"로 오인해 더 자주 방문한다. 내부 링크는 색인시키기로 한 정식 카테고리 페이지 위주로만 걸어 두는 것이 안전하다.
자주 묻는 질문
구글 서치 콘솔의 URL 파라미터 도구로 필터를 관리하면 되지 않나요?
그 도구는 이미 사라졌다. 구글은 2022년 4월 28일 자로 서치 콘솔의 URL 파라미터 도구를 완전히 종료했다. 예전에는 이 도구에서 "이 파라미터는 정렬용이니 무시해 달라"는 식으로 직접 지정할 수 있었지만, 지금은 그런 별도 설정 화면 자체가 없다. 지금은 robots.txt·canonical 태그·noindex 조합으로 파라미터를 직접 관리하는 방법뿐이며, 아직도 옛 자료에서 이 도구를 언급한다면 오래된 정보이니 참고하지 않는 것이 좋다.
rel=next/prev 태그를 붙이면 페이지네이션 문제가 해결되나요?
아니다. 구글은 rel=next/prev 태그를 이미 오래전부터 색인 신호로 쓰지 않는다고 밝혔다. 페이지네이션(목록이 여러 쪽으로 나뉘는 구조)이 있는 카테고리 페이지는 각 페이지가 서로 다른 상품을 보여준다면 각자 색인되게 두고, 완전히 같은 내용을 정렬만 바꿔 보여준다면 canonical이나 noindex로 정리하는 편이 낫다. 페이지네이션 자체는 사용자 경험을 위한 구조일 뿐, 별도의 특수한 SEO 태그가 문제를 대신 해결해 주지는 않는다.
필터 조합이 몇 개부터 위험하다고 봐야 하나요?
정해진 절대 숫자는 없다. 다만 필터 종류와 값의 개수를 곱해 봤을 때 결과가 수만 단위를 넘어간다면 점검이 필요한 신호로 보는 편이 안전하다. 조합 개수 자체보다, 그중 실제 검색 수요가 있는 조합의 비율이 얼마나 되는지가 더 중요한 판단 기준이다. 조합이 만 개든 백만 개든, 그중 검색되는 조합이 몇십 개뿐이라면 나머지는 전부 정리 대상이라고 보면 된다.
noindex 처리한 필터 페이지도 사이트맵에 넣어야 하나요?
아니다. 사이트맵에는 정규(canonical) URL이자 색인을 원하는 페이지만 나열하는 것이 원칙이다. noindex 페이지를 사이트맵에 포함시키면 구글에 상반된 신호를 동시에 보내는 셈이라 혼란만 커진다. 사이트맵은 "여기 있는 페이지들을 색인해 달라"는 요청서에 가까우므로, 검색에 내보내지 않기로 한 페이지는 애초에 목록에서 빼는 것이 자연스럽다.
소프트 404란 정확히 무엇인가요?
필터 결과가 하나도 없는데도 서버가 정상 응답(200)을 돌려주며 빈 페이지나 "결과 없음" 문구만 보여주는 상태를 말한다. 구글은 이런 페이지를 실질적인 404(존재하지 않는 페이지)로 판단해 별도로 분류하며, 이런 페이지가 많으면 사이트 전체의 콘텐츠 품질 신호에도 좋지 않은 영향을 준다. 결과가 없는 조합은 실제 404 응답을 주거나 noindex 처리하는 것이 안전하다.
필터 페이지 규칙을 나중에 바꾸면 순위에 문제가 생기나요?
규칙을 바꾸는 것 자체는 문제가 아니지만, 반영에는 시간이 걸린다는 점을 감안해야 한다. canonical 대상을 바꾸거나 noindex를 새로 추가하면 구글이 그 URL을 다시 방문해 신호를 갱신할 때까지 몇 주가 걸릴 수 있다. 규칙을 바꾼 뒤에는 서치 콘솔의 URL 검사 도구로 몇 개 대표 URL을 직접 재색인 요청해 반영 속도를 앞당기는 것이 좋다.
패싯 내비게이션 관리는 한 번 규칙을 세우면 끝나는 작업이 아니라, 필터 종류가 늘어날 때마다 다시 점검해야 하는 살아 있는 작업입니다. 검색 수요·전환 가능성 데이터를 기준으로 색인 대상을 가려내고, robots.txt·canonical 태그·noindex를 상황에 맞게 일관되게 적용하는 것만으로도 크롤 예산과 순위 신호를 지킬 수 있습니다.
특히 쇼핑몰처럼 상품 수와 필터 종류가 계속 늘어나는 사이트라면, 처음 한 번 규칙을 세워 두는 것에서 그치지 않고 분기마다 서치 콘솔 데이터를 다시 확인하며 판단 기준을 손보는 습관이 필요합니다. 필터가 새로 추가될 때마다 "이 조합을 색인할 것인가"를 먼저 결정하는 팀 문화를 만들어 두면, 사이트가 커질수록 오히려 관리가 수월해집니다.
이 판단 기준을 직접 사이트 구조에 적용하는 일이 막막하게 느껴지신다면, 이루웹이 카테고리·필터 구조 진단부터 robots.txt·canonical 설계, 구조화 데이터 적용까지 함께 도와드리고 있습니다. SEO 최적화 홈페이지 제작 서비스와 함께 사이트 전체의 색인 구조를 점검해 보시길 권해 드리며, 궁금한 점이 있으시면 상담 문의로 편하게 연락해 주시면 성심껏 함께하겠습니다.
함께 보면 좋은 글
전체 보기구글 스크래퍼 차단, 9월 들어 더 강해졌다
구글의 검색결과 스크래핑·트래킹 차단이 9월 중순부터 강해져 랭크트래커 여러 업체가 영향을 인정했습니다. 지금 확인할 것을 정리했습니다.
5분 분량구글·빙, 검색결과 보기 전 사람인증 요구한다
구글과 빙이 일부 이용자에게 검색결과를 보여주기 전 사람인증을 요구하기 시작했습니다. 원인과 방문자·운영자가 챙길 점을 정리했습니다.
4분 분량구글 goto 리다이렉트, 실제로 무엇이 깨졌나
8월 26일부터 6일간 실제로 확인된 랭크트래커·GA4·AI 인용 피해와 지금 점검해야 할 대응법을 정리했습니다.
21분 분량구글, EU DMA 때문에 검색 품질 낮아졌다고 인정
구글이 EU 디지털시장법(DMA) 규제 때문에 검색 결과를 바꾸며 스스로 역사상 최대 품질 저하라고 밝혔습니다. 무엇이 바뀌었는지 정리했습니다.
4분 분량