배너 이미지 출처: https://www.trailblaze.marketing/blog/google-search-console
구글 서치 콘솔에서는 도메인을 등록하면 문제가 생길때마다 관련 이슈를 메일로 보내주는데,
경험했던 구글 서치 콘솔 에러들을 유형별로 정리 해보았다:
여기서 "적절한 표준 태그가 포함된 대체 페이지"란 canonical tag를 말한다.
Canonical Tag:
웹사이트에서
<link rel="canonical" href="https://example.com/page/" />
형식으로 사용되는 HTML 태그로, 유사하거나 중복된 콘텐츠를 가진 여러 URL이 있을 때, 구글에게 "이 URL이 원본(또는 선호되는) 버전이다"라고 알려주는 페이지다.예를 들어,
- 다국어를 지원하지만 모든 페이지가 완벽히 번역되지 않아 여러 페이지가 동일한 컨텐츠를 보여주고 있을 때
- 동일한 제품이 여러 카테고리에 있어 다른 URL로 접근 가능할 때
- 모바일과 데스크톱 버전의 페이지가 별도로 있을 때
- 매개변수가 다른 URL들이 동일한 콘텐츠를 제공할 때 (예: ?color=red, ?size=large 등)
이런 경우 정규화 태그를 사용하여 구글에게 "이 여러 URL 중에서 이 URL이 대표 URL이다"라고 알려주는 목적으로 사용된다.
부연 설명을 하자면, 위 서비스의 경우 10여개의 언어를 지원하는 '다국어'서비스이다. 따라서 언어별로 URL이 각각 생겨나게 되는데, URL이 다르면 구글에서는 모두 다른 페이지로 인식을 한다.
(ex. www.abc.com/en-US/promotion
-> 영어 페이지, www.abc.com/ko-KR/promotion
-> 한국어 페이지)
그런데 완벽하게 번역이 적용된 페이지도 있고, 현재 번역작업이 진행중이라 백업 언어인 영어로 표기되는 페이지들도 다수 있었던 것! 구글의 봇의 입장에서는 URL만 다를뿐, 영어로 된 내용이 같으니 중복페이지로 인식을 했던 것이다!💡
그래서 이렇게 피치못하게 URL이 다른 중복이나 유사 페이지가 생기는 경우에는 구글에게 선호되는 버전을 canonical 태그로 알려주는 것이 중요하다.⭐️⭐️⭐️
다시 돌아와서,
구글 서치콘솔에서 "적절한 표준 태그가 포함된 대체 페이지"라는 메일이 올때는 다음 중 하나일 가능성이 높다:
(이 부분부터 보여지는 재검사 프로세스는 모든 이슈 공통)
수정 작업이 완료되었다면 수정 결과 확인
버튼으로 재검사 요청을 할 수 있다.
재검사가 시작되면 유효성 검사 상태:시작됨
이 보여진다.
검사가 시작되면 아래 메일을 보내주고,
그리고 정상적으로 반영이 되었다면 반영결과를 알려주는 메일을 구글 서치 콘솔에서 보내준다.
위 이슈는 헤더에 스키마로 넣었던 review rating 정보가 구글이 지정한 rating 범위를 벗어났을 때 나타났다.
// LD+JSON (schema) 중 해당부분 추출
{
'@context': 'https://schema.org',
'@type': 'Product',
name: `${partnerName}`,
aggregateRating: {
'@type': 'AggregateRating',
ratingValue: `${
!reviewData?.ratings.overall || reviewData?.ratings.overall === 0
? 1
: reviewData?.ratings.overall / 2
}`, // 구글이 인정하는 평점은 5.0 만점이므로 2로 나누어 준다. 값이 없거나 0인 경우 1로 처리 (default: 10점 만점)
reviewCount: `${
Number(reviewData?.serviceDetails.reviewCount || 0) === 0
? 1
: Number(reviewData?.serviceDetails.reviewCount || 1)
}`, // 리뷰 수가 0인 경우 1로 처리
},
},
💡 ratingValue와 reviewCount 등록 조건:
ratingValue: 최대
5
이하의 점수
reviewCount: 최소1
개 이상
그래서 1/2값으로 변환된 평점으로 수정해서 다시 검사를 실행한 결과, 정상적으로 반영이 되었다!
제품 스니펫 (Product Rich Snippet)
정식 명칭은 "Product Rich Snippet". 흔히 알고 있는 스키마 마크업과도 일맥상통한다.
스키마 마크업이 Google에 의해 인식되면 제품 스니펫(가격·재고 등)이 검색 결과에 노출되는 것!
즉, 스키마는 마크업, 스니펫은 결과물!
결론부터 말하자면, "아니요, '꼭' 넣을 필요는 없습니다."
하지만 클릭전환율을 하나라도 올리고 싶다면, "네, 넣으세요."
제품 스니펫을 넣어야겠다는 생각이 닿은 데에는 이런 플로우가 있었다:
➡️ 검색결과에서 클릭하고 싶은 페이지란 어떤 페이지일까?
➡️ 정보를 얻기 위한 검색이라면, 신뢰도가 높고 사용자가 많은 페이지를 클릭 하지 않을까?
➡️ 그럼 어떤 검색결과가 신뢰도가 높아보이고, 사용자가 많아 보일까?
➡️ 검색결과에 정보가 더 많이 보여지게 해야겠다!
이런 이유로 타사이트의 리뷰와 평점을 남기는 커뮤니티 서비스의 성격상, 별점과 리뷰수를 검색결과에 보여줄 수 있을 것이란 결론이 났던 것이다.
리뷰 수 & 평점 제품 스니펫이 적용된 검색결과 예시(*아래 사진은 본문의 서비스와 무관 합니다) 🔽:
스니펫을 설정해서 배포하더라도 실제 검색결과에 노출이 되기 까지는 시간이 N주 ~ 1달가량 소요되는데,
잘 적용이 되고나면 Google Search Console의 사이드바에도 해당 메뉴가 생겨난다.
아래와 같이 사이드바에 못보던 메뉴가 생겼다면, 적어도 구글이 인지를 했다는 것!
페이지가 색인(a.k.a 인덱싱)되지 않는 이유는 다양하다.
Google Search Console의 색인 생성 보고서에서는 어떤 이유로 페이지가 색인이 되지 않는 지를 보여준다.
보안상의 이유(ex. 로그인이 되어야 볼 수 있는 페이지)나 모종의 이유로 임시로 사용자 유입을 막아야 한다면 여러가지 방법으로 페이지 색인을 막을 수 있다.
의도와는 상관없이 Google Search Console에서는 (어떠한 기준이나 주기로 이메일을 보내주는 지 정확히 알 수는 없지만) 페이지 미노출이 의도된 액션이 아닐 걸 우려해서 주기적으로 이메일로 노티를 준다.
이번에도 색인이 생성되지 않았다며 이메일을 받았고, 위 경우는 의도된 색인방지 조치가 있었기 때문이었다:
미노출 페이지 색인 방지하기
- Sitemap에서 페이지 제거
- robots.txt에
Disallow: {경로}
표기- URL로 직접 접근 시 404 페이지 혹은 메인 페이지로 리라우팅 될 수 있게 미들웨어 설정 (선택)
- 페이지
<Head>
태그 내부에<meta name="robots" content="noindex, nofollow" />
메타태그 넣어주기
이 중에서도 2번 혹은 4번 때문에 받은 이슈 메일으로 보여졌는데 심각하지 않은 문제
라고 한다.
(정말 영향을 크게 미치는 심각한 문제는 "심각"이라는 표현이 그대로 사용된다😅)
자세한 내용을 보니 해당 페이지는 위의 페이지 색인 방지하기
4가지 방법이 모두 적용된 페이지였는데, 추후 재사용 될 경우를 위해서 페이지 자체는 삭제하지 않았다보니, URL이 살아있는 걸로 판단해 위와 같은 경고를 보낸 것으로 보여진다.
그래서 무시하고 넘어갈 수도 있었겠지만, 가능한 추가조치를 모색하다가 이미 색인된 내역 안에서 삭제를 요청하는 삭제 기능을 사용해보았다:
적용 결과는 TBC...