SEO 중복 UPL 정리 중 검색 기능을 망가뜨린 원인 코드

쿼리스트링 제거 후 검색이 멈춘 이유 | 301 리다이렉트 예외 처리

웹개발·SEO 댓글쓰기

중복 URL을 잡겠다고 쓴 코드 한 줄 때문에 사이트 검색이 통째로 멈췄습니다. 그것도 며칠이나 모르고 있었고요. 같은 실수를 하는 분이 없길 바라며 과정을 그대로 남깁니다.

이 글은 단순히 쿼리스트링을 제거하는 방법을 설명하는 글이 아닙니다. 실제 사이트에서 중복 URL을 줄이려다 검색 기능을 망가뜨린 사례를 바탕으로, 어떤 파라미터를 남겨야 하는지, 301 리다이렉트 규칙을 만들 때 어떤 기능을 반드시 테스트해야 하는지 정리한 글입니다.

쿼리스트링 제거 후 검색이 멈춘 이유 이미지

쿼리스트링 정리가 위험해지는 순간

검색엔진 입장에서는 같은 본문이 여러 주소로 열리는 상황이 좋지 않습니다. 예를 들어 게시글 하나가 /board/856, /board/856?ckattempt=1, /board/856?fbclid=...처럼 여러 URL로 잡히면 중복 콘텐츠처럼 보일 수 있습니다.

그래서 불필요한 파라미터를 제거하는 리다이렉트 규칙을 넣고 싶어집니다. 문제는 사이트 안에서 실제로 쓰는 검색어, 페이징, 필터 값도 결국 쿼리스트링이라는 점입니다. 구분 없이 지우면 SEO 문제는 줄어드는 것처럼 보여도, 사용자가 쓰는 기능이 조용히 망가질 수 있습니다.

서치콘솔에 쌓인 이상한 주소들

서치콘솔을 열어보면 같은 페이지가 이런 모양으로 여러 번 잡혀 있었습니다.

/board/856
/board/856?ckattempt=1
/board/856?fbclid=IwAR...
/board/856?아무거나

내용은 전부 똑같은데 주소만 다릅니다. 전형적인 중복 콘텐츠죠. 그래서 “허용한 파라미터 외에는 전부 떼고 301로 보내버리자”는 규칙을 넣었습니다.

처음에는 좋은 정리처럼 보였습니다. 실제로 이상한 파라미터가 붙은 주소는 깨끗한 주소로 이동했고, 서치콘솔에서도 중복 URL이 줄어드는 듯했습니다. 하지만 이 방식에는 큰 구멍이 있었습니다.

검색어가 사라진 네트워크 흐름

사이트 상단 검색창에 단어를 넣고 엔터를 치면 검색어가 사라지고 원래 페이지로 돌아오는 현상이었습니다. 에러도 안 나고 백지도 아니니, 저도 재현하기 전까지 믿지 않았습니다.

개발자 도구 네트워크 탭을 열어보니 답이 바로 나왔습니다.

302 GET /search?q=검색어
301 GET /search          ← 검색어가 잘림
200 GET /search

브라우저는 분명히 /search?q=검색어로 요청을 보냈습니다. 그런데 서버의 리다이렉트 규칙이 q=검색어를 불필요한 파라미터로 판단했고, 결국 /search로 다시 보내버린 겁니다.

사용자 입장에서는 검색어를 입력했는데 아무 결과도 나오지 않는 것처럼 보입니다. 서버 입장에서는 정상적으로 301을 처리했으니 오류 로그에도 남지 않습니다. 그래서 더 위험했습니다.

문제는 검색어까지 지운 규칙

제가 짜놓은 규칙은 이런 논리였습니다.

쿼리스트링이 있으면 → 지우고 301

여기에 예외를 몇 개 넣긴 했는데, 그건 제가 미리 떠올린 파라미터만 예외처리한 것이었습니다. 검색어 q는 그 목록에 없었고, 서버는 지시대로 성실하게 지워버렸죠.

이게 이번 삽질의 핵심입니다. 제거 대상을 기준으로 짜면, 나중에 추가되는 기능은 전부 사고로 돌아옵니다.

특히 오래된 게시판이나 직접 만든 PHP 사이트는 기능마다 파라미터 이름이 제각각인 경우가 많습니다. 어떤 곳은 q를 쓰고, 어떤 곳은 keyword를 쓰고, 목록 페이지는 start나 page를 쓰기도 합니다. 이 값을 전부 확인하지 않은 상태에서 쿼리스트링 제거 규칙을 넣으면, 검색·페이징·필터 기능이 한꺼번에 영향을 받을 수 있습니다.

쿼리스트링 제거 전에 봐야 할 구조

아래에 해당하는 사이트라면 쿼리스트링 제거 리다이렉트를 넣기 전에 먼저 기능 점검부터 하는 게 좋습니다.

  • 게시판 검색이나 통합 검색 기능이 있는 사이트
  • 목록 페이지에서 page, start, offset 같은 페이징 값을 쓰는 사이트
  • 카테고리, 지역, 정렬, 기간 필터를 URL 파라미터로 처리하는 사이트
  • 오래된 PHP 게시판이나 직접 만든 CMS를 운영하는 사이트
  • 서치콘솔에서 ?ckattempt=1, ?fbclid=, 임의 파라미터가 많이 잡히는 사이트
  • .htaccess에서 쿼리스트링을 강제로 제거하는 규칙을 쓰는 사이트

이런 구조에서는 모든 파라미터가 나쁜 것이 아닙니다. 어떤 파라미터는 검색엔진에는 불필요해 보여도, 실제 사용자 기능에는 꼭 필요합니다.

해결 기준은 삭제 목록이 아니라 허용 목록

지울 것을 정하는 대신, 남길 것을 정하는 방식으로 전부 다시 썼습니다.

아래 코드는 허용 목록에 없는 파라미터가 하나라도 있을 때만 깨끗한 주소로 301 보내는 역할을 합니다.

// 이 페이지가 정상적으로 쓰는 파라미터만 나열
$allowed = ['id', 'menu', 'q', 'keyword', 'start'];

if (!empty($_SERVER['QUERY_STRING'])) {
    parse_str($_SERVER['QUERY_STRING'], $params);
    $extra = array_diff(array_keys($params), $allowed);

    if (!empty($extra)) {
        // 허용된 것만 다시 조립
        $keep = array_intersect_key($params, array_flip($allowed));
        $clean = strtok($_SERVER['REQUEST_URI'], '?');
        if ($keep) {
            $clean .= '?' . http_build_query($keep);
        }
        header('Location: ' . $clean, true, 301);
        exit;
    }
}

이 코드가 하는 일은 간단합니다. 먼저 현재 URL에 붙은 파라미터를 읽고, 허용 목록에 없는 값이 있는지 확인합니다. 허용되지 않은 파라미터가 있으면 그 값만 제거하고, q, keyword, start처럼 실제 기능에 필요한 값은 남긴 채 301 리다이렉트합니다.

핵심은 “나쁜 파라미터를 하나씩 찾아서 지우는 것”이 아니라 “사이트 기능에 필요한 파라미터만 남기는 것”입니다. 이렇게 해야 나중에 불필요한 값이 새로 들어와도 정리할 수 있고, 검색어처럼 필요한 값은 보호할 수 있습니다.

.htaccess 쪽에도 같은 예외를 걸어줍니다.

# 쿼리스트링 제거 — 검색 파라미터는 제외
RewriteCond %{QUERY_STRING} !^$
RewriteCond %{QUERY_STRING} !(^|&)q=
RewriteCond %{QUERY_STRING} !(^|&)keyword=
RewriteCond %{QUERY_STRING} !(^|&)start=
RewriteRule ^(.*)$ /$1? [R=301,L]

이 규칙은 쿼리스트링이 있을 때 무조건 제거하지 않고, 검색어와 페이징에 필요한 파라미터가 포함된 경우에는 리다이렉트를 건너뛰도록 만든 것입니다.

다만 .htaccess만 믿고 끝내지는 않는 게 좋습니다. 서버 설정, PHP 코드, 프레임워크 라우팅이 함께 동작하는 사이트라면 어느 지점에서 파라미터가 사라지는지 반드시 네트워크 탭으로 확인해야 합니다.

배포 후 다시 눌러본 기능들

수정 후에는 단순히 페이지가 열리는지만 보지 않았습니다. 실제 사용자가 하는 동작을 기준으로 다시 확인했습니다.

  • 사이트 상단 검색창에서 검색어가 유지되는지 확인
  • 게시판 내부 검색에서 keyword 값이 사라지지 않는지 확인
  • 목록 페이지의 페이징 값이 정상적으로 유지되는지 확인
  • 이상한 파라미터가 붙은 URL은 깨끗한 주소로 301 이동하는지 확인
  • 검색 결과가 없는 경우와 있는 경우를 나눠서 확인
  • 모바일에서도 검색창 동작이 같은지 확인

적용 후 결과는 이랬습니다.

  • 사이트 검색·게시판 검색 모두 정상 동작
  • 서치콘솔 ‘중복 페이지’ 보고가 계속 줄어드는 중
  • 크롤러가 쓸데없는 주소를 도는 빈도가 감소

중요한 건 검색 기능이 멈췄던 기간입니다. 오류 로그에 안 남는 종류의 고장이라 누가 알려주지 않았다면 더 오래 몰랐을 겁니다.

쿼리스트링 리다이렉트 점검표

SEO 수정은 기능 테스트까지 끝나야 한다

SEO 작업은 대부분 “뭔가를 지우는” 일입니다. 그리고 지우는 작업은 망가졌는지 바로 티가 안 납니다. 색인 수가 줄어드는 건 좋은 신호처럼 보이고, 기능이 죽은 건 사용자가 말해주지 않으면 모릅니다.

이번 문제도 그랬습니다. 중복 URL을 줄이려는 의도는 맞았지만, 검색 기능에 필요한 q 값까지 지워버리면서 사용자는 검색을 할 수 없게 됐습니다. 검색엔진을 위한 정리가 사용자 기능을 망가뜨린 셈입니다.

제거형 규칙을 넘기기 전에는 넘기는 것보다 남기는 것을 먼저 적어보세요. 그리고 SEO 수정 후에는 서치콘솔만 보지 말고, 검색·페이징·필터처럼 사용자가 직접 만지는 기능을 반드시 다시 눌러봐야 합니다.

조회수 5

댓글 남기기