기술 블로그 방문자 늘리기 | 주제 클러스터·내부 링크·검색 친화 글쓰기
이 글의 핵심
메타 description과 og:image부터 손봤지만 실제로 유입이 달라진 건 같은 주제로 다음 글을 써서 이어 붙였을 때였다는 경험에서 출발합니다. 한 편이 잘 돼도 옆에 연결된 글이 없으면 검색엔진과 독자 모두에게 신호가 약하다는 전제 아래, 시리즈와 내부 링크를 설계하는 방식을 설명합니다.
검색 유입을 늘려 보려고 제가 가장 먼저 손댄 것은 메타 description과 og:image였습니다. 검색 결과 스니펫이 애매해 보이면 당연히 거기부터 만지게 됩니다. 그런데 몇 달 동안 이것저것 해 보고 나서 돌아보니, 순위와 유입에 체감할 만한 변화를 만든 것은 메타 손질이 아니라 같은 주제로 다음 글을 써서 이어 붙인 것이었습니다. 메타 정보는 당연히 정확해야 하고 틀리면 손해지만, “메타를 예쁘게 다듬었는가”보다 “이 주제로 읽을 거리가 쌓여 있는가”가 먼저라는 쪽으로 생각이 바뀌었습니다. 크롤링, Core Web Vitals, 구조화 데이터 같은 기술 SEO는 기술 SEO 가이드에 따로 정리해 두었으므로, 이 글에서는 “블로그 글을 어떻게 묶고 연결할 것인가”만 다룹니다.
주제 클러스터: 글을 한 편씩이 아니라 묶음으로 설계하기
이 글의 전제는 단순합니다. 한 편이 잘 되더라도 옆에 이어지는 글이 없으면, 독자도 검색 엔진도 “이 사이트가 이 주제를 깊이 다루는가”라는 신호를 약하게 받습니다. 그래서 저는 클러스터 단위로 글을 계획합니다. 핵심 주제를 하나 정하고(예: 코딩 테스트, 기술 면접, 특정 기술 스택), 그 주변에 난이도와 관점이 다른 글을 몇 편 배치한 뒤, 본문 안에서 서로 링크를 겁니다.
흔히 “허브와 스포크”라고 부르는 구조입니다. 허브 글은 주제 전체를 개관하고 각 세부 글로 안내하는 역할을 하고, 스포크 글은 하나의 좁은 질문(예: “투 포인터는 언제 쓰는가”, “동적 계획법 점화식을 세우는 순서”)에 깊게 답합니다. 스포크 글은 허브로 돌아가는 링크를, 허브는 모든 스포크로 가는 링크를 갖습니다. 이렇게 하면 검색 엔진은 링크 구조만으로 “이 글들이 한 주제에 속하고, 이 글이 중심”이라는 것을 파악할 수 있고, 독자는 검색으로 들어온 스포크 글에서 자연스럽게 다음 글로 넘어갑니다.
여기서 중요한 것은 태그로만 모아 둔 가짜 묶음과 구분하는 것입니다. 같은 태그를 붙이면 태그 목록 페이지에 글이 모이긴 하지만, 글 본문에서는 서로를 전혀 언급하지 않습니다. 반면 “앞에서 말한 경계 처리는 이 글에서 자세히 다룹니다”처럼 읽는 흐름 안에서 이어지는 링크는 독자가 실제로 클릭하고, 검색 엔진도 본문 속 링크를 태그 목록보다 강한 관계 신호로 봅니다.
클러스터를 만들 때 가장 흔히 저지르는 실수는 같은 질문에 답하는 글을 여러 편 쓰는 것입니다. “React 상태 관리 정리”, “React 상태 관리 가이드”, “React 상태 관리 완벽 정리”처럼 제목만 조금씩 다른 글이 여러 개 있으면, 검색 엔진은 어느 쪽을 보여 줄지 헷갈려하고 결국 모든 글이 서로의 순위를 깎아 먹습니다(키워드 카니발리제이션). 면접과 알고리즘처럼 키워드가 겹치는 주제라면 제목 키워드를 복사하기보다 문제를 어떤 각도에서 쪼갤지로 차별화하는 편이 낫습니다. 예를 들어 기술 면접 가이드는 “면접에서 어떻게 설명할 것인가”를, 코딩 테스트 가이드는 “시간 안에 어떻게 풀 것인가”를 다루도록 역할을 나누는 식입니다. 이미 비슷한 글이 여러 편 있다면 가장 좋은 한 편으로 내용을 합치고 나머지는 301 리다이렉트로 넘기는 것이 대개 효과적입니다.
내부 링크: 어디에, 몇 개, 어떤 문구로
내부 링크는 “몇 개가 정답”이라고 정해 두기보다 글의 흐름에서 필요한 지점을 기준으로 넣습니다. 제가 쓰는 기준은 세 곳입니다. 도입부에서 이 글을 이해하는 데 선행 지식이 필요하면 그 글로, 개념 설명 직후에 더 깊이 들어가는 심화 글로, 마무리에서 “다음에 읽을 글” 두세 개로 연결합니다. 이 정도면 독자 입장에서 링크가 너무 많다는 느낌이 들지 않고, 각 링크가 왜 거기 있는지가 분명합니다.
링크 문구(앵커 텍스트)는 “여기”, “이 글”, “클릭” 대신 링크된 글의 주제가 드러나는 짧은 구절로 씁니다. “캐시 무효화 전략은 Redis 캐싱 글에서 다룹니다”처럼 쓰면, 독자는 클릭하기 전에 무엇을 얻을지 알 수 있고 검색 엔진은 링크된 페이지가 무엇에 관한 것인지 문구로 파악합니다. 스크린 리더 사용자는 페이지의 링크 목록만 따로 모아 듣는 경우가 많은데, 그때 “여기”가 열 개 나열되면 아무 정보도 얻을 수 없습니다. SEO와 접근성이 같은 방향을 가리키는 대표적인 예입니다. 다만 모든 앵커를 똑같은 검색 키워드로 맞추는 것은 부자연스러워 보일 수 있으므로, 문맥에 맞게 표현을 바꿔 가며 쓰는 편이 좋습니다.
운영하면서 놓치기 쉬운 것은 링크의 유지보수입니다. 글의 slug를 바꾸거나 글을 합치고 삭제하면, 그 글을 가리키던 다른 글들의 링크가 깨집니다. 관련 글 위젯이나 사이드바 같은 자동 링크는 알아서 따라가지만, 본문에 직접 쓴 링크는 그대로 남기 때문입니다. 저는 빌드할 때 본문의 내부 링크가 실제로 존재하는 페이지를 가리키는지 확인하는 스크립트를 돌리는데, 글이 수백 편을 넘어가면 이런 자동 점검 없이는 깨진 링크를 찾기 어렵습니다. URL을 바꿔야 한다면 301 리다이렉트를 함께 설정해 두어야 외부에서 들어오는 링크와 검색 엔진에 쌓인 신호를 잃지 않습니다.
리다이렉트를 걸었다고 본문 링크를 그대로 두는 것도 좋지 않습니다. 리다이렉트를 거치는 링크는 사용자에게는 한 번의 왕복이 더 생기고, 검색 엔진에게는 “이 사이트는 스스로 옛 주소를 가리키고 있다”는 약한 혼선을 줍니다. 글을 합치고 나면 옛 slug를 가리키는 본문 링크를 새 slug로 일괄 치환하고, 리다이렉트는 외부 링크를 위한 안전망으로만 남겨 두는 편이 깔끔합니다. 합친 뒤 또 합치는 일이 반복되면 A→B→C 같은 리다이렉트 체인이 생기므로, 새 규칙을 추가할 때 기존 규칙의 목적지도 함께 갱신해야 합니다.
반대로 어디에서도 링크되지 않는 글(고아 페이지)도 점검 대상입니다. 사이트맵에는 들어 있어도 본문 링크가 하나도 없는 글은, 검색 엔진 입장에서 사이트 스스로 중요하지 않다고 말하는 것과 비슷합니다. 새 글을 발행할 때 새 글에서 기존 글로 나가는 링크만 넣고 끝내기 쉬운데, 실제로 효과가 있는 것은 기존 글에서 새 글로 들어오는 링크를 한두 개 추가하는 쪽입니다. 이미 색인되어 있고 신뢰가 쌓인 페이지에서 오는 링크여야 크롤러가 새 글을 빨리 발견합니다.
링크를 넣지 말아야 할 곳도 있습니다. 주제와 상관없는 인기 글로 억지로 링크를 거는 것, 모든 글 하단에 같은 목록을 수십 개씩 붙이는 것, 같은 페이지로 가는 링크를 한 글 안에 여러 번 거는 것은 독자에게 소음일 뿐 아니라 링크 하나하나의 의미를 흐립니다. 내부 링크에 rel="nofollow"를 붙이는 것도 효과가 없습니다. 크롤링을 막고 싶은 페이지라면 링크를 빼거나 해당 페이지에 noindex를 거는 것이 맞습니다.
제목·요약·첫 문장
요약(메타 description)이 비어 있으면 불안하지만, 실제로 스니펫 품질을 좌우하는 것은 첫 문장인 경우가 많습니다. 구글은 메타 description을 그대로 쓰지 않고 검색어에 맞는 본문 문장을 스니펫으로 골라 보여 주는 일이 흔하기 때문입니다. 그래서 첫 문단에 “누구를 위한 글인지”와 “읽고 나면 무엇을 할 수 있게 되는지”를 담는 것만으로도 스니펫이 상당히 좋아집니다.
제목은 검색하는 사람이 실제로 입력할 법한 표현을 담되, 모든 글에 “완벽 가이드”, “총정리” 같은 같은 꼬리표를 붙이는 것은 피하는 편이 좋습니다. 사이트 전체의 제목이 같은 틀로 찍혀 나오면 독자가 글을 구분하기 어렵고, 구글의 유용한 콘텐츠 평가 관점에서도 대량 생산된 템플릿 글처럼 보일 수 있습니다. 목차는 긴 글에서 H2/H3로 훑어볼 수 있게만 정리하면 충분합니다. 발행 전에 복잡한 체크리스트를 채우기보다는 “이 글을 한 문장으로 요약할 수 있는가”, “이미 쓴 글 두어 편으로 자연스럽게 링크가 나가는가”, “이어서 쓸 후속 주제가 떠오르는가” 정도만 물어봐도 충분합니다. 세 번째 질문에 답이 없다면 그 글은 클러스터 밖에 떨어진 섬일 가능성이 높습니다.
같은 글을 한국어와 영어로 함께 운영한다면 두 버전은 서로의 “중복”이 아니라 번역 관계라는 것을 명시해야 합니다. 각 페이지의 <head>에 hreflang="ko"와 hreflang="en" 대체 링크를 서로 걸어 두면 구글은 두 URL을 한 글의 언어별 버전으로 묶어, 검색어 언어에 맞는 쪽을 보여 줍니다. 이때 한국어 글의 본문 링크는 한국어 글로, 영문 글의 본문 링크는 영문 글로 가도록 맞추는 것도 중요합니다. 영문 페이지에서 한국어 글로 링크가 새면 독자는 읽을 수 없는 페이지에 도착하고, 클러스터 구조도 언어별로 끊깁니다. 저도 slug를 두 언어에서 똑같이 쓰다 보니 영문 글의 관련 글 목록이 한국어 글로 잘못 연결된 적이 있어서, 지금은 빌드 단계에서 언어가 섞인 링크를 따로 점검합니다. 프롬프트나 LLM처럼 빠르게 늘어나는 주제라면 프롬프트 엔지니어링 글처럼 기존 글과 다루는 문제 정의가 겹치지 않도록 먼저 선을 그어 두는 것이 클러스터를 깔끔하게 유지하는 방법입니다.
서치 콘솔로 손볼 글 고르기
구글 서치 콘솔은 숫자 자체에 빠지기 쉬운데, 저는 “실적” 보고서에서 페이지별·검색어별로 다음 두 가지 패턴만 찾습니다.
노출은 많은데 클릭률(CTR)이 낮은 글은 검색 결과에서 사람들의 눈에는 띄지만 선택받지 못하는 경우입니다. 제목이나 첫 인상(스니펫)이 검색 의도와 어긋나 있을 가능성이 높으므로 제목과 첫 문단을 먼저 손봅니다. 이때 그 페이지로 들어오는 검색어 목록을 함께 보면, 내가 생각한 주제와 사람들이 실제로 찾는 표현이 어떻게 다른지 드러나는 경우가 많습니다.
클릭은 나오는데 평균 순위가 뒤쪽(대략 2페이지 이후)인 글은 주제는 맞지만 경쟁 글보다 부족하다고 평가받는 경우입니다. 본문이 짧거나, 비슷한 내용의 URL이 여러 개로 쪼개져 있거나, 내부 링크로 이어진 “이 주제의 허브”가 약할 때 흔히 보입니다. 이런 경우에도 메타 문구 몇 자를 고치는 것보다 관련 글 한두 편을 보강하거나 합쳐서 이야기를 완성하는 쪽이 효과가 있었습니다.
어떤 조치든 효과가 나타나기까지는 몇 주에서 몇 달이 걸리고, 그 사이 검색 알고리즘 업데이트나 계절 요인도 섞입니다. 그래서 한 달에 한 번 정도 상위 검색어 수십 개와 주요 페이지의 노출·클릭·순위를 스냅샷으로 남겨 두는 것을 권합니다. 나중에 “그때 무엇을 바꿨더니 이렇게 됐더라”를 맞춰 볼 수 있는 유일한 근거가 이 기록입니다. 서치 콘솔의 “페이지 색인 생성” 보고서도 가끔 확인해서, 새로 쓴 글이 “크롤링됨 - 현재 색인이 생성되지 않음” 상태로 오래 머물러 있지 않은지 보는 것이 좋습니다. 이 상태가 많다면 개별 글보다 사이트 전체의 품질이나 중복 문제를 의심해 봐야 합니다.
솔직하게 말하면, 내부 링크는 이미 쓸 만한 글이 있을 때 그 가치를 퍼뜨리는 도구이지 얇은 글을 좋은 글로 바꿔 주지는 않습니다. 코드만 나열하고 설명이 거의 없는 글, 비슷한 틀에 주제만 바꿔 찍어 낸 글이 사이트의 상당 부분을 차지하면, 구글은 사이트 전체를 낮게 평가하고 새 글도 잘 색인하지 않습니다. 이때 링크 구조를 아무리 다듬어도 숫자는 거의 움직이지 않습니다. 그런 경우에는 링크 작업을 잠시 멈추고, 방문자가 많은 주제부터 글 자체를 보강하거나 겹치는 글을 합치는 작업을 먼저 하는 것이 순서입니다. 또 이런 보강 작업의 효과는 서치 콘솔에 몇 주 늦게 반영되므로, 며칠 만에 결과를 판단하고 방향을 다시 바꾸는 것은 피하는 편이 좋습니다.