증상: 검색어 6개에서 28일 동안 노출 1회, 순위는 52위
앵커 텍스트를 점검하기 전까지 저희는 홈페이지 제작 검색에서 보이지 않는 이유를 엉뚱한 곳에서 찾고 있었습니다. 홈페이지 제작을 맡길 곳을 찾는 사람이 구글에 한국어로 칠 만한 검색어 6개를 골라 두고 지켜봤는데, 6개를 합친 월 검색량이 5,850회인 자리에서 28일 동안 저희 사이트가 검색 결과에 나온 횟수는 1회였습니다. 그 한 번의 순위도 52위였습니다.
52위는 검색 결과 다섯째 페이지 근처입니다. 사람이 거기까지 넘겨 볼 일은 거의 없으니 사실상 노출 0과 같은 상태였습니다. 이 6개 검색어는 '홈페이지 제작을 의뢰하려는 사람'이 치는 말이라 저희 매출과 가장 가까운 자리였고, 그래서 더 답답했습니다.
이 글은 그 원인을 두 번 잘못 짚었다가 바로잡은 기록입니다. 첫 번째 가설은 데이터 한 줄로 기각했고, 두 번째 가설인 “내부링크가 없다”는 절반만 맞았습니다. 링크는 있었습니다. 다만 69편의 글이 전부 같은 앵커 문구를 달고 있었습니다.
처음 의심한 것: 글이 모자라거나, 내부링크가 없다
검색에서 안 보이면 가장 먼저 떠오르는 처방은 글을 더 쓰는 일입니다. 검색어마다 그 말을 제목에 단 글이나 랜딩 페이지를 하나씩 만들면 구글이 그 페이지를 보여 주지 않겠느냐는 생각이었습니다. “홈페이지 제작 업체”, “홈페이지 제작 비용”, “홈페이지 리뉴얼”처럼 꼬리가 조금씩 다른 말마다 페이지를 쪼개는 방식입니다.
두 번째로 의심한 곳은 사이트 안의 연결이었습니다. 검색 유입용 글은 많은데 정작 돈이 되는 서비스 페이지로 힘을 모아 주는 링크가 없으니, 서비스 페이지가 사이트 안에서도 존재감이 없다는 진단이었습니다. 이 진단은 그럴듯했고 실제로 작업 목록에 “내부링크가 없다”라는 문장으로 올라갔습니다.
두 가설 모두 확인 없이 세운 가설이었습니다. 글이 정말 모자란지, 링크가 정말 없는지 아무도 세어 보지 않은 상태였습니다. 그래서 고치기 전에 셋을 직접 세기로 했습니다. 이미 있는 글의 수, 서비스 페이지에 실제로 적힌 낱말, 그리고 글에 달린 링크와 그 앵커 문구입니다.
무엇으로 확인했나? 글 개수, 페이지 문구, 링크 앵커를 하나씩 셌다
관측 수단은 세 가지였습니다. 첫째는 구글 검색 노출 집계입니다. 6개 검색어 각각에 대해 최근 28일 동안 몇 번 보였고 몇 위였는지를 봤고, 앞에서 말한 노출 1회와 52위가 여기서 나왔습니다. 이 숫자가 기준선이고, 나중에 고친 결과도 같은 자로 잽니다.
둘째는 서비스 페이지 원문 대조입니다. 홈페이지 제작 서비스 페이지의 title, h1, 자주 묻는 질문(FAQ) 영역을 열어 검색어에 들어가는 낱말이 실제로 몇 번 나오는지 셌습니다. 검색엔진은 페이지가 스스로 무엇이라고 부르는지를 먼저 읽기 때문에, 여기에 검색어의 낱말이 없으면 아무리 좋은 글이 가리켜도 그 검색어의 후보로 올라가기 어렵습니다.
셋째는 링크 전수 조사입니다. 검색 유입용 글을 한 편씩 열어 서비스 페이지로 가는 링크가 몇 개인지, 그 링크에 걸린 문구가 무엇인지 적었습니다. “없다”는 진단을 확인하려면 하나라도 있는지부터 봐야 했습니다. 마지막으로 남의 사례를 하나 봤습니다. 비슷한 검색어에서 구글이 AI 요약(AI Overview)을 만들 때 어떤 형태의 페이지를 인용하는지입니다.
알리바이 ①: 글이 정말 모자랐나?
첫 가설은 숫자 하나로 무너졌습니다. 홈페이지 제작을 다룬 글은 이미 공개된 글이 39편, 써 두고 올리지 않은 초안이 43편이었습니다. 같은 주제를 다룬 글이 이미 넘치도록 있었습니다. 글이 모자라서 안 보이는 상황이 아니었습니다.
검색어마다 페이지를 쪼개는 안도 같은 자리에서 내려놓았습니다. 꼬리가 조금씩 다른 동의어마다 거의 같은 내용의 랜딩을 하나씩 세우는 방식은 구글이 doorway 페이지(검색어만 바꿔 찍어 낸 진입용 페이지)로 보고 제재하는 유형입니다. 저희도 이전에 같은 방향을 검토했다가 이 이유로 이미 접은 적이 있었습니다.
그래서 결정은 오히려 반대로 갔습니다. 새로 쓰는 글은 0편입니다. 홈페이지 제작 서비스 페이지 1장을 착지면으로 그대로 두고, 그 한 장이 검색어를 받아 낼 수 있게 만드는 쪽으로 방향을 바꿨습니다. 페이지를 늘리지 않고 이름표만 붙이는 작업입니다.
알리바이 ②: 내부링크는 정말 없었나?
두 번째 가설은 직접 세어 보니 절반이 틀렸습니다. 링크가 없지 않았습니다. 글마다 서비스 페이지로 가는 링크가 4개씩 있었습니다. “내부링크가 없다”라는 진단을 그대로 믿고 링크를 더 달았다면 이미 4개인 링크를 5개, 6개로 늘리는 헛수고를 했을 겁니다.
문제는 링크의 개수가 아니라 링크에 걸린 문구였습니다. 한 편에 달린 링크 4개의 앵커가 4개 모두 “홈페이지 제작 보기”였고, 이 모양이 69편에서 똑같았습니다. 글이 무슨 이야기를 하든 서비스 페이지를 가리키는 말은 늘 같은 한 줄이었습니다.
같은 앵커가 69편에서 반복되면 그 링크는 문맥 속 링크라기보다 메뉴나 바닥글 같은 템플릿 링크에 가깝습니다. 사람이 글을 읽다가 '이 이야기를 더 보려면 여기'라고 다는 링크가 아니라, 틀에 박혀 모든 페이지에 똑같이 찍히는 링크로 읽힌다는 뜻입니다. 그런 링크는 목적지 페이지가 무엇에 관한 페이지인지 검색엔진에게 거의 알려 주지 못합니다.
관련 글 목록을 정리할 때도 비슷한 일을 겪은 적이 있습니다. 링크를 많이 달기와 링크로 뜻을 전하기가 별개라는 이야기는 내부 링크 SEO, 관련 글 목록 101개를 6개로 줄인 이유에 따로 정리해 두었습니다.
진짜 원인: 링크도 페이지도 검색어의 낱말을 달고 있지 않았다
세 관측을 겹치니 원인이 한 줄로 모였습니다. 글은 충분했고 링크도 있었지만, 그 어디에도 사람이 실제로 검색창에 치는 낱말이 붙어 있지 않았습니다. 69편의 링크는 같은 문구로 서비스 페이지를 가리켰고, 서비스 페이지는 스스로를 검색어의 낱말로 부르지 않았습니다.
서비스 페이지 원문을 대조한 결과가 이를 보여 줬습니다. title, h1, FAQ 어디에도 “업체”, “비용”, “리뉴얼”, “중소기업”, “AI홈페이지” 다섯 낱말이 나오지 않았습니다. 5종 모두 0건이었습니다. 의뢰하려는 사람이 치는 검색어는 대개 이 낱말과 함께 들어오는데, 정작 받아야 할 페이지는 그 낱말을 한 번도 쓰지 않고 있었습니다.
같은 문제가 블로그 운영 대행 페이지에서도 나왔습니다. 페이지에는 “블로그 관리 대행”이라는 표현이 있었는데, 사람들이 붙여서 치는 “블로그대행”(월 검색량 900회)과는 어절이 벌어져 있었습니다. 단어 사이에 “관리”가 끼고 띄어쓰기가 갈라져 있으니, 검색어와 페이지가 같은 말을 하지 않은 셈입니다.
링크는 편당 4개 있었다. 4개 모두 같은 문구였고, 69편이 같은 모양이었다. 없는 것은 링크가 아니라 이름표였다.
고친 방법: 페이지를 늘리지 않고 이름표만 붙였다
고친 곳은 세 군데입니다. 첫째, 홈페이지 제작 서비스 페이지의 title, h1, FAQ에 0건이던 다섯 낱말(업체·비용·리뉴얼·중소기업·AI홈페이지)을 문장 안에 자연스럽게 넣었습니다. 블로그 운영 대행 페이지는 표현을 좁혀 “블로그대행” 검색어를 정면으로 받게 했습니다. 새 페이지는 한 장도 만들지 않았습니다.
둘째, 서비스 페이지에 유형×비용×기간을 한 번에 보여 주는 구간표 4행을 넣고, 같은 내용을 구조화 데이터(JSON-LD의 AggregateOffer, 가격 범위를 기계가 읽을 수 있게 적는 형식)로 함께 실었습니다. 이 형태를 고른 근거도 관측입니다. “AI 챗봇 구축 비용” 검색에서 구글 AI 요약이 TreeSoop이라는 회사의 같은 형태 표를 4회 인용해 답변을 조립하는 장면을 확인했습니다. 답변엔진은 구간이 정리된 표를 통째로 집어 간다는 신호였습니다.
가격은 손대지 않았습니다. 기존 금액 범위를 구간으로 다시 늘어놓았을 뿐 숫자는 하나도 바꾸지 않았습니다. 금액을 바꾸는 일은 검색 노출 문제가 아니라 사업 결정이라 이번 수정 범위 밖에 두었습니다.
셋째가 앵커입니다. 69편의 앵커를 한 편씩 손으로 고치는 방식은 쓰지 않았습니다. 그렇게 하면 다음에 쓰는 새 글은 또 “홈페이지 제작 보기”를 달고 나옵니다. 대신 글 주소(slug)를 넣으면 그 글의 주제에 맞는 앵커 문구를 돌려주는 함수 하나를 두고, 모든 글이 이 함수에서 앵커를 받아 가게 했습니다. 글별로 따로 편집한 곳은 0곳입니다.
같은 실수를 막는 장치: 앵커는 글 주소에서 만들고, 판정 날짜를 먼저 정한다
첫 번째 장치는 위의 함수 자체입니다. 앵커 문구가 글 본문 69곳에 흩어져 있으면 누군가 한 곳을 복사해 새 글을 쓰는 순간 같은 문구가 다시 퍼집니다. 문구를 정하는 곳을 한 군데로 모아 두면, 새 글이 생겨도 그 글의 주소에서 앵커가 자동으로 나옵니다. 같은 앵커가 수십 편에 반복되는 상태가 구조적으로 생기기 어렵습니다.
두 번째 장치는 판정 날짜와 합격선을 고치기 전에 먼저 적어 둔 일입니다. 판정일은 2026년 9월 28일, 합격선은 6개 검색어 중 4개에서 노출되고 평균 순위가 20위 이내인 상태입니다. 고친 뒤에 결과를 보고 기준을 정하면 어떤 결과든 성공처럼 읽히기 때문에 순서를 바꿨습니다.
불합격일 때 할 일도 같이 적었습니다. 페이지 형식과 검색어 조준을 다 맞추고도 노출이 안 나오면, 남는 원인은 도메인 자체의 신뢰도뿐입니다. 그건 저희 사이트 안에서 글을 고쳐서 풀 문제가 아니므로, 그때는 이 방향을 접고 다른 경로를 찾기로 했습니다. 판정 결과는 이 글의 근거 기록 범위 밖이라 여기 적지 않습니다.
왜 고친 내용이 바로 반영되지 않았나?
수정을 머지한 뒤에도 한동안 실제 사이트에는 바뀐 내용이 보이지 않았습니다. 이 사이트는 Vercel에 GitHub를 연결해 머지하면 자동으로 배포하는 구조인데, 머지 시각부터 GitHub 쪽 배포 확인 작업이 `queued` 상태로 멈춰 있었습니다. 같은 코드로 명령줄에서 만든 미리보기 배포는 정상적으로 Ready까지 갔으니, 코드가 아니라 배포를 일으키는 연결 쪽 문제였습니다.
결국 수정분은 9월 2일 다음 머지에서 생긴 자동 배포로 라이브에 올라갔습니다. 서비스 페이지 title에 업체·중소기업·리뉴얼·비용이 들어가고 AggregateOffer가 1건 잡히는 모습을 라이브에서 확인했습니다. 머지했다는 사실만으로 끝났다고 적었다면, 그 사이 검색엔진은 고치기 전 페이지를 계속 읽고 있었을 겁니다.
같은 날 다른 배포 4건은 Vercel이 402 오류로 거부했습니다. Hobby 계정의 하루 배포 생성 한도 100회를 넘었기 때문입니다. 한도를 태운 쪽은 저희였습니다. 24시간 동안 사이트 코드와 무관한 문서만 바꾼 푸시가 한 저장소에서만 37회였고, 푸시마다 배포가 하나씩 만들어졌습니다. 진단을 바로잡는 일과 별개로, 고친 내용이 실제로 나갔는지 라이브에서 확인하는 단계가 따로 필요하다는 점을 다시 확인했습니다.
이 진단에서 무엇을 남겼나?
- “없다”는 진단은 하나라도 있는지부터 센다. 이번에는 편당 4개가 있었다
- 링크는 개수보다 문구를 본다. 같은 앵커가 69편에 반복되면 템플릿 링크로 읽힌다
- 착지면이 검색어의 낱말을 쓰는지 title·h1·FAQ에서 직접 센다. 이번에는 5종 모두 0건이었다
- 글이 많은데 안 보이면 글을 더 쓰기 전에 이름표부터 본다. 공개 39편과 초안 43편이 이미 있었다
- 판정 날짜와 합격선은 고치기 전에 적는다
- 머지가 아니라 라이브 화면에서 반영을 확인한다
돌아보면 “내부링크가 없다”는 진단은 틀린 관찰이라기보다 세어 보지 않은 관찰이었습니다. 링크가 하는 일을 '연결'로만 보면 4개면 충분해 보이고, 링크가 '이 페이지가 무엇인지 알려 주는 이름표'라는 점까지 보면 69편의 같은 문구가 문제로 드러납니다. 사이트 검색 노출이 글 수에 비해 안 나오는 상황이라면 앵커 텍스트와 착지면의 낱말부터 세어 보시길 권합니다. 비슷한 문제를 겪고 있다면 상담에서 이야기를 나눌 수 있습니다.