[카테고리:] Technical SEO

  • 웹접근성과 SEO

    웹접근성과 SEO

    웹접근성

    웹 접근성(web accessibility)은 장애인이나 고령자분들이 웹 사이트에서 제공하는 정보를 비장애인과 동등하게 접근하고 이용 할 수 있도록 보장하는 것으로 웹 접근성 준수는 법적의무사항 입니다.

    사단법인 한국장애인총연합회 한국웹접근성인증평가원

    웹접근성은 의외로 어려운 작업입니다. 꽤 까다로운 항목들이 많아 실제 작업에 적용하기 힘든 부분이 다수 존재할 수 밖에 없습니다. 웹접근성과 SEO사이에는 공통점이 있습니다. 그것은 사용자에게 콘텐츠를 전달하는 것입니다. 실제로 접근 가능한 콘텐츠와 검색엔진에 최적화 된 콘텐츠는 모두 컴퓨터를 통해서 읽을 수 있다는 의미입니다. 검색엔진과 스크린리더(장애인의 콘텐츠 접근을 돕는 보조 기술장치)의 기술은 이러한 관점에서 매우 유사하며, 둘다 콘텐츠의 구조와 의미, 기능에 의존하여 사용자에게 콘텐츠를 제공하거나 콘텐츠간의 관련성을 결정하게 됩니다.

    웹접근성 심사와 관련하여 아래의 인증 후기를 방문해 보신다면 아마도 웹관련 일을 하시는 분이시라면 물 없이 삶은 고구마와 달걀을 원없이 드신 후의 답답함을 느끼실 수 있으실 겁니다.

    접근성과 SEO

    하지만 최근의 검색엔진은 점점 사람의 지능을 따라올 정도로 발전하고 있습니다. 특히 구글 검색엔진은 크롤러/봇 부터 별도의 기술을 사용하지 않고 크롬브라우저와 거의 동일한 기능을 가진 엔진을 사용하여 여러분의 웹사이트를 읽게 됩니다. 또한 최신의 AI와 ML을 통해서 점점 더 인간과 유사한 동작을 하고 있습니다. 예를 들면 이미지의 텍스트를 OCR하여 텍스트로 변환하여 의미를 파악하는 수준에서 이제는 이미지 속 사람의 수와 표정 등을 읽거나 주변환경 등을 읽어내기 시작했습니다.

    이러한 기술의 접목이 검색엔진에 적용되어 그 차이가 커졌을거라 예상하기 쉽습니다. 하지만 구글은 이러한 기술의 발전을 점점 더 그 차이를 확인하는 곳에 사용하고 있습니다. 예를 들면 화면을 읽어 링크간의 거리를 측정하여 사용자가 사용하기 어렵게 구현되어 있다든지, 모바일 화면보다 콘텐츠가 밀려나서 표시된다든지 하는 부분을 발견한다면 구글은 해당 페이지의 순위를 낮추는 행위를 합니다.

    구글에서는 검색순위에 영향을 미치는 웹접근성을 돕기위해 구글 Lighthouse에서 Accessibility 점수를 제공하고 있습니다. 아쉽게도 제 서비스인 https://seoguide.kr 은 Accessibility가 89점으로 나오는군요.

    다른 점수는 그럴듯한데 Accessibility 만 떨어집니다.

    SEO와 접근성을 위한 기초 작업

    • 이미지는 무조건 적합한 대체 텍스트 사용
    • 구조적으로 정확한 H tag 사용, 제목은 무조건 사용
    • 설명을 포함한 링크 텍스트 사용
    • 마우스 동작에 의존적인 기능 사용 자제
    • 가능한 웹표준 형식 사용
    • 비디오 삽입시 스크립트 및 캡션 제공
    • 다양한 콘텐츠 접근 방법 제공 (ex. 검색, 사이트맵, 목차, 메뉴, 네비게이션 등)
    • 이미지 보다는 텍스트 우선 사용
    • 명확하고 일관된 페이지 구조와 네비게이션
    • 사람이 인식할 수 있고 논리적인 URL 제공

    SEO는 접근성 개선과 함께

    검색엔진 로봇에 의한 크롤 가능성을 확보하는 작업을 「크롤러빌리티의 확보」, 정확한 색인을 돕는 작업을 「인덱서빌리티의 확보」라고 합니다. 이것들은 웹 접근성 향상을 위한 기본적인 작업을 통해 동시에 달성할 수 있습니다. 스크린 리더로 접근가능하고 읽을 수 있는 콘텐츠를 검색엔진은 선호하고 읽어서 인덱스를 만들어 검색엔진 사용자에게 제공합니다. 다르게 말하면 웹 접근성을 따르는 것이 곧 SEO 작업의 하나 입니다.

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

    리치 스니펫

    스니펫에 관해서는 아래의 글에서 몇가지를 설명했고 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이나 페이지의 코드를 구글 리치 검색결과 테스트 페이지를 통해 테스트 해보실 수 있습니다.

  • sitemap.html? sitemap.xml 사이트맵!

    Sitemap?

    Sitemap은 웹마스터가 크롤링에 사용할 수 있는 사이트의 페이지에 대한 정보를 검색 엔진에 알리는 손쉬운 방법입니다. Sitemap의 가장 간단한 형식은 검색 엔진에서 사이트를 보다 지능적으로 크롤링할 수 있도록 각 URL에 대한 추가 메타데이터(마지막 업데이트된 날짜, 변경 빈도, 사이트의 다른 URL에 상대적인 중요도)와 함께 사이트에 대한 URL을 나열하는 XML 파일입니다.

    웹크롤러는 보통 해당 사이트 및 기타 사이트의 링크에서 페이지를 검색합니다.Sitemap은 해당 데이터를 보완하여 Sitemap을 지원하는 크롤러가 해당 Sitemap에 있는 모든 URL을 선택하고 관련 메타데이터를 사용하여 이들 URL에 대해 파악할 수 있도록 합니다.Sitemap 프로토콜을 사용하더라도 웹페이지가 반드시 검색 엔진에 포함되는 것은 아니지만 이를 통해 웹크롤러가 귀하의 사이트를 보다 효과적으로 크롤링하기 위한 힌트를 얻을 수 있습니다.

    Sitemap 0.90은 Attribution-ShareAlike Creative Commons License의 약관에 따라 제공되며 Google, Yahoo! 및 Microsoft의 지원을 비롯하여 널리 채택되고 있습니다.

    sitemaps.org 에서 이야기 하는 Sitemap의 의미

    Sitemap 은 사이트의 웹페이지 등을 나열하는 파일로 사이트 콘텐츠 구성을 구글, 네이버, 다음, Bing 등 다양한 검색 엔진에 알리는데 사용되는 파일입니다. 예전에는 웹페이지만을 이야기 했지만 최근에는 사이트에 있는 페이지 외에도, 동영상 및 이미지, 기타 파일과 각 관계에 관한 정보를 제공할 수 있습니다. 검색엔진은 이 파일을 읽고 사이트를 크롤링하여 검색 요청에 대응하기 위한 인덱스를 만들게 됩니다. 쉽게 말해서 사이트맵은 나의 사이트에서 중요하다고 생각하는 페이지와 파일을 검색엔진에 전달하여 검색 결과에 노출되게 하기 위한 기초적인 데이터입니다.

    반대로 이야기하면 나의 웹사이트를 검색엔진에 노출되게 하기 위한 가장 편리한 방법이 사이트맵을 제작하여 검색엔진에 제공하는 것입니다. 조금 딱딱한 내용이지만 이런 사이트맵에 관한 내용은 글로벌 검색엔진 업체들의 협약으로 만들어졌습니다. 반대로 이야기하면 자기들이 좀 더 쉽게 검색할 데이터를 얻기 위해서 만들었다고 봐도 되지만, 그 덕택에 새로운 자료를 검색엔진에 노출하기가 더 용이해지기도 하였습니다. 구글, 야후, 마이크로소프트(빙) 등이 채택한 사이트맵 표준은 sitemaps.org 에 정의되어 있습니다.

    Sitemap 만들기

    <?xml version="1.0" encoding="UTF-8"?>
    <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
       <url>
          <loc>http://www.example.com/</loc>
          <lastmod>2005-01-01</lastmod>
          <changefreq>monthly</changefreq>
          <priority>0.8</priority>
       </url>
    </urlset> 

    위 샘플코드를 보시면 쉽게 이해가 되겠지만 URL(절대경로)과 페이지가 마지막으로 업데이트된 날짜, 페이지 변경 빈도, 페이지의 중요성을 부가 정보로 추가할 수 있습니다. URL 외의 내용은 생략이 가능하며 최근의 매우 똑똑해진 검색엔진(구글 이라든가 google 이라든가..)은 해당 내용이 없어도 자신이 만든 기준으로 크롤링을 하고 중요도를 판단하고 있습니다. 실제로 구글은 공식적으로 <changefreq> 값과 <priority>값은 무시하기 때문에 사이트맵에 넣지 않도록 안내하고 있습니다.

    사이트맵은 위 샘플코드 처럼 XML로 제작하는 것이 일반적입니다. 다만 블로그의 경우 RSS, mRSS, Atom와 같은 표준 feed관리 코드로 검색엔진에 등록이 가능합니다. 그외에 지원하는 포맷은 TEXT입니다. 단순 URL을 한줄에 하나씩 넣은 txt 파일을 사이트맵으로 사용할 수 있습니다. 하지만 대부분의 경우 XML포맷을 이용합니다.

    또한 사이트맵의 XML 파일 안에 별도의 XML을 포함시킬 수 있습니다. 이것은 개발 운영 관점에서 매우 유용합니다. 프로그램으로 등록 / 관리되는 콘텐츠가 있다면(보통은 상품목록과 같은 것들이 해당됩니다.) 해당 콘텐츠의 URL만 별도의 XML로 일단위/주단위/월단위 등 주기적으로 생성하여 관리하고, 고정된 콘텐츠의 URL 묶음의 XML로 별도로 관리하면 굉장히 관리가 편리해 집니다. 또한 이벤트와 같이 freq가 높은 콘텐츠의 경우 daily로 관리한다면 검색엔진에 등록/관리하기가 유용해집니다. 또한 용량이 큰 경우 압축하여 관리할 수 있습니다. 한개의 사이트맵 파일은 50MB, 50,000개 이하의 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.gz</loc>
        </sitemap>
        <sitemap>
          <loc>http://www.example.com/sitemap2.xml.gz</loc>
        </sitemap>
      </sitemapindex> 

    Sitemap 등록

    사이트맵을 만드는 것은 익숙하지 않은 개발자에게는 꽤 오류를 만드는 작업입니다. 이것은 XML 파일을 만들면서 URL등의 이스케이프 처리가 익숙하지 않아서 발생하는 문제인데 작업 후 인터넷으로 무료 이용 가능한 무료 XML 사이트맵 확인기와 같은 서비스를 이용하여 검사하는 것이 좋습니다.

    사이트맵의 등록은 검색엔진들이 운영하는 search consol, webmaster tools 와 같은 서버스에 등록하거나, 웹 사이트 root에 robots.txt 에 아래 샘플코드와 같이 삽입하여 처리합니다.

    User-agent: *
    Allow: /
    
    Sitemap: http://www.example.com/sitemap.xml

    Sitemap이 필요하지 않은 경우

    하지만 사이트맵 파일이 전혀 필요치 않은 경우도 있습니다.

    1. 사이트의 크기가 적당히 작은 경우, 총 페이지가 500개 이하인 경우 특별히 만들어서 제공할 필요가 없습니다.
    2. 사이트의 모든 페이지들이 유기적으로 링크되어 있어 검색엔진의 크롤러가 직접 접속하여 확인이 가능한 경우
    3. 외부에 알려진 서비스로 제작된 사이트의 경우 (예를 들면 Wix와 같은 경우 별도의 작업이 필요 없습니다.)

    특히 2번의 경우를 주목하여야 합니다. 우리가 만드는 서비스는 내부의 링크를 유기적으로 관리하여 검색엔진이 직접 크롤이 가능하도록 설계할 필요가 있습니다. 기회가 되면 이 내용으로 별도의 내용을 포스팅하겠습니다.

  • 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로 삽입부터 하시죠.

  • SNS의 시대, SEO와 SNS의 상호 관계

    Open Graph Protocol

    Open Graph Protocol은 페이스북에서 정의하고 만들어 공개/표준화한 Meta Tag Protocol입니다. 기본적으로 하나의 URL이 페이스북에 공유될 때 표시될 콘텐츠를 정의하는 것을 목적으로 합니다. 이미 표준을 오픈소스로 공개하여 현재는 아주 다양한 곳에서 이 표준안을 활용하여 서비스를 하고 있습니다. The Open Graph protocol을 방문하시면 표준안 전체를 보실 수 있습니다. 웹만이 아닌 다양한 미디어를 공유하기 위한 표준이기에 꽤 많은 타입이 존재합니다.

    Open Graph protocol 로고

    표준으로 공개 후 급속히 활용 범위가 넓어지면서 현재는 Naver에서는 스니펫에 활용된다든지, Kakao의 경우 메신저에서 URL이 공유될 때 나오는 썸네일 등에 활용됩니다.

    <html prefix="og: https://ogp.me/ns#">
    <head>
    <title>The Rock (1996)</title>
    <meta property="og:title" content="The Rock" />
    <meta property="og:type" content="video.movie" />
    <meta property="og:url" content="https://www.imdb.com/title/tt0117500/" />
    <meta property="og:image" content="https://ia.media-imdb.com/images/rock.jpg" />

    실제로 가장 많이 사용하게 되는 태그 타입은 아래의 5가지입니다. Kakao와 Naver에서도 이 5개의 태그를 주로 활용합니다.

    • “og:title”
    • “og:type”
    • “og:url”
    • “og:image”
    • “og:description”

    html tag <title> 과 “og:title”은 거의 같다고 생각하시겠지만 활용에서 약간의 차이가 있으며 결정적으로 “og:title”에서는 서비스명이나 회사명이 들어가면 안됩니다. <title> 에서는 대부분 페이지내용 – 서비스명이나 회사명, 또는 “|” 기호를 넣어서 작성하는데 반해 “og:title”에는 삭제하여야 합니다. 잘 발생하지는 않으나 SNS으로부터 패널티가 있을 수 있습니다.

    일반적으로 관리 중인 페이지의 URL을 페이스북에 공유했을 때 나타나는 모양이나 내용이 생각했던 것과 다르다면 페이스북의 cache를 확인해볼 필요가 있습니다. “og:url”로 정의된 동일 URL에 대해서 기존에 만들어둔 캐시의 내용을 계속 활용하기 때문입니다. 카카오톡에서 링크 공유 시 나오는 이미지 등이 계획과 다른 경우 역시 cache 를 재설정 해야합니다.2 페이스북은 공식적으로 30일마다 한번씩 내용을 갱신하기에 최장 30일 동안 잘못된 내용이 공유될 수 있습니다.

    페이스북의 경우 페이스북에서 제공하는 공유 디버거일괄 무효화 도구를 활용하면 됩니다.3 또한 Kakao의 경우 초기화 도구4를 통해 초기화 할 수 있습니다.

    Twitter Card

    이제는 페이스북에 많이 뒤쳐진 것 같지만 그래도 한때의 왕자 트위터에도 같은 용도의 Meta Tag가 존재합니다. Twitter Card라고 부르는 이 표준은 페이스북의 Open Graph 대비 많은 옵션을 제공하고 상세하게 설정도 가능합니다만 아무래도 og tag 만큼 활성화는 되어 있지 않습니다. Twitter Developer에 상세한 내용이 설명되어 있습니다.

    기존에는 twitter card와 open graph를 둘다 사용하는 것을 당연하게 생각했습니다만 트위터에서 twitter card가 없고 og tag만 존재할 경우 유사성을 판단하여 twitter card로 활용하게되어 특별히 복잡한 항목을 가지고 있지 않는 이상 og tag만으로도 트위터에서 동일한 효과를 얻을 수 있게 되었습니다.

    아래 코드는 og tag와 twitter card가 함께 표기되어 있는 샘플 코드입니다. 트위터에서 “og:url”, “og:title”, “og:description”, “og:image”를 해석해서 twitter card로 활용합니다.

    <meta name="twitter:card" content="summary" />
    <meta name="twitter:site" content="@nytimesbits" />
    <meta name="twitter:creator" content="@nickbilton" />
    <meta property="og:url" content="http://bits.blogs.nytimes.com/2011/12/08/a-twitter-for-my-sister/" />
    <meta property="og:title" content="A Twitter for My Sister" />
    <meta property="og:description" content="In the early days, Twitter grew so quickly that it was almost impossible to add new features because engineers spent their time trying to keep the rocket ship from stalling." />
    <meta property="og:image" content="http://graphics8.nytimes.com/images/2011/12/08/technology/bits-newtwitter/bits-newtwitter-tmagArticle.jpg" />

    이렇게 트위터에서 og tag를 활용해주기에 조금은 코드가 짧아지고 개발하는 과정도 단순해질 수 있었습니다. 이전에는 페이스북과 트위터 외에 여러개가 더 있어서 관련 태그만해도 10여줄이 넘어가는 흑역사도 있었습니다. 이미 역사의 저편으로 사라진 Google+에서는 schema.org에서 정의된 마이크로데이터를 사용하는걸로 되어 있습니다.

    RIP 덕택에 그나마 개발자의 수고가 조금은 줄었습니다.

    SNS와 SEO

    og tag와 twitter card는 웹페이지가 SNS에서 공유/표현될 때 미리보기에 더욱 풍성한 정보를 포함시킬 수 있으므로 사용자 참여도를 높이는 효과를 거둘 수 있습니다. 단순히 URL만 나열되는 것보다는 더 나은 참여(클릭)을 유도하게 되겠죠. 그렇기 때문에 일부에서는 어떻게 더 많은 클릭을 유도할 수 있을까를 고민하기도 하고 별도의 SNS 전용 이미지를 삽입하여 흥미를 유발하기도 합니다. 

    검색엔진은 웹페이지의 내용만이 아니라 이 meta tag의 내용 또한 참고하여 검색엔진에 반영하기도 하며, 콘텐츠를 추천하기도 합니다. 또한 장기적으로는 더 많은 공유와 참여를 통해 SEO에 더 나은 결과를 만들기도 합니다만 꽤나 장기적인 투자가 됩니다. 하지만 구글에서는 공식적으로 얼마나 반영하고 있다고 밝히지는 않지만5 페이스북과 트위터를 통한 공유가 SEO에 반영된다고 밝혔으며, 그 링크를 통한 트래픽 또한 SEO에 영향을 준다고 이야기 하고 있습니다. 페이스북의 좋아요와 트위터에서 리트윗은 SEO에 긍정적인 영향을 끼칩니다.

  • rel=”canonical” 기준이 될 URL

    rel=”canonica”

    canonical 미국식 [-ˈnɑːn-]  영국식 [kəˈnɒnɪkl] 

    1. (성경이) 정본에 속하는; (문학 작품이) 고전으로 여겨지는
    2. 교회법에 따른
    3. (수학에서) 표준이 되는

    네이버 사전의 canonical 의 해석, 1번 또는 3번의 뜻이 된다.

    canonical 이라는 설정값은 평소에 잘 사용하지 않았던 태그로 대부분의 비전공자(?) 기획자, 디지털마케터 등은 잘 모르는 태그일 것입니다. 기본적으로 이 태그는 하나의 페이지에 여러 개의 URL이 존재할 경우 대표값을 검색엔진에 알려주는 역할을 합니다.

    A canonical link element is an HTML element that helps webmasters prevent duplicate content issues in search engine optimization by specifying the “canonical” or “preferred” version of a web page. It is described in RFC 6596, which went live in April 2012.

    canonical link element는 웹 마스터가 웹 페이지의 “표준”또는 “선호”버전을 지정하여 검색 엔진 최적화에서 중복 컨텐츠 문제를 방지하는 데 도움이되는 HTML 요소입니다. RFC 6596에 설명되어 있으며 2012 년 4 월에 시작되었습니다.

    위키피디아의 Canonical Link의 설명

    위키피디아의 설명이 조금은 정확할 것 같습니다. canonical element는 강제성을 가진 태그가 아닌 권장사항이고 실제로 2012년에 시작될 정도로 오래되지 않은 표준입니다. 그런 이유로 인해 오래전부터 웹사이트를 제작해온 분들은 잘 모르는 태그이기도 하고 국내의 꽤 많은 프로젝트에서 적용되지 않은 태그이기도 합니다. 하지만 모바일과 다국어 페이지에 대한 요구가 확대됨에 따라 최근에는 거의 대부분의 웹페이지에 적용되고 있는 태그입니다.

    <title>S.E.O. Guide - 모두의 검색엔진 최적화 가이드</title>
    <meta name="description" content="모두의 검색엔진 최적화 가이드" />
    <link rel="canonical" href="https://seoguide.kr/" />

    canonical link의 값은 특정 페이지의 기준이 되는 주소라고 생각하시면 됩니다. 상황에 따라 특정 페이지는 여러가지 주소를 가질 수 있습니다. 쉽게 이야기 하자면 구글과 네이버와 같은 검색엔진에게 중복되는 콘텐츠 페이지(같은 페이지이지만 접속 방법이나 장치에 따라 다른 주소를 가지는 페이지)에 대해 어떤 페이지가 오리지널인지 알려주는 역할을 합니다.

    예를 들어 국문/영문/일문/중문 4개의 언어를 지원하며 모바일을 위해 별도의 Sub Domain을 운영하는 웹사이트의 경우를 가정해 본다면 국/영/일/중 4개 페이지가 모바일과 데스크탑으로 각각 2개의 페이지, 총 8개의 페이지가 만들어져 있고 8개의 접속 주소를 가지고 있을 것입니다. 사용자가 검색엔진 등을 통해 접속을 한다면 검색엔진에서 제공한 링크 URL로 접근하여 기기 정보를 읽어 모바일과 데스크탑으로 분기가 되고, 해당 접속 브라우저의 기준 언어에 따라 국문/일문/중문으로 접속시키며 그 외의 언어 접속자는 모두 영문으로 이동하게 될 것입니다.

    그래 내가 왕이될.. 아니 기준이 될 URL인가?

    canonical link, 검색엔진 그리고 SEO

    이렇게 동일한 페이지가 8개의 접속주소를 가지는 경우(언어가 다르고 내용이 일부 다를 수는 있습니다만 동일한 콘텐츠로 판단할 수 있습니다.) 검색엔진은 어떤 주소를 사용자에게 전달해야 할까요? 이런 경우를 위해 만들어진 표준안이 지금 이야기 하고 있는 canonical link 입니다. 검색엔진은 사용자의 검색 언어에 따라 동일한 URL에 다른 스니펫을 보여줍니다.

    일반적으로 기준이 되는 데스크탑 페이지의 URL을 기준 URL로 지정하고 다국어 및 모바일 페이지가 존재한다면 이 페이지들은 기준 URL로 리다이렉션 처리하여야 합니다.

    또한 모바일 접근에 따른 리다이렉션 페이지는 데스크탑과 동일한 내용을 제공하여야 하며 별도의 간략화 된 모바일 서비스로 이동하는 것은 SEO에 나쁜 영향을 줍니다. 웹에서 제공하는 모든 페이지는 모바일에도 동일하게 제공하는 것이 SEO를 위해서는 꼭 필요합니다.

    또한 rel=“canonical” 요소에는 상대경로가 아닌 절대경로6를 이용하여야 합니다.

    Naver의 경우 모바일 사이트가 별도로 있는 경우 모바일 사이트의 페이지 내에 데스크탑 사이트의 URL를 명시하는 것을 권장하고 있습니다.

    역설적으로 canonical link를 기입하지 않았을 경우 제공하는 페이지의 수가 많아져서 더 나은 SEO가 될 것처럼 생각되지만 실제 검색엔진은 해당 페이지가 동일 내용임을 판단하여 패널티를 적용 SEO가 나빠지게 됩니다. 검색엔진의 목표가 사용자에게 더 나은 검색 경험을 제공하는 것이기 때문에 동일한 내용을 여러 주소로 표현하여 사용자의 선택(클릭)에 불편을 주는 것은 나쁜 것이라고 판단하기 때문입니다. 또한 canonical link의 올바른 운영을 통해 사용자의 이용이 많은 페이지임을 검색엔진에게 알리게 되어 SEO 값이 한곳으로 모이게 되어 더 나은 결과를 만들 수 있습니다.

    접속 경로가 다양한 서비스 일수록 더욱 정확한 canonical link 설계가 중요합니다. 아래는 최근 오픈한 그랜드 하얏트 제주 웹사이트의 canonical link와(ko-KR이 기준 URL로 지정되어 있군요) 각 언어에 따른 리다이렉트 URL값 입니다. 하얏트의 경우 반응형 웹으로 구성되어 모바일을 별도로 처리하지 않는군요.

    <link rel="canonical" href="https://www.hyatt.com/ko-KR/hotel/south-korea/grand-hyatt-jeju/cjugh"/>
            <link rel="alternate" href="https://www.hyatt.com/en-US/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="en"/>
            <link rel="alternate" href="https://www.hyatt.com/es-ES/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="es"/>
            <link rel="alternate" href="https://www.hyatt.com/fr-FR/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="fr"/>
            <link rel="alternate" href="https://www.hyatt.com/ja-JP/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="ja"/>
            <link rel="alternate" href="https://www.hyatt.com/ko-KR/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="ko"/>
            <link rel="alternate" href="https://www.hyatt.com/pt-PT/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="pt"/>
            <link rel="alternate" href="https://www.hyatt.com/ru-RU/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="ru"/>
            <link rel="alternate" href="https://www.hyatt.com/de-DE/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="de"/>
            <link rel="alternate" href="https://www.hyatt.com/zh-CN/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="zh-hans"/>    
            <link rel="alternate" href="https://www.hyatt.com/zh-HK/hotel/south-korea/grand-hyatt-jeju/cjugh" hreflang="zh-hant"/>    

    IE의 시대가 저물고 크롬 브라우저를 필두로 하여 파이어폭스, 마이크로소프트 엣지까지 탭 브라우징이 기본이 된 시대에 canonical link 만큼은 꼭 설계하여 반영하여야 합니다.