티스토리 Search Console ‘리디렉션이 포함된 페이지’ 확인 방법｜정상 이동과 점검할 URL 구분하기

Google Search Console의 페이지 색인 생성 보고서를 확인하다 보면 ‘리디렉션이 포함된 페이지’라는 항목을 발견할 수 있습니다.

처음 보면 페이지에 오류가 생겼거나 검색 노출에서 제외된 것처럼 느껴질 수 있습니다.

“리디렉션이 있으면 SEO에 문제가 있는 걸까?”

“이 URL도 색인 생성 요청을 해야 할까?”

“애드센스 신청 전에 모두 해결해야 할까?”

하지만 리디렉션이 포함된 페이지라는 이유만으로 문제가 있다고 판단할 필요는 없습니다.

리디렉션은 특정 URL에 접속했을 때 사용자를 다른 URL로 이동시키는 방식입니다. 정상적으로 다른 주소로 이동하도록 만들어진 URL이라면 원래 URL 대신 최종 목적지 URL이 검색에서 사용되는 것이 자연스러울 수 있습니다.

따라서 Search Console에서 이 상태를 발견했을 때 중요한 것은 ‘리디렉션이 있다’는 사실 자체가 아닙니다.

어디에서 어디로 이동하는지, 최종 페이지가 정상적인지, 내가 의도한 이동인지를 확인해야 합니다.

이번 글에서는 티스토리에서 ‘리디렉션이 포함된 페이지’를 발견했을 때 정상적으로 둘 수 있는 URL과 추가 확인이 필요한 URL을 구분하는 방법을 정리해 보겠습니다.

✓ 먼저 리디렉션이 무엇인지 이해합니다

리디렉션은 한 URL로 접속했을 때 다른 URL로 자동 이동시키는 처리입니다.

예를 들어 A라는 주소를 열었는데 브라우저가 자동으로 B라는 주소로 이동한다고 가정하겠습니다.

이 경우 A는 사용자를 B로 보내는 리디렉션 URL이고 B는 최종 목적지 URL이 됩니다.

검색엔진 입장에서도 A와 B를 각각 독립적인 페이지로 색인해야 하는 것은 아닙니다.

따라서 Search Console에서 A가 ‘리디렉션이 포함된 페이지’로 분류되고 A 자체가 색인되지 않는 것은 정상적인 상황일 수 있습니다.

✓ 리디렉션 페이지가 색인되지 않는다고 바로 오류는 아닙니다

페이지 색인 생성 보고서의 목적은 모든 URL을 색인시키는 것이 아닙니다.

Google이 발견한 URL 가운데 어떤 주소가 색인되고 어떤 주소가 색인되지 않았는지 이유를 보여주는 데 의미가 있습니다.

리디렉션되는 URL은 자체 콘텐츠를 보여주는 대신 다른 페이지로 이동시키기 때문에 원래 URL이 검색 결과에 포함되지 않을 수 있습니다.

따라서

‘리디렉션이 포함된 페이지 = 반드시 수정해야 하는 오류’

라고 생각하지 않는 것이 좋습니다.

정상적인 목적지로 이동하고 있다면 의도한 처리일 수 있습니다.

✓ Search Console에서 실제 URL부터 확인합니다

먼저 Search Console의 페이지 색인 생성 보고서에서 ‘리디렉션이 포함된 페이지’ 항목을 확인합니다.

표시되는 예시 URL을 살펴봅니다.

여기에서 숫자만 확인하고 끝내지 않는 것이 중요합니다.

실제 URL이 어떤 주소인지 확인해야 합니다.

예전에 사용하던 주소인지, 현재 사용하는 게시글 주소인지, 내가 예상하지 못한 주소인지에 따라 판단이 달라질 수 있기 때문입니다.

특히 중요한 게시글 주소가 포함되어 있다면 직접 확인하는 것이 좋습니다.

✓ 브라우저에서 URL을 직접 열어봅니다

가장 간단하면서 중요한 확인 방법입니다.

Search Console에 표시된 URL을 브라우저 주소창에 입력해 직접 열어봅니다.

그리고 최종적으로 어떤 주소가 표시되는지 확인합니다.

예를 들어

A URL 입력

→ 자동으로 B URL 이동

→ B 페이지 정상 표시

라면 A가 B로 리디렉션되고 있다는 것을 직접 확인할 수 있습니다.

여기서 핵심은 이동 자체보다 B가 내가 의도한 최종 페이지인지 확인하는 것입니다.

✓ 정상적인 리디렉션은 그대로 둘 수 있습니다

A에서 B로 이동하고 B가 실제로 사용해야 하는 정상적인 페이지라면 리디렉션 자체를 없앨 이유는 없습니다.

예를 들어 과거 주소 대신 현재 사용 중인 정상 주소로 이동하도록 처리되고 있고 최종 페이지의 내용도 올바르다면 자연스러운 이동일 수 있습니다.

이런 경우 Search Console에서 A가 색인되지 않는다는 이유만으로 A까지 별도의 페이지로 만들 필요는 없습니다.

검색 결과에 나타나야 하는 페이지는 최종 목적지인 B이기 때문입니다.

✓ URL 검사에서는 원래 URL과 최종 URL을 구분합니다

중요한 주소라면 Search Console의 URL 검사를 이용합니다.

여기서 주의할 점은 리디렉션되는 원래 URL과 최종 목적지 URL을 같은 페이지처럼 확인하지 않는 것입니다.

A가 B로 이동한다면 실제 검색에 노출되기를 원하는 주소가 B인지 먼저 판단합니다.

그렇다면 B 주소를 URL 검사에 입력해 색인 상태를 확인하는 것이 중요합니다.

A가 리디렉션된다는 이유만으로 A에 색인 생성 요청을 반복하는 것은 목적에 맞지 않을 수 있습니다.

✓ 최종 목적지 URL이 정상적으로 색인 가능한지 확인합니다

리디렉션 문제에서 더 중요한 것은 이동이 끝난 뒤 도착하는 페이지입니다.

최종 URL을 직접 열어 다음을 확인합니다.

페이지가 정상적으로 표시되는가?

게시글이 공개 상태인가?

404 페이지로 연결되지 않는가?

다시 다른 주소로 불필요하게 이동하지 않는가?

실제로 검색에 노출되기를 원하는 콘텐츠인가?

최종 페이지에 문제가 없다면 원래 URL이 리디렉션 상태로 표시되는 것만으로 걱정할 필요는 없습니다.

✓ 의도하지 않은 페이지로 이동한다면 점검이 필요합니다

반대로 A라는 게시글 주소를 열었는데 전혀 관계없는 C 페이지로 이동한다면 확인이 필요합니다.

예를 들어 Search Console 관련 글의 주소가 갑자기 다른 카테고리의 게시글이나 예상하지 못한 페이지로 이동한다면 정상적인 이동인지 살펴봐야 합니다.

특히 기존 내부 링크가 잘못된 주소를 가리키고 있거나 URL을 변경하는 과정에서 예상하지 못한 이동이 생겼다면 해당 링크를 수정하는 것이 좋습니다.

리디렉션 자체보다 ‘어디로 이동하느냐’가 더 중요합니다.

✓ 여러 번 연속 이동하는 주소도 확인합니다

가능하면 리디렉션 경로는 단순한 편이 좋습니다.

예를 들어

A → B → C

처럼 여러 단계를 거쳐 최종 페이지로 이동하는 주소가 있을 수 있습니다.

더 복잡하게 여러 URL을 계속 거치거나 다시 이전 URL로 돌아가는 문제가 있다면 정상적인 페이지 접근에 영향을 줄 수 있습니다.

특히 A → B → A처럼 반복되는 리디렉션 루프가 발생하면 사용자가 최종 콘텐츠에 도달하지 못할 수 있습니다.

브라우저에서 페이지가 정상적으로 열리지 않거나 리디렉션 관련 오류가 표시된다면 추가 점검이 필요합니다.

✓ 내부 링크가 리디렉션 URL을 가리키는지 확인합니다

블로그 내부 링크도 함께 살펴볼 수 있습니다.

예를 들어 현재 정상 게시글 주소가 B인데 과거 글에서 계속 A를 연결하고 있고 A가 B로 리디렉션된다고 가정하겠습니다.

사용자는 결국 B에 도착할 수 있지만 내가 직접 수정할 수 있는 내부 링크라면 처음부터 B를 연결하는 편이 더 단순합니다.

따라서 중요한 내부 링크가 오래된 주소나 불필요한 중간 URL을 거치고 있다면 최종 정상 URL로 수정할 수 있습니다.

다만 리디렉션 URL이 하나 발견됐다는 이유만으로 블로그 전체 링크를 무조건 변경할 필요는 없습니다.

✓ 티스토리에서는 직접 관리할 수 있는 범위를 구분합니다

티스토리는 자체 서버를 직접 운영하는 방식과 다릅니다.

따라서 모든 리디렉션 동작을 블로그 운영자가 서버 수준에서 직접 설정하거나 변경할 수 있는 것은 아닙니다.

Search Console에서 리디렉션 URL을 발견했을 때 먼저 직접 관리할 수 있는 부분부터 확인하는 것이 좋습니다.

게시글의 현재 주소

게시글 공개 여부

내부 링크 주소

삭제하거나 변경한 게시글 여부

직접 수정한 스킨이나 HTML 설정

이런 부분을 먼저 점검합니다.

플랫폼에서 자동으로 처리하는 주소까지 무리하게 없애려고 할 필요는 없습니다.

✓ 리디렉션 URL에 색인 생성 요청을 반복하지 않습니다

리디렉션되는 A URL 자체를 검색 결과에 표시하려고 색인 생성 요청을 반복하는 것은 적절하지 않을 수 있습니다.

A가 정상적으로 B로 이동하고 실제 콘텐츠가 B에 있다면 확인해야 할 대상은 B입니다.

따라서

A는 리디렉션 상태 확인

B는 실제 페이지와 색인 상태 확인

이렇게 구분하는 것이 좋습니다.

색인 생성 요청이 필요하다면 실제 검색 결과에 나타나야 하는 최종 페이지가 정상적인 상태인지 먼저 확인합니다.

✓ 모든 리디렉션을 홈페이지로 보내는 방식은 피합니다

삭제되거나 존재하지 않는 URL을 모두 블로그 홈페이지로 이동시키면 문제를 해결할 수 있다고 생각하기 쉽습니다.

하지만 원래 페이지와 관계없는 홈페이지로 무조건 보내는 방식은 사용자에게도 도움이 되지 않을 수 있습니다.

기존 페이지와 실질적으로 대응되는 새 페이지가 있다면 관련 있는 목적지로 이동하는 것이 자연스럽습니다.

반대로 대체할 콘텐츠가 전혀 없다면 무조건 홈페이지로 보내는 것이 항상 좋은 해결책은 아닙니다.

리디렉션은 단순히 오류를 숨이는 기능이 아니라 사용자를 적절한 새 위치로 안내할 때 의미가 있습니다.

✓ 이런 리디렉션은 추가 확인이 필요합니다

모든 리디렉션을 수정할 필요는 없지만 다음과 같은 경우에는 조금 더 자세히 살펴봅니다.

중요한 게시글이 전혀 관계없는 페이지로 이동합니다.

최종 페이지가 404로 끝납니다.

여러 단계를 계속 거쳐야 최종 페이지가 열립니다.

페이지가 반복적으로 서로 이동해 정상적으로 열리지 않습니다.

현재 내부 링크가 계속 오래된 리디렉션 URL을 사용합니다.

검색에 노출되어야 할 정상 게시글 자체가 예상하지 못한 곳으로 이동합니다.

이 경우에는 단순히 Search Console 상태를 없애는 것이 아니라 실제 URL 구조와 연결 상태를 점검해야 합니다.

✓ 실제 상황별로 판단해 봅니다

A 사례

Search Console에 A URL이 ‘리디렉션이 포함된 페이지’로 표시됩니다.

브라우저에서 A를 열었더니 정상 게시글 B로 바로 이동합니다.

B도 정상적으로 공개되어 있습니다.

이 경우 A가 별도로 색인되지 않는 것은 정상적인 처리일 수 있습니다.

B 사례

A URL을 열었더니 B로 이동하고 다시 C로 이동합니다.

최종적으로 C가 정상 페이지이지만 내부 링크에서 A를 직접 사용하고 있습니다.

직접 수정할 수 있는 내부 링크라면 C를 연결해 불필요한 중간 이동을 줄일 수 있습니다.

C 사례

Search Console 관련 게시글 주소를 열었는데 전혀 관계없는 다른 게시글로 이동합니다.

이 경우 의도한 리디렉션인지 확인해야 합니다.

내부 링크 오류나 주소 변경 과정에서 잘못 연결된 것은 아닌지 살펴봅니다.

D 사례

A URL이 B로 이동하지만 B를 열었더니 404 페이지가 표시됩니다.

이 경우 A가 리디렉션된다는 사실보다 최종 목적지 B가 정상적으로 존재하지 않는다는 것이 더 중요한 문제입니다.

실제로 사용해야 하는 페이지가 무엇인지 확인하고 관련 링크도 함께 점검합니다.

✓ 리디렉션 페이지 최종 체크리스트

□ Search Console에서 실제 리디렉션 URL을 확인했다.

□ 해당 URL을 브라우저에서 직접 열어봤다.

□ 최종적으로 도착하는 URL을 확인했다.

□ 최종 페이지가 내가 의도한 페이지인지 확인했다.

□ 최종 페이지가 정상적으로 열리는지 확인했다.

□ 중요한 최종 URL은 URL 검사에서 상태를 확인했다.

□ 404 페이지로 이동하지 않는지 확인했다.

□ 불필요하게 여러 번 이동하지 않는지 확인했다.

□ 내부 링크가 오래된 리디렉션 URL을 사용하지 않는지 살펴봤다.

□ 리디렉션 URL에 색인 생성 요청을 반복하지 않았다.

□ 모든 리디렉션을 무조건 없애려고 하지 않았다.

자주 묻는 질문

Q1. ‘리디렉션이 포함된 페이지’가 있으면 SEO 오류인가요?

반드시 오류는 아닙니다. 해당 URL이 정상적으로 다른 대표 URL로 이동하고 있고 최종 페이지가 올바르다면 의도된 처리일 수 있습니다.

Q2. 리디렉션 URL도 Google에 색인되어야 하나요?

리디렉션 URL 자체보다 최종 목적지 URL이 검색에서 사용되는 것이 자연스러운 경우가 많습니다. 따라서 원래 URL을 억지로 색인시키기보다 최종 URL의 상태를 확인하는 것이 중요합니다.

Q3. 색인 생성 요청은 어느 URL에 해야 하나요?

실제로 검색 결과에 나타나야 하는 최종 페이지를 먼저 확인합니다. 리디렉션되는 중간 URL에 반복적으로 색인 생성 요청을 할 필요는 없습니다.

Q4. 리디렉션이 여러 개 있으면 모두 삭제해야 하나요?

아닙니다. 정상적인 목적지로 이동하는 리디렉션까지 숫자를 줄이기 위해 없앨 필요는 없습니다. 의도하지 않은 이동, 잘못된 목적지, 지나치게 복잡한 이동 경로가 있는지를 확인하는 것이 중요합니다.

Q5. 리디렉션 페이지가 있으면 애드센스 신청 전에 모두 해결해야 하나요?

Search Console에 리디렉션 URL이 존재한다는 사실만으로 애드센스 심사 문제라고 단정할 수 없습니다. 정상적인 리디렉션인지, 방문자가 최종 콘텐츠에 정상적으로 접근할 수 있는지를 중심으로 확인하는 것이 좋습니다.

마무리｜리디렉션 숫자보다 최종 도착 페이지를 확인합니다

Search Console에서 ‘리디렉션이 포함된 페이지’를 발견했다고 모든 URL을 수정할 필요는 없습니다.

리디렉션은 한 주소에서 다른 주소로 사용자를 이동시키는 정상적인 처리에도 사용됩니다.

따라서 가장 먼저 해당 URL을 직접 열어봅니다.

그다음 어디로 이동하는지 확인합니다.

최종 목적지가 정상적인 게시글이고 실제로 사용하려는 대표 URL이라면 원래 주소가 별도로 색인되지 않는 것은 자연스러운 상황일 수 있습니다.

반대로 예상하지 못한 페이지로 이동하거나 최종 주소가 404로 끝나거나 여러 URL을 불필요하게 반복해서 거친다면 추가 점검이 필요합니다.

Search Console 관리의 목표는 ‘리디렉션이 포함된 페이지’를 무조건 0으로 만드는 것이 아닙니다.

사용자와 Google이 최종적으로 올바른 페이지에 도달하고 있는지를 확인하는 것이 더 중요합니다.

함께 보면 좋은 글

티스토리 Search Console ‘중복 페이지’ 확인 방법｜표준 페이지와 canonical 상태 이해하기

다음 글 예고

티스토리 Search Console ‘robots.txt에 의해 차단됨’ 확인 방법｜크롤링 차단과 색인 상태 구분하기

다음 글에서는 Search Console에서 robots.txt 관련 상태를 발견했을 때 무조건 차단을 해제하려고 하지 않고 먼저 해당 URL이 검색에 노출될 필요가 있는 페이지인지 판단하는 방법을 정리하겠습니다.

robots.txt가 하는 역할과 noindex의 차이, 티스토리에서 직접 수정할 수 있는 범위, 실제 게시글이 차단된 경우 확인할 내용까지 살펴보겠습니다.

티스토리 Search Console ‘중복 페이지’ 확인 방법｜표준 페이지와 canonical 상태 이해하기