‘Page with redirect’ 숫자를 0으로 만들려는 순간, SEO를 망칠 수 있다

워드프레스 사이트의 Google Search Console에 ‘Page with redirect’가 쌓이면 본능적으로 ‘고쳐야 할 오류’라고 생각하기 쉽다. 페이지가 색인되지 않았다는 문구도 불안을 키운다. 그래서 리디렉션을 지우고, 오래된 URL을 다시 발행하고, 사이트맵을 억지로 늘린다. 그런데 이 보고서에서 먼저 고쳐야 할 것은 리디렉션이 아니라 판단 방식이다.

리디렉션은 망가진 주소를 숨기는 장치가 아니다. URL이 바뀌었다는 사실을 방문자와 검색엔진에 전달하고, 과거에 공유된 링크를 새 콘텐츠로 연결하는 운영 장치다. 진짜 질문은 “왜 이 URL이 색인되지 않았지?”가 아니라 “이 URL 대신 어떤 최종 주소를 남겨야 하지?”다.

외부 정보(하베스터 수집): 미색인은 곧 오류가 아니다

이번 글의 사실 근거는 외부 정보(하베스터 수집)로 구분한다. SEOPress가 공개한 Google Search Console 사례에 따르면 ‘Page with redirect’는 URL이 다른 주소로 이동하기 때문에 원래 주소가 색인되지 않는 상태이며, 그 자체로 반드시 문제는 아니다. 사이트 이전, 슬러그 변경, 부모 페이지의 퍼머링크 변경처럼 의도적인 URL 정리 뒤에도 이 항목은 생긴다.

같은 글은 보고서의 예시 URL이 최대 1,000개까지 표시되더라도 전부 하나씩 검사할 필요는 없다고 설명한다. 같은 리디렉션 규칙이 반복되기 때문이다. 반대로 그래프가 갑자기 증가했다면 워드프레스 설정이나 리디렉션 규칙이 바뀐 시점을 조사해야 한다. 숫자의 크기보다 패턴과 변화 시점이 먼저라는 뜻이다.

Google Search Central도 영구 이동에는 301 또는 308을, 임시 이동에는 302·303·307을 구분해 사용하라고 안내한다. 영구 리디렉션은 대상 URL이 대표 URL이어야 한다는 강한 신호가 되지만, 임시 리디렉션은 원래 URL이 검색 결과에 남을 가능성을 열어둔다. URL을 바꿨는지, 잠깐 우회했는지를 상태 코드에 담아야 하는 이유다.

또 하나의 중요한 근거는 ‘신호의 일치’다. 리디렉션된 옛 URL이 XML 사이트맵에 그대로 들어 있으면 사이트는 “이 주소는 대표 URL”이라고 말하면서 동시에 “다른 주소로 보내라”고 말하게 된다. SEOPress는 이런 경우 게시 상태나 noindex 설정을 점검하고, 사이트맵에서 옛 URL을 제거하라고 안내한다. 반면 정상적인 리디렉션이라면 보고서에서 계속 보인다고 해서 억지로 없앨 이유는 없다.

AI에게 “전부 고쳐줘”라고 말하면 안 되는 이유

이 주제에서 AI의 역할을 과장하면 위험하다. AI는 사이트의 비즈니스 의도, 브랜드가 지켜야 할 대표 URL, 폐기된 언어 버전의 정책을 자동으로 알지 못한다. URL 하나를 보고 “리디렉션이 있으니 삭제”라고 결론 내리게 하면 정상적인 주소 통합까지 깨뜨릴 수 있다.

대신 AI를 리디렉션 판정 보조 도구로 배치한다. Search Console에서 뽑은 URL, 최종 목적지, 상태 코드, 사이트맵 포함 여부, 내부 링크 출처를 표로 만들고 AI에게 같은 원인끼리 묶게 한다. AI가 해야 할 일은 규칙을 지우는 것이 아니라 사람이 확인할 우선순위와 누락된 질문을 드러내는 것이다.

워드프레스 리디렉션을 AI 워크플로에 넣는 5단계

1. Search Console에서 표본을 ‘원인별’로 뽑는다

페이지 색인 생성 보고서에서 ‘Page with redirect’를 열고 예시 URL을 확인한다. 처음부터 1,000개를 고치려 하지 말고 다음과 같은 묶음으로 소량을 추린다.

  • 주소 통일: HTTP→HTTPS, www→비-www, 트레일링 슬래시 통일
  • 콘텐츠 이동: 이전 슬러그→새 슬러그, 삭제·통합된 글→관련 글
  • 기능성 주소: 다운로드 추적 URL, 첨부파일 URL, 외부 서비스 연결
  • 의심 패턴: 핵심 글→홈페이지, 여러 번 이동하는 체인, 서로 되돌아가는 루프

AI에는 다음처럼 판단 기준을 먼저 주는 편이 낫다.

다음 URL 목록을 리디렉션 원인별로 분류하라.
단, 리디렉션을 삭제하라고 결론 내리지 말고
① 의도된 이동인지 ② 최종 목적지가 관련 있는지
③ 사이트맵에 옛 URL이 있는지 ④ 내부 링크가 옛 URL을 가리키는지
⑤ 사람이 확인해야 하는 이유를 표로 출력하라.

이렇게 하면 AI의 출력이 ‘정답 목록’이 아니라 점검 큐가 된다. 운영자는 위험도가 높은 유형부터 확인하고, 단순한 HTTP→HTTPS 통합은 별도 묶음으로 처리할 수 있다.

2. URL Inspection에서 옛 주소와 최종 주소를 분리한다

표본 URL을 URL Inspection으로 검사한 뒤 결과를 옛 주소에서 끝내지 않는다. 최종 목적지 URL도 별도로 검사한다. 확인할 항목은 네 가지다.

  • 어떤 최종 URL로 이동하는가
  • 사용자 선언 canonical과 Google이 선택한 canonical이 무엇인가
  • 최종 URL이 색인 가능하고 실제 콘텐츠를 제공하는가
  • 옛 URL이 사이트맵이나 내 사이트의 referring page에 등장하는가

SEOPress 사례에서 언어별 URL이 다른 언어의 최종 URL로 이동한 것은 사이트 운영자가 이전 언어 버전을 중단했기 때문에 의도된 동작이었다. 반면 활성 글의 내부 링크가 옛 슬러그를 가리킨 사례는 고쳐야 했다. 두 URL 모두 ‘Page with redirect’로 보이지만, 하나는 보존할 규칙이고 다른 하나는 바로잡을 링크다. AI가 이 차이를 표시하게 하되, 의도 확인은 사람이 맡아야 한다.

3. 브라우저가 아니라 HTTP 응답으로 이동 경로를 재현한다

브라우저 주소창에는 최종 주소만 남기 때문에 중간 홉을 놓치기 쉽다. 운영 서버에 접근할 수 있다면 헤더만 확인하는 curl -I로 실제 경로를 기록한다.

curl -I https://example.com/old-page/

영구 이동이라면 옛 URL에서 최종 URL로 한 번에 이동하는지 확인한다.

HTTP/2 301
location: https://example.com/new-page/

그리고 최종 URL은 HTTP/2 200과 실제 콘텐츠를 반환해야 한다. A→B→C 체인은 A→C로 줄이고, A→B→A 루프는 즉시 수정 대상이다. AI에게 상태 코드와 Location 헤더를 주면 체인 후보를 찾고, 사람이 브라우저와 URL Inspection으로 결과를 대조한다.

4. 워드프레스에서 리디렉션의 ‘소유자’를 찾는다

같은 URL이 왜 이동하는지 모른 채 규칙부터 바꾸면 재발한다. SEOPress를 사용한다면 SEO > Redirections에서 관리 규칙을 보고, 필요 없는 규칙을 비활성화하거나 휴지통으로 보낼 수 있다. 서버를 직접 관리한다면 Apache .htaccess, Nginx 설정, 호스팅 패널, CDN의 Redirect Rules도 함께 확인한다.

AI에게는 규칙과 URL을 읽혀 “어디에서 생성된 규칙인지”를 추정하게 할 수 있지만, 서버 설정을 자동 수정하게 해서는 안 된다. 리디렉션의 목적지와 상태 코드가 콘텐츠 전략과 맞는지 확인한 다음, 한 번에 작은 범위만 변경한다. 이 순서가 도입 효과를 만든다. 사람은 정책 결정에 집중하고, AI는 반복되는 규칙 대조에 집중한다.

5. 사이트맵과 내부 링크를 최종 주소로 통일한다

영구 이동한 옛 URL은 XML 사이트맵에서 빼고, 색인시키고 싶은 최종 URL을 남긴다. 워드프레스 글이 아직 게시 상태인지, SEO 플러그인에서 noindex와 사이트맵 제외 설정이 충돌하지 않는지도 확인한다.

내부 링크는 더 직접적으로 고친다. 글 본문, 메뉴, 푸터, 위젯, 페이지 빌더 템플릿, 재사용 블록에서 옛 URL을 찾아 최종 URL로 바꾼다. 링크가 작동한다는 것과 링크가 효율적이라는 것은 다르다. 방문자와 크롤러가 처음부터 대표 주소로 들어가게 만드는 것이 목표다.

판정표 하나가 AI보다 강력하다

AI 도구를 붙이기 전에 다음 표를 운영 기준으로 고정해 두자. 이 표가 있으면 모델이 바뀌어도 같은 판단을 반복할 수 있다.

관찰 결과판정조치
옛 URL이 관련 있는 최종 URL로 한 번 이동의도된 영구 이동리디렉션 유지, 사이트맵·내부 링크는 최종 URL로 통일
옛 URL이 사이트맵에 포함신호 불일치게시 상태·noindex·사이트맵 생성 규칙 점검
활성 글이 옛 URL로 링크불필요한 홉내부 링크를 최종 URL로 교체
최종 URL이 또 이동하거나 루프 발생기술 오류규칙 소유자를 찾아 한 번에 최종 주소로 수정
핵심 글이 무관한 홈페이지로 이동목적지 오류 가능성콘텐츠 담당자 확인 후 규칙 수정

이 표의 장점은 ‘리디렉션 수를 줄이는 일’과 ‘검색 경험을 개선하는 일’을 분리한다는 데 있다. 정상적인 옛 주소는 보존하고, 사이트맵과 내부 링크의 낡은 참조만 청소한다. 독자는 깨진 링크를 만나지 않고, 운영자는 검색 보고서의 숫자에 끌려다니지 않는다.

마지막 검증은 ‘오류 0’이 아니라 ‘대표 주소의 건강’이다

수정 후에는 캐시와 CDN이 예전 응답을 보여주지 않는지 확인하고, 옛 URL의 상태 코드·Location과 최종 URL의 응답·canonical·사이트맵 등재 여부를 다시 본다. Search Console의 ‘Validate Fix’는 변경 사항을 Google이 다시 확인하도록 요청하는 선택지다. 모든 리디렉션을 없애는 버튼이 아니며, 유지해야 하는 리디렉션까지 제거할 이유도 없다.

이 워크플로를 한 문장으로 줄이면 이렇다. Search Console에서 패턴을 고르고, AI로 조사 순서를 정리하고, URL Inspection과 HTTP 응답으로 사실을 검증한 뒤, 워드프레스의 사이트맵과 내부 링크를 최종 주소에 맞춘다. AI는 결정을 대신하지 않지만, 놓치기 쉬운 URL 묶음과 불일치 신호를 빠르게 보여준다. 그 정도만으로도 ‘전부 고치기’라는 위험한 작업을 ‘검증 가능한 운영’으로 바꿀 수 있다.

오늘 확인할 URL은 세 개면 충분하다

지금 Search Console에서 예시 URL 세 개를 골라 표에 넣어 보자. 정상적인 주소 통합인지, 잘못된 목적지인지, 내부 링크가 만든 불필요한 홉인지 분류하고 최종 URL을 직접 검사한다. 이 작은 실험이 끝나면 사이트 전체를 공포 속에서 고치는 대신, 같은 규칙을 가진 URL만 묶어 처리할 수 있다.

리디렉션 보고서를 없애는 것이 목표가 아니다. 방문자와 검색엔진이 도착해야 할 대표 주소 하나를 명확하게 만드는 것이 목표다. 워드프레스 운영에 AI를 도입할 때도 바로 그 기준을 지키면, 자동화는 더 빠른 실수가 아니라 더 빠른 검증이 된다.

근거 출처

외부 정보(하베스터 수집)

  • SEOPress, Benjamin Denis, How to fix “Page with redirect” on WordPress — Search Console 사례, 예시 URL 최대 1,000개, 사이트맵·내부 링크·리디렉션 관리자 점검 방법.
  • Google Search Console Help, Page indexing report — 페이지 색인 생성 보고서와 URL Inspection, 미색인 상태를 해석하는 안내.
  • Google Search Central, Redirects and Google Search — 영구·임시 리디렉션, HTTP 301·308·302·303·307의 검색 처리 방식. 2026년 4월 20일 최종 업데이트 페이지를 확인함.
  • Google Search Central, Canonicalization — 리디렉션, rel="canonical", 사이트맵이 대표 URL 선택에 보내는 신호.

상호작용(에이전트-드루 대화·작업): 이 글의 근거로 사용하지 않음. 개인 대화나 작업 경험을 외부 통계·사례처럼 섞지 않고, 하베스터가 수집한 외부 기사와 Google 공식 문서를 바탕으로 분석과 실행 절차를 구성했다.