테크니컬 SEO

사이트가 HTML 문서 몇 장으로 이루어져 있던 시절에는 이 일에 이름이 필요 없었습니다. 검색 엔진의 수집 프로그램은 첫 화면에 들어와 링크를 따라가기만 하면 사이트에 있는 글을 전부 읽을 수 있었고, 마케터가 신경 쓸 일은 글을 잘 쓰는 것뿐이었습니다.

사이트가 커지면서 그 전제가 깨졌습니다. 화면을 브라우저에서 자바스크립트로 그려 내는 방식이 흔해지자 수집 프로그램이 받아 가는 첫 응답에는 빈 껍데기만 담기게 됐습니다. 목록 화면에 필터를 붙이면 조합마다 주소가 하나씩 생겨 글 200편짜리 사이트가 주소 2만 개로 부풀었습니다. 도움말을 로그인 뒤로 옮기거나 사이트를 새로 단장하며 주소 규칙을 통째로 바꾸는 일도 몇 달에 한 번씩 일어났습니다.

이때 나타나는 증상은 순위가 낮은 것이 아니라 검색 결과에 아예 없는 것입니다. 페이지덱도 그렇게 반년을 흘려보낸 적이 있습니다. 마케터 현우가 석 달 동안 블로그 글 스무 편을 올렸는데 검색에 걸리는 것은 네 편뿐이었습니다. 현우는 글이 부족해서라고 보고 제목과 소제목을 다시 썼고, 그래도 달라지지 않자 더 긴 글을 썼습니다. 개발자 태오가 사이트 설정을 열어 본 것은 그다음이었습니다. 블로그 목록이 아래로 내릴 때마다 다음 글을 불러오는 방식이라, 수집 프로그램은 첫 화면의 네 편 말고는 나머지 글로 가는 링크를 아예 만나지 못하고 있었습니다.

검색 엔진 최적화를 네 갈래로 나눌 때 이 갈래가 따로 서는 이유가 여기 있습니다. 노릴 말을 고르는 키워드 리서치, 그 말에 맞춰 페이지 안쪽 문구를 다듬는 온페이지 SEO, 바깥에서 평판을 쌓는 오프페이지 SEO는 모두 사람이 읽을 것을 다룹니다. 테크니컬 SEO가 다루는 것은 사람이 읽기 전에 기계가 먼저 지나가는 길입니다. 길이 막혀 있으면 앞의 세 갈래가 한 일이 통째로 검색에 도달하지 못합니다.

이 아래 묶인 일은 여섯 갈래입니다. 봇이 페이지를 찾아 읽어 가는 수집, 봇에게 길을 문서로 알려 주는 안내, 같은 내용이 여러 주소에 흩어진 것을 정리하는 중복 처리, 페이지의 뜻을 기계가 알아보게 표시하는 이해 지원, 화면이 뜨는 속도와 모바일 대응을 다루는 성능, 언어별 페이지를 짝지어 주는 다국어입니다. 나열한 순서에는 뜻이 있습니다. 앞쪽이 막히면 뒤쪽을 아무리 손봐도 결과가 나오지 않습니다. 수집되지 않는 페이지에 기계용 표시를 꼼꼼히 붙이는 것은 문이 잠긴 가게의 간판을 다시 칠하는 일과 같습니다.

수집은 검색 엔진이 우리 페이지를 손에 넣는 단계이고 셋으로 갈립니다.

1. 크롤링 — 검색 봇이 링크를 따라 페이지를 훑어 가는 과정입니다. 봇은 주소를 스스로 상상해 내지 못하고 어딘가에 걸린 링크를 통해서만 새 페이지에 닿습니다. 어느 페이지에서도 링크가 걸려 있지 않은 글은 사이트 안에 분명히 있어도 검색 엔진에게는 없는 글입니다.
2. 색인 — 훑어 간 페이지를 검색 대상 목록에 등록하는 과정입니다. 크롤링과 색인은 붙어 있는 것처럼 보이지만 별개입니다. 봇이 다녀갔는데도 내용이 얇거나 다른 페이지와 겹친다고 판단되면 목록에 오르지 않습니다. 검색 결과에 없는 페이지를 볼 때 첫 질문이 "긁어는 갔는가, 목록에 올랐는가" 인 이유입니다.
3. 크롤 예산 — 검색 봇이 한 사이트에 쓰는 수집 여력입니다. 봇은 무한정 돌지 않고 사이트마다 하루에 몇 페이지를 볼지 정해 두고 움직입니다. 주소 2만 개짜리 사이트에서 1만 9천 개가 필터 조합으로 생긴 껍데기라면, 정작 봐야 할 제품 소개 페이지 차례가 몇 주 뒤로 밀립니다.

안내는 봇에게 길을 문서로 일러 주는 갈래이고 파일 둘로 이루어집니다.

1. 사이트맵 — 사이트에 어떤 페이지가 있는지 목록으로 적어 검색 엔진에 건네는 파일입니다. 링크를 따라가다 놓칠 수 있는 페이지를 직접 일러 주는 자리이고, 새로 올린 글이 빨리 잡히게 하는 데도 씁니다.
2. robots.txt — 사이트의 어느 경로를 수집해도 되고 어디는 하지 말아야 하는지 적어 두는 파일입니다. 관리자 화면이나 사이트 내부 검색 결과처럼 목록에 오를 이유가 없는 곳을 막는 데 씁니다. 한 줄만 잘못 적어도 사이트 전체가 막히는 자리라, 검색에서 통째로 사라졌을 때 가장 먼저 열어 보는 파일이기도 합니다.

중복 처리는 같은 내용이 주소만 다르게 여러 벌 존재하는 상태를 정리하는 갈래입니다. 주소 끝에 유입 경로를 적은 꼬리표가 붙거나, 슬래시가 있는 주소와 없는 주소가 함께 살아 있거나, 옛 주소 체계가 그대로 남아 있는 것만으로도 같은 글이 네 벌이 됩니다. 검색 엔진은 그중 어느 것을 대표로 볼지 스스로 고르는데, 그 선택이 우리가 밀고 싶은 주소가 아닐 수 있습니다.

1. 캐노니컬 — 여러 주소 가운데 무엇이 대표인지 페이지 안에 적어 두는 표시입니다. 나머지 주소가 쌓은 평가를 대표 한 곳으로 모으는 장치입니다.
2. 중복 콘텐츠 — 같은 내용이 여러 주소에 존재하는 상태 자체를 가리킵니다. 벌점이 매겨지지는 않지만 평가가 갈라지고, 검색 결과에는 그중 한 벌만 나옵니다.
3. 리다이렉트 — 옛 주소로 들어온 사람과 봇을 새 주소로 자동으로 넘기는 처리입니다. 사이트를 새로 단장하며 주소 규칙을 바꿀 때 이 연결을 빠뜨리면 몇 년간 쌓은 평가가 그날로 끊깁니다.

이해 지원은 페이지에 적힌 말의 뜻을 기계가 알아보도록 따로 표시해 두는 갈래입니다.

1. 구조화 데이터 — 사람 눈에 보이는 글과 별개로, 이 숫자가 가격이고 이 글자가 글쓴이 이름이라는 것을 기계용으로 적어 두는 데이터입니다. 화면에 적힌 "4.5" 가 평점인지 버전 번호인지를 기계는 글만 읽어서는 가려내지 못합니다.
2. 스키마 마크업 — 그 표시를 어떤 어휘로 적을지 검색 엔진들이 함께 쓰기로 정해 둔 공통 규격입니다. 이 표시가 붙은 페이지는 검색 결과에 제목과 설명문만 나오지 않고 별점이나 가격, 채용 마감일 같은 것이 함께 실리기도 합니다.

성능은 페이지가 사람 앞에 얼마나 빨리 도착하는지를 다루는 갈래이고, 순위 규칙에 직접 들어간다고 공개된 몇 안 되는 기술 항목입니다.

1. 코어 웹 바이탈 — 구글이 정한 세 가지 측정값입니다. 화면에서 가장 큰 요소가 그려지기까지 걸리는 시간, 눌렀을 때 반응이 시작되기까지 걸리는 시간, 읽는 도중에 요소가 밀려 움직이는 정도를 봅니다. 개발자 도구로 재는 값이 아니라 실제 방문자의 브라우저에서 모은 값을 씁니다.
2. 모바일 친화성 — 작은 화면에서 글자가 읽히고 버튼이 눌리는지를 봅니다. 구글은 모바일 화면을 기준으로 수집하고 판정하므로, PC 화면만 보고 만든 페이지는 우리가 보는 화면과 봇이 보는 화면이 서로 다른 상태가 됩니다.

다국어는 같은 내용을 언어나 지역별로 나눠 둔 사이트에서만 쓰는 갈래입니다. hreflang은 이 페이지의 한국어판과 영어판이 각각 어디 있는지를 서로 가리키게 해 주는 표시입니다. 이 연결이 없으면 검색 엔진은 두 페이지를 그냥 비슷한 내용 두 벌로 보고 한쪽만 결과에 올리거나, 한국에서 검색한 사람에게 영어판을 보여 줍니다.

여섯 갈래를 한꺼번에 볼 일은 드뭅니다. 검색 유입에 문제가 생기면 점검은 앞에서부터 순서대로 내려갑니다. 봇이 들어올 수 있는가, 들어와서 목록에 올렸는가, 올린 것이 우리가 원하는 주소인가, 그 페이지의 뜻이 제대로 전달되는가, 사람이 열었을 때 기다리지 않고 볼 수 있는가입니다. 앞 단계가 막혀 있는데 뒤 단계를 손보면 일한 티는 나지만 숫자는 움직이지 않습니다.

"그 페이지 robots.txt 에서 막혀 있어요. 글을 더 고쳐도 소용없습니다."

수집 자체가 차단된 상태라 내용을 아무리 손봐도 검색에 닿지 않는다는 뜻입니다.

"같은 글이 주소 세 개로 잡혀 있네요. 캐노니컬부터 걸고 다시 봅시다."

평가가 세 주소로 갈라져 있으니 대표 주소를 지정해 한곳으로 모으자는 제안입니다.

"이번 리뉴얼은 리다이렉트 표 없이는 못 나갑니다."

주소 규칙이 바뀌는 배포라서, 옛 주소와 새 주소를 짝지은 목록을 만들기 전에는 내보내지 않겠다는 말입니다.

페이지덱에서 이 갈래는 현우와 태오가 같이 보는 자리이고, 둘의 역할이 나뉘어 있습니다. 검색 유입이 떨어졌다는 것을 먼저 알아채고 어느 페이지가 사라졌는지 목록을 만드는 쪽은 현우입니다. 그 원인이 사이트 설정 어디에 있는지 찾아 고치는 쪽은 태오입니다. 현우가 "지난주부터 도움말 유입이 40퍼센트 빠졌어요" 라고 말하면 태오가 그 주에 나간 배포를 거슬러 올라갑니다.

지난 분기에는 원인이 배포 한 번에 있었습니다. 새 기능을 내보내면서 테스트 서버에만 쓰던 설정 파일이 함께 올라갔고, 그 파일에는 사이트 전체를 수집하지 말라는 한 줄이 들어 있었습니다. 되돌리는 데는 5분이 걸렸지만 검색 결과가 원래대로 돌아오는 데는 3주가 걸렸습니다. 그 뒤로 페이지덱은 배포 점검 목록에 그 파일을 확인하는 항목을 넣었습니다. 이 갈래의 작업은 새로 무엇을 만드는 일보다 이렇게 깨지는 것을 막는 일이 더 많습니다.

개발자만 손댈 수 있는 일이라고 여기는 경우가 가장 많습니다. 고치는 자리가 설정 파일과 코드라서 그렇게 보입니다. 하지만 이 일에서 시간이 가장 많이 드는 부분은 고치는 것이 아니라 무엇이 잘못됐는지 찾는 것이고, 그 단서는 검색 유입 수치와 검색 결과 화면에 먼저 나타납니다. 어느 페이지가 언제부터 안 잡히는지 아는 사람은 대개 마케터입니다. 이 오해를 그대로 두면 문제를 발견할 사람은 남의 일이라 여겨 넘기고, 고칠 사람은 문제가 있는 줄도 모릅니다. 사이트가 통째로 막힌 채 몇 달이 지나는 사고는 거의 이 틈에서 납니다.

한 번 제대로 맞춰 두면 끝나는 일로 보는 오해도 흔합니다. 사이트맵을 만들고 캐노니컬을 걸고 나면 형태가 갖춰지니 완료로 보입니다. 실제로는 배포할 때마다 깨질 수 있는 설정입니다. 주소 규칙이 바뀌고, 새 목록 화면이 생기고, 실험용 설정이 운영에 섞여 들어갑니다. 점검을 배포 흐름 안에 넣어 두지 않은 팀은 유입이 절반으로 떨어진 뒤에야 알아차리고, 그 시점에는 원인이 된 배포가 몇 주 전이라 되짚는 데만 며칠이 듭니다.