[태그:] schema

  • 구조화된 데이터와 리치 스니펫

    리치 스니펫

    스니펫에 관해서는 아래의 글에서 몇가지를 설명했고 RICH Snippet에 관한 내용도 일부 포함하고 있습니다. 특별히 중요한 이야기는 아닙니다만 SEO를 이야기 하다보면 스니펫이라는 단어가 자주 등장합니다. 스니펫의 의미를 모르는 분은 별로 없으시겠지만 확인 한번 하시는 것을 추천합니다.

    별것 아니지만 이미 스니펫에 대해서는 이야기를 했습니다.

    검색엔진은 구조화된 데이터(structured data)라는 값을 이용하여 리치 스니펫으로 나타낼 내용을 만들어 냅니다. 이러한 구조화된 데이터는 표준안으로 다양한 정보를 웹에 표기하고 (기계들이 이해하기 편하도록 하여서) DB화 하기 편하도록 만들어진 것으로 실제로 검색엔진에 사용되지 않는 표준안의 내용도 굉장히 많은 수가 https://schema.org에 정의 되어 있습니다. 예를 들면 비행편의 출도착 시간과 같은 데이터의 경우 검색엔진에서는 사용되지 않지만 메일을 통해 수신된 데이터를 아웃룩의 일정이나 구글 캘린더의 일정에 자동삽입 하는 등 다양한 용도로 활용될 수도 있습니다.1 메일의 내용에 구조화된 데이터가 삽입되어 있어 이것을 읽어 다양하게 활용하는 것이지요. 메일의 디자인이 바뀌거나 보내는 형태가 달라진다 하더라도 가능한 이유는 실제 보이지 않는 부분에서 이렇게 데이터가 읽어지게 되어 있기 때문입니다.

    리치 스니펫의 종류

    구글과 Bing.com 같은 검색엔진은 사용자의 편의를 위해 이러한 구조화된 데이터를 활용하여 더 많은 정보를 검색엔진 상에서 바로 사용자에게 전달할 수 있도록 리치 스니펫이라는 것으로 해당 데이터를 표현하고 있으나 이러한 리치 스니펫은 각각이 유사하긴 하지만 표준화 될 수 없는 각 검색엔진의 고유의 디자인을 따르며 검색 엔진 별로 제공되는 종류도 다릅니다.

    Bing.com의 경우 구글에 비해 매우 적은 수의 리치스니펫을 제공하고 있습니다. bing.com의 Marking up your site: Overview에 따르면 2021년 1월 말 현재 총 9가지의 리치스니펫이 제공되고 있습니다. 그중 하나는 Breadscrums라 실질적으로는 8가지라고 봐야겠네요. 하지만 지속적으로 확대할 것이 확실한 만큼 확인해 보실 필요가 있습니다. 그래도 항상 구글과 다른 특별한 것을 제공한 적은 없었기에 구글의 리치 스니펫 갤러리만 확인하여도 무방할거라 생각되며, 아직 Bing.com의 한국내 점유율은 너무 적어서 의미가 없을 것 같습니다. 다만 서비스가 영문으로 글로벌 시장에 대응한다면 그래도 10%가 넘는 점유율을 가지고 있으므로 그렇게 무시할 수 있는 존재는 아닙니다. 구글의 경우 2021년 1월 말 현재 30가지의 리치 스니펫이 제공되고 있음을 확인할 수 있습니다.

    추천하는 구글 리치 스니펫

    리치 스니펫의 효과

    하지만 구조화된 데이터를 통해서 검색엔진에서 리치 스니펫을 구현했다고 하더라도 실제로 SEO에 나타나는 효과는 전무합니다.리치 스니펫과 구조화된 데이터는 검색 순위에는 전혀 즉각적인 영향을 끼치지 않습니다. 다만 이러한 리치 스니펫은 사용자의 시선을 집중시켜 더 많은 클릭을 유도할 수 있고 그러한 클릭에 의해 검색순위는 차츰 올라가게 됩니다.

    리치 스니펫은 적극적이고 전략적으로 반영하자

    이러한 긍정적인 효과가 있기 때문에 대부분의 SEO 컨설턴트들도 단기적 성과가 전혀 나오지 않지만 적극적으로 이용하는 것을 추천하고 있습니다. 또한 어떤 데이터를 활용하여 구조화된 데이터를 만들어야 하는지에 대한 가이드를 제시하기도 합니다. 실제로 웹서비스의 각 페이지에 어떤 구조화된 데이터를 심어서 어떤 리치 스니펫을 검색엔진에 노출할 것인지를 결정하는 것은 전략적으로 굉장히 중요한 요소입니다. 이 때문에 웹사이트를 제작하는 단계나 SEO 개선작업을 진행하는 단계에서 경험자의 조언을 필요로 하는 경우가 많으며 이를 위해 컨설팅이 필요하기도 합니다. 이를 위해 웹페이지의 콘텐츠 내용을 추가하거나 페이지를 합치는 등 개발적 요소가 추가되어야 할 경우도 종종 발생합니다.

    리치 스니펫을 만들 수 있는 구조화된 데이터 페이지를 확인하기 위해 만들어진 페이지의 URL이나 페이지의 코드를 구글 리치 검색결과 테스트 페이지를 통해 테스트 해보실 수 있습니다.

  • Breadcrumb List, 구조화된 데이터이지만 뭔가 다르다.

    Breadcrumb List, 구조화된 데이터이지만 뭔가 다르다.

    Breadcrumb List

    breadcrumb 미국 [brédkrΛm] 영국 [brédkrΛm] 
    1. 빵부스러기
    2. 지나온 흔적
    3. 빵가루

    daum 사전, breadcrumb의 뜻

    평소에 잘 사용하지 않는 단어가 나와서 조금 어색합니다만 breadcrumb이라는 단어를 사용합니다. 그림형제의 헨젤과 그레텔에서 유래한 단어입니다. 돌아갈 길을 표시하기 위해 길에 뿌려두었던 빵부스러기가 이 단어가 사용된 유래라고 하는데 쉬운 단어를 쓰지 왜…. breadcrumbs, breadcrumb list, breadcrumb navigation 등으로 불리웁니다.

    헨젤과 그레텔의 빵조각, 헨젤과 그랬데가 아니다. 출처 : 안전보건공단 공식블로그

    우리말로는 ‘탐색경로’로 보통 표기합니다. 사이트의 각 페이지간 계층 구조에서 페이지의 위치를 말하며 방문자가 웹사이트를 효율적으로 인지하여 이동하는데 도움이 됩니다. 일반적으로 웹페이지에 표기하는 네비게이션이 이에 해당합니다. 이러한 현 위치를 포함한 상위 페이지에 대한 목록을 규정하여 검색엔진에 알려주기 위한 데이터 표준이 Breadcrumb List입니다. 이렇게 제공된 데이터(구조화된 데이터)은 Google 등 검색엔진의 스니펫에 네비게이션 값으로 표시됩니다.

    Breadcrumb List의 schema

    Breadcrumb을 표현하는 방법은 이미 표준화가 잘 되어 있습니다만 오래전에 작업된 곳은 Data-Vocabulary.org의 표준을 따라 만들어 진 곳이 있을지도 모르겠습니다. 2021년 1월 이후에는 무조건 schema.org의 표준을 따라야 합니다. Breadcrumb List 표준 스키마는 꽤나 보기에 심플합니다. 표준 스키마(구조화된 데이터)를 각 페이지에 표기하는 방식은 Microdata, RDFa, JSON-LD 세가지 방법을 사용합니다.

    일반적으로 우리는 [Home > 제품 > 가구 > 의자] 또는 [Home / 제품 / 가구 / 의자] 와 같은 형태로 웹페이지에 현재의 위치를 표기합니다. 이 내용을 3가지 방식으로 표기할 때 상세 내용은 표준 스키마를 참고하시면 되겠지만 구현 방법은 셋중 하나를 선택해야 합니다.

    Microdata를 선택한 경우 장점은 개발 시 HTML에 추가의 마크업을 하는 것으로 화면상의 네비게이션을 데이터로 검색엔진에 전달가능하다는 장점이 있습니다. Microdata는 HTML 마크업의 속성으로 메타 데이터를 지정하는 방법으로 W3C 에서 정의한 표준방식입니다.

    <ol itemscope itemtype="https://schema.org/BreadcrumbList">
      <li itemprop="itemListElement" itemscope
          itemtype="https://schema.org/ListItem">
        <a itemprop="item" href="https://example.com/dresses">
        <span itemprop="name">Dresses</span></a>
        <meta itemprop="position" content="1" />
      </li>
      <li itemprop="itemListElement" itemscope
          itemtype="https://schema.org/ListItem">
        <a itemprop="item" href="https://example.com/dresses/real">
        <span itemprop="name">Real Dresses</span></a>
        <meta itemprop="position" content="2" />
      </li>
    </ol>

    RDFa는 Resource Description Framework in Attributes의 약자로 꼭 이걸 알아야만 하나 싶은 이름인데 실제로는 Microdata와 거의 차이가 없고 W3C의 표준입니다. Microdata와 같이 HTML에 속성으로 어떤 정보인지를 표시합니다. 다만 기술적으로 약간의 차이가 존재하긴 합니다.

    <ol vocab="https://schema.org/" typeof="BreadcrumbList">
      <li property="itemListElement" typeof="ListItem">
        <a property="item" typeof="WebPage" href="https://example.com/dresses">
         <span property="name">Dresses</span></a>
         <meta property="position" content="1">
      </li>
      <li property="itemListElement" typeof="ListItem">
        <a property="item" typeof="WebPage" href="https://example.com/dresses/real">
        <span property="name">Real Dresses</span></a>
        <meta property="position" content="2">
      </li>
    </ol>

    JSON-LD는 JavaScript Object Notation for Linked Data의 약자로 JSON을 사용하여 링크드 데이터를 인코딩하는 방식이라고 하는데 개발자의 영역에 속한 이야기라고 생각되긴 하지만 제목 정도는 알아둘 필요가 있을 것 같다. 다른 방식과의 가장 큰 차이는 HTML 표기와 별개로 <script> 태그를 통해 웹페이지 가운데 별도로 데이터를 삽입 하는 형태라는 것이 가장 큰 차이가 되겠습니다.

    <script type="application/ld+json">
    {
     "@context": "https://schema.org",
     "@type": "BreadcrumbList",
     "itemListElement":
     [
      {
       "@type": "ListItem",
       "position": 1,
       "item":
       {
        "@id": "https://example.com/dresses",
        "name": "Dresses"
        }
      },
      {
       "@type": "ListItem",
      "position": 2,
      "item":
       {
         "@id": "https://example.com/dresses/real",
         "name": "Real Dresses"
       }
      }
     ]
    }
    </script>

    세가지 방식에서 살짝 Microdata가 구식 방식이긴 합니다. 다만 적용면에서 RDFa보다는 쉽다는 장점이 있습니다. 기획자의 입장에서 본다면 Microdata나 RDFa는 어느 정도 HTML에 대한 이해가 있다면 직접 수정이나 이해가 가능한 수준이라고 생각됩니다만 마지막 방법인 JSON-LD는 개발자 또는 퍼블리셔의 지원이 필요할 것 같습니다. 최근의 개발자들은 아무래도 JSON-LD를 선호하는 것 같습니다. 또한 디자인과 별개로 운영이 가능한 장점이 있어 최근의 프로젝트는 대부분 이 형태를 취하는 추세입니다.

    Google은 공식적으로 JSON-LD를 이용하는 것을 추천하고 있습니다. 하지만 Microdata나 RDFa를 쓰지 말라는 이야기는 아닙니다.

    Breadcrumb List는 어떻게 만들어야 하나?

    이제까지 이게 어떤 것인지, 어떻게 데이터를 만들어서 검색엔진에 전달할 것인지를 이야기 했는데 갑자기 어떻게 만들어야 하냐는 질문을 하니 뭔가 어색합니다. 하지만 네비게이션(탐색경로)을 정의하는 것은 꽤 큰 난제가 하나 있습니다.

    이것은 사이트를 처음 구축할 때 구축할 때 일반적으로 작성하는 문서와 깊은 관련이 있습니다. 아마도 이 글을 읽으시는 분들은 대부분 화면흐름도 (Screen Flow chart)와 IA(Information Architecture)라는 단어를 들어 보셨을 겁니다.

    IA는 메뉴를 분류/그룹화하여 Depth 구조로 설계한 것이고, 화면흐름도는 화면, 기능 단위로 사용 동선을 설계하는 것입니다.

    화면흐름도 (Screen Flow chart)와 IA(Information Architecture)

    IA를 생각했을 때 일반적인 경우에는 [홈 > 제품 > 가구 > 의자 > 회전의자A] 라는 ‘회전의자A’라는 상품페이지의 탐색경로가 매우 당연한 상태라고 생각되겠지만, 화면흐름도상 검색을 통해서 접근했다고 하면 [홈 > 검색목록 > 회전의자A] 또한 틀리지 않을 겁니다. 화면의 네비게이션이 현재의 위치를 표시한다는 정의에 따르면 둘다 맞는 것이죠. 또한 다른 형태의 카테고리로 이동이 가능하도록 설계된 웹사이트라고 한다면 [홈 > 제품 > 가구 > 사무용 > 회전의자A] 의 접근도 가능할 것입니다. 심한 경우에는 [홈 > 특가상품 > 회전의자A]라는 형태도 나오게 되겠죠. 이렇게 동일한 페이지에 대한 접근 방식은 여러가지가 나오는 것이 당연하고 이 모든 것을 기획하는 기획자는 기준을 잡아야 할 필요가 있습니다.

    사실 이부분은 아직도 명확하게 정답은 없습니다. 다만 요령을 피울 필요가 있는 상황이죠. 하지만 한가지 확실한 부분은 SEO를 위해서는 동일한 콘텐츠를 가지고 있는 페이지는 동일한 canonical link를 보유하고, 검색엔진에 다양한 접근방법이 있더라도 동일한 페이지라고 알려주는 것이 좀더 나은 결과를 만들 수 있다는 것입니다. 다행스럽게도 코드상 삽입할 때는 2개까지는 유효하게 인정되기는 합니다. 심플하게 가장 접근이 많은 분류로 구조를 잡으시는 것을 추천합니다.

    최근 얼마간의 시장에서의 접근 방법은 새창/새탭으로 접근하는 방식입니다. IA상의 표준화된 네비게이션을 표시하여도 문제가 되지 않고 그 전단계는 의미를 가진 다른 페이지이니 만큼 화면흐름도 상의 네비게이션을 사용하는 것입니다.

    대단히 큰 문제를 만들거나 하지는 않겠지만 조금은 섬세한 접근이 필요하다고나 할까요? 그전에 지금 당장 서비스 하고 있는 웹사이트에 Breadcrumb List가 올바로 들어가 있는지 확인해보시고 추가가 필요한 경우 화면 디자인 수정 없이 접근 가능하도록 JSON-LD로 삽입부터 하시죠.