구글 검색 너란 녀석...
구글은 어떻게 방대한 웹페이지에서 검색어에 맞는 결과를 빠르게 골라낼까요? 검색할 때마다 모든 사이트를 방문하는 것은 아닙니다. 미리 발견하고 분석한 정보가 담긴 색인(index)에서 후보를 찾습니다.
이 과정을 크롤링, 색인 생성, 검색 결과 제공으로 나누면 “내 글이 검색에 안 나온다”는 문제도 조금 더 정확하게 볼 수 있어요.
2022년에 쓴 검색 원리 입문 글을 보완했습니다. PageRank의 기본 아이디어와 현재 공개된 검색 가이드를 구분하며, 공개되지 않은 순위 가중치를 추정하지 않습니다.
1. 크롤링: 페이지를 발견하고 가져온다
웹에는 모든 페이지가 등록된 단일 주소록이 없습니다. Googlebot은 이미 아는 페이지의 링크나 사이트맵 등으로 새로운 URL을 발견하고, 방문할 페이지를 정해 콘텐츠를 가져옵니다. 발견한 URL을 모두 즉시 방문하는 것은 아닙니다.
서버 오류나 로그인 요구, robots.txt 제한 때문에 내용을 가져오지 못할 수도 있습니다. JavaScript로 본문을 만드는 페이지는 렌더링과 리소스 접근도 영향을 줍니다. Google은 크롤링 과정에서 페이지를 렌더링해 내용을 확인한다고 설명합니다. Google 검색의 세 단계에 이 흐름이 정리돼 있습니다.
크롤링과 스크래핑도 구분할 수 있습니다. 크롤링은 페이지를 탐색하고 수집하는 과정, 스크래핑은 가져온 내용에서 원하는 데이터를 추출하는 작업입니다. 한 프로그램이 둘 다 할 수 있고, 규모가 작다고 크롤러가 아닌 것은 아니에요.
2. 색인 생성: 내용을 이해하고 대표 페이지를 정한다
페이지를 수집했다고 곧바로 검색에 나오는 것은 아닙니다. 검색엔진은 본문과 제목, 이미지 등의 내용을 분석하고, 비슷하거나 중복된 페이지 중 어떤 URL을 대표로 삼을지 판단합니다.
예를 들어 같은 글이 /posts/cache/, 추적 파라미터가 붙은 URL, 다른 카테고리 경로에서 각각 보인다면 사용자는 세 페이지를 열 수 있어도 검색엔진은 하나를 대표로 선택할 수 있습니다. 크롤링됨, 색인에 저장됨, 특정 검색어에서 상위에 나옴은 서로 다른 상태입니다.
canonical은 선호하는 대표 URL을 알리는 신호입니다. 강제 명령으로 생각하면 안 됩니다. 내부 링크와 사이트맵도 같은 대표 URL을 가리키게 정리하면 의도를 전달하기 쉬워집니다. Google의 canonical 선택 가이드를 참고할 수 있습니다.
3. 검색 결과 제공: 질문에 맞는 순서를 정한다
사용자가 검색하면 색인에 있는 후보 중 검색 의도에 맞는 결과를 고릅니다. 같은 “자전거 수리”라도 사용자의 위치에 따라 유용한 결과가 다를 수 있죠. 모든 페이지에 하나의 절대 점수가 있고 그 순서대로만 보여주는 구조로 이해하면 부족합니다.
PageRank는 무엇을 바꿨을까?
래리 페이지와 세르게이 브린의 초기 검색 연구는 웹의 링크 구조를 페이지의 중요도를 판단하는 데 활용했습니다. PageRank의 출발점은 링크를 받는 수뿐 아니라 어떤 페이지가 링크했는지도 보자는 것입니다.
중요한 페이지가 여러 곳으로 링크한다면 그 기여는 나가는 링크에 나뉘고, 링크를 받은 페이지의 중요도는 다시 다른 페이지에 영향을 줍니다. 즉 전체 링크 구조를 반복적으로 계산하는 아이디어예요. 팔로워 수나 유명 블로거의 추천 횟수와 같은 개념은 아닙니다. Google의 초기 검색엔진 논문에서 배경을 읽을 수 있습니다.
현재의 검색을 이 알고리즘 하나로 설명할 수는 없습니다. Google은 PageRank가 발전한 형태로 계속 사용되며, 관련성·신선도 등 여러 시스템을 함께 사용한다고 공개합니다. 신선도도 모든 글에 같은 방식으로 적용되는 것은 아닙니다. 오늘의 환율과 TCP 원리를 찾는 질문은 최신 정보의 중요도가 다르겠죠. 검색 순위 시스템 가이드는 공개된 범위를 확인하는 자료입니다.
SEO: 검색엔진과 독자가 글을 이해하도록 돕기
SEO는 검색엔진 최적화입니다. 제목에 키워드를 많이 넣는 요령보다, 읽을 만한 내용을 만들고 발견·해석을 방해하는 문제를 줄이는 작업으로 보는 편이 좋겠습니다.
개발 블로그라면 먼저 다음을 살펴보겠습니다.
| 확인 대상 | 구체적인 개선 |
|---|---|
| 제목과 도입 | 어떤 문제를 어떤 범위에서 해결하는 글인지 명시 |
| 본문 | 조건·버전·실패 사례와 실행 가능한 예시 제공 |
| 링크 | 관련 글로 이동할 수 있는 실제 링크와 의미 있는 텍스트 사용 |
| 중복 URL | 대표 URL을 정하고 내부 링크·사이트맵과 일치시킴 |
| 이미지 | 이미지에만 있는 핵심 코드·결론을 본문 텍스트로도 제공 |
| 모바일 경험 | 글과 코드가 잘리지 않고 핵심 내용을 읽을 수 있는지 확인 |
이런 개선은 독자에게 직접적인 가치가 있지만 특정 순위를 보장하지는 않습니다. 페이지 성능도 마찬가지입니다. Lighthouse는 문제를 진단하는 도구이지, 그 점수 자체가 검색 순위표는 아닙니다. Google의 페이지 경험 안내는 좋은 사용자 경험을 종합적으로 보라고 설명합니다.
Lighthouse 점수보다 어떤 병목을 찾아 고쳤는지 살펴봅니다.
내 글이 검색되지 않으면 어디부터 볼까?
검색 결과에서 못 찾았다는 관찰만으로 알고리즘이 글을 나쁘게 평가했다고 결론 내리기는 이릅니다. 단계별로 가능한 원인을 좁혀보겠습니다.
- URL에 접근 가능한가? 공개 URL의 응답 코드, 로그인 요구, 반복 리디렉션부터 확인합니다.
- Google이 발견·수집했는가? Search Console의 URL 검사에서 크롤링 상태와 접근 문제를 봅니다. 사이트맵 제출은 발견을 돕지만 수집을 보장하지 않습니다.
- 색인에 들어갈 수 있는가? 의도하지 않은
noindex, 다른 URL로 선택된 canonical, 렌더링된 본문을 확인합니다. - 색인에는 있는데 노출이 적은가? 검색어와 글의 실제 내용이 맞는지, 노출·클릭 데이터가 충분히 쌓였는지 살펴봅니다.
특히 robots.txt로 막으면 검색에서 완전히 사라진다고 오해하기 쉽습니다. Google은 방문하지 못한 URL도 외부 링크 등을 통해 알고 검색에 표시할 수 있습니다. 색인을 막는 noindex를 읽게 하려면 해당 페이지에 접근할 수 있어야 하고, 비공개 정보는 인증으로 보호해야 합니다. robots.txt의 용도와 한계에 분명히 구분돼 있습니다.
글을 발행한 뒤 순위가 올랐다고 방금 바꾼 제목만의 효과라고 단정할 수도 없습니다. 재크롤링 시점, 검색 수요, 경쟁 페이지도 함께 변하니까요. 발견 문제인지, 색인 문제인지, 내용과 검색 의도의 문제인지 구분하는 것만으로도 SEO 작업의 방향이 훨씬 선명해집니다.