프로그래매틱 SEO로 770페이지를 쌓았는데 왜 파는 서비스 글은 0편이었나?
프로그래매틱 SEO를 주력 서비스 쪽으로 돌리려던 계획은 접었습니다. 주력 서비스 검색어 72종을 하나씩 뜯어보니 서로 겹치지 않게 만들 수 있는 페이지가 모두 6개였고, 그 6개는 이미 사이트에 있었습니다. 대신 검색어를 두 갈래로 나눠 질문형 검색어만 새 글로 발행하기로 했고, 그 결과 발행 검사를 통과하는 주제 묶음이 4개에서 14개로 늘었습니다.
우리 사이트에는 콘텐츠 묶음이 두 개 있었습니다. 기업 데이터베이스를 템플릿에 부어 만든 /insights 770페이지, 그리고 사람이 주제를 골라 쓰는 /reports 리포트 47편입니다. 리포트 발행은 7월 19일 이후 멈춰 있었습니다.
문제는 주제였습니다. 두 묶음 모두 세일즈 인텔리전스·세무·노무를 다뤘고, 정작 매출을 내야 할 주력 서비스 다섯 가지(AI 업무 자동화, 홈페이지 제작, AI 챗봇, 아웃바운드 영업 대행, 블로그 운영 대행)를 다룬 글은 0편이었습니다. 검색으로 들어온 사람이 우리가 파는 서비스를 만날 길이 없었습니다.
리포트 발행을 다시 시작하려면 두 가지를 먼저 정해야 했습니다. 하나는 모든 서비스에 고루 쓸지, 매출을 노리는 서비스에 모을지였습니다. 다른 하나는 이미 770페이지를 찍어 낸 프로그래매틱 SEO 설비를 주력 서비스 쪽으로 돌리면 한 번에 풀리지 않겠냐는 질문이었습니다.
처음 잰 숫자: 817편을 쓰고도 100위 안에 든 검색어 0종
분산 발행의 결과는 이미 숫자로 나와 있었습니다. 세 방향으로 흩어 쓴 콘텐츠가 817편이었는데, 주력 서비스 검색어 72개를 네이버에서 조회하면 우리 페이지가 100위 안에 든 검색어는 0종이었습니다. 같은 목록을 2주 연속 조회했고 두 번 모두 0종이었습니다.
측정 방법은 단순합니다. 주력 서비스 검색어 72개를 고정 목록으로 정해 두고, 네이버 검색 결과에서 우리 페이지의 순위를 확인합니다. 편수가 아니라 검색어 기준으로 세는 이유는, 편수가 아무리 많아도 사람이 실제로 치는 말에서 보이지 않으면 유입이 생기지 않기 때문입니다.
순위를 잡은 글이 전혀 없지는 않았습니다. 상업 의도가 강한 짧은 검색어(머리 키워드)는 75~99위에 머물렀습니다. 반면 질문형 롱테일 검색어는 11위까지 올라와 있었습니다. 「ai 콘텐츠 최적화 도구 비용이 어느 정도야?」, 「llm mvp」 같은 검색어입니다.
이 두 숫자의 차이는 뒤에서 다시 씁니다. 여기서 먼저 정리한 결론은 하나입니다. 817편으로 0종이었다면 같은 방식으로 편수만 늘려서는 결과가 달라지기 어렵습니다. 모든 서비스에 고루 쓰는 안은 이 단계에서 탈락했습니다.
세운 가설: 있는 프로그래매틱 SEO 설비를 주력 서비스로 돌리면 된다
프로그래매틱 SEO는 데이터 한 벌과 페이지 템플릿 하나로 수백 페이지를 찍어 내는 방식입니다. /insights 770페이지도 이렇게 나왔습니다. 기업 21,961곳이 든 데이터베이스가 있었고, 템플릿이 그 데이터를 페이지로 바꿨습니다.
그래서 가설은 자연스러웠습니다. 설비는 이미 돌아가니 데이터만 주력 서비스 쪽으로 바꾸면 된다는 생각입니다. 주력 서비스 검색어마다 페이지를 하나씩 만들면 검색어 72종이 페이지 72개가 되고, 페이지마다 한 검색어를 정면으로 노릴 수 있다는 계산이었습니다.
더 좁힌 변형도 후보에 있었습니다. 구매 의도가 강해 보이는 검색어 6개를 골라, 그 검색어 전용 페이지를 만드는 안입니다. 수는 적어도 사려는 사람이 치는 말이니 전환에 가깝다는 논리였습니다.
두 안 모두 새 설비가 필요 없고 바로 착수할 수 있다는 점에서 매력이 컸습니다. 그래서 착수 전에 검색어 목록부터 다시 열어 보기로 했습니다.
가설은 어디서 틀렸나 — 검색어 72종이 허락하는 페이지는 6개
72개 검색어를 하나씩 분류해 보니 대부분이 「{주제어}×{행동어}」 꼴이었습니다. 주제어 하나에 행동을 뜻하는 말만 바꿔 붙인 조합이라, 검색하는 사람이 원하는 답은 사실상 같았습니다. 72종은 72개의 질문이 아니라 몇 개 질문의 동의어 묶음이었습니다.
원하는 답이 같으면 페이지도 하나여야 합니다. 같은 답을 단어만 바꿔 여러 페이지에 나누면 우리 페이지끼리 같은 검색어를 두고 부딪히고, 검색 엔진은 그 묶음을 검색어 하나만 노린 얇은 페이지로 봅니다. 우리 페이지끼리 부딪히는 문제를 진단할 때 빠지기 쉬운 함정은 SEO 카니발리제이션 오진단 기록에 따로 적었습니다.
그렇게 묶고 나면 정당하게 만들 수 있는 페이지는 판매 서비스 하나에 1개, 모두 6개였습니다. 그리고 그 6개는 이미 /ai/ 경로 아래 서비스 소개 페이지로 사이트에 있었습니다. 새로 찍어 낼 페이지가 남아 있지 않았습니다.
좁힌 변형도 산수가 맞지 않았습니다. 후보 검색어 6개는 각각 월 20회였고 합쳐도 월 120회였습니다. 전용 페이지 6개를 모두 1위에 올린다 해도 들어올 방문자의 상한이 그 정도입니다.
구매 의도 검색어로 페이지를 대량 생성하는 안은 사실 2026년 7월 26일에 한 번 기각한 적이 있었습니다. 네 가지 관점에서 일부러 반대 논리를 세워 교차 검증했고, 결론은 기각이었습니다. 이번에 검색어를 다시 세면서 같은 결론에 다른 경로로 도착한 셈입니다.
진짜 원인: 프로그래매틱 SEO는 설비가 아니라 데이터로 돈다
770페이지가 가능했던 이유는 설비가 아니라 데이터였습니다. 기업 21,961곳은 곳마다 서로 다른 정보를 갖고 있어서, 템플릿이 같아도 페이지마다 내용이 달랐습니다. 프로그래매틱 SEO의 재료는 템플릿에 부을 서로 다른 사실의 모음, 곧 데이터 유니버스입니다.
주력 서비스 쪽에는 그런 데이터가 없었습니다. 있는 재료는 검색어 72종인데, 그 검색어들은 서로 다른 사실이 아니라 같은 질문의 다른 표현입니다. 재료가 없으면 템플릿은 같은 내용을 제목만 바꿔 찍어 낼 뿐입니다.
검색어마다 페이지를 만드는 방식은 구글과 네이버가 모두 도어웨이 페이지(검색어를 받아 다른 곳으로 넘기려고 만든 얇은 페이지)로 규정하고 제재합니다. 2026년 3월 코어 업데이트가 바로 이 유형을 때렸습니다. 방향을 바꾼 프로그래매틱 SEO는 실익이 없는 데다 제재 위험까지 떠안는 구조였습니다.
그러니 질문 자체가 잘못 서 있었습니다. 문제는 프로그래매틱 SEO를 어느 방향으로 돌리냐가 아니었습니다. 주력 서비스 쪽에는 돌릴 프로그래매틱 SEO가 처음부터 없었습니다.
질문형 검색어는 구조가 다릅니다. 질문은 묻는 사람의 조건이 저마다 달라서 동의어끼리 겹치는 일이 구조적으로 드뭅니다. 매일 한 편씩 발행해도 같은 답을 여러 페이지에 나누는 모양이 나오지 않습니다. 앞에서 본 11위와 75~99위의 차이가 이 설명과 맞아떨어졌습니다.
조치: 검색어를 두 갈래로 나누고, 한 갈래만 발행한다
주력 서비스에 콘텐츠를 모은다는 방향은 그대로 두고, 수단만 바꿨습니다. 검색어를 성격에 따라 두 갈래로 나눴습니다.
- 상업 의도 갈래 — 「{주제어}×{행동어}」 동의어 묶음입니다. 새 페이지는 0건입니다. 기존 서비스 페이지 6개가 본문과 FAQ에서 이 표현들을 흡수합니다.
- 질문 갈래 — 실제로 관측한 질문형 검색어만 모읍니다. 이 갈래만 /reports에 새 리포트로 발행합니다.
발행할 주제는 판매 서비스 목록 파일과 대조해 고릅니다. 이번에 만든 build_offer_topic_backlog.py 스크립트가 후보 주제마다 연결된 판매 서비스를 찾고, 그 서비스가 목록에서 판매 중(active) 상태일 때만 통과시킵니다. 매칭이 불확실하면 통과가 아니라 탈락으로 처리하는 fail-closed 방식입니다.
검사를 켜자마자 걸리는 문제가 하나 나왔습니다. 가장 중요한 주력 서비스인 AI 업무 자동화가 목록에서 판매 중 상태가 아니었습니다. 실제 서비스 설계 문서에 적힌 가격 범위를 근거로 채워 판매 중으로 등록했고, 그러자 검사를 통과하는 주제 묶음이 4개에서 14개로 늘었습니다.
분류 규칙에 걸리지 않는 글의 기본 분류도 바꿨습니다. 전에는 매칭되지 않은 새 글이 세일즈 인텔리전스 섹션으로 떨어졌는데, 그 섹션은 판매를 접은 서비스였습니다. 기본값을 AI 전환 섹션으로 바꿔 새 글이 폐기한 서비스 쪽으로 흘러가는 길을 막았습니다.
발행 절차도 손봤습니다. 사이트 배포에 사람 승인을 받는 규칙이 있어서, 첫 편을 승인받아 배포하자마자 두 번째 편에서 같은 대기가 다시 생겼습니다. 매일 발행이 목표라면 편당 승인은 그 자체로 병목입니다. 그래서 글 데이터 파일(reports.json)에 글을 더하는 일 외에 코드·설정·라우트·의존성 변경이 0건인 커밋은 승인 없이 배포하도록 규칙을 나눴습니다.
근거는 두 위험의 크기가 다르다는 점입니다. 글을 하나 더한 배포는 잘못돼도 그 항목을 빼고 다시 배포하면 끝나지만, 코드 변경 배포는 사이트 전체를 깨뜨릴 수 있습니다. 성격이 다른 두 위험을 한 승인 절차로 묶어 둔 탓에 병목이 생겼습니다. 대신 발행 전 품질 책임은 전부 자동화 쪽에 남습니다. 글이 판매 중인 서비스와 맞는지, 외부 시세·통계를 지어내지 않았는지, 매출이나 수익을 보장하는 문장이 없는지를 발행 전에 확인해야 하고, 그중 가격 노출은 빌드 단계의 검사 스크립트가 막습니다.
다시 재 보니 무엇이 달라졌나?
발행 쪽 숫자는 바로 움직였습니다. 검사 통과 주제 묶음은 4개에서 14개로 늘었고, 새 기준의 첫 편이 나가며 리포트는 47편에서 48편, 이어 두 번째 편으로 49편이 됐습니다. 결정 후 3주가 지난 8월 17일에는 리포트가 102편이었습니다.
새 기준으로 나간 첫 두 편의 주제도 달라졌습니다. 첫 편은 홈페이지 제작 업체를 고르는 법, 두 번째 편은 AI로 자동화할 업무를 고르는 법이었습니다. 둘 다 서비스를 사려는 사람이 실제로 묻는 질문이고, 글 하단 버튼이 해당 서비스 페이지로 바로 이어집니다.
검색 쪽 숫자는 아직 답을 주지 않았습니다. 8월 7일에 Google Search Console 28일 기준으로 재 보니 서비스 페이지의 검색 클릭은 0이었습니다. 그런데 이 0이 글이 안 읽혀서인지, 읽혔는데 서비스 페이지로 넘어가는 버튼을 안 눌러서인지 가를 방법이 없었습니다.
원인은 GA4 설정이었습니다. 서비스 페이지는 같은 도메인의 서브도메인에 있는데, 사이트 간 세션을 잇기 위해 같은 도메인 서브도메인 링크를 외부 클릭 계측에서 일부러 빼 두었습니다. 그 설계 자체는 옳았으므로 건드리지 않고, 글 속 버튼 쪽에 계측 속성을 달았습니다. 리포트 상세의 버튼 2개와 인사이트 상세의 버튼 3개에 「<주제>→<서비스>:<자리>」 꼴의 GA4 이벤트 라벨을 붙였습니다.
버튼마다 연결된 서비스를 판매 서비스 목록과 대조하는 회귀 테스트도 함께 세웠습니다. 첫 실행에서 판매를 접은 서비스로 연결된 버튼이 6편에서 나왔습니다. 방향을 바꾼 뒤에도 옛 연결이 글 속에 남아 있었던 셈입니다.
편수가 늘며 생긴 부작용도 재측정에서 드러났습니다. 리포트 하단의 관련 글 목록이 자기 자신을 뺀 전체를 나열하는 구조였습니다. 52편일 때는 눈에 덜 띄었지만 102편이 되자 한 페이지에서 내부 링크 101개가 나갔습니다. 링크 권위가 고르게 흩어지고 어느 글이 중요한지 신호가 사라지는 구조라, 관련도 점수로 6편과 허브 1개만 가리키도록 바꿨습니다.
관련도 점수는 같은 판매 서비스 분류면 +3, 같은 주제 섹션이면 +2, 겹치는 태그 1개당 +1입니다. 바꾼 뒤 빌드한 914페이지에서 리포트 102편 모두 관련 링크가 최대 7개였고, 새 테스트 12개가 이 동작을 고정합니다.
같은 작업에서 주제 뱃지도 고쳤습니다. 첫 렌더에서 부가세 글에 「AI 업무 자동화」 뱃지가 붙어 나왔습니다. 뱃지가 판매 서비스 분류를 그대로 찍었는데, 세무·노무 글은 연결된 서비스가 없어 기본값으로 채워지기 때문이었습니다. 뱃지는 판매 서비스가 아니라 글의 주제를 찍도록 따로 계산하게 바꿨고, AI 전환 섹션 55편은 홈페이지·챗봇·블로그로 나뉘어 표시됩니다.
검토하고 버린 대안은 무엇이었나?
방향을 정하는 동안 버린 대안이 여럿 있었습니다. 대부분 당장 손이 덜 가는 길이었고, 그래서 버린 이유를 남겨 둡니다.
- 모든 서비스에 고루 발행하기 — 버렸습니다. 분산의 결과가 이미 817편, 100위 안 0종으로 나와 있었습니다.
- 구매 의도 검색어로 페이지 대량 생성 — 버렸습니다. 검색어가 동의어라 도어웨이 페이지 구조가 되고, 후보 6개 검색어를 합쳐도 월 120회였습니다.
- 관련 글 101개를 접기·더보기로 감추기 — 버렸습니다. 화면에서만 가려질 뿐 문서 안에는 링크 101개가 그대로 남아 링크 희석이 하나도 줄지 않습니다.
- 관련 글을 무작위 N편으로 고르기 — 버렸습니다. 빌드할 때마다 결과가 달라져 정적 생성과 색인에 불리하고, 회귀 테스트를 세울 수 없습니다.
- 관련 글을 태그만으로 고르기 — 버렸습니다. 태그 품질은 검증한 적이 없고, 판매 서비스 분류는 판매 서비스 목록과 물려 있어 이미 믿을 만했습니다.
- GA4의 서브도메인 제외 규칙에 서비스 페이지만 예외로 넣기 — 버렸습니다. 세션 연결 기능과 클릭 계측 목적이 한 규칙에 섞여 회귀 위험이 큽니다.
- 별도 분석 도구를 새로 들이기 — 버렸습니다. GA4가 주 계측 도구인 상태에서 도구를 하나 더 붙이면 계측이 이중으로 갈라지고 고정비도 늘어납니다.
버린 대안에는 공통점이 있습니다. 증상이 보이는 자리만 덮고, 증상을 만든 구조는 그대로 둡니다. 접기·더보기가 대표적입니다. 사람 눈에는 목록이 짧아지지만 검색 엔진이 읽는 문서에서는 아무것도 바뀌지 않습니다.
남는 한계는 무엇인가?
첫째, 질문 갈래의 재료가 아직 깨끗하지 않습니다. 발행 대기열 23건 가운데 판매 서비스와의 연결이 헐거운 주제가 섞여 있습니다. 질문 목록의 출처가 원래 지식iN 답변 활동용으로 모은 기록이라, 발행 전에 사람이 1차로 골라내야 합니다.
둘째, 순위 효과는 아직 확인하지 못했습니다. 이 글이 보여 주는 개선은 발행 쪽 숫자이고, 검색 유입 쪽 숫자는 서비스 페이지 클릭 0에 머물러 있습니다. 버튼 계측을 붙인 뒤 다음 4주 판정 주기부터 「노출은 있는데 안 눌림」과 「노출 자체가 없음」을 가를 수 있습니다.
셋째, 발행 절차에서 한 번 틀린 가정이 있었습니다. 처음에는 콘텐츠 커밋과 코드 커밋을 커밋 단위로 나누면 콘텐츠만 승인 없이 나갈 수 있다고 적었습니다. 그런데 git push는 브랜치 단위로 나갑니다. 승인을 기다리던 가격 검사 코드 커밋이 메인 브랜치에 먼저 쌓여 있었고, 그 뒤의 세 번째 글이 함께 묶여 대기했습니다. 지금 규칙은 승인 전 코드를 메인 브랜치에 쌓지 않는 쪽으로 바뀌었습니다.
넷째, 관련 글 6편이 같은 분류로만 채워지면 주제 사이를 오가는 길이 줄어듭니다. 홈페이지 글에서 세무 글로 넘어가는 경로가 사라지는 식입니다. 전체 목록의 역할은 허브 페이지와 상단 메뉴에 맡겼고, 허브가 막히면 글 사이 이동이 좁아진다는 약점은 그대로 남아 있습니다.
다섯째, 버튼 이벤트 라벨 형식이 사실상 계측 스키마가 됐습니다. 앞으로 글에 버튼을 더할 때마다 이 형식을 지켜야 하고, 한 곳이라도 어긋나면 그 버튼의 클릭은 집계에서 조용히 빠집니다. 지금 회귀 테스트가 보는 쪽은 버튼이 판매 중인 서비스로 이어지는지입니다. 사람이 손으로 붙이는 버튼이 늘수록 라벨 형식을 지키는 부담도 함께 늘어납니다.
프로그래매틱 SEO를 검토한다면 무엇부터 세어야 하나?
이번 일에서 얻은 교훈은 하나입니다. 프로그래매틱 SEO의 가능성은 템플릿이나 설비가 아니라, 템플릿에 부을 서로 다른 사실이 몇 개인지로 정해집니다. 우리는 기업 21,961곳이 있던 쪽에서는 770페이지를 만들었고, 검색어 72종만 있던 쪽에서는 6페이지가 상한이었습니다.
설비가 이미 있다는 사실은 오히려 판단을 흐립니다. 한 번 잘 돌아간 방식은 다음 문제에도 맞을 것처럼 보이기 쉽기 때문입니다. 비슷한 계획을 검토한다면 설비 이야기는 뒤로 미루고, 아래 순서로 먼저 세어 보기를 권합니다.
- 페이지마다 다른 내용을 채울 데이터가 몇 건인지 셉니다. 검색어 목록은 데이터가 아닙니다.
- 검색어를 검색하는 사람이 원하는 답 기준으로 묶고, 묶음이 몇 개 남는지 셉니다.
- 남은 묶음을 담을 페이지가 이미 있는지 확인합니다. 있다면 새 페이지가 아니라 기존 페이지 보강이 답입니다.
- 후보 검색어의 월 검색량을 더해, 모두 1위를 해도 들어올 방문자 상한을 계산합니다.
- 같은 사이트에서 머리 키워드와 질문형 롱테일의 현재 순위를 나란히 놓고 비교합니다.
홈페이지나 콘텐츠를 운영하면서 글은 쌓이는데 검색 유입이 붙지 않아 고민이라면, 무엇부터 세어 볼지 함께 정리해 드릴 수 있습니다. 상황은 상담으로 알려 주세요.