검색 엔진 최적화 Deep Dive
Next.js와 같은 SSR을 지원하는 프레임워크를 사용하면서, SEO와 관련된 이야기를 자주 접하게 되는데, 이런 이야기들을 대개 중간 과정없이, 곧바로 다음 결론으로 이어지는 경향이 있는 것 같다.
SSR은 SEO에 유리하다.
CSR은 SEO에 불리하다.
그런데 단순히 렌더링 관점에서만 SEO를 생각하기엔 해결되지 않는 의문들이 많다.
만약 모든 사이트가 SSR을 사용한다면, 그중에서도 높은 점수와 낮은 점수를 받는 기준이 있어야 하지 않을까?
CSR인데도 검색 결과에 잘 표시되는 사이트는 뭐지?
렌더링 이외에 SEO에 영향을 주는 요소?
이런 궁금증들이 구글 SEO 가이드를 읽은 계기가 되었다. 이해가 잘 안되거나 어려운 내용도 있었는데, 대부분은 웹마스터(구글의 경우, Search Console)도구를 활용하여 진단 및 해결, 원인 분석이 가능한 내용이었다.
이 글의 대부분은 구글 SEO 가이드를 참고하여 정리한 내용이라, 구글 검색엔진에만 해당하는 내용이 있을 수 있다.
검색 엔진
검색 엔진은 검색 기능이 있는 웹 콘텐츠 데이터베이스이며, 검색어에 대해 복잡한 알고리즘을 거쳐, 가장 적합한 결과를 유저에게 보여주는 소프트웨어이고, 구글은 주기적으로 크롤링, 인덱싱을 통해 데이터를 확보하고 검색어에 대한 검색 결과를 보여주는 100% 자동화된 검색 엔진이다.
크롤링은 웹페이지를 찾아서 수집하는 과정이다. 이 과정은 다양한 방식으로 진행되는데, 사람이 검색 엔진에게 알려줄 수도 있고, 크롤러가 페이지에 포함된 링크들을 이동해가며 알아낼 수도 있다. 단순히 웹 페이지뿐만 아니라, 이미지, 동영상, 파비콘 등도 수집 대상이 된다.
이렇게 수집 대상이 된 리소스들은 인덱싱이라는 프로세스를 통해 데이터베이스에 저장되는데, 인덱싱은 단순히 리소스를 데이터베이스에 저장하는 과정만 포함된게 아니라, 크롤링된 대상을 분석하는 과정까지 포함한다.
분석 과정에선 유저에게 보이는 페이지의 콘텐츠인 Text, 이미지, 동영상도 활용되고, 검색 엔진을 위해 작성한 meta 태그, Structured Data등의 요소도 활용된다.
SEO
검색엔진 최적화(SEO)의 정의는 보통 SEO자체에 대한 정의와, SEO로 얻을 수 있는 이점들을 함께 나열하는 경우가 많은 것 같다. 구글에선 다음과 같이 정의한다.
- 웹 사이트를 검색 엔진이 잘 이해하도록 만드는 과정
웹사이트를 검색 엔진이 잘 이해하면 좋은 점은 다음과 같다.
검색 결과에 표시될 수 있다.
검색 결과에 매력적으로 표시될 수 있다. (= Rich results)
관련있는 검색 결과에 표시될 수 있다.
검색 결과에 표시된다는건 이해하기 어렵지 않다.
매력적으로 보인다는건, 검색을 하는 주체인 사람이, 검색된 사이트에 유입될 수 있도록 검색 결과를 매력적으로 표시하는걸 의미한다.
관련있는 검색 결과라는건, 검색어에 꼭 그 웹사이트의 이름을 직접적으로 사용하지 않더라도, 연관이 있다고 검색엔진이 판단하는 경우에 검색 결과로 보여줄 수 있음을 의미한다.
검색 엔진은 복잡하다
검색 엔진은 정말 복잡하다. 검색 랭킹 시스템 가이드를 살펴보면, 구글이 웹페이지의 콘텐츠를 이해하기 위해 사용하는 수많은 시스템, AI와 심지어 PageRank 논문까지 소개되어있다.
똑같은 키워드로 검색해도 유저의 위치에 따라 검색 결과가 달라질 수 있는 것처럼, 검색어 이외에도 검색 결과에 영향을 주는 요소들이 존재하고, 검색 결과에 반영하기 위해 meta 태그, Structured Data를 작성하는 등의 SEO를 적용한다 하더라도, 검색결과를 100% 제어하는건 불가능하다.
대부분의 심층 가이드에서도 이러한 SEO과정은 검색 결과에 표시되었으면 하는 단어나 문장을 힌트로 제공하는 역할로 소개되고, 무조건 검색 결과에 반영되는것도 아니며, 최종적으로는 검색 시스템이 결정한다고 적혀있다.
SEO 기본 가이드에 대부분의 내용이 설명되어있지만, 내용이 너무 많아서 다 언급하는건 힘들고, 중요하다고 생각하는 몇 가지만 정리해보았다.
스팸 정책 확인하기
웹페이지를 만들 때 유저를 위한 콘텐츠를 만드는게 우선되어야 하고, 검색 엔진을 위한 콘텐츠를 만들지 말라는 말이 반복적으로 나온다. 주로 스팸 정책에서 설명하고 있는데, 작정하고 위반하려는게 아닌 이상, 신경 쓸 필요가 없는게 대부분이다.
예를들어 의도적으로 배경색과 텍스트색을 동일하게 만들거나, 폰트사이즈를 매우 작게 설정하여 유저에게 텍스트를 숨기는건 스팸 정책 위반이지만, 스크린 리더 사용자에게 좋은 경험을 주기 위한 텍스트 숨김이나, 아코디언 혹은 탭, 툴팁을 사용하여 페이지의 공간을 절약하기 위해 텍스트를 숨기는건 스팸에 해당하지 않는다. 그리고 검색엔진은 이를 잘 구분하는 듯 하다.
그나마 신경써야 할 부분은 링크 스팸 정책이다.
Crawlable 링크
크롤러는 페이지에 포함된 링크를 따라가며 웹 사이트를 수집한다. 단, 크롤링 가능한 링크는 <a>태그에 href어트리뷰트로 포함된 링크뿐이다. 이러한 링크를 Crawlable한 링크라고 한다.
href어트리뷰트가 아니라 다른 커스텀 어트리뷰트를 쓰거나, 핸들러를 등록하는 방식으로 링크하는 경우엔, 크롤러가 파싱을 시도할 수는 있지만 대부분 권장되지 않는다. 따라서 크롤링 대상이 될 링크를 추가하고 싶다면, <button>같은게 아니라 <a>를 활용하는게 좋다.
백링크
웹사이트에 <a>태그로 작성된 외부 링크를 백링크라고 한다. 구글 검색 순위에 반영되는 요소들은 명확하게 공개되어있지 않지만, 백링크와 검색 순위가 강한 상관관계를 보이는 통계자료는 어렵지 않게 접할 수 있다. (출처)
그래서 악용될 가능성 또한 높다. 예를들어, 백링크를 구매하거나 판매하는 행위들이 있을 수 있는데, 검색 랭킹 상승을 위해 링크를 사고 파는 행위는 스팸 정책 위반에 해당한다.
링크 스팸 정책
링크 스팸을 신경써야 하는 이유는, 백링크 사이트가 품질이 낮다면, 백링크를 게재한 사이트도 불이익을 받을 수 있기 때문이다. 이를 막을 수 있는 방법이, <a>태그의 rel 어트리뷰트를 사용하여 링크된 페이지와 내 페이지의 관계를 크롤러에게 알려주는 것이다.
예를들어, 위에서 언급한 백링크를 사고 파는 행위도, 링크에 rel="sponsored"를 넣어주면 스팸 정책 위반이 아니다.
유저가 사이트에서 작성하는 게시글, 댓글에 포함된 링크의 품질도, 사이트를 제작한 개발자가 제어할 수 있는 부분이 아니다. 이 경우엔, 유저로부터 생성된 콘텐츠(user-generated content)라는 의미로, rel="ugc"라는 어트리뷰트를 포함시키면 된다. ugc대신 nofollow라는 값을 써도 되고, 둘 다 써도 된다. 이게 포함되어있는 경우 크롤러가 백링크를 따라가지 않는다.
자세한 내용은 rel 어트리뷰트 가이드에서 확인할 수 있다.
유저 중심 콘텐츠
유저 중심의 콘텐츠와 반대되는 말은 검색 순위를 올리기 위한, 검색 엔진을 위한 콘텐츠를 의미한다.
예를들어, 내용과 관계없는 키워드를 자주 반복(Keyword Stuffing)하는 방식으로, 검색 결과에 특정 키워드를 노출시키려는 목적으로 작성하면 스팸으로 간주될 수 있다. 다음은 키워드 스터핑의 예시이다. (출처)
이것도 작정한게 아니라면 위반하기 힘들 것으로 생각한다.
꼭 키워드 반복이 아니더라도, 타 사이트의 원본 콘텐츠를 복제해서 전달하는 페이지라든가, 유저들의 이목을 끌기 위한 어그로성 제목을 작성해놓고, 내용에는 아예 상관없는 콘텐츠를 포함시키는 방식같은 것들은 전부 페이지 품질을 하락시키는 요인이 된다.
콘텐츠 뿐만 아니라, 좋은 Page Experience를 제공하는 것도 중요하다. Page Experience을 평가하는 여러가지 지표가 있는데, 페이지 내부 링크가 적절하게 연결되어 있어서 유저가 쉽게 탐색이 가능한지, 광고가 유저의 인터랙션을 방해하지 않는지, 웹사이트가 모바일 버전을 지원하는지, HTTPS를 사용하는지, Core Web Vitals 점수가 높은지 등이다.
Mobile-First Indexing
구글의 크롤러는 데스크톱 버전과 스마트폰 버전으로 나뉘는데, 대부분의 경우 스마트폰 크롤러를 사용하며, 이를 Mobile-First Indexing라고 부른다.
robots.txt로 선호하는 로봇을 선택할 수 있지 않나? 하는 의문이 들 수 있는데, 아래 사진을 보면 알 수 있듯, 두 크롤러의 UA토큰(robots.txt에서 사용되는 크롤러의 이름)은 Googlebot으로 동일해서 어느 하나를 선택하는게 불가능하며, 구글봇 가이드에도 이 내용이 언급되어 있다.
따라서 모바일 버전을 반드시 지원하는게 좋다. 모바일을 지원하기 위한 방법은 여러가지가 있지만, 요즘에는 대부분 Responsive Design을 적용하는편인것 같고, 구글에서도 가장 권장하는 형태이다. 모바일 버전과 데스크톱 버전을 다른 URL로 만들어두고, 요청 디바이스를 감지해서 응답하는 방법도 있는데 자주 사용되는것 같지는 않다.
크롤링과 인덱싱 제어하기
구글이 인덱싱할 수 있는 파일타입은 매우 많으며, 웹페이지(HTML)는 그중 하나다. (참고)
기본적으로 웹사이트를 배포하고 아무런 조치를 취하지 않으면, 사이트의 모든 페이지가 크롤링 및 인덱싱 대상이 된다. 결과적으로 검색 결과에 표시될 가능성이 생긴다. 하지만, 어떤 페이지는 검색결과에 노출시키고 싶지 않을 수도 있다. 이런 경우에 특정 페이지가 검색 결과에 표시되지 않도록 인덱싱을 제어하거나, 수집 대상이 되지 않도록 크롤링을 제어하는 방법이 있다.
크롤링을 제어할 때는 robots.txt파일을 사용하고, 인덱싱을 제어할 때는 robots meta태그 또는 X-Robots-Tag HTTP응답 헤더를 활용한다.
Crawl Budget
Crawl Budget은 구글에서 크롤링하는데 사용하는 시간 및 리소스의 양을 의미한다. 당연하지만 크롤러의 개수는 한정되어 있고, 웹 페이지는 계속해서 늘어나기 때문에 Crawl Budget도 제한되어있다.
Crawl Budget은 Crawl Capacity Limit과 Crawl Demand 두 가지 요인에 의해 결정된다.
Crawl Capacity Limit은 한번 크롤링할 때 얼마나 많이 할 수 있느냐와 관련이 있는데, 사이트가 빠르게 응답하면 값이 올라가고, 사이트의 응답 속도가 느려지거나 오류 응답이 발생하는 경우엔 낮아진다.
Crawl Demand는 크롤링이 얼마나 필요한가와 관련있다. 인기있는 URL일수록 자주 크롤링되고, 업데이트가 필요한 URL도 여러번 크롤링될 수 있다. (따라서 사이트맵의 <lastmod>를 잘 활용하면 좋다.)
중요한건 크롤링을 위한 리소스는 제한되어있으니, 크롤링을 효율적으로 하도록 만들어야 한다는 것이다. 이를 위해 canonicalization, robots.txt를 통한 크롤링 제어, 삭제된 페이지에 대해 404 상태코드 반환, 사이트맵 관리 등 여러 방법을 사용할 수 있다. (참고)
robots.txt
Robots.txt는 크롤러가 접근할 수 있는 파일 및 페이지를 제어하려는 목적으로 작성하는 파일이다. 주로 웹 서버에 과부하가 걸리는걸 방지하는 용도로 사용한다. (참고)
크롤러도 HTTP 클라이언트라서, 크롤러가 과도하게 웹 서버에 요청을 보내면 실제 유저에게까지 영향을 줄 수 있다. 예를들어 페이지에 캘린더가 있고, 이전달 또는 다음달로 갈 수 있는 링크가 배치되어있다면, 날짜의 범위가 정해져있지 않는 한, 크롤러는 계속해서 다음달에 해당하는 링크를 따라가며 웹 서버에 요청을 보낼것이다. 이러면 서버에 과도한 요청이 발생할 수 있다. 이런 상황에 크롤링을 제어할 목적으로 robots.txt를 사용할 수 있다.
robots.txt는 웹사이트의 최상위 디렉토리에 존재해야 하고, public한 파일이기 때문에, 누구나 볼 수 있다. 따라서 민감한 정보를 포함해서는 안된다. 그리고 특정 파일, URL의 크롤링을 허용하는게 기본값이기 때문에, 크롤링을 허용하지 않을 URL이나 파일이 있을 때만 작성하면 된다.
robots meta 태그
Robots meta태그는 HTML 메타 태그로, 크롤러의 행동이나 검색 결과에 표시되는 방식을 제어할 때 사용한다. 예를들어 인덱싱을 제어하려면 아래와 같이 사용한다.
<meta name="robots" content="noindex" />
// 검색 결과에 표시되지 않음
이외에도 다양한 룰이 있다. (참고)
페이지에 존재하는 링크의 크롤링 여부 제어
검색 결과에 표시되는 스니펫의 Visibility 제어, 길이 제어
이미지 미리보기 개수 제어, 동영상 미리보기 시간 제어
메타 태그 대신에, HTTP 응답의 X-Robots-Tag 헤더를 사용할 수도 있다.
크롤링을 차단하는 것과 인덱싱을 차단하는 것은 다르다
특정 URL이 검색 결과에 표시되지 않도록 하려면 인덱싱을 차단해야한다. 크롤링을 차단한다고 검색결과에서 제거될 것을 보장하지는 않는다. (참고)
예를들어, 내 사이트의 robots.txt에서 크롤링을 차단해도, 다른 사이트에 차단하려는 페이지가 백링크로 게재되어있으면 크롤링 대상이 될 수 있으며, 이 때 robots meta태그로 인덱싱을 제어하지 않았다면 검색 결과에 여전히 표시될 수 있는 것이다.
그러니까 특정 페이지를 검색 결과에 표시하고 싶지 않은 경우엔, robots.txt가 아니라, robots meta태그를 활용해야 한다. 중요한 점은, robots meta태그는 “일단 크롤링이 되어야” 크롤러가 확인할 수 있다는 것이다. 그리고, 크롤러는 인덱싱이 차단된 페이지를 가끔 다시 크롤링하여 차단 여부가 바뀌지 않았는지 체크하는 과정도 고려하기 때문에, 인덱싱을 차단하고 싶은 페이지를 robots.txt에 작성하는건 엄밀히 말하면 올바른 사용법은 아니다. (참고)
404 페이지는 인덱싱 대상일까?
404 Not Found 페이지도 커스텀 방식에 따라 유용하게 활용될 수 있다. 단순히 페이지를 찾을 수 없다는 메세지만 주기보다는, 사이트 내의 여러 페이지들을 링크해줄 수도 있다.
그렇다면 404페이지는 크롤링 및 인덱싱을 허용해야하는건가? 하는 의문이 들 수 있다. 개인적으로 궁금해서 여러 사이트의 404페이지를 열고 메타 태그를 비교해봤는데, noindex룰을 따로 명시하지 않은 사이트가 많았다. 룰을 명시하지 않으면 기본값은 허용이다. 그래서 인덱싱이 되는 줄 알았지만, 결론만 먼저 얘기하자면 404페이지는 인덱싱 대상이 아니다.
웹 서버가 HTTP 요청에 대해 응답할 때는 상태 코드도 함께 응답한다. 2XX는 성공, 3XX는 리다이렉션, 4XX는 클라이언트 에러, 5XX는 서버 에러이다.
크롤러는 2XX로 응답하는 리소스에 대해서만 인덱싱 후보로 간주하고, 4XX에 대해서는 429코드를 제외한 나머지는 전부 인덱싱 대상으로 고려하지 않는다.
404페이지는 페이지 응답시 항상 404 상태 코드를 반환하기 때문에, meta 태그가 어떻게 되어있든 무조건 인덱싱 대상이 아닌 것이다. (참고)
Soft 404
404 상태코드를 반환하지 않는 404 페이지도 있다. 200코드를 반환하면서, 페이지에 오류 메세지를 표시해주는 경우이다. (참고)
구글은 이미 인덱싱 되어있는 URL이 4XX 상태코드를 응답하는 경우엔, 해당 URL을 인덱스에서 제거한다. 따라서 삭제된 페이지가 있다면 200코드보단 404로 응답하는게 적절하다. SPA에서는 이게 어렵기 때문에 404페이지로 리다이렉션 시키거나, 자바스크립트를 사용하여 동적으로 robots meta태그를 사용하여, noindex값을 추가하는 방법을 사용할 수 있다. (출처)
Canonicalization
중복 페이지가 있는 경우 효율적인 크롤링이 어려워진다.
프로토콜(HTTP, HTTPS)또는 포트번호가 다르지만 콘텐츠는 중복인 경우
지역은 다르지만 동일한 언어로 쓰인 경우 (언어가 다르면 동일 콘텐츠로 취급하지 않는다)
테스트(데모) 서버를 크롤링 가능하게 설정한 경우
필터링, 정렬 결과 URL은 다르지만 콘텐츠는 동일한 경우
이렇게 중복되거나 유사한 페이지가 여러개 있다면 검색엔진이 적절한 알고리즘을 통해 그중 하나의 URL을 대표 URL로 선택한다. 이를 Canonical URL이라고 하는데, Canonical URL은 가장 자주 크롤링되며, 나머지는 적게 크롤링된다. 따라서 Crawl Budget을 효율적으로 사용할 수 있게 된다.
사이트 소유주 입장에서 우려되는건 의도하지 않은 URL이 Canonical URL로 선택되는 경우일 것이다. 그래서 선호하는 Canonical URL을 검색엔진에게 힌트로 제공하는 방법이 있다.
선호하는 Canonical URL을 강한 시그널로 알리려는 경우엔, 중복 URL에 접속했을 때, 힌트로 제공하고 싶은 Canonical URL로 리다이렉션을 시키거나, meta 태그인 <link>태그에 rel="canonical"어트리뷰트를 추가하면 된다.
사이트맵에 Canonical URL을 작성하는 방법도 있는데, 이 방법은 리다이렉션이나 rel="canonical"어트리뷰트가 포함된 <link> meta태그를 작성하는 것보단 약한 시그널로 취급된다. (참고)
Sitemap
사이트의 모든 페이지가 내부적으로 링크되어있어서 어떤 페이지든 도달 가능하면, 모든 페이지가 크롤링이 된다. 그런데 사이트가 커지다보면 도달 가능 여부를 판단하는게 어려울 수 있고, 내부적으로 링크되어있지 않아서 도달할 수 없는 페이지도 생길 수 있다. 이 때 사이트맵이 도움이 될 수 있다. 사이트맵은 크롤링 가능한 페이지를 검색 엔진에게 알리는 파일이다.
Sitemap Protocol
사이트맵을 작성하는 방법은 사이트맵 프로토콜 가이드에 자세히 나와있다. 여러 포맷으로 작성할 수 있지만, XML이 가장 흔하다.
여기를 참고하면 사용할 수 있는 태그는 6개로 소개되지만, 구글은 <priority>랑 <changefreq>를 무시하고 (참고), <urlset>은 HTML로 치면 <html>처럼 루트레벨에서 한번만 쓰이므로 사실상 <url>, <loc>, <lastmod>만 알면 된다. <lastmod>는 옵션이고, 나머지 두개는 필수로 작성해야 한다.
예시
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="<http://www.sitemaps.org/schemas/sitemap/0.9>">
<url>
<loc><http://www.example.com/></loc>
</url>
</urlset>
사이트맵 사용시 URL은 절대경로를 사용해야하고, 용량 제한은 최대 5만개의 URL 또는 압축하지 않았을 때 50MB를 넘으면 안된다. 용량 제한을 넘었다면 사이트맵 인덱스 파일을 활용할 수 있는데, 한마디로 여러개의 사이트맵을 작성한 뒤, 각 사이트맵의 URL을 명시한 인덱스 파일을 작성하는 것이다. (참고)
예시
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="<http://www.sitemaps.org/schemas/sitemap/0.9>">
<sitemap>
<loc><http://www.example.com/sitemap1.xml></loc>
</sitemap>
<sitemap>
<loc><http://www.example.com/sitemap2.xml></loc>
</sitemap>
</sitemapindex>
사이트맵 프로토콜은 확장 가능하다(= 추가적인 태그를 활용할 수 있다). 확장을 위해서는 <urlset>태그에 xmlns라는 네임스페이스 어트리뷰트를 추가해야 하는데, 이를 통해 URL에 대한 추가 정보를 제공하여 검색 엔진에게 더 구체적인 정보를 줄 수 있다. 구글에선 이미지, 동영상, 뉴스에 대한 사이트맵 확장을 제공한다. (참고)
사이트맵을 제출하는 방법은 여기를 참고하면 된다.
자바스크립트와 SEO
구글의 검색 시스템은 클라이언트 사이드에서 자바스크립트로 HTML을 렌더링하는(CSR) 페이지도 인덱싱이 가능하다. (출처)
구글봇은 메타 태그 혹은 HTTP 응답헤더에 noindex값이 있는 경우를 제외하면 페이지를 렌더 큐에 넣는데, 리소스가 남으면 페이지의 자바스크립트까지 실행한다.
SSR이나 SSG(Pre-render)가 SEO에 유리하다는건, HTML을 렌더링하기 위해 구글의 WRS(Web Rendering System)가 아닌 웹서버의 리소스를 쓰기 때문에, 페이지가 렌더 큐에서 대기하는 시간이 짧아진다는 점, 모든 봇이 자바스크립트를 실행할 수 있는게 아니라는 점 때문이다. 그렇다고 CSR로 작성된 페이지가 인덱싱 대상에서 제외된다는건 아니므로, 웹사이트가 CSR을 사용한다고 해도 구글 검색 결과에는 여전히 표시될 수 있다.
Infinite Scroll vs Pagination
아이템의 목록을 보여주는 경우에 무한스크롤이나 페이지네이션을 고려해볼 수 있다. 페이지네이션은 다음 페이지에 대한 링크를 제공하기 때문에, 모든 페이지 및 아이템에 연결된 링크가 크롤링될 수 있다.
하지만, 무한스크롤은 그렇지 않다. 크롤러는 스크롤이나 더보기 버튼 클릭같은 유저 인터랙션을 수행할 수 없어서, 유저 인터랙션이 있어야 추가적인 아이템이 로드되는 상황에선, 크롤러가 누락하는 아이템이 생긴다. (출처)
검색 친화적인 무한스크롤을 만들려면 페이지네이션이랑 결합해야 한다. 이 사이트에서 해당 예시를 확인할 수 있다.
Structured Data
Structured Data는 페이지의 정보를 검색 엔진에게 더 명확하게 전달하기 위한 포맷으로, 검색 결과를 더 풍부하게 만드는데 사용된다. 더 풍부한 검색 결과는 유저 유입 가능성을 더 높일 수 있으니 이득이다. 이러한 검색 결과를 Rich Results라고 한다. 구조화된 데이터, 스키마 마크업이라고도 불린다.
Structured Data의 대상은 여기서 확인할 수 있고, 우측에는 각 대상에 해당하는 Rich Results가 어떻게 보이는지 나타나있다.
Structured Data 포맷은 3가지가 있다. JSON-LD, Microdata, RDFa인데, JSON-LD는 콘텐츠 외부에 <script>태그를 써서 JSON으로 표현하고, Microdata와 RDFa는 모두 마크업된 콘텐츠에 특정 어트리뷰트를 추가하여 표현하는 방식이다. 구글은 JSON-LD를 권장하는데, 개인적으로도 기존 마크업을 건드리지 않아도 된다는 점 때문에, 사용하게 된다면 JSON-LD를 선택할 생각이다.
Microdata와 RDFa는 어트리뷰트로 표현한다는 점 때문에 비슷해보이는데, 차이점은 여기에서 확인할 수 있다.
예를들어, 구글 검색 결과에 노출되는 사이트 이름은 검색 엔진이 결정하는데, Structured Data를 추가하여 선호하는 사이트 이름을 힌트로 제공할 수 있다. (참고)
JSON-LD로 표현한 예시는 다음과 같다.
<script type="application/ld+json">
{
"@context" : "<https://schema.org>",
"@type" : "WebSite",
"name" : "SiteName", // 여기에 이름을 적는다. (필수)
"alternateName": ["AltSiteName1", "AltSiteName2"], // 여기에 대체 버전을 적는다. (옵션)
"url" : "<https://example.com/>"
}
</script>
Microdata로는 다음과 같이 표현할 수 있다.
<div itemscope itemtype="<https://schema.org/WebSite>">
<meta itemprop="url" content="<https://example.com/>"/>
<meta itemprop="name" content="SiteName"/>
<meta itemprop="alternateName" content="AltSiteName1"/>
<meta itemprop="alternateName" content="AltSiteName2"/>
</div>
RDFa로는 다음과 같이 표현할 수 있다.
<div vocab="<http://schema.org/>" typeof="WebSite">
<meta property="url" content="<https://example.com/>"/>
<meta property="name" content="SiteName"/>
<meta property="alternateName" content="AltSiteName1"/>
<meta property="alternateName" content="AltSiteName2"/>
</div>
Schema.org에서 제공하는 Validator를 통해 테스트도 가능하다.
실제 HTML 콘텐츠엔 없는 내용을 Structured Data에 포함시키는 경우 스팸 정책 위반(클로킹)에 해당할 수 있으므로 주의해야 한다.
가이드 내용은 계속 업데이트 되고 있고, Google SEO Blog에도 반영된다.
가이드를 읽고 느낀점은, 여기 나온 내용대로 따른다고 원하는 결과를 100% 달성할 수는 없다는 것이다. 기본 내용들은 당연히 숙지해야겠지만, Search Console을 활용한 모니터링이 더 중요한 것 같고, 분석중 의문이 생기면 가이드를 다시 한번 보거나 Google Support에 질문 올리는게 나아보인다.
다른 자료들도 여러개 찾아봤는데, 목록은 다음과 같다.
대부분은 구글 가이드에서 나온 내용의 반복이라 굳이 읽을 필욘 없는것 같다. 네이버 서치 어드바이저의 경우, 사이트를 그만둘 때에 대한 가이드는 한번 쯤 읽어볼 만 하고, 나머지는 구글 SEO 가이드의 한국어 버전 느낌인데, 아마 Bing이나 Yahoo같은 다른 검색엔진도 비슷하지 않을까 싶다.