← 목록으로

cue SEO/GEO 가설 원장 — 던져놓은 그물

이 파일의 용도: SEO 조치는 즉시 효과가 안 난다. 그래서 "무엇을 했고 → 무엇이 될 거라 봤고
→ 언제 어디서 확인하고 → 실제로 어떻게 됐는지"를 한 곳에 적는다.
며칠 뒤 "그거 어떻게 됐어?" 라고 물으면 이 파일을 읽고 답한다.

🚫 결과 칸을 비워두고 넘어가지 마라. 틀린 가설은 틀렸다고 적는 게 이 문서의 값이다.
🚫 새 조치를 하면서 여기 안 적으면, 나중에 뭐 때문에 좋아졌는지 영영 모른다.

자동 측정: node scripts/gsc.mjs (키 필요) · python3 ~/bin/seo_check.py --live --domain cue.the-moment.us --pages 1


0. 출발점 — 2026-08-28 09:40 GSC 실측

이게 기준선이다. 앞으로 모든 비교는 이 숫자와 한다.

지표
색인 생성됨 0
색인 안 됨 620
├ 발견됨 - 크롤 안 됨 609
└ 크롤링됨 - 색인 안 됨 11
총 클릭수(28일) 0
총 노출수(28일) 0
사이트맵 마지막 읽음 2026-08-15 (13일 전)
구글의 마지막 크롤 2026-07-19 (40일 전)

⚠️ GSC 페이지 리포트는 며칠~일주일 지연된다(이 화면의 "최종 업데이트: 26.8.21").
오늘 한 조치가 이 표에 나타나려면 빨라도 9월 초다. 매일 들여다볼 이유가 없다.

크롤된 11개 = / · /jobs · /playbook · /prep · /role · /company/{naver,kakao,coupang,toss,daangn}
→ 전부 핵심 허브. 7/19에 한 번 보고 "색인 가치 없음" 판정.

홈 URL 검사 결과 (진단의 핵심):

크롤링 허용: 예 · 페이지 가져오기: 성공 · 색인 생성 허용: 예
참조 사이트맵: 감지된 참조 사이트맵이 없습니다
참조 페이지: https://mark.the-moment.us/병원-로고/

기술적 장벽 0. robots도 리다이렉트도 오류도 아니다. 순수하게 "크롤할 이유가 없다"는 판단이다.
→ 그리고 구글이 홈을 사이트맵이 아니라 mark 사이트 링크를 타고 발견했다.


1. 가설 — 무엇을 왜 했고, 뭐가 될 거라 보나

H1. 고아 페이지가 "발견됨-크롤 안 됨 609"의 주원인이다 🔴 최우선

근거(리서치): "사이트맵에 있지만 내부 링크가 0인 페이지가 Discovered 큐에 갇히는 1순위다.
사이트맵은 발견만 시키고, 크롤 우선순위는 내부 링크가 정한다." (Onely)

실측(2026-08-28):

/jobs 허브 → /job/ 링크  0개   ← 목록을 전부 JS 로 그려서 봇에겐 빈 페이지
sitemap /job/  495개 · 내부링크 도달 112개
고아 383개 (77%)

조치: /jobs 에 495장 전부를 서버 HTML 로 구움(sync-seo.mjs bakeJobs).
홈에도 12장 + 회사칩 10개(bakeHome). 배포 후 재측정 → 고아 0개 (0%)

예상: 609개가 "발견됨"에서 빠져나와 크롤되기 시작한다.
확인: GSC → 페이지 → "발견됨 - 현재 색인이 생성되지 않음" 숫자
언제: 2~4주 (리서치 기준: 조치 후 2~4주 내 변화)
언제까지 안 변하면 틀린 것: 4주(2026-09-25) 뒤에도 609가 그대로면 H1은 틀렸고, 원인은 크롤 예산이 아니라 도메인 단위 품질 신호다 → H5 로 간다

확인일 발견됨 크롤됨-미색인 색인됨 판정
2026-08-28 (기준) 609 11 0
2026-09-04
2026-09-11
2026-09-25

H2. 7/19에 받은 "색인 가치 없음" 판정은 그때 페이지가 빈약해서다

근거: 크롤된 11개는 전부 기술적으로 정상(가져오기 성공·색인 허용 예)인데 색인이 안 됐다.
= 구글이 내용을 보고 뺐다는 뜻. 7/19 당시 그 페이지들의 상태:

페이지 7/19 당시 지금
/ 공고 목록이 JS 렌더 → 봇에게 0 851건·10개사·카드 12장 서버 렌더
/jobs JSON-LD 0건 · 목록 JS 렌더 CollectionPage + 495장 서버 렌더
/playbook·글 40편 author=회사 · 날짜 없음 Person 박진이 + 발행일 + 화면 바이라인
/prep·/role 얇음 그대로(추가 조치 없음)
sitemap lastmod 0개 · 301 되는 /blog 제출 lastmod 519개 · /insights 정상

예상: 재크롤되면 판정이 뒤집힌다. 특히 홈과 /jobs.
확인: GSC URL 검사에서 / 의 "최근 크롤링" 날짜가 7/19에서 바뀌는가 → 바뀌고도 미색인이면 H2 틀림
언제: 홈은 색인 요청을 넣었으므로 3~10일

확인일 / 최근 크롤링 / 색인 여부 판정
2026-08-28 (기준) 2026-07-19 미색인
2026-09-04

H3. 사이트맵 재제출 + lastmod 가 재크롤을 부른다

근거: 구글은 lastmod 로 재방문 우선순위를 정한다. 우리는 0개였다 = "바뀐 게 있다"는 신호를 준 적이 없다.
조치(2026-08-28): lastmod 519개 부여 + GSC 에서 사이트맵 재제출 → 읽음 날짜 8/15 → 8/28, 발견 619 → 611
예상: 다음 읽기 간격이 13일보다 짧아진다.
확인: GSC → Sitemaps → "마지막으로 읽은 날짜"
틀렸다고 볼 조건: 3주(9/18) 뒤에도 8/28에 멈춰 있으면 lastmod 는 이 도메인에 안 먹는다

확인일 마지막 읽음 간격 판정
2026-08-28 (기준) 2026-08-28
2026-09-11

H4. 색인 API 가 609개를 뚫는 유일한 지렛대다 🔑 미실행

근거: IndexNow 는 빙·네이버·얀덱스 전용 — 구글엔 한 통도 안 간다. 수동 색인요청은 하루 1~2건이 한계
(2026-08-28 실측: 홈 1건 성공, /insights 2건째에서 "오류 발생" = 할당량).
구글 색인 API 는 JobPosting 구조화 데이터 페이지에 공식 허용이고 우리 /job/* 495장이 정확히 해당. 일 200건.

상태: 🔴 미실행.gindex-sa.json 키 없음. 매 크롤마다 sent=0.
막힌 이유: GCP 콘솔 + GSC 소유자 추가는 사람의 구글 계정 권한이라 내가 못 한다.
절차: scripts/GINDEX_SETUP.md (10분)
예상: 495장이 크롤 큐에 직접 들어가 H1 의 2~4주를 수일로 줄인다.
같은 키가 여는 두 번째 문: node scripts/gsc.mjs — 색인 현황을 사람 없이 읽는다.
확인: node scripts/gindex.mjs --allsent=200 ok=true

확인일 키 있음 sent 판정
2026-08-28 0 미실행

H5. 크롤 예산을 수명 15일짜리에 81% 쓰고 있다 (재정의됨 · 근거 확보 2026-08-28)

⚠️ 처음엔 "품질 신호 문제"라고 썼는데 H7 이 그걸 반증했다 — 네이버가 같은 공고 페이지를
색인했다. 품질이 문제면 네이버도 안 넣었을 것이다. 그래서 품질이 아니라 배분 문제로 다시 쓴다.

실측 근거 (마감된 공고 1,160건):

공고 수명 (게시→마감) 중앙값 15일 · 평균 23일
30일 이내 마감 78%
60일 이내 마감 93%
구글이 우리를 안 온 기간 40일

즉 구글이 지금 크롤하러 와도, sitemap 의 공고 상당수는 이미 죽어 있다.
크롤 → 색인 → 순위까지 보통 수 주가 걸리는데 공고는 그 전에 마감된다.
수명 15일짜리에 크롤 예산의 81% 를 태우는 구조다.

반대로 영속 자산은 17%뿐이다:

묶음 장수 sitemap 비중 수명
/job/* 495 81% 중앙값 15일 ☠️
/company/* (허브 10 + 회사×직군 39) 49 8% 영속 — 공고가 마감돼도 질문은 쌓인다
글 (/playbook 34 + /first-aid 6) 40 7% 영속
/role 9 + /prep 9 18 3% 영속

/company/{회사}/{직군} 39장이 진짜 자산인데 sitemap 비중이 6%다.
다이닝코드가 "영등포 맛집"으로 뜨는 것처럼, 우리 착지점은 개별 공고가 아니라
"쿠팡 PM 면접 예상질문" 이어야 한다. 개별 공고는 거기로 가는 재료지 착지점이 아니다.

🚫 지금 실행하지 않는다. H1(오늘 495장 전부에 내부 링크를 걸었다)과 정반대 방향이라
동시에 하면 서로 상쇄되고 뭐가 효과였는지 영원히 못 가린다. H1 판정(9/25) 이후에 판단한다.

H1이 틀렸을 때 실행할 것 (순서대로):
1. sitemap 에서 공고를 질문이 실제로 쌓인 것만 남긴다 — 나머지는 회사×직군 허브로 흡수
2. /company/{회사}/{직군} 39장을 늘린다 (지금 조합 커버리지가 낮다)
3. 글 40편을 늘린다 — 이미 하루 1편 자동 발행 중이라 시간이 해결한다


H6. 형제 사이트 링크 — 전제가 틀렸다. 실행 완료 (2026-08-28)

원래 가설: "형제 사이트에서 cue 로 링크를 걸면 크롤 경로가 생긴다."

실측 결과 — 링크는 이미 충분했다:

사이트 sitemap 표본 중 cue 링크 있는 페이지
apex 32장 12/12
mark 778장 12/12
notes 49장 12/12

860페이지가 이미 cue 를 가리키고 있었다. 🔴 그런데 전부 홈(/)으로만 갔다.
홈은 이미 크롤됐고(7/19), 깊은 페이지로 가는 경로가 0 이었다.
문제는 링크 가 아니라 어디로 가느냐 였다.

조치: products.jsondeeplinks 필드를 만들고(전 제품이 쓰는 장치, cue 전용 땜질 아님)
apex 제품 페이지에서 cue 깊은 링크 4개를 걸었다 — /companies · /jobs · /insights · /pricing.

부수 발견: /pricing 이 200 인데 우리 sitemap 에 없었다. apex 가 거기로 링크하는데
정작 우리가 제출을 안 하고 있었다. sitemap 추가 + Product/Offer 스키마를 넣었다.

예상: 형제 사이트는 이미 크롤되므로, 그 링크를 타고 cue 깊은 페이지에 크롤이 흐른다.
확인: GSC URL 검사에서 /companies·/jobs 의 "참조 페이지"에 apex 가 뜨는가
언제: 2~3주 (apex 재크롤이 먼저 일어나야 한다)
주의: 🚫 상호링크를 남발하지 마라 — 문맥에 맞는 자리에만. 지금 4개가 상한이라고 본다.

확인일 /companies 참조 페이지 판정
2026-08-28 (기준) 없음
2026-09-11

H7. 구글 0개는 콘텐츠 문제가 아니다 — 검증됨 (2026-08-28)

검증 방법: 같은 페이지를 다른 엔진이 색인했는지 본다.

엔진 결과
구글 0개
네이버 최소 10 URL — 홈·/about·/companies·/jobs·/spike·/prep + 글 2편 + 공고 1건
0개

네이버가 우리 글과 공고 페이지까지 색인했다. 같은 HTML·같은 스키마·같은 본문이다.
콘텐츠는 무죄. 구글 0개의 원인은 페이지 품질이 아니라 도메인 단위 크롤 수요다.
→ H1(내부 링크)·H4(색인 API)의 중요도가 올라가고, "페이지를 더 다듬는다"는 우선순위가 내려간다.

부수 발견: 빙이 0인데 IndexNow 는 매 크롤 ok=true 를 찍는다.
핑이 갔다 ≠ 받아들여졌다. 빙은 ChatGPT 검색 백엔드라 GEO 와 직결된다.

할 것 (사람): 빙 웹마스터 계정 개설(5분, GSC 가져오기 지원) · 네이버 서치어드바이저 상태 확인


2. 이미 확인된 사실 (가설 아님)

🚨 이 대비가 이 문서의 존재 이유다. 점검기 통과는 "구글이 안 뺄 이유"를 만든 것이지
"구글이 올 이유"를 만든 게 아니다. 오게 만드는 건 내부 링크와 색인 API 다.


3. 다음 확인 (2026-09-04)

# 1) 자동 (키가 있으면)
cd ~/Projects/cue && node scripts/gsc.mjs

# 2) 수동 — GSC 화면
#    https://search.google.com/search-console/index?resource_id=sc-domain%3Acue.the-moment.us
#    → 색인 생성됨 / 발견됨 / 크롤됨 세 숫자를 위 표에 적는다
#    → URL 검사에 https://cue.the-moment.us/ → "최근 크롤링" 날짜 확인

# 3) 고아 재발 여부 (공고가 늘면 다시 생길 수 있다)
python3 ~/bin/seo_check.py --live --domain cue.the-moment.us --pages 1