RSS·사이트맵 제출 배경
서치콘솔과 서치어드바이저에 블로그를 등록하면서 RSS와 사이트맵을 모두 제출해야 한다는 것을 알게 되었습니다. 등록 절차를 따라가다 보면 두 가지를 당연한 순서처럼 제출하게 됩니다. 저도 안내대로 둘 다 제출했지만, 정작 왜 둘 다 필요한지, 둘이 정확히 어떻게 다른지는 그때 생각해보지 못했습니다.
그 뒤로 색인이 생각만큼 늘지 않으면서 이 두 파일이 실제로 무슨 일을 하는지 궁금해졌습니다. 그래서 이번에는 RSS와 사이트맵이 각각 무엇이고 어떻게 다른지 찾아본 내용과, 제 블로그에서 직접 열어보며 확인한 내용을 함께 정리했습니다.
RSS의 정의와 역할
RSS는 블로그에 새 글이 올라오면 그 목록을 담아 내보내는 피드입니다. 피드라는 말은 정보를 계속 흘려보내는 통로라고 이해하면 쉽습니다. RSS는 Really Simple Syndication의 줄임말로, 말 그대로 정말 간단한 배포 방식이라는 뜻입니다. 이 피드를 구독하면 블로그에 직접 들어가지 않아도 새 글이 올라왔는지 확인할 수 있습니다.
검색엔진도 이 피드를 읽어서 새 글이 생겼는지 알아챌 수 있습니다. 블로그 전체를 처음부터 다시 훑어보지 않아도 새로 추가된 글만 확인할 수 있으니 효율적인 방식입니다. 그런데 처음에 제가 잘못 알고 있던 부분이 있었습니다. 피드에 새 글이 올라가면 검색엔진이 곧바로 그 글을 크롤링하고 색인까지 해줄 거라고 생각했습니다. 실제로는 그렇지 않았습니다. 피드는 새 글이 있다는 사실을 알려줄 뿐이고, 언제 크롤링할지, 색인을 할지는 검색엔진이 따로 판단합니다. 제 블로그스팟도 새 글을 발행하면 피드에는 바로 올라갔지만, 서치콘솔에서는 '발견됨 - 현재 색인이 생성되지 않음' 상태로 오래 남아 있는 글이 많았습니다.
블로그스팟 피드를 직접 열어보다가 눈에 띈 부분도 있었습니다. 피드 코드 안에 hub라는 이름과 함께 pubsubhubbub.appspot.com이라는 주소가 적혀 있었습니다. 찾아보니 WebSub라는 방식에 쓰이는 주소였습니다. 피드를 받아보는 쪽이 계속 들어와서 확인하지 않아도 새 글이 생겼다는 알림을 받을 수 있게 해주는 장치입니다. 블로그스팟은 이 설정이 기본으로 되어 있어서 제가 따로 할 일은 없었습니다.
RSS는 원래 뉴스 사이트에서 새 기사를 독자에게 빠르게 전달하는 용도로 널리 쓰였습니다. 여러 사이트의 새 글을 한곳에 모아 보는 피드 리더 서비스와 함께 발전해온 기술이기도 합니다. 지금은 피드 리더를 쓰는 사람이 예전보다 줄었지만, 검색엔진이 새 글을 알아채는 데에는 여전히 이 기술이 쓰이고 있다는 점이 흥미로웠습니다.
사이트맵의 정의와 역할
사이트맵은 블로그에 있는 전체 페이지의 목록을 정리한 파일입니다. 새 글만 담는 것이 아니라 블로그를 개설했을 때부터 지금까지 쌓인 글과 페이지의 주소를 모두 담습니다. 검색엔진은 사이트맵으로 블로그 전체 구조를 파악하고, 아직 발견하지 못한 페이지가 있으면 찾아낼 수 있습니다. 특히 다른 글에서 링크가 거의 걸려 있지 않아 검색엔진이 스스로 찾기 어려운 페이지에 도움이 됩니다.
제 블로그 주소 뒤에 sitemap.xml을 붙여서 열어보니 글 주소가 목록으로 죽 나열되어 있었습니다. 소개나 개인정보처리방침처럼 블로그스팟의 '페이지' 기능으로 만든 문서는 sitemap-pages.xml이라는 파일에 따로 들어 있었습니다. RSS를 열었을 때와는 생김새가 확연히 달라서, 두 파일의 목적이 다르다는 것을 눈으로도 확인할 수 있었습니다.
구글 도움말을 찾아보며 알게 된 점도 있습니다. 사이트맵은 구글에 주는 일종의 힌트입니다. 사이트맵을 제출했다고 해서 그 안의 모든 주소가 크롤링되거나 색인된다는 보장은 없습니다. 저도 사이트맵을 제출했지만 색인되지 않은 글이 여전히 많은 걸 보면, 사이트맵은 글이 있다는 것을 알려주는 역할까지라는 것을 알 수 있었습니다.
RSS·사이트맵의 범위 및 갱신 방식 비교
두 파일의 차이를 정리하면서 가장 먼저 눈에 들어온 것은 다루는 범위였습니다. RSS는 보통 최근에 발행된 글 몇십 개 정도로 범위가 정해져 있습니다. 티스토리 초기 설정 글에서 RSS 공개 개수를 50개로 설정했던 것도 피드에 담기는 글의 수를 정하는 일이었습니다.
사이트맵은 글이 몇 개든 전체를 담는 것을 목표로 합니다. 글이 백 개를 넘어도 사이트맵에는 전체 목록이 들어갑니다. 사이트맵 파일 하나에는 주소 5만 개까지 담을 수 있고, 그보다 크면 여러 파일로 나누어 관리합니다. 이제 막 시작한 제 블로그 규모에서는 아직 신경 쓸 일이 없는 이야기였습니다.
담는 정보도 달랐습니다. RSS에는 글 제목, 요약이나 본문, 발행일처럼 사람이 읽어도 내용을 알 수 있는 정보가 들어 있습니다. 사이트맵에는 페이지 주소와 마지막으로 수정한 날짜 정도만 들어 있습니다. 사이트맵은 사람보다 검색엔진이 읽기 위한 파일이라 직접 열어보면 딱딱하게 느껴졌습니다. 마지막 수정 날짜는 글을 고치면 함께 바뀝니다. 지금처럼 예전 글을 수정하고 있을 때 검색엔진이 어떤 글이 바뀌었는지 알 수 있는 단서가 됩니다.
두 번째로 눈에 들어온 것은 갱신 방식이었습니다. 블로그스팟과 티스토리는 RSS와 사이트맵을 모두 자동으로 갱신해줍니다. 새 글을 쓰면 피드에도 사이트맵에도 바로 반영됩니다. 차이는 검색엔진이 언제 다시 읽어가느냐에 있습니다. RSS는 새 글 소식을 빠르게 전하는 쪽에 가깝고, 사이트맵은 검색엔진이 자기 일정에 맞춰 다시 확인하는 쪽에 가깝습니다.
처음에는 블로그스팟 색인 개수가 2주마다 업데이트되던 경험도 이런 사이트맵 확인 주기와 관련이 있지 않을까 생각했습니다. 찾아보니 그 2주는 서치콘솔 보고서 화면이 갱신되는 간격이었고, 사이트맵을 읽어가는 주기와는 다른 이야기였습니다. 숫자가 바뀌는 시점과 구글이 실제로 블로그에 다녀가는 시점은 따로 봐야 했습니다.
RSS·사이트맵 제출 목적 비교
제출하는 목적도 조금 달랐습니다. RSS를 제출하는 것은 새 글이 생길 때마다 검색엔진이 빨리 알아챌 수 있게 하려는 것입니다. 사이트맵을 제출하는 것은 검색엔진이 블로그 전체를 빠짐없이 파악하도록 안내하려는 것입니다. 구글 검색 센터에서도 사이트맵은 사이트 전체 주소를, 피드는 최근 변경 사항을 알려주는 것이니 둘을 함께 쓰라고 권하고 있었습니다. RSS만 제출하면 최신 글 위주로 전달되고, 사이트맵만 제출하면 새 글 소식이 상대적으로 늦게 전달될 수 있다는 것이 함께 제출하는 이유였습니다.
구글 서치콘솔에서는 사이트맵 메뉴 하나에 사이트맵 주소와 RSS 주소를 모두 넣을 수 있습니다. 네이버 서치어드바이저는 사이트맵 제출과 RSS 제출 메뉴가 따로 나뉘어 있습니다. 티스토리와 블로그스팟 네이버 서치어드바이저 등록 비교 글에서 겪었던 것처럼, 제출하는 주소 형식에서 차이가 났습니다. 티스토리는 블로그 주소 뒤에 /rss만 붙이면 됩니다. 블로그스팟은 주소 뒤에 /feeds/posts/default?alt=rss처럼 더 긴 경로를 붙여야 했습니다. 이 형식을 모르면 블로그스팟 RSS 주소를 찾느라 한참 헤매게 됩니다. 사이트맵은 두 플랫폼 모두 주소 뒤에 sitemap.xml을 붙이는 같은 방식이라 어렵지 않았습니다.
사이트맵은 robots.txt와도 연결되어 있었습니다. robots.txt를 정리한 글에서 제 블로그의 robots.txt를 열어봤을 때, 맨 아래에 Sitemap이라는 줄과 함께 사이트맵 주소가 적혀 있었습니다. 따로 제출하지 않아도 검색엔진이 robots.txt를 읽다가 사이트맵 위치를 알 수 있게 해둔 것입니다.
RSS와 사이트맵을 정리하며
정리하고 나니 RSS와 사이트맵을 왜 둘 다 제출하는지 이해가 되었습니다. 지금까지는 절차의 일부로만 여기고 별생각 없이 제출했습니다. 이제는 둘이 검색엔진에 서로 다른 정보를 전달한다는 것을 알게 되어, 새 블로그를 등록할 때도 왜 이렇게 하는지 스스로 설명할 수 있을 것 같습니다.
함께 알게 된 것은 두 파일 모두 글이 있다는 것을 알려주는 역할까지만 한다는 점입니다. 색인이 될지는 결국 글 자체를 보고 판단합니다. 그래서 RSS와 사이트맵은 한 번 제대로 제출해두고, 그다음부터는 글을 다듬는 데 시간을 쓰는 것이 맞다는 생각이 들었습니다. 절차를 그대로 따라 하는 것과 그 절차가 왜 필요한지 알고 따라 하는 것은 다르다는 것을 이번에도 느꼈습니다.
