Rev. 2.73

개발자들이 정의한 각종 데이터를 최종 결과물인 HTML 문서를 통해서 출력하지만 이를 다시 데이터형으로 돌리기에는 많은 어려움이 있기 때문에 HTML 문서에서 데이터를 구분해 낼 수 있는 방법으로 마이크로데이터이나 마이크로포맷 또는 RDFa를 이용할 수 있습니다. RDFa는 XHTML에나 잘 어울릴 법한 모양새이고 사용법이 다소 까다롭다는 점에서 개인적으로는 마이크로포맷이나 마이크로데이터를 선호합니다. 마이크로포맷은 별도의 네임스페이스 선언을 필요로하지 않고 class와 rel 속성만을 이용하여 구조화된 데이터를 표현할 수 있지만, 단계가 있거나 관계가 있는 데이터를 구조화하기에는 부족한 면이 있습니다. 마이크로데이터는 RDFa와 마이크로포맷의 중간쯤으로 볼 수 있습니다. 자세한 사용 방법은 구글이 문서(microdata, microformats, RDFa)를 잘 만들어 뒀습니다.

이 얘기는 수년 전부터 거론되었지만 웹사이트 소유주에게 돌아가는 이렇다 할 가치가 없었기 때문에 지들끼리 말만 많았던 HTML5 스팩이죠. 최근 구글은 이 구조화된 데이터를 이용하여 저자나 인물을 표시하거나 제품이나 장소 등의 평점 및 리뷰, 앨범의 트랙 정보 이벤트 등을 검색결과에 노출하고 있으며, 이것을 리치 스니펫이라 부르고 있습니다. 구글은 리치 스니펫을 제공하는 방법으로는 마이크로데이터를 권장하고 있으며 이는 데이터가 어떤 종류인지를 정의하는 스키마를 필요로합니다. 대표적으로 data-vocabulary.org또는 schema.org에서 제공하는 데이터 스키마를 선언하는데 이를 잘 이용하면 관계형 데이터 구조화가 가능해 집니다.

구글은 웹마스터 도구를 통해 구조화된 데이터 테스팅 도구를 제공합니다. 다음은 schema.org의 데이터 스키마를 기반으로 이 블로그의 데이터를 구조화하고 테스팅 도구를 통해 얻은 결과입니다. 제법 쓸만한 데이터가 만들어 지더라고요. 조금 더 발전하면 ATOM이나 RSS를 별도로 제공하는게 무의미해질지도 모르겠네요.

Item

  • type: http://schema.org/blog
  • property:
    • url: Firejune
    • name: Firejune
    • description: The Web is still changing.
    • version: 2.19
    • blogpost: Item 1
    • author: Item 2

Item 1

Item 3

  • type: http://schema.org/comment
  • property:
    • datecreated: 2012-12-20T08:55:50+09:00
    • image: http://a0.twimg.com/profile_images/2399594250/8dp14wildkk8xbt8ownl_normal.png
    • url: beyonditblog
    • name: beyonditblog
    • text: Node.JS용 Scribd 모듈 배포: 역시나, 기업 요구사항은 파일 교환 보다는 문서 관리쪽으로 많이 치우쳐져 있더군요. 그래서 문서관련 기능을 강화하기...

Item 4

  • type: http://schema.org/comment
  • property:
    • datecreated: 2012-12-20T09:24:06+09:00
    • image: http://a0.twimg.com/profile_images/1123405595/IT_NEWS_normal.jpg
    • url: All_IT_News
    • name: All_IT_News
    • text: text: [경준호] Node.JS용 Scribd 모듈 배포: 역시나, 기업 요구사항은 파일 교환 보다는 문서 관리쪽으로 많이 치우쳐져 있더군요. 그래서 문서관련 기능을...

Item 5

  • type: http://schema.org/comment
  • property:
    • datecreated: 2012-12-22T00:50:28+09:00
    • image: http://a0.twimg.com/profile_images/2514809179/stcr8k585g4tkcch9pgw_normal.jpeg
    • url: nanhapark
    • name: nanhapark
    • text: Node.JS용 Scribd 모듈 배포 http://t.co/qpzDlro0 #nodeqa

Item 6

  • type: http://schema.org/comment
  • property:
    • datecreated: 2012-12-22T01:20:16+09:00
    • image: http://a0.twimg.com/profile_images/1032276925/imazine_normal.jpg
    • url: iMaZiNe80
    • name: iMaZiNe80
    • text: RT @nanhapark: Node.JS용 Scribd 모듈 배포 http://t.co/qpzDlro0 #nodeqa

Item 2

  • type: http://schema.org/person
  • property:
    • image: https://firejune.com/attach/image/272778.jpeg
    • name: Joon Kyoung
    • jobtitle: web front-end development
    • worksfor: Spark & Associates Corp
    • url: @firejune
    • url: Blog
    • url: More information

Comments

구글봇의 크롤 정보가 갱신되는 시간인 오후 한 시가 되면 어김없이 구글 웹마스터 도구에 들어갑니다. 최근 블로그를 리뉴얼 하면서 주소형식이 변경되는 일이 있었습니다. 그래서 이전의 주소로 접근했을 때 올바른 주소로 301 리디렉션하도록 했어요. 그런데 만드는 과정에서의 실수로 잘못된 주소가 대량 방출되었다는 사실을 뒤늦게 알았습니다. 한 달 만에, 무려 60만 건에 달하는 크롤 오류가 감지되었더군요.

404.png

웹마스터 도구에서 보고한 오류 정보를 토대로 수정 작업을 완료하고 Googlebot에게 이제 다시 크롤해도 좋다고 알려줄 수 있습니다. 그런데 이는 오류 종류(500, 404, 401, 410 등)별로 하루 최대 1,000개이므로 60만 건을 모두 처리하려면 600일이 소요됩니다.(물론, 놔두면 구글봇이 알아서 처리한다고 합니다.) 그런데, 이게 은근 중독성인 게, 마치 롤플레잉 게임에서 몹을 때려잡는 듯한 감칠맛까지 나더라고요.

구글이 개밥 주듯이 조금씩 내주는 정보에 만족할 수 없어서 사이트 전체의 깨진 링크를 검사해 주는 도구인 Integrity(맥용)를 이용해서 내부적으로 잘못된 주소가 생성되는지 확인했습니다. 공짜치고는 꽤 쓸만한 도구였어요. 전체 5만 여건의 내부링크가 검색되었는데 그중에서 잘못된 링크를 모두 찾아 고치고 수개월째 경과를 지켜보고 있습니다.

구글봇이 가져간 크롤오류가 바로잡히는 데에는 생각보다 오랜 시간이 걸렸습니다. 약 3개월에 걸쳐 조금씩 줄어들어 지금은 22만여 건으로 많이 줄어든 상태에요. 기존에 서비스되고 있는 라우트를 건드릴 때에는 정말 조심스럽게 작업에 임해야겠습니다.

Comments