사이트맵 제출 다음에 할 일: 크롤링·색인·순위를 가르는 단계별 점검

구글과 네이버에 서브도메인 열세 개를 등록하고 사이트맵까지 낸 뒤 Bing 등록을 시작하고 나니, 할 일이 끝났다는 기분이 들었습니다. 콘솔마다 「성공」이 떴고 발견된 페이지 수도 나왔습니다. 그런데 네이버 수집요청 가이드에 이런 문장이 있었습니다.

수집성공이 되더라도 네이버의 검색결과에 노출된다는 보장은 없습니다.

사이트맵 제출은 검색에 뜨는 일의 앞부분일 뿐이었습니다. 무엇이 앞부분이고 무엇이 뒷부분인지 정리해 두려고 이 글을 씁니다. 저 스스로 몇 주 뒤에 다시 열어 볼 체크리스트이기도 합니다.

검색이 거치는 세 단계

구글은 검색이 작동하는 방식을 세 단계로 나눕니다.

Google Search works in three stages, and not all pages make it through each stage: Crawling, Indexing, Serving search results.

크롤링은 로봇이 페이지를 가져가는 일이고, 색인은 가져간 페이지를 검색에 쓸 수 있게 저장하는 일이고, 게재는 검색어에 맞춰 순서를 매겨 보여 주는 일입니다. 핵심은 뒷부분입니다. 모든 페이지가 모든 단계를 통과하지는 않습니다. 같은 문서에 「가이드라인을 지켜도 크롤링·색인·게재를 보장하지 않는다」는 문장도 있습니다.

사이트맵이 닿는 곳은 첫 단계

구글이 새 주소를 알게 되는 길은 셋입니다. 이미 방문한 페이지, 아는 페이지에서 뻗은 링크, 그리고 제출된 사이트맵입니다. 사이트맵은 이 중 하나일 뿐이고, 하는 일은 「이런 주소가 있다」고 알리는 것까지입니다. 사이트맵 개요 문서는 더 분명하게 적습니다.

it doesn't guarantee that all the items in your sitemap will be crawled and indexed

같은 문서가 사이트맵이 특히 필요한 경우로 드는 것이 「사이트가 새로 생겼고 밖에서 들어오는 링크가 적을 때」입니다. 서브도메인 대부분이 여기에 해당합니다. 그래서 사이트맵을 내는 일 자체는 의미가 있었습니다. 다만 거기서 멈추면 첫 단계에서 멈춘 셈입니다.

단계	하는 일	오늘 상태
크롤링	로봇이 주소를 알고 가져가게 하기	사이트맵·robots.txt·콘솔 등록 완료
색인	가져간 페이지가 버려지지 않게 하기	큰 원인들을 고침, 결과 확인 대기
게재·순위	검색어에 맞춰 위에 뜨게 하기	앞으로 할 일
유지	새 페이지가 같은 구멍을 다시 파지 않게 하기	장치 없음

첫 단계에서 고친 것: 비어 있던 사이트맵과 robots.txt

등록하기 전에 서브도메인마다 robots.txt 와 sitemap.xml 을 한 번씩 받아 봤습니다. 열세 곳 중 네 곳은 사이트맵이 없거나 첫 화면 한 줄뿐이었습니다. 한 곳은 robots.txt 가 404 였는데, 네이버 가이드에 따르면 4xx 는 「모두 허용」으로 읽습니다. 막아 둔 줄 알았던 경로가 로봇에게는 열려 있었다는 뜻입니다.

사이트맵이 빈 원인 하나는 설정에 있었습니다. 사이트맵이 공개 주소를 환경변수에서 읽는데, 그 변수는 배포할 때가 아니라 서버가 뜰 때 들어왔습니다. 빌드 때 만들어진 사이트맵에는 주소가 없었습니다. 공개 주소를 코드의 상수로 옮기고 나서야 사이트맵이 채워졌습니다.

두 번째 단계에서 고친 것: 홈을 가리키던 canonical과 얇은 페이지

색인 단계에서 걸릴 만한 것은 이번 점검에서 더 많이 나왔습니다. 가장 컸던 것은 canonical 이었습니다. 한 서브도메인의 루트 레이아웃에 canonical: "/" 가 있었고, Next.js 에서 레이아웃 메타데이터는 하위 페이지로 상속됩니다. 하위 페이지 스무 개가 전부 「나는 홈의 사본」이라고 말하고 있었습니다. 운영 페이지를 열어 보고서야 알았습니다. canonical 은 페이지마다 자기 주소를 적도록 바꿨습니다.

두 번째는 얇은 페이지였습니다. 데모 앱 두 곳의 모듈 화면 189장이 사이트맵에 올라가 있었는데, 서버가 내주는 HTML 을 열어 보니 페이지마다 다른 글은 제목 한 줄뿐이었습니다. 나머지는 189장이 똑같은 사이드바 메뉴였습니다. 화면은 브라우저에서 그려지기 때문입니다. 모듈 화면 맨 아래에 서버에서 그리는 소개 단을 붙였습니다. 이 화면이 무엇을 하는지와 같은 묶음의 다른 화면으로 가는 링크를 담았습니다.

나머지는 작은 것들이었습니다. 제목만 다르고 본문이 같은 공유용 주소 78장은 noindex 로 돌리고 사이트맵에서 뺐습니다. 한 사이트맵에는 noindex 를 건 페이지 셋이 섞여 있었습니다. 호스팅 플랫폼이 붙여 주는 기본 주소 하나가 noindex 없이 같은 내용을 두 번째 주소로 내고 있었습니다.

이것들이 실제로 색인을 바꿨는지는 아직 모릅니다. 구글이 페이지를 다시 가져가고 판단하는 데 시간이 걸리기 때문입니다.

세 번째 단계는 코드 밖의 일이 더 많음

게재와 순위는 코드로 할 수 있는 몫이 작습니다. 제가 할 수 있다고 보는 것은 둘입니다.

하나는 내용을 두껍게 하는 일입니다. 모듈 소개 단은 지금 카탈로그의 한 줄 설명을 씨앗으로 씁니다. 모듈마다 「무엇을 해결하나, 어떤 업종에 맞나」를 두세 문장만 더해도 수백 장이 같이 두꺼워집니다. 다른 하나는 링크입니다. 본진의 개념 글과 데모 화면이 서로 가리키면, 로봇이 주소를 찾는 두 번째 길인 링크가 생깁니다.

밖에서 들어오는 링크는 코드로 만들 수 없습니다. 포트폴리오, 고객사, 커뮤니티에서 우리 페이지를 가리키는 일은 좋은 페이지가 먼저 있어야 생깁니다. 이 부분은 계획이라고 부르기도 어렵습니다.

같은 구멍을 다시 파지 않을 장치

이번에 고친 구멍 대부분은 새 앱을 만들 때 기본값이 비어 있어서 생겼습니다. 사이트맵이 빈 것도, canonical 이 상속된 것도, 기본 주소를 막지 않은 것도 앱마다 따로 생긴 사고가 아니라 같은 출발점의 문제였습니다.

그래서 두 가지를 하려고 합니다. 새 앱을 찍어 내는 스타터 템플릿에 사이트맵·robots.txt·공개 주소 상수·구조화 데이터를 기본으로 넣는 것, 그리고 이번에 손으로 돌린 운영 점검을 매주 자동으로 돌려 어긋나면 알림이 오게 하는 것입니다. 둘 다 아직 만들지 않았습니다.

2~4주 뒤 다시 열 화면

제가 다시 볼 것을 콘솔별로 적어 둡니다.

Google Search Console 「페이지 색인 생성」. 색인이 생성되지 않은 이유 목록에서 이 넷의 숫자를 봅니다.

• 「크롤링됨 - 현재 색인이 생성되지 않음」: 가져갔지만 색인하지 않은 페이지. 얇은 페이지가 여기 모입니다
• 「발견됨 - 현재 색인이 생성되지 않음」: 주소는 알지만 아직 가져가지 않은 페이지
• 「사용자가 선택한 표준이 없는 중복 페이지」와 「중복 페이지, Google에서 사용자와 다른 표준 URL을 선택함」: canonical 문제가 여기 나타납니다
• 「URL이 'NOINDEX'로 표시됨」: 사이트맵에 올렸는데 noindex 인 페이지

페이지 색인 생성 보고서 도움말에 사유마다 설명이 있습니다. 「크롤링됨 - 현재 색인이 생성되지 않음」은 「이후에 색인이 생성될 수도 있고 생성되지 않을 수도 있습니다」라고 적혀 있어서, 숫자가 줄어드는 추세를 봐야 합니다.

Google Search Console 「실적」. 어떤 검색어로 들어오는지 봅니다. 다음 글과 다음에 두껍게 할 모듈 소개가 여기서 정해집니다.

네이버 서치어드바이저 「리포트」. 서브도메인마다 따로 등록했으니 사이트마다 수집 현황을 봅니다. 네이버 서치어드바이저 등록 과정에 적은 대로, 네이버는 수집 요청 반영에만 「최소 1일에서 몇 주」가 걸린다고 적었습니다.

몇 주 뒤 이 숫자들이 움직였는지 보고, 움직였다면 무엇이 움직였는지를 이 글에 덧붙이겠습니다.