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

티스토리를 운영하면서 Google Search Console의 페이지 색인 생성 보고서를 확인하다 보면 ‘중복’이나 ‘표준 페이지’와 관련된 상태를 발견할 수 있습니다.

대표적으로 다음과 같은 문구입니다.

‘사용자가 선택한 표준이 없는 중복 페이지’

‘적절한 표준 태그가 포함된 대체 페이지’

‘중복 페이지, Google에서 사용자와 다른 표준 페이지를 선택함’

처음 보면 내 블로그에 중복 콘텐츠 문제가 생긴 것처럼 느껴질 수 있습니다.

“비슷한 글을 너무 많이 작성한 걸까?”

“중복 페이지를 삭제해야 할까?”

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

하지만 Search Console에서 말하는 ‘중복 페이지’와 블로그에서 흔히 말하는 ‘내용이 비슷한 게시글’은 반드시 같은 의미가 아닙니다.

하나의 콘텐츠가 여러 URL로 접근되는 기술적인 상황에서도 중복 URL이 발생할 수 있고, Google은 이 가운데 대표로 사용할 URL을 선택할 수 있습니다.

따라서 중복이라는 문구만 보고 게시글부터 삭제하는 것은 피하는 것이 좋습니다.

이번 글에서는 Search Console에서 중복 페이지 관련 상태를 발견했을 때 표준 URL이 무엇인지, 어떤 주소를 먼저 확인해야 하는지, 실제 게시글 중복과 URL 중복을 어떻게 구분하는지 정리해 보겠습니다.

✓ 먼저 표준 URL이 무엇인지 이해합니다

같거나 매우 비슷한 콘텐츠를 여러 URL에서 볼 수 있는 경우 Google은 그중 하나를 대표 URL로 선택할 수 있습니다.

이 대표 URL을 표준 URL, 즉 canonical URL이라고 합니다.

예를 들어 같은 콘텐츠에 접근할 수 있는 주소가 여러 개 있다고 가정하겠습니다.

Google이 이 주소들을 서로 중복되거나 매우 유사한 페이지로 판단하면 하나를 대표 URL로 선택하고 나머지는 중복 또는 대체 URL로 처리할 수 있습니다.

따라서 중복으로 분류된 URL이 모두 Google 검색 결과에 각각 표시되어야 하는 것은 아닙니다.

✓ Search Console의 중복은 글 내용 중복만 의미하지 않습니다

블로그 운영자가 생각하는 중복 콘텐츠는 보통 이런 경우입니다.

제목만 조금 다르고 내용은 거의 같은 게시글 두 개를 작성한 경우입니다.

하지만 Search Console에서 말하는 중복 URL은 범위가 조금 다릅니다.

실질적으로 같은 페이지가 서로 다른 URL을 통해 발견되거나 URL 매개변수, 모바일·대체 버전 등의 이유로 비슷한 페이지가 여러 주소에서 발견되는 경우도 포함될 수 있습니다.

따라서 Search Console에 ‘중복’이라는 단어가 있다고 바로 자신의 게시글 두 개가 서로 경쟁하고 있다고 결론 내리지 않습니다.

✓ 먼저 어떤 중복 상태인지 확인합니다

Search Console의 페이지 색인 생성 보고서에서 중복 관련 상태를 발견했다면 문구를 정확하게 확인합니다.

대표적으로 구분해서 볼 상태가 있습니다.

‘적절한 표준 태그가 포함된 대체 페이지’

해당 URL이 다른 페이지의 대체 버전으로 올바르게 표준 페이지를 가리키고 있는 상태일 수 있습니다.

표준으로 지정된 페이지가 정상적이라면 별도의 조치가 필요하지 않을 수 있습니다.

‘사용자가 선택한 표준이 없는 중복 페이지’

Google이 해당 URL을 다른 페이지의 중복으로 판단했고 별도로 선언된 표준 URL이 없어 Google이 다른 URL을 표준으로 선택한 상태입니다.

이 경우 Google이 어떤 주소를 표준으로 선택했는지 확인하는 것이 중요합니다.

‘중복 페이지, Google에서 사용자와 다른 표준 페이지를 선택함’

페이지에서 선호하는 표준 URL을 나타냈지만 Google이 다른 URL을 더 적절한 표준 페이지라고 판단한 상황입니다.

이 경우 내가 의도한 URL과 Google이 선택한 URL을 비교해야 합니다.

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

중복 관련 상태를 발견했다면 보고서의 숫자만 보고 판단하지 않습니다.

페이지 색인 생성 보고서에서 해당 상태를 선택한 뒤 표시되는 예시 URL을 확인합니다.

그리고 URL 하나를 선택해 실제 주소를 살펴봅니다.

여기에서 먼저 확인할 것은 단순합니다.

정상적인 게시글 URL인가?

같은 게시글의 다른 형태의 주소인가?

내가 직접 작성한 다른 게시글인가?

주소 뒤에 추가 문자열이나 매개변수가 붙어 있는가?

실제로 존재할 필요가 있는 별도의 페이지인가?

URL 형태를 확인하면 기술적인 중복인지 실제 콘텐츠 중복인지 판단하는 데 도움이 됩니다.

✓ URL 검사에서 Google이 선택한 표준 페이지를 확인합니다

중복 상태를 이해하는 데 가장 중요한 단계입니다.

Search Console의 URL 검사에 확인하려는 주소를 입력합니다.

페이지 색인 생성 관련 세부 정보에서 사용자가 선언한 표준 URL과 Google이 선택한 표준 URL 정보를 확인할 수 있습니다.

여기서 Google이 선택한 표준 URL이 내가 실제 검색 결과에 표시되기를 원하는 정상 게시글 주소인지 살펴봅니다.

중복으로 표시된 주소 자체가 색인되지 않았더라도 정상적인 원본 URL이 표준으로 선택되어 색인되고 있다면 의도대로 처리되고 있는 상황일 수 있습니다.

반대로 전혀 예상하지 못한 URL이 표준으로 선택되어 있다면 두 페이지의 관계를 조금 더 자세히 확인해야 합니다.

✓ 실시간 URL 테스트만으로 표준 선택을 판단하지 않습니다

지난 글에서 사용했던 실시간 URL 테스트와 구분해야 할 부분이 있습니다.

실시간 테스트는 현재 Google의 검사 도구가 URL에 접근할 수 있는지 등을 확인하는 데 도움이 됩니다.

하지만 Google의 표준 URL 선택은 색인 처리 과정에서 결정되는 정보이므로 실시간 테스트만으로 최종 canonical 선택을 예측할 수는 없습니다.

따라서 중복 페이지를 확인할 때는 저장된 URL 검사 결과의 ‘Google이 선택한 표준 URL’을 확인하는 것이 중요합니다.

✓ Google이 정상 게시글을 표준으로 선택했다면 먼저 상황을 이해합니다

예를 들어 동일한 콘텐츠로 연결되는 A 주소와 B 주소가 있다고 하겠습니다.

A는 실제 티스토리 게시글의 정상 URL입니다.

B는 같은 콘텐츠를 보여주는 다른 형태의 URL입니다.

Search Console에서는 B를 중복으로 처리하고 A를 표준 URL로 선택했습니다.

이때 A가 정상적으로 색인되고 있다면 B까지 별도의 검색 결과로 표시되지 않는 것이 반드시 문제는 아닙니다.

중복된 여러 URL 가운데 대표 URL 하나를 선택하는 과정일 수 있기 때문입니다.

따라서 중복 URL 숫자를 무조건 0으로 만드는 것을 목표로 삼지 않습니다.

✓ 실제 게시글 두 개가 비슷한 경우는 따로 확인합니다

이번에는 기술적인 URL 중복이 아니라 실제 게시글 두 개가 매우 비슷한 경우입니다.

예를 들어 다음과 같은 글이 있다고 하겠습니다.

‘티스토리 검색 유입이 줄었을 때 확인하는 방법’

‘티스토리 구글 검색 방문자가 감소했을 때 확인하는 방법’

제목뿐 아니라 두 글에서 해결하는 질문과 본문 내용까지 거의 같다면 실제 콘텐츠 역할이 겹칠 수 있습니다.

이 경우 canonical만 확인한다고 해결되는 문제로 생각하면 안 됩니다.

두 글이 각각 다른 검색 의도에 답하는지 확인하고, 실질적으로 같은 내용을 반복한다면 기존 글 보완이나 콘텐츠 통합 등을 검토하는 편이 자연스럽습니다.

canonical은 비슷한 글을 계속 만들어도 괜찮게 해주는 장치가 아닙니다.

✓ 제목이 비슷하다는 이유만으로 중복이라고 판단하지 않습니다

반대의 경우도 있습니다.

제목에 같은 단어가 많이 들어간다고 두 게시글이 반드시 중복인 것은 아닙니다.

예를 들어 이번 글과 지난 글을 비교해 보겠습니다.

‘발견됨 - 현재 색인이 생성되지 않음’

‘크롤링됨 - 현재 색인이 생성되지 않음’

두 제목에는 많은 단어가 겹칩니다.

하지만 하나는 Google이 URL을 알고 있지만 아직 크롤링하지 않은 상태를 다루고, 다른 하나는 이미 크롤링했지만 현재 색인하지 않은 상태를 다룹니다.

검색자가 해결하려는 문제와 확인 과정이 다르므로 별도의 콘텐츠로 존재할 이유가 있습니다.

따라서 단어의 중복보다 검색 의도와 실제 답변의 차이를 확인하는 것이 중요합니다.

✓ Google이 다른 표준 페이지를 선택했다면 두 URL을 비교합니다

내가 기대한 URL과 Google이 선택한 표준 URL이 다르다면 먼저 두 주소를 직접 열어봅니다.

콘텐츠가 실제로 거의 같은지 확인합니다.

제목과 본문이 같은지도 살펴봅니다.

한쪽이 다른 쪽의 대체 버전인지 확인합니다.

내가 의도하지 않은 별개의 게시글인지도 살펴봅니다.

만약 Google이 선택한 URL이 실제로 대표 페이지로 사용해도 되는 정상적인 주소라면 반드시 문제가 있는 것은 아닙니다.

반대로 두 페이지가 서로 다른 주제를 다루는데 Google이 중복으로 판단했다면 두 콘텐츠의 차이가 충분히 명확한지 다시 확인할 필요가 있습니다.

✓ canonical은 명령이 아니라 신호로 이해합니다

페이지에서 특정 URL을 표준으로 나타냈다고 Google이 반드시 그 URL만 선택하는 것은 아닙니다.

Google은 여러 신호를 종합해 다른 URL을 표준으로 선택할 수도 있습니다.

따라서

“canonical이 있으니 무조건 이 URL이 색인된다.”

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

Search Console에서 사용자가 선언한 표준 URL과 Google이 선택한 표준 URL이 다르게 표시될 수 있는 이유도 여기에 있습니다.

중요한 것은 실제로 어떤 URL이 대표 페이지로 선택되었는지를 확인하는 것입니다.

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

독립적으로 서버를 운영하는 웹사이트에서는 URL 구조나 리디렉션, HTTP 헤더 등 다양한 기술적 설정을 직접 관리할 수 있습니다.

하지만 티스토리는 플랫폼에서 제공하는 환경 안에서 운영합니다.

따라서 Search Console에서 중복 URL을 발견했다고 서버 수준의 설정을 임의로 변경하려고 하기보다 먼저 티스토리에서 실제로 관리할 수 있는 부분을 확인하는 것이 좋습니다.

게시글 공개 상태

게시글 주소

내부 링크

실제 중복 게시글

스킨을 직접 수정했다면 관련 HTML 설정

이런 항목부터 확인합니다.

기술적인 설정을 잘 모르는 상태에서 canonical 관련 코드를 무작정 추가하거나 변경하는 것은 피하는 것이 좋습니다.

✓ 중복 페이지를 발견했을 때 하지 말아야 할 방법

중복이라는 문구를 없애기 위해 다음과 같은 작업부터 하지 않습니다.

중복으로 표시된 URL을 모두 삭제합니다.

정상 게시글을 새 주소로 다시 작성합니다.

비슷한 글을 삭제했다가 다시 발행합니다.

canonical 코드를 정확한 이유 없이 수정합니다.

모든 페이지에 임의로 같은 canonical URL을 지정합니다.

Search Console에서 중복 숫자가 0이 될 때까지 계속 설정을 변경합니다.

Google이 정상 원본 URL을 표준으로 선택한 상태라면 별도의 수정이 필요하지 않을 수도 있습니다.

따라서 먼저 상태를 이해한 뒤 실제 문제가 있을 때만 수정합니다.

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

A 사례

Search Console에서 B 주소가 중복으로 표시됩니다.

URL 검사를 확인했더니 Google이 선택한 표준 URL은 정상적인 A 게시글입니다.

A 게시글도 정상적으로 색인되어 있습니다.

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

B 사례

서로 다른 두 게시글을 작성했지만 제목과 본문 내용이 거의 같습니다.

Google이 한쪽을 다른 글의 중복으로 판단하고 있습니다.

이 경우 canonical 설정부터 변경하기보다 두 글이 실제로 각각 존재해야 할 이유가 있는지 확인합니다.

검색 의도가 사실상 같다면 콘텐츠 통합이나 기존 글 보완을 검토할 수 있습니다.

C 사례

중복으로 표시된 URL에 매개변수처럼 보이는 문자열이 붙어 있지만 실제로 열어보면 정상 게시글과 같은 내용을 보여줍니다.

Google도 정상 게시글 주소를 표준으로 선택했습니다.

이 경우 해당 중복 URL을 검색 결과에 별도로 표시할 필요가 있는지부터 생각합니다.

정상 원본이 표준으로 처리되고 있다면 중복 URL 자체를 억지로 색인시키지 않습니다.

D 사례

A와 B는 서로 다른 내용을 제공하는 독립적인 게시글인데 Google이 A를 B의 중복으로 판단하고 있습니다.

이 경우 두 페이지의 제목만 다른 것이 아니라 본문에서 해결하는 질문과 정보까지 충분히 구분되는지 확인합니다.

실제로 서로 다른 콘텐츠라면 차이가 명확하게 드러나도록 내용을 개선할 수 있습니다.

✓ 중복 페이지 최종 체크리스트

□ Search Console에서 정확한 중복 상태 문구를 확인했다.

□ 예시 URL을 직접 열어봤다.

□ 실제 게시글인지 다른 형태의 URL인지 확인했다.

□ URL 검사에서 Google이 선택한 표준 URL을 확인했다.

□ 정상 게시글이 표준으로 선택되어 있는지 확인했다.

□ 사용자가 선언한 표준과 Google이 선택한 표준을 구분했다.

□ 기술적인 URL 중복과 실제 게시글 중복을 구분했다.

□ 제목만 비슷하다는 이유로 중복이라고 판단하지 않았다.

□ 실제 게시글의 검색 의도와 내용이 겹치는지 확인했다.

□ 중복 URL을 억지로 모두 색인시키려고 하지 않았다.

□ 이유 없이 canonical 관련 설정을 변경하지 않았다.

자주 묻는 질문

Q1. Search Console에 중복 페이지가 있으면 SEO 문제가 생긴 건가요?

반드시 그렇지는 않습니다. Google이 같은 콘텐츠에 접근할 수 있는 여러 URL 가운데 하나를 표준으로 선택하고 나머지를 중복으로 처리하는 것은 정상적인 상황일 수 있습니다. Google이 예상한 정상 URL을 표준으로 선택했는지 확인하는 것이 먼저입니다.

Q2. ‘적절한 표준 태그가 포함된 대체 페이지’는 수정해야 하나요?

대체 URL이 올바르게 표준 페이지를 가리키고 있고 해당 표준 페이지가 정상적으로 색인되어 있다면 별도의 조치가 필요하지 않을 수 있습니다.

Q3. ‘사용자가 선택한 표준이 없는 중복 페이지’는 무엇인가요?

해당 URL이 다른 페이지와 중복되지만 별도로 선호하는 표준 URL을 나타내지 않은 상태를 의미합니다. Google이 다른 URL을 표준으로 선택했으므로 URL 검사에서 어떤 주소가 선택되었는지 확인하는 것이 좋습니다.

Q4. Google이 내가 원하는 URL과 다른 페이지를 표준으로 선택하면 어떻게 하나요?

먼저 두 URL을 직접 비교합니다. 실제로 같은 콘텐츠라면 Google이 선택한 URL이 대표 페이지로 적절한지 확인합니다. 서로 다른 독립적인 글인데 중복으로 판단됐다면 두 콘텐츠가 실제로 충분히 다른 질문과 정보를 제공하는지도 살펴봅니다.

Q5. canonical을 설정하면 원하는 페이지가 반드시 색인되나요?

반드시 그렇지는 않습니다. canonical은 Google이 표준 URL을 판단할 때 사용하는 신호이며 Google이 다른 URL을 선택할 수도 있습니다. 따라서 설정 자체보다 Search Console에서 실제로 어떤 URL이 표준으로 선택됐는지 확인하는 것이 중요합니다.

마무리｜중복 숫자보다 Google이 선택한 대표 URL을 확인합니다

Search Console에서 ‘중복 페이지’라는 문구를 발견하면 먼저 콘텐츠를 삭제하고 싶어질 수 있습니다.

하지만 중복 URL이 있다는 사실과 품질이 낮은 중복 게시글을 여러 개 작성했다는 것은 같은 의미가 아닙니다.

같은 콘텐츠에 여러 주소로 접근할 수 있어 Google이 하나를 표준 URL로 선택한 상황일 수도 있습니다.

따라서 가장 먼저 해야 할 일은 중복으로 표시된 URL을 직접 확인하는 것입니다.

그다음 URL 검사에서 Google이 선택한 표준 URL을 살펴봅니다.

정상적인 원본 게시글이 표준으로 선택되어 있다면 중복 URL이 별도로 색인되지 않는 것이 자연스러운 경우도 있습니다.

반대로 실제 게시글 두 개의 검색 의도와 본문 내용이 거의 같다면 canonical만으로 해결하려 하지 말고 두 콘텐츠가 각각 존재할 이유가 있는지 확인해야 합니다.

Search Console 관리의 목표는 모든 ‘색인이 생성되지 않음’ 숫자를 0으로 만드는 것이 아닙니다.

검색 결과에 대표로 나타나야 할 페이지가 올바르게 선택되고 있는지를 확인하는 것이 더 중요합니다.

함께 보면 좋은 글

티스토리 Search Console ‘발견됨 - 현재 색인이 생성되지 않음’ 확인 방법｜크롤링 전 상태 점검하기

티스토리 Search Console ‘발견됨 - 현재 색인이 생성되지 않음’ 확인 방법｜크롤링 전 상태 점검

다음 글 예고

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

다음 글에서는 Search Console에서 ‘리디렉션이 포함된 페이지’를 발견했을 때 왜 해당 URL 자체가 색인되지 않을 수 있는지 살펴보겠습니다.

정상적으로 다른 주소로 이동하는 URL과 의도하지 않은 이동을 구분하고, URL 검사에서 확인할 내용과 티스토리에서 실제로 점검할 부분까지 정리하겠습니다.